From 6849c33d86acb6eda21b130be52063123ba57fca Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 9 Dec 2024 19:39:01 +0000 Subject: [PATCH] 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 27b01fe..d5d19ed 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.