mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-13 19:37:31 +01:00
Code Issues Projects Releases Wiki Activity

Do not unnecessarily retransmit commitment_signed in dual funding

Browse source 
On reconnection in the middle of the dual-funding flow, if both
nodes have exchanged the initial `commitment_signed` and node A
had sent its (initial) `tx_signatures` but node B never received
them, both nodes should send a `channel_reestablish` with
`next_funding_txid` set and a `next_commitment_number` of 1 (as
they've already received the commitment transaction for commitment
number 0).

The spec indicates in this case that both nodes should retransmit
their `commitment_signed`, however, as this is only gated on
`next_funding_txid` and not the `next_commitment_number` field.
This may cause implementations which assume that each new
`commitment_signed` is for a new state to fail and potentially
fail the channel.

Instead, we should rely both the presence of `next_funding_txid`
*and* `next_commitment_number` being zero to decide if we need to
resend our `commitment_signed`. Sadly, we cannot rely on just
`next_commitment_number` as that is used to request a force-closure
in a non-standard way to work around implementations not honoring
the `error` message.
This commit is contained in:
Matt Corallo 2024-12-09 19:39:01 +00:00
parent c41536829c
commit 6849c33d86
1 changed files with 4 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
02-peer-protocol.md
View file

@ -2482,12 +2482,8 @@ A node:
the last `commitment_signed` message the receiving node has sent: the last `commitment_signed` message the receiving node has sent:
- MUST reuse the same commitment number for its next `commitment_signed`. - MUST reuse the same commitment number for its next `commitment_signed`.
- otherwise: - otherwise:
- if `next_commitment_number` is not 1 greater than the - if `next_commitment_number` is not equal to the commitment number of the
commitment number of the last `commitment_signed` message the receiving next `commitment_signed` the receiving node will send:
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. - SHOULD send an `error` and fail the channel.
- if `next_revocation_number` is equal to the commitment number of - if `next_revocation_number` is equal to the commitment number of
the last `revoke_and_ack` the receiving node sent, AND the receiving node the last `revoke_and_ack` the receiving node sent, AND the receiving node
@ -2520,7 +2516,8 @@ A receiving node:
- if `next_funding_txid` is set: - if `next_funding_txid` is set:
- if `next_funding_txid` matches the latest interactive funding transaction: - if `next_funding_txid` matches the latest interactive funding transaction:
- if it has not received `tx_signatures` for that funding transaction: - if it has not received `tx_signatures` for that funding transaction:
- MUST retransmit its `commitment_signed` for that funding transaction. - if `next_commitment_number` is zero:
- MUST retransmit its `commitment_signed` for that funding transaction.
- if it has already received `commitment_signed` and it should sign first, - if it has already received `commitment_signed` and it should sign first,
as specified in the [`tx_signatures` requirements](#the-tx_signatures-message): as specified in the [`tx_signatures` requirements](#the-tx_signatures-message):
- MUST send its `tx_signatures` for that funding transaction. - MUST send its `tx_signatures` for that funding transaction.