Navigation Menu

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

Jump to bottom

Demand revoke_and_ack before more updates #552

Closed
wants to merge 1 commit into from
Closed

Demand revoke_and_ack before more updates #552

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 6 additions & 0 deletions 02-peer-protocol.md
View file
Open in desktop
Expand Up @@ -953,6 +953,9 @@ fee changes).
to BIP69 lexicographic ordering of the commitment transaction.
- if it has not recently received a message from the remote node:
- SHOULD use `ping` and await the reply `pong` before sending `commitment_signed`.
- after sending a `commitment_signed` message:
- MUST ignore any `update` message from the other party before receiving the
`revoke_and_ack` that corresponds to the `commitment_signed` sent.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also clarify what happens if the counterparty continues to send updates. Should it queue them up? Should it fail the channel?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose that further update messages should be simply ignored. I've updated the text accordingly.


A receiving node:
- once all pending updates are applied:
Expand All @@ -978,6 +981,9 @@ offline until after sending `commitment_signed`. Once
those HTLCs, and cannot fail the related incoming HTLCs until the
output HTLCs are fully resolved.

Allowing a node to make more updates before receiving `revoke_and_ack` leaves the old
state unrevoked.

### Completing the Transition to the Updated State: `revoke_and_ack`

Once the recipient of `commitment_signed` checks the signature and knows
Expand Down