-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature 106/107: option_simplified_update. #867
base: master
Are you sure you want to change the base?
Feature 106/107: option_simplified_update. #867
Conversation
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 <[email protected]>
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
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)...
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good q! I think it means the former, but should be more explicit!
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.