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

Abort active splice RBF when prior candidate confirms

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Abort active splice RBF when prior candidate confirms

Rejecting new RBF attempts after confirmation does not cover an RBF
negotiation which began while the prior candidate was still unconfirmed.
When an earlier candidate confirms, inspect any active RBF and reset it
if is still safe and holder funding signatures have not been provided.
Propagate a structured abort through the chain-event path so
ChannelManager can notify a connected peer, fail any local contribution,
and release holding-cell updates. If signing has advanced too far,
retain the RBF until it completes, as splice promotion is blocked on its
completion.

Co-Authored-By: Codex <noreply@openai.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 state-handling bug in Lightning Dev Kit's splicing feature. When a user tries to speed up or replace a pending splice (an 'RBF' attempt) and the older splice transaction unexpectedly gets confirmed on-chain, the software could get stuck with two conflicting splice attempts active. The patch detects that situation, safely cancels the newer RBF attempt, tells the peer, returns any locked-up funds, and resumes normal channel operation. If signing has already progressed too far, it keeps the RBF alive until it finishes to avoid unsafe cancellation.

Recommended action

Review and merge if part of supported release branch; ensure downstream users running splicing-enabled nodes update to include this fix. No immediate emergency response is indicated, but the fix prevents potential channel-stuck or fund-lockup scenarios.

Security signals we found

01

State-conflict handling between confirmed splice candidate and active RBF negotiation

02

Structured abort propagation through chain-event path

03

Conditional abort based on holder signature progress to avoid unsafe cancellation

04

Peer notification via TxAbort and local failure via SpliceFundingFailed

05

Holding-cell release after splice RBF abort

06

New regression tests for connected, disconnected, reloaded, and edge cases

Risk score

Why this scored 60/100

Our methodology →
Potential impact 18/30
Exploitability 12/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.