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

Model RBF splice tx replacement in chanmon_consistency

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Model RBF splice tx replacement in chanmon_consistency

The SplicePending event handler was immediately confirming splice
transactions, which caused force-closes when RBF splice replacements
were also confirmed for the same channel. Since both transactions spend
the same funding UTXO, only one can exist on a real chain.

Model this properly by adding a mempool-like pending pool to ChainState.
Splice transactions are added to the pool instead of being confirmed
immediately. At chain-sync time, pending transactions are sorted by
txid and confirmed together in one block; candidates that double-spend
an already-confirmed outpoint or another candidate earlier in the sort
are dropped.

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
The short version

What changed, and why it matters

This commit fixes a bug in a fuzzing test harness, not in the production Lightning Dev Kit code. The test was incorrectly treating splice transactions as confirmed immediately, which could cause simulated force-closes when multiple RBF (fee-bump) replacements existed. The fix adds a fake mempool so the test models real Bitcoin behavior: only one transaction spending the same funding output can be confirmed. End users running real Lightning nodes are not directly affected.

Recommended action

No production action required. Reviewers should verify the fuzz harness now exercises both RBF replacement confirmation and rejection paths correctly, and that production splice/RBF handling in the non-fuzz codebase is separately tested.

Security signals we found

01

Fixes a test-harness modeling bug that produced false-positive force-closes during fuzzing of splice/RBF flows

02

Adds double-spend detection for confirmed outpoints in confirm_tx and confirm_pending_txs

03

No change to consensus, P2P, or channel-state machine logic in production crates

Risk score

Why this scored 17/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 1/15
Confidence 9/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.