BOLT 2: allow more leniancy with forks during channel establishment.#77
Merged
rustyrussell merged 2 commits intoJan 13, 2017
Merged
Conversation
Christoper points out that two nodes with aggressive minimum-depth settings may see different blocks and the protocol requires they close the channel since their funding_locked messages will disagree. This can also happen when only one side has an aggressive minimum-depth setting: if it sends funding_locked referring to a block which is orphaned, it can't update it. There are three changes here, two optional. - Allow sending of an updated funding_locked. This fixes this case where one side is on an orphan and uses a v. low minimum-depth. - Require accepting of an updated funding_locked. - Allow waiting instead of immediate failure if funding_lock disagrees. eg. you might wait another block or two to see if one side reorgs. Reported-by: Christopher Jämthagen Closes: lightning#73 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
cdecker
reviewed
Jan 7, 2017
| received. The sender MUST set `next-per-commitment-point` to the | ||
| it MAY fail the channel if its own `channel-id` does not match the | ||
| received: otherwise it MUST ignore the `funding_locked` message. | ||
| The sender MAY re-transmit `funding_locked` if the `channel-id` changes. |
Collaborator
There was a problem hiding this comment.
I think we also need to specify that a node MUST retransmit the funding_locked message if the channel-id changes, otherwise we may never make progress. If both nodes silently drop the funding_locked message, but never issue send the changed channel-id then we just sit there and wait forever. This may also include sending a funding_locked at a bigger depth than what we were waiting for.
Collaborator
Author
There was a problem hiding this comment.
I think we can fix this by tying the two together: If either node chooses to ignore, it must re-transmit when it changes. Because if either node is doing the naive "fail on disagree" it will have failed.
Otherwise we'd deadlock until one side timed out. Reported-by: Christian Decker <decker.christian@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
cdecker
approved these changes
Jan 11, 2017
Collaborator
|
ACK 83e04bf |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Christoper points out that two nodes with aggressive minimum-depth settings
may see different blocks and the protocol requires they close the channel
since their funding_locked messages will disagree.
This can also happen when only one side has an aggressive minimum-depth
setting: if it sends funding_locked referring to a block which is orphaned,
it can't update it.
There are three changes here, two optional.
one side is on an orphan and uses a v. low minimum-depth.
eg. you might wait another block or two to see if one side reorgs.
Reported-by: Christopher Jämthagen
Closes: #73
Signed-off-by: Rusty Russell rusty@rustcorp.com.au