Skip to content
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

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

rustyrussell
Copy link
Collaborator

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.

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
- 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
Copy link
Contributor

@instagibbs instagibbs Apr 28, 2022

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.
Copy link
Contributor

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?

Copy link
Collaborator Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants