From 6009147dc1089df9cc08dab7757b4f6ba1698bed Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 9 Dec 2024 19:39:01 +0000 Subject: [PATCH 1/2] 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 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 27b01fe04..f6ebaa540 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2520,7 +2520,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 90772fff8227a4e9db1282a6ae751075d07e4d0b Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 9 Dec 2024 19:49:48 +0000 Subject: [PATCH 2/2] 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 f6ebaa540..e9ba8bc75 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2530,6 +2530,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,