Retransmit announcement_signatures if requested
What the developer wrote
Authored by Jeffrey Czyz
Retransmit announcement_signatures if requested
The previous commit allowed requesting retransmission of
announcement_signatures during channel reestablishment. This commit
handles such requests.
What changed, and why it matters
This commit completes a feature that lets a Lightning node ask its peer to resend 'announcement_signatures' messages during channel reestablishment. These signatures are needed to publicly announce a channel on the network. The change simply adds the logic to honor that request, matching a protocol rule. It is a follow-up implementation patch, not a fix for an active vulnerability.
Review as normal protocol feature completion. No urgent security action required. Verify that resetting 'announcement_sigs_state' to NotSent cannot cause duplicate or conflicting signatures in edge cases, and ensure the prior commit's request mechanism is gated appropriately.
Security signals we found
Implements retransmission of announcement_signatures on request
Resets internal state only when funding txid matches the requested one
Follow-up to prior commit that added request capability
No input validation changes beyond existing funding txid comparison
Evidence from the diff
The commit adds handling for the ‘announcement_signatures’ retransmission bit in the ‘my_current_funding_locked’ field of channel_reestablish messages. When the peer sets the bit and the funding transaction matches, the local node resets its internal ‘announcement_sigs_state’ to ‘NotSent’ so that ‘get_announcement_sigs’ will retransmit the signatures. A helper method ‘should_retransmit’ is added to FundingLocked. This is a protocol-compliance change implementing behavior described in the BOLT/BLIP-like retransmission rules.
Changed components
lightning/src/ln/channel.rslightning/src/ln/msgs.rsInspect captured patch +19 / −0
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 8b26a88..a5789da 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -9173,6 +9173,20 @@ where
let shutdown_msg = self.get_outbound_shutdown();
+ // A receiving node:
+ // - if `my_current_funding_locked` is included with the `announcement_signatures` bit
+ // set in the `retransmit_flags`:
+ // - if `announce_channel` is set for this channel and the receiving node is ready
+ // to send `announcement_signatures` for the corresponding splice transaction:
+ // - MUST retransmit `announcement_signatures`.
+ if let Some(funding_locked) = &msg.my_current_funding_locked {
+ if funding_locked.should_retransmit(msgs::FundingLockedFlags::AnnouncementSignatures) {
+ if self.funding.get_funding_txid() == Some(funding_locked.txid) {
+ self.context.announcement_sigs_state = AnnouncementSigsState::NotSent;
+ }
+ }
+ }
+
let announcement_sigs = self.get_announcement_sigs(node_signer, chain_hash, user_config, best_block.height, logger);
let mut commitment_update = None;
diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs
index fc99ea5..30e4d50 100644
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -985,6 +985,11 @@ impl FundingLocked {
pub fn retransmit(&mut self, flag: FundingLockedFlags) {
self.retransmit_flags |= 1 << flag as u8;
}
+
+ /// Returns whether the message corresponding to `flag` should be retransmitted.
+ pub fn should_retransmit(&self, flag: FundingLockedFlags) -> bool {
+ self.retransmit_flags & (1 << flag as u8) != 0
+ }
}
/// Bit positions used in [`FundingLocked::retransmit_flags`] for requesting message retransmission.
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.