From 6849c33d86acb6eda21b130be52063123ba57fca Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 9 Dec 2024 19:39:01 +0000 Subject: [PATCH 1/3] Do not unnecessarily retransmit `commitment_signed` in dual funding 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. --- 02-peer-protocol.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 27b01fe04..d5d19edf5 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2482,12 +2482,8 @@ A node: 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: + - if `next_commitment_number` is not equal to the commitment number of the + next `commitment_signed` the receiving node will send: - 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 @@ -2520,7 +2516,8 @@ A receiving node: - if `next_funding_txid` is set: - if `next_funding_txid` matches the latest interactive 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, as specified in the [`tx_signatures` requirements](#the-tx_signatures-message): - MUST send its `tx_signatures` for that funding transaction. From d8cfa95925336b63b17d6cd989b618ddcef1efa8 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 9 Dec 2024 19:49:48 +0000 Subject: [PATCH 2/3] Bless the LND SCB force-close request message format Sending a `channel_reestablish` with `next_commitment_number` of zero is used in practice to request a peer fail a channel and broadcast the latest state (for implementations which continue to ignore the `error` message). Because its used in practice we should document it to avoid accidentally writing up incompatible things in the future. --- 02-peer-protocol.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index d5d19edf5..3e7ecb2ec 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2526,6 +2526,9 @@ A receiving node: - otherwise: - MUST send `tx_abort` to let the sending node know that they can forget this funding transaction. + - if `next_funding_txid` is not set, and `next_commitment_number` is zero: + - MUST immediately fail the channel and broadcast any relevant latest commitment + transaction. A node: - MUST NOT assume that previously-transmitted messages were lost, From 7d1bfd2791b5d612f01149f8521f92d14e4be6db Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 28 Jul 2025 20:03:42 +0000 Subject: [PATCH 3/3] Un-gate `commitment_signed` retransmission from `tx_signatures` recv If we receive a reestablish with a `next_commitment_number` of zero, there's no harm in always re-transmitting our `commitment_signed` for a dual-funded channel. To simplify things somewhat, here we simply do so, removing the gate on having received `tx_signatures`. --- 02-peer-protocol.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 3e7ecb2ec..2bee28850 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2515,12 +2515,11 @@ A node: A receiving node: - if `next_funding_txid` is set: - if `next_funding_txid` matches the latest interactive funding transaction: - - if it has not received `tx_signatures` 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, - as specified in the [`tx_signatures` requirements](#the-tx_signatures-message): - - MUST send its `tx_signatures` for that funding transaction. + - if `next_commitment_number` is zero: + - MUST retransmit its `commitment_signed` for the funding transaction. + - if it has already received `commitment_signed` and it should sign first, + as specified in the [`tx_signatures` requirements](#the-tx_signatures-message): + - MUST send its `tx_signatures` for that funding transaction. - if it has already received `tx_signatures` for that funding transaction: - MUST send its `tx_signatures` for that funding transaction. - otherwise: