Use correct commitment number/point in initial commitment_signed
What the developer wrote
Authored by Jeffrey Czyz
Use correct commitment number/point in initial commitment_signed
When splicing a channel, the initial commitment_signed should use the
same commitment number and point previously sent. Account for this by
adjusting these to use the previous commitment number and point, since
the next expected one is stored.
What changed, and why it matters
This patch fixes a bug in the Lightning Dev Kit's channel-splicing code. When a channel is being spliced, the first new commitment transaction was being built with the wrong commitment number and the wrong counterparty public key (the 'commitment point'). The fix makes the code use the previous commitment number and the previous commitment point instead, matching what the counterparty already expects. Using the wrong values could cause the commitment transaction to be rejected or, in the worst case, lead to an invalid or unenforceable on-chain transaction if a dispute arises.
Review splice protocol tests to ensure both commitment number and commitment point are validated for the initial splice commitment_signed. Consider adding explicit test vectors covering the transition from pre-splice to post-splice commitment state.
Security signals we found
Wrong commitment number used in initial splice commitment_signed
Wrong counterparty commitment point used in splice commitment transaction
Channel state inconsistency during splicing
Potential invalid commitment signature or transaction during channel splice
Evidence from the diff
In rust-lightning’s channel.rs, the initial commitment_signed during a splice was calling build_commitment_transaction with cur_counterparty_commitment_transaction_number and counterparty_cur_commitment_point. Because the next expected commitment number/point is already stored in those fields, the correct values for the splice’s initial commitment are the previous number (current + 1, since commitment numbers count down) and the previous commitment point. The patch centralizes this logic in one helper and updates the second splice-specific call site to use +1 and counterparty_prev_commitment_point.
Changed components
lightning/src/ln/channel.rsChannel splicing / commitment_signed constructionbuild_commitment_transactionInspect captured patch +13 / −4
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index b2f88d2..5777ea4 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -5590,10 +5590,19 @@ where
SP::Target: SignerProvider,
L::Target: Logger,
{
+ let mut commitment_number = self.cur_counterparty_commitment_transaction_number;
+ let mut commitment_point = self.counterparty_cur_commitment_point.unwrap();
+
+ // Use the previous commitment number and point when splicing since they shouldn't change.
+ if commitment_number != INITIAL_COMMITMENT_NUMBER {
+ commitment_number += 1;
+ commitment_point = self.counterparty_prev_commitment_point.unwrap();
+ }
+
let commitment_data = self.build_commitment_transaction(
funding,
- self.cur_counterparty_commitment_transaction_number,
- &self.counterparty_cur_commitment_point.unwrap(),
+ commitment_number,
+ &commitment_point,
false,
false,
logger,
@@ -7021,8 +7030,8 @@ where
.context
.build_commitment_transaction(
pending_splice_funding,
- self.context.cur_counterparty_commitment_transaction_number,
- &self.context.counterparty_cur_commitment_point.unwrap(),
+ self.context.cur_counterparty_commitment_transaction_number + 1,
+ &self.context.counterparty_prev_commitment_point.unwrap(),
false,
false,
logger,
Why this scored 54/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.