AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 35 Bitcoin

Add backwards-compatible parts of the official splicing protocol (#3261)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

86/100 · Strong
Add backwards-compatible parts of the official splicing protocol (#3261)

* Add `funding_txid` to `commit_sig`

In https://github.com/lightning/bolts/pull/1160 we add a TLV field to
`commit_sig` messages to let the receiver know to which `funding_txid`
this signature applies. This is more resilient than relying on the
order of the `commit_sig` messages in the batch. This is an odd TLV,
so we can start writing it right now without creating compatibility
issues.

We also slightly refactor existing code to make it easier to introduce
a backwards-compat layer when migrating to the official splicing. We
also increase the default number of RBF attempts allowed.

* Insert a `start_batch` message during splices

In https://github.com/lightning/bolts/pull/1160, we introduce a message
to let our peer know how many `commit_sig` messages they will receive
and treat them as a batch. This replaces our previous version that did
something similar, but by adding a batch TLV in every `commit_sig`
message we send.

We currently do both: we keep inserting the experimental batch TLV, and
we start by sending a `start_batch` message (with the same information).
Since it is an odd message (127), it should be safely ignored if our
peer doesn't understand it.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit updates the Eclair Lightning node software to support a new, backwards-compatible draft of the official Bitcoin Lightning 'splicing' protocol. It adds a funding transaction identifier to commitment signatures and introduces a 'start_batch' message so peers know when multiple signatures belong together. It also keeps the older experimental batching mechanism for compatibility with older Phoenix wallets. The changes are primarily a protocol upgrade and compatibility shim, not a clear security fix, though they reduce ambiguity about which signature applies to which funding transaction during splices.

Recommended action

Treat as a normal protocol-upgrade commit. Reviewers should verify that the new `start_batch` parser cannot be abused for memory exhaustion (batch size is capped at 20), that the fallback ordering logic in `Commitments.receiveCommit` correctly handles missing `fundingTxId_opt`, and that the legacy experimental batch path remains safe until removed. No urgent security patch action is indicated by the commit itself.

Security signals we found

01

Adds disambiguation of commitment signatures by funding transaction ID, reducing risk of applying a signature to the wrong commitment during multi-funding splicing

02

Introduces a new odd-length message (start_batch) and odd TLV (FundingTx), which unknown peers should ignore per Lightning spec conventions

03

Maintains legacy experimental batch TLV for backwards compatibility

04

Adds input validation on start_batch: only message type 132 (commit_sig) supported, batch size capped at 20, with Warning responses and fallback to individual forwarding

05

Increases default remote RBF attempt limit from 5 to 10

06

No explicit security advisory, CVE, or vulnerability disclosure language in commit message or diff

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 7/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.