Skip to content

Commit

Permalink
Add changes from lightning#932
Browse files Browse the repository at this point in the history
It was decided in the spec meeting to combine lightning#932 and lightning#942 as they are
closely related. It was also decided to add a rationale for lightning#932 to clearly
state why nodes must wait for an error before force-closing instead of
eagerly force-closing when detecting that their peer is behind.
  • Loading branch information
t-bast committed Jan 4, 2022
1 parent fdd791a commit ae2d1e9
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 21 deletions.
29 changes: 15 additions & 14 deletions 02-peer-protocol.md
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.
- 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 Expand Up @@ -1466,18 +1466,19 @@ Similarly, for the fundee's `funding_signed` message: it's better to
remember a channel that never opens (and times out) than to let the
funder open it while the fundee has forgotten it.

`option_data_loss_protect` was added to allow a node, which has somehow fallen behind
(e.g. has been restored from old backup), to detect that it's fallen-behind. A fallen-behind
node must know it cannot broadcast its current commitment transaction — which would lead to
total loss of funds — as the remote node can prove it knows the
revocation preimage. The error returned by the fallen-behind node
(or simply the invalid numbers in the `channel_reestablish` it has
sent) should make the other node drop its current commitment
transaction to the chain. This will, at least, allow the fallen-behind node to recover
non-HTLC funds, if the `my_current_per_commitment_point`
is valid. However, this also means the fallen-behind node has revealed this
fact (though not provably: it could be lying), and the other node could use this to
broadcast a previous state.
`option_data_loss_protect` was added to allow a node, which has somehow fallen
behind (e.g. has been restored from old backup), to detect that it has fallen
behind. A fallen-behind node must know it cannot broadcast its current
commitment transaction — which would lead to total loss of funds — as the
remote node can prove it knows the revocation preimage. The `error` returned by
the fallen-behind node should make the other node drop its current commitment
transaction to the chain. The other node should wait for that `error` to give
the fallen-behind node an opportunity to fix its state first (e.g by restarting
with a different backup). If the fallen-behind node doesn't have the latest
backup, this will, at least, allow it to recover non-HTLC funds, if the
`my_current_per_commitment_point` is valid. However, this also means the
fallen-behind node has revealed this fact (though not provably: it could be lying),
and the other node could use this to broadcast a previous state.

`option_static_remotekey` removes the changing `to_remote` key,
so the `my_current_per_commitment_point` is unnecessary and thus
Expand Down
13 changes: 6 additions & 7 deletions 05-onchain.md
Original file line number Diff line number Diff line change
Expand Up @@ -143,15 +143,14 @@ A node:
sufficient fee:
- SHOULD use this fee to perform a *mutual close*.
- otherwise:
- if the node knows or assumes its channel state is outdated it
- MUST NOT broadcast its *last commitment transaction*.
- SHOULD send an `error`.
- if the node knows or assumes its channel state is outdated:
- MUST NOT broadcast its *last commitment transaction*.
- otherwise:
- MUST broadcast the *last commitment transaction*, for which it has a
signature, to perform a *unilateral close*.
- MUST spend any `to_local_anchor` output, providing sufficient fees as incentive to include the commitment transaction in a block
Special care must be taken when spending to a third-party, because this re-introduces the vulnerability that was
addressed by adding the CSV delay to the non-anchor outputs.
signature, to perform a *unilateral close*.
- MUST spend any `to_local_anchor` output, providing sufficient fees as incentive to include the commitment transaction in a block.
Special care must be taken when spending to a third-party, because this re-introduces the vulnerability that was
addressed by adding the CSV delay to the non-anchor outputs.
- SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) or other mechanism on the spending transaction if it proves insufficient for timely inclusion in a block.

## Rationale
Expand Down

0 comments on commit ae2d1e9

Please sign in to comment.