Removed requirement to broadcast an outdated commitment transaction #942
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
If a node has to fail a channel but knows that its latest commitment transaction is outdated it should not be required to send it but rather wait for the peer to unilaterally close the channel. The proposed solution is not so clean because it might produce a deadlock in which two peers assume they have outdated state and send `error` back and forth without actually force closing. Maybe in such a scenario we could create a protocol that mutually closes with split balance? Also replaced the word use with broadcast as it seems more accurate.
19 tasks
t-bast
reviewed
Dec 15, 2021
t-bast
added
the
clarification
21 tasks
Roasbeef
requested changes
Jan 3, 2022
05-onchain.md
Outdated
| - MUST use the *last commitment transaction*, for which it has a | ||
| - if the node knows or assumes its channel state is outdated it | ||
| - MUST NOT broadcast its *last commitment transaction*. | ||
| - SHOULD send an `error`. |
There was a problem hiding this comment.
Seems related to #932. I think this is a weird place to add this requirement as BOLT 2 is where we define the p2p interaction, while BOLT 5 so far has been reserved primarily for on chain interaction. In other words, this seems to sort of "breach" layers.
This was discussed during the latest dev call, with some inclination to sort of merge this and #932, remove this line (as it's in #932) and keep the rest of the diff.
There was a problem hiding this comment.
@lightning-developer I've prepared a commit on top of your branch that does this: t-bast@ae2d1e9
Can you cherry-pick it and update this PR? We can then include it and simply close #932.
There was a problem hiding this comment.
Done as requested.
|
This is already stated explicitly in reestablish, but probably worth mentioning here too, indeeed. |
t-bast
added a commit
to t-bast/bolts
that referenced
this pull request
Jan 4, 2022
It was decided in the spec meeting to combine lightning#932 and lightning#942 as they are closely related. It was also decided to add a rationale for lightning#932 to clearly state why nodes must wait for an error before force-closing instead of eagerly force-closing when detecting that their peer is behind.
18 tasks
It was decided in the spec meeting to combine lightning#932 and lightning#942 as they are closely related. It was also decided to add a rationale for lightning#932 to clearly state why nodes must wait for an error before force-closing instead of eagerly force-closing when detecting that their peer is behind.
t-bast
approved these changes
Jan 17, 2022
TheBlueMatt
approved these changes
Jan 17, 2022
t-bast
added a commit
to t-bast/bolts
that referenced
this pull request
Jan 10, 2023
There are conflicting requirements after applying lightning#942. The only case where a node should fail the channel when receiving an unexpected `channel_reestablish` is when the remote peer is provably lying by sending an invalid `your_last_per_commitment_secret`.
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.
Following the discussion at #932 and looking at the proposal of #834 I thought it might be good to clarify in BOLT 5 when a node MUST NOT (potentially SHOULD NOT) broadcast its own commitment transaction when failing the channel.
If a node has to fail a channel but knows that its latest commitment transaction is outdated it should not be required to send it but rather wait for the peer to unilaterally close the channel.
The proposed solution is not so clean because it might produce a deadlock in which two peers assume they have outdated state and send
errorback and forth without actually force closing. Maybe in such a scenario we could create a protocol that mutually closes with split balance?Also replaced the word use with broadcast as it seems more accurate.