Clear announcement_sigs on FundingScope promotion
What the developer wrote
Authored by Jeffrey Czyz
Clear announcement_sigs on FundingScope promotion
When a splice transaction is promoted (i.e., when splice_locked has been
exchanged), announcement_signatures must be sent. However, if we try to
send a channel_announcement before they are received, then the
signatures will be incorrect. To avoid this, clear the counterparty's
announcement_signatures upon promoting a FundingScope.
What changed, and why it matters
This patch fixes a Lightning channel bug that could produce an invalid channel announcement after a splice is finalized. When a channel is spliced (its on-chain funds are moved to a new transaction), both sides must exchange fresh announcement signatures before re-announcing the channel to the network. The bug caused the old counterparty signature to be kept briefly after the splice was promoted, so if the node tried to build and send a channel_announcement before the new signature arrived, it would use a stale signature and create an invalid message. The fix simply clears the old signature when the splice is promoted, forcing the node to wait for the new one. There is no direct theft-of-funds path, but it could cause gossip inconsistencies or a peer to send invalid protocol messages.
Apply the patch. It is a minimal, clearly correct state consistency fix. Nodes running splice-enabled builds should upgrade to avoid emitting invalid channel_announcement messages. No immediate emergency response is warranted because the issue is a protocol-correctness/gossip problem rather than a direct funds-loss vulnerability.
Security signals we found
Use of stale cryptographic signature after channel state transition
State-machine inconsistency: announcement_sigs_state reset without clearing corresponding signature storage
Protocol message (channel_announcement) could be generated with invalid counterparty signature
Splicing code path, which is a newer and more complex channel state transition
Evidence from the diff
In rust-lightning, channel.rs macro promote_splice_funding! now sets self.context.announcement_sigs = None when a splice FundingScope is promoted (splice_locked exchanged). Previously only announcement_sigs_state was reset to NotSent, leaving the old counterparty announcement_sigs in place. Because channel_announcement construction uses the stored announcement_sigs, a node that attempted to re-announce before receiving the post-splice announcement_signatures message would generate a channel_announcement signed with the pre-splice counterparty signature, which is invalid for the new funding outpoint/short_channel_id. The patch prevents generation of that invalid message by removing the stale signature.
Changed components
lightning/src/ln/channel.rsChannel announcement/gossip logic after splice promotionpromote_splice_funding! macroInspect captured patch +1 / −0
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 08054a8..9de3bd3 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -6437,6 +6437,7 @@ macro_rules! promote_splice_funding {
core::mem::swap(&mut $self.funding, $funding);
$self.interactive_tx_signing_session = None;
$self.pending_splice = None;
+ $self.context.announcement_sigs = None;
$self.context.announcement_sigs_state = AnnouncementSigsState::NotSent;
// The swap above places the previous `FundingScope` into `pending_funding`.
Why this scored 45/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.