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

Check can_initiate_rbf in stfu handler before sending tx_init_rbf

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

85/100 · Strong
Check can_initiate_rbf in stfu handler before sending tx_init_rbf

If splice_locked is sent between our outgoing STFU and the
counterparty's STFU response, the stfu() handler would proceed to
send tx_init_rbf for an already-confirmed splice. Guard against this
by re-checking can_initiate_rbf when entering quiescence. Disconnect
because there is no way to cancel quiescence after both sides have
exchanged STFU.

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

What changed, and why it matters

This commit fixes a bug in the Lightning Dev Kit's splicing/RBF (fee-bump) protocol. If a splice transaction got confirmed while both sides were exchanging 'quiet' (STFU) messages, the code could wrongly try to start a new RBF round for an already-final splice. The fix adds a re-check before sending the RBF initiation message and disconnects the peer if the splice is already locked, preventing protocol confusion and potential loss or locking of funds.

Recommended action

Review and merge the patch. Ensure downstream users running splicing/RBF nodes upgrade to a version containing this fix, as the race could otherwise lead to protocol desynchronization or fund-locking edge cases.

Security signals we found

01

Race condition between splice confirmation and RBF initiation

02

Prevention of invalid tx_init_rbf after splice_locked

03

New NegotiationFailureReason::CannotInitiateRbf for failed RBF initiation

04

WarnAndDisconnect because quiescence cannot be cancelled once both STFUs are exchanged

05

Regression test added in splicing_tests.rs

Risk score

Why this scored 58/100

Our methodology →
Potential impact 18/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 10/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.