BOLTs: update announcement_signatures and next_funding reconnect quotes
What the developer wrote
Authored by Níckolas Goline
BOLTs: update announcement_signatures and next_funding reconnect quotes
Changelog-None
What changed, and why it matters
This commit updates Core Lightning's implementation of Lightning protocol (BOLT) rules for reconnecting after a channel disruption and for sending channel announcement signatures. It adds handling for newer 'splicing' scenarios—where an existing channel's funding transaction is changed—so that nodes correctly retransmit messages, detect mismatched funding states, and send announcement signatures for splice transactions. The changes appear to be protocol-compliance fixes rather than fixes for an active security flaw, but incorrect reconnection behavior could theoretically lead to channel confusion or stale state between peers.
Treat as a normal protocol-compliance update. Reviewers should verify that the new splice-related conditions are correctly evaluated and that the added error/force-close paths cannot be triggered by malformed but otherwise benign reconnect messages. No urgent security response is indicated by the commit alone.
Security signals we found
Protocol state machine update for channel reconnection
Added mismatch detection for next_funding in channel_reestablish
Added force-close requirement when next_commitment_number is zero
Extended announcement_signatures requirement to splice transactions
No explicit security advisory, CVE, or changelog entry in commit
Evidence from the diff
The patch modifies three daemons to align with updated BOLT specifications. In channeld/channeld.c, the peer_reconnect logic now checks whether channel_reestablish messages contain my_current_funding_locked or next_funding for a splice before deciding to retransmit channel_ready, and adds handling for next_commitment_number == 0 (force close). In lightningd/channel_gossip.c, the announcement_signatures requirement is extended to splice_locked splice transactions. In openingd/dualopend.c, a mismatch between next_funding values in channel_reestablish now triggers an error and channel failure instead of silent tx_abort. These are defensive consistency checks for the splicing protocol flow.
Changed components
channeld/channeld.clightningd/channel_gossip.copeningd/dualopend.cInspect captured patch +25 / −13
diff --git a/channeld/channeld.c b/channeld/channeld.c
index ed4cc6e..9c7aeae 100644
--- a/channeld/channeld.c
+++ b/channeld/channeld.c
@@ -5956,14 +5956,19 @@ static void peer_reconnect(struct peer *peer,
/* BOLT #2:
*
- * - if `next_commitment_number` is 1 in both the
- * `channel_reestablish` it sent and received:
- * - MUST retransmit `channel_ready`.
- * - otherwise:
- * - MUST NOT retransmit `channel_ready`, but MAY send
- * `channel_ready` with a different `short_channel_id`
- * `alias` field.
+ * A node:
+ * - if `next_commitment_number` is zero:
+ * - MUST immediately fail the channel and broadcast any relevant latest commitment
+ * transaction.
+ * - if `next_commitment_number` is 1 in both the `channel_reestablish` it
+ * sent and received, and none of those `channel_reestablish` messages
+ * contain `my_current_funding_locked` or `next_funding` for a splice transaction:
+ * - MUST retransmit `channel_ready`.
+ * - otherwise:
+ * - MUST NOT retransmit `channel_ready`, but MAY send `channel_ready` with
+ * a different `short_channel_id` `alias` field.
*/
+
if (peer->channel_ready[LOCAL]
&& peer->next_index[LOCAL] == 1
&& next_commitment_number == 1) {
diff --git a/lightningd/channel_gossip.c b/lightningd/channel_gossip.c
index 63088b1..8eea0cd 100644
--- a/lightningd/channel_gossip.c
+++ b/lightningd/channel_gossip.c
@@ -688,9 +688,13 @@ static void stash_remote_announce_sigs(struct channel *channel,
* - If the `open_channel` message has the `announce_channel` bit set AND a
* `shutdown` message has not been sent:
* - After `channel_ready` has been sent and received AND the funding
- * transaction has enough confirmations to ensure that it won't be
- * reorganized:
- * - MUST send `announcement_signatures` for the funding transaction.
+ * transaction has enough confirmations to ensure that it won't be
+ * reorganized:
+ * - MUST send `announcement_signatures` for the funding transaction.
+ * - After `splice_locked` has been sent and received AND the splice
+ * transaction has enough confirmations to ensure that it won't be
+ * reorganized:
+ * - MUST send `announcement_signatures` for the matching splice transaction.
* - Otherwise:
* - MUST NOT send the `announcement_signatures` message.
*/
diff --git a/openingd/dualopend.c b/openingd/dualopend.c
index e7da540..2253bc3 100644
--- a/openingd/dualopend.c
+++ b/openingd/dualopend.c
@@ -4048,9 +4048,12 @@ static void do_reconnect_dance(struct state *state)
* - 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:
- * - MUST send `tx_abort` to let the sending node know that they can forget
- * this funding transaction.
+ * - if it also sets `next_funding` in its own `channel_reestablish`, but the
+ * values don't match:
+ * - MUST send an `error` and fail the channel.
+ * - otherwise:
+ * - MUST send `tx_abort` to let the sending node know that they can forget
+ * this funding transaction.
*/
if (tlvs->next_funding) {
/* Does this match ours? */
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.