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

Rework channel_reestablish requirements #1051

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

Rework channel_reestablish requirements #1051

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
17dab63
Properly align statements
t-bast Jan 11, 2023
1a0d592
Merge last section in previous ones
t-bast Jan 11, 2023
e46fd42
Rework `channel_reestablish` error cases
t-bast Jan 11, 2023
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
127 changes: 59 additions & 68 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1398,25 +1398,31 @@ A node:
- MUST handle continuation of a previous channel on a new encrypted transport.
- upon disconnection:
- MUST reverse any uncommitted updates sent by the other side (i.e. all
messages beginning with `update_` for which no `commitment_signed` has
been received).
messages beginning with `update_` for which no `commitment_signed` has
been received).
- Note: a node MAY have already used the `payment_preimage` value from
the `update_fulfill_htlc`, so the effects of `update_fulfill_htlc` are not
completely reversed.
the `update_fulfill_htlc`, so the effects of `update_fulfill_htlc` are not
completely reversed.
- MUST NOT assume that previously-transmitted messages were lost.
- if it has sent a previous `commitment_signed` message:
- MUST handle the case where the corresponding commitment transaction is
broadcast at any time by the other side.
- Note: this is particularly important if the node does not simply
retransmit the exact `update_` messages as previously sent.
- upon reconnection:
- if a channel is in an error state:
- SHOULD retransmit the error packet and ignore any other packets for
that channel.
that channel.
- otherwise:
- MUST transmit `channel_reestablish` for each channel.
- MUST wait to receive the other node's `channel_reestablish`
message before sending any other messages for that channel.

The sending node:
- MUST set `next_commitment_number` to the commitment number of the
next `commitment_signed` it expects to receive.
next `commitment_signed` it expects to receive.
- MUST set `next_revocation_number` to the commitment number of the
next `revoke_and_ack` message it expects to receive.
next `revoke_and_ack` message it expects to receive.
- if `option_static_remotekey` applies to the commitment
transaction:
- MUST set `my_current_per_commitment_point` to a valid point.
Expand All @@ -1429,74 +1435,59 @@ The sending node:
- otherwise:
- MUST set `your_last_per_commitment_secret` to the last `per_commitment_secret` it received

A node:
- if `next_commitment_number` is 1 in both the `channel_reestablish` it
sent and received:
- MUST retransmit `channel_ready`.
- otherwise:
- MUST NOT retransmit `channel_ready`, but MAY send `channel_ready` with
a different `short_channel_id` `alias` field.
- upon reconnection:
- MUST ignore any redundant `channel_ready` it receives.
- if `next_commitment_number` is equal to the commitment number of
the last `commitment_signed` message the receiving node has sent:
- MUST reuse the same commitment number for its next `commitment_signed`.
- otherwise:
- if `next_commitment_number` is not 1 greater than the
commitment number of the last `commitment_signed` message the receiving
node has sent:
- SHOULD send an `error` and fail the channel.
- if it has not sent `commitment_signed`, AND `next_commitment_number`
is not equal to 1:
- SHOULD send an `error` and fail the channel.
- if `next_revocation_number` is equal to the commitment number of
the last `revoke_and_ack` the receiving node sent, AND the receiving node
hasn't already received a `closing_signed`:
- MUST re-send the `revoke_and_ack`.
- if it has previously sent a `commitment_signed` that needs to be
retransmitted:
- MUST retransmit `revoke_and_ack` and `commitment_signed` in the same
relative order as initially transmitted.
- otherwise:
- if `next_revocation_number` is not equal to 1 greater than the
commitment number of the last `revoke_and_ack` the receiving node has sent:
- SHOULD send an `error` and fail the channel.
- if it has not sent `revoke_and_ack`, AND `next_revocation_number`
is not equal to 0:
- SHOULD send an `error` and fail the channel.

A receiving node:
- if `option_static_remotekey` applies to the commitment transaction:
- if `next_revocation_number` is greater than expected above, AND
`your_last_per_commitment_secret` is correct for that
`next_revocation_number` minus 1:
The receiving node:
- if `next_revocation_number` is greater than the commitment number of the
last `commitment_signed` message the receiving node has sent:
- if `your_last_per_commitment_secret` is correct for that
`next_revocation_number` minus 1:
- MUST NOT broadcast its commitment transaction.
- 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 send an `error` and fail the channel.
- otherwise, if it supports `option_data_loss_protect`:
- if `next_revocation_number` is greater than expected above, AND
`your_last_per_commitment_secret` is correct for that
`next_revocation_number` minus 1:
- MUST NOT broadcast its commitment transaction.
- SHOULD store `my_current_per_commitment_point` to retrieve funds
should the sending node broadcast its commitment transaction on-chain.
- Note: the sending node proved that the receiving node has lost data.
- otherwise (`your_last_per_commitment_secret` is incorrect):
- 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`
do not match the expected values):
- SHOULD send an `error` and fail the channel.

A node:
- MUST NOT assume that previously-transmitted messages were lost,
- if it has sent a previous `commitment_signed` message:
- MUST handle the case where the corresponding commitment transaction is
broadcast at any time by the other side,
- Note: this is particularly important if the node does not simply
retransmit the exact `update_` messages as previously sent.
- upon reconnection:
- Note: the receiving node may or may not have lost data, but it
cannot be sure based on the data provided by the sending node.
- if the commitment number of the last `commitment_signed` message the
receiving node has sent is greater than `next_revocation_number` plus 1:
- MUST NOT broadcast its commitment transaction.
- SHOULD wait for the sending node to send an `error` or reconnect.
- Note: the sending node seems to have lost data.
- if `next_commitment_number` is greater than the commitment number of the
last `commitment_signed` message the receiving node has sent plus 1:
- 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.
- Note: the receiving node may or may not have lost data.
- if `next_commitment_number` is smaller than the commitment number of the
last `commitment_signed` message the receiving node has sent:
- MUST NOT broadcast its commitment transaction.
- SHOULD wait for the sending node to send an `error` or reconnect.
- Note: the sending node seems to have lost data.
- otherwise:
- if `next_commitment_number` is 1 in both the `channel_reestablish` it
sent and received:
- MUST retransmit `channel_ready`.
- otherwise:
- MUST NOT retransmit `channel_ready`, but MAY send `channel_ready` with
a different `short_channel_id` `alias` field.
- MUST ignore any redundant `channel_ready` it receives.
- if it has sent a previous `shutdown`:
- MUST retransmit `shutdown`.
- if `next_commitment_number` is equal to the commitment number of the
last `commitment_signed` message the receiving node has sent:
- MUST reuse the same commitment number for its next `commitment_signed`.
- if `next_revocation_number` is equal to the commitment number of the
last `revoke_and_ack` the receiving node sent, AND the receiving node
hasn't already received a `closing_signed`:
- MUST re-send the `revoke_and_ack`.
- if it has previously sent a `commitment_signed` that needs to be
retransmitted:
- MUST retransmit `revoke_and_ack` and `commitment_signed` in the same
relative order as initially transmitted.

### Rationale

Expand Down