Skip to content

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)...

- 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