Fix `generated_by_local` arg to build commmitment during splicing
What the developer wrote
Authored by Matt Corallo
Fix `generated_by_local` arg to build commmitment during splicing
`build_commitment_transaction`'s fifth argument is supposed to be
whether we're the one generating the commitment (i.e. because we're
signing rather than validating the commitment). During splicing,
this doesn't matter because there should be no async HTLC
addition/removal happening so the commitment generated wil be the
same in either case, but its still good to pass the correct bool.
What changed, and why it matters
A single boolean argument in a function call was corrected during a process called 'splicing' (a way to resize a Lightning channel). The argument tells the code whether the local side is the one creating the commitment transaction. The commit message says this doesn't actually change the resulting transaction during splicing, because no pending payment updates are happening, but it is still correct to pass the right value. There is no clear security vulnerability here.
No immediate action required. Treat as a minor correctness fix. If reviewing, verify that the true value is correct for all splicing paths and that no other call sites pass the wrong boolean.
Security signals we found
Argument-correctness fix in commitment-building code
No async HTLC state changes during affected code path per commit message
No validation bypass, overflow, or authorization change visible in diff
Evidence from the diff
In lightning/src/ln/channel.rs, a call to build_commitment_transaction had its fifth argument changed from false to true during splicing. That argument, generated_by_local, indicates whether the local node is generating (and thus signing) the commitment rather than validating a counterparty-generated commitment. The commit message explicitly states that during splicing this distinction is irrelevant because no asynchronous HTLC additions/removals are occurring, so the produced commitment is identical either way. The change is therefore a correctness fix with no demonstrated security impact.
Changed components
lightning/src/ln/channel.rssplicing commitment generationInspect captured patch +1 / −1
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index c50d0d4..dc966af 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -6252,7 +6252,7 @@ where
commitment_number,
&commitment_point,
false,
- false,
+ true,
logger,
);
let counterparty_initial_commitment_tx = commitment_data.tx;
Why this scored 18/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.