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

More robust splicing edge cases (#3366)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

81/100 · Strong
More robust splicing edge cases (#3366)

We apply some defense-in-depth to better handle edge cases during
splicing where a remote peer doesn't follow the BOLTs. This also
includes more thorough pattern-matching, which protects against
future refactoring or new features from inadvertently introducing
a vulnerability related to splicing.

Co-authored-by: Fabrice Drouin <sstone@users.noreply.github.com>
✓ 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 hardens Eclair's handling of the Lightning 'splicing' feature when a peer misbehaves. Splicing lets two nodes resize an open payment channel without closing it on-chain. The patch adds extra checks so that if a peer sends unexpected messages during the splice—especially messages that would shift the channel's commitment index—it disconnects or force-closes instead of applying them. Applying such messages could let a malicious peer trick the node into revoking a commitment number that a new splice commitment is still using, potentially putting funds at risk. The commit also fixes a batching bug so that a single commit_sig is delivered as a single message, not as a one-message batch that could trigger an unnecessary force-close.

Recommended action

Treat this as a security-hardening patch for the splicing code path. Operators running nodes that support splicing and liquidity ads should upgrade. Reviewers should verify that the new consistency checks cover all splice/RBF entry points and that the batching change in PeerConnection does not break legitimate multi-commit_sig batches outside of splicing.

Security signals we found

01

Adds commitment-index consistency checks before completing splice/RBF funding attempts

02

Rejects forbidden update messages while remote peer is quiescing

03

Rejects commit_sig during quiescence to prevent commitment-index desync

04

Rejects CommitSigBatch during splice to prevent revocation of the splice commitment index

05

Fixes commit_sig batching edge case where a single-message batch could trigger force-close

06

Notifies peer actor when a liquidity purchase funding attempt is aborted

07

Adds explicit pattern matching on splice statuses instead of catch-all behavior

Risk score

Why this scored 70/100

Our methodology →
Potential impact 22/30
Exploitability 14/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/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.