Set funding_locked_txid TLVs in channel_reestablish
What changed, and why it matters
This commit fills in two previously-empty fields in a Lightning channel recovery message. These fields tell each side which funding transaction the other side last confirmed as locked. Setting them correctly helps nodes resume a channel after a disconnect without disagreeing about which funds are active. The change is a follow-up to a prior commit that added the message fields but left them unset.
Review the prior commit that introduced these TLVs to confirm the state machine now behaves correctly when my_current_funding_locked is non-None. Treat as a normal protocol-correctness fix; no urgent security action is indicated by this diff alone.
Security signals we found
Follow-up completion of a prior protocol-extension commit
Populates TLVs used for channel reestablishment state reconciliation
Splicing-gated, so mainnet non-experimental behavior is unchanged
No explicit security claim or advisory in commit message
Evidence from the diff
The patch adds maybe_get_my_current_funding_locked() in lightning/src/ln/channel.rs. Under the splicing feature it returns a FundingLocked containing either the pending splice’s sent funding txid, if one exists, or the current channel funding txid once our side has sent funding_locked. Under non-splicing builds it always returns None. The channel_reestablish construction now populates my_current_funding_locked with this value instead of None. This completes the wiring started by the previous commit that introduced your_last_funding_locked_txid and my_current_funding_locked_txid TLVs.
Changed components
lightning/src/ln/channel.rschannel_reestablish message generationsplicing featureInspect captured patch +17 / −1
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 5a78bd9..5724592 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -10962,6 +10962,22 @@ where
}
}
+ #[cfg(splicing)]
+ fn maybe_get_my_current_funding_locked(&self) -> Option<msgs::FundingLocked> {
+ self.pending_splice
+ .as_ref()
+ .and_then(|pending_splice| pending_splice.sent_funding_txid)
+ .or_else(|| {
+ self.is_our_channel_ready().then(|| self.funding.get_funding_txid()).flatten()
+ })
+ .map(|txid| msgs::FundingLocked { txid, retransmit_flags: 0 })
+ }
+
+ #[cfg(not(splicing))]
+ fn maybe_get_my_current_funding_locked(&self) -> Option<msgs::FundingLocked> {
+ None
+ }
+
/// May panic if called on a channel that wasn't immediately-previously
/// self.remove_uncommitted_htlcs_and_mark_paused()'d
#[rustfmt::skip]
@@ -11013,7 +11029,7 @@ where
your_last_per_commitment_secret: remote_last_secret,
my_current_per_commitment_point: dummy_pubkey,
next_funding_txid: self.maybe_get_next_funding_txid(),
- my_current_funding_locked: None,
+ my_current_funding_locked: self.maybe_get_my_current_funding_locked(),
}
}
Why this scored 33/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.