Drop the required channel_update in failure onions
#1163
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As noted previously, `channel_update`s in the onion failure packets are massive gaping fingerprintign vulnerabilities - if a node applies them in a publicly-visible way the err'ing node can easily identify the sender of an HTLC. While the updates are still arguably marginally useful for nodes to use in their pathfinding local to retires of the same payment, this too will eventually become an issue with PTLCs. Further, we shouldn't be letting nodes get away with delaying payments by failing to announce the latest channel parameters or enforcing new parameters too soon, so treating the node as having indicated insufficient liquidity (or other general failure) is appropriate in the general case. Thus, here, we begin phasing out the `channel_update` field, requiring nodes ignore it entirely and making it optional (though obviously nodes should still provide it for some time).
t-bast
reviewed
May 6, 2024
25 tasks
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
May 7, 2024
lightning/bolts#1163 makes the channel update in onion failures optional. One reason for this change is that it can be a privacy issue: by applying a `channel_update` received from an payment attempt, you may reveal that you are the sender. Another reason is that some nodes have been omitting that field for years (which was arguably a bug), and it's better to be able to correctly handle such failures.
23 tasks
valentinewallace
added a commit
to valentinewallace/rust-lightning
that referenced
this pull request
May 24, 2024
vincenzopalazzo
approved these changes
May 31, 2024
23 tasks
Roasbeef
reviewed
Jun 3, 2024
| @@ -1080,12 +1080,7 @@ The top byte of `failure_code` can be read as a set of flags: | |||
| * 0x8000 (BADONION): unparsable onion encrypted by sending peer | |||
| * 0x4000 (PERM): permanent failure (otherwise transient) | |||
| * 0x2000 (NODE): node failure (otherwise channel) | |||
| * 0x1000 (UPDATE): new channel update enclosed | |||
There was a problem hiding this comment.
+1 for this section, it's already optional today, but the spec still states it as being mandatory.
Roasbeef
reviewed
Jun 3, 2024
| - MAY treat the `channel_update` as invalid. | ||
| - otherwise: | ||
| - SHOULD apply the `channel_update`. | ||
| - MAY queue the `channel_update` for broadcast. |
There was a problem hiding this comment.
We can also remove just this line.
Roasbeef
reviewed
Jun 3, 2024
| - if `channel_update` should NOT have caused the failure: | ||
| - MAY treat the `channel_update` as invalid. | ||
| - otherwise: | ||
| - SHOULD apply the `channel_update`. |
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Jun 4, 2024
lightning/bolts#1163 makes the channel update in onion failures optional. One reason for this change is that it can be a privacy issue: by applying a `channel_update` received from an payment attempt, you may reveal that you are the sender. Another reason is that some nodes have been omitting that field for years (which was arguably a bug), and it's better to be able to correctly handle such failures.
22 tasks
23 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As noted previously,
channel_updates in the onion failure packets are massive gaping fingerprintign vulnerabilities - if a node applies them in a publicly-visible way the err'ing node can easily identify the sender of an HTLC.While the updates are still arguably marginally useful for nodes to use in their pathfinding local to retires of the same payment, this too will eventually become an issue with PTLCs. Further, we shouldn't be letting nodes get away with delaying payments by failing to announce the latest channel parameters or enforcing new parameters too soon, so treating the node as having indicated insufficient liquidity (or other general failure) is appropriate in the general case.
Thus, here, we begin phasing out the
channel_updatefield, requiring nodes ignore it entirely and making it optional (though obviously nodes should still provide it for some time).