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.

Sign up for GitHub

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

Clarify and relax requirements on channel_reestablish #932

Closed
wants to merge 1 commit into from
Closed

Clarify and relax requirements on channel_reestablish #932

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.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1381,7 +1381,7 @@ A node:
`your_last_per_commitment_secret` is correct for that
`next_revocation_number` minus 1:
- MUST NOT broadcast its commitment transaction.
Copy link
Contributor

Choose a reason for hiding this comment

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

as @rustyrussell mentioned and according to BOLT 1 upon sending an error the node SHOULD fail the channel and failing usually means broadcasting the commitment transaction.

This situation seems a little bit paradox because obviously in this case the node does not want to / MUST NOT broadcast its commitment transaction and thus can't really fail the channel.

I wonder if this could also leave the node in a problematic situation indicating the peer that they may attempt to cheat? But I guess it can't be worse than the already existing situation.

- SHOULD fail the channel.
- SHOULD send an `error` to request the peer to fail the channel.
- otherwise:
- if `your_last_per_commitment_secret` does not match the expected values:
- SHOULD fail the channel.
Expand All @@ -1390,7 +1390,7 @@ A node:
`your_last_per_commitment_secret` is correct for that
`next_revocation_number` minus 1:
- MUST NOT broadcast its commitment transaction.
- SHOULD fail the channel.
- SHOULD send an `error` to request the peer to fail the channel.
- SHOULD store `my_current_per_commitment_point` to retrieve funds
should the sending node broadcast its commitment transaction on-chain.
- otherwise (`your_last_per_commitment_secret` or `my_current_per_commitment_point`
Expand Down