Remove invalid splice debug assertion in funding_tx_constructed
What the developer wrote
Authored by Wilmer Paulino
Remove invalid splice debug assertion in funding_tx_constructed
We incorrectly assumed that both commitments must be at the same height,
but this is certainly possible whenever updates are proposed in both
directions at the same time.
What changed, and why it matters
This commit removes a debug-only assertion in the code that handles splicing (a way to resize a Lightning channel). The assertion incorrectly assumed two commitment counters would always match during a splice, but they can legitimately differ when both channel peers propose updates at the same time. The change only affects debug builds and does not alter production behavior, so it is unlikely to be directly exploitable. It is a code-correctness fix rather than a security patch for a live vulnerability.
No immediate security action is required. Developers and users running debug builds of LDK should update to avoid spurious assertion failures during concurrent splice updates. Reviewers may want to confirm that the remaining non-splice checks still adequately protect initial funding negotiation.
Security signals we found
Removal of an incorrect debug assertion
Splicing code path affected
Commitment transaction number synchronization logic
No runtime behavior change in release builds
Evidence from the diff
In lightning/src/ln/channel.rs, the function funding_tx_constructed previously contained a debug_assert_eq! that required holder_commitment_transaction_number to equal self.counterparty_next_commitment_transaction_number whenever is_splice was true. The commit removes that assertion because it can fire falsely when both sides have advanced commitment numbers independently during concurrent updates. The non-splice branch still calls assert_no_commitment_advancement and updates channel_state. Because the removed check is a debug_assert, it compiles away in release builds and cannot cause runtime panics in production nodes.
Changed components
lightning/src/ln/channel.rsfunding_tx_constructedsplicing flowInspect captured patch +1 / −6
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index d7acb1a..45a1d98 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -6199,12 +6199,7 @@ where
{
funding.channel_transaction_parameters.funding_outpoint = Some(funding_outpoint);
- if is_splice {
- debug_assert_eq!(
- holder_commitment_transaction_number,
- self.counterparty_next_commitment_transaction_number,
- );
- } else {
+ if !is_splice {
self.assert_no_commitment_advancement(holder_commitment_transaction_number, "initial commitment_signed");
self.channel_state = ChannelState::FundingNegotiated(FundingNegotiatedFlags::new());
}
Why this scored 28/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.