From 82f6862a6fa56f47b5e7c27dc9378173a0800cbd Mon Sep 17 00:00:00 2001 From: t-bast Date: Fri, 24 Jan 2025 10:33:33 +0100 Subject: [PATCH] Clarify `splice_locked` retransmission on reconnect When we reconnect, we send `splice_locked` for the latest splice that reached acceptable depth. To avoid sending `splice_locked` at every reconnection, we omit it if the `commitment_number` has progressed since the last time we sent `splice_locked`, which implicitly means that our peer received our `splice_locked` since they stored more recent updates to the channel. --- 02-peer-protocol.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index d11d3db85..0920f5051 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -3056,9 +3056,6 @@ A receiving node: - 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. - - if `next_funding_txid` matches the latest funding transaction: - - if that transaction has reached acceptable depth: - - MUST send `splice_locked`. - if it also sets `next_funding_txid` in its own `channel_reestablish`, but the values don't match: - MUST send an `error` and fail the channel. @@ -3066,6 +3063,13 @@ A receiving node: - MUST send `tx_abort` to let the sending node know that they can forget this funding transaction. +A receiving node: + - MUST send `splice_locked` for the most recent splice transaction that reached + acceptable depth, unless `splice_locked` was already sent for this transaction + and `next_commitment_number` is strictly greater than the `commitment_number + 1` + that was used when `splice_locked` was previously sent (which indicates that + the previous `splice_locked` was received). + A node: - MUST NOT assume that previously-transmitted messages were lost, - if it has sent a previous `commitment_signed` message: