Feature 106/107: option_simplified_update. #867
Draft
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
This feature turns on a simplification of the current update scheme: 1. Turns are taken, with all updates settling before switching sides. 2. update_fee is always a separate commitment by itself. This is a fairly easy addition for existing implementations, but a much-reduced burden for new implementations. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add update_noop, clean up whitespace and mark option requirements on yield msg.
1. Clarify what happens when optimistic implementation reconnects. 2. Assume we use quiescence for channel feature upgrade, so no complex reestablishment handling
21 tasks
19 tasks
21 tasks
18 tasks
17 tasks
17 tasks
19 tasks
23 tasks
22 tasks
20 tasks
23 tasks
instagibbs
reviewed
Apr 28, 2022
| - During this node's turn: | ||
| - if it receives an update message or `commitment_signed`: | ||
| - if it has sent its own update or `commitment_signed`: | ||
| - MUST ignore the message |
There was a problem hiding this comment.
the remote node sends a commitment_signed during the local node's turn, after the local node has sent a commitment_signed message though? diagram, step (5) and the response (6)...
22 tasks
instagibbs
reviewed
May 6, 2022
| @@ -1119,6 +1232,8 @@ given in [BOLT #3](03-transactions.md#fee-calculation). | |||
| The node _responsible_ for paying the Bitcoin fee: | |||
| - SHOULD send `update_fee` to ensure the current fee rate is sufficient (by a | |||
| significant margin) for timely processing of the commitment transaction. | |||
| - if `option_simplified_update` is negotiated: | |||
| - MUST NOT mix `update_fee` with other updates in the same commitment. | |||
There was a problem hiding this comment.
does this mean any other updates, including other update_fee messages in same turn, or just update_fee vs all other update types?
There was a problem hiding this comment.
Good q! I think it means the former, but should be more explicit!
23 tasks
24 tasks
24 tasks
25 tasks
25 tasks
25 tasks
27 tasks
27 tasks
26 tasks
26 tasks
30 tasks
28 tasks
27 tasks
25 tasks
This was referenced Aug 22, 2023
24 tasks
24 tasks
22 tasks
20 tasks
20 tasks
20 tasks
20 tasks
21 tasks
19 tasks
22 tasks
21 tasks
21 tasks
21 tasks
21 tasks
22 tasks
25 tasks
23 tasks
23 tasks
22 tasks
23 tasks
22 tasks
23 tasks
21 tasks
20 tasks
This was referenced Sep 6, 2024
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.
This feature turns on a simplification of the current update scheme:
This is a fairly easy addition for existing implementations, but
a much-reduced burden for new implementations.