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

Send tx_init_rbf instead of splice_init when a splice is pending

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Send tx_init_rbf instead of splice_init when a splice is pending

When the quiescence initiator has a pending splice and enters the stfu
handler with a QuiescentAction::Splice, send tx_init_rbf to bump the
existing splice's feerate rather than starting a new splice_init.

This reuses the same QuiescentAction::Splice variant for both initial
splices and RBF attempts -- the stfu handler distinguishes them by
checking whether pending_splice already exists.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a logic bug in the Lightning Dev Kit's splicing protocol. Previously, if a node tried to RBF (bump the fee of) a pending splice, it would incorrectly send a new splice_init message instead of tx_init_rbf, which could cause the peer to disconnect or the protocol to fail. The change makes the node detect when a splice is already pending and send the correct RBF message instead. It is a protocol correctness fix rather than a critical security vulnerability.

Recommended action

Review and merge as a protocol correctness improvement. Monitor for any edge cases where pending_splice state could be stale or inconsistent when entering quiescence. No immediate security response required.

Security signals we found

01

Protocol state machine correction in splicing/RBF flow

02

Removes a debug_assert + WarnAndDisconnect path for already-pending splice

03

Adds explicit handling for tx_init_rbf initiator path

04

Includes test coverage for insufficient RBF feerate rejection

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/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.