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

Preserve original contribution on counterparty RBF abort

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Preserve original contribution on counterparty RBF abort

When the counterparty initiates an RBF, the prior contribution was
popped and replaced with the feerate-adjusted version. If the RBF
aborted, the adjusted version persisted, leaving a stale higher
feerate in contributions.

Change contributions to be an append-only log where each negotiation
round pushes a new entry. On abort, pop the last entry if its feerate
doesn't match the locked feerate. This naturally preserves the original
contribution as an earlier entry in the vec.

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 Lightning Dev Kit's channel splicing/RBF logic. When a counterparty started a fee-bump (RBF) negotiation that later aborted, the local node's record of its own funding contribution was accidentally left at the higher, adjusted fee rate instead of reverting to the original. The fix makes the contribution history append-only and pops the unconfirmed round's entry on abort, restoring the original contribution. The bug could cause incorrect fee accounting and, in some abort paths, a panic or wrong wallet events when the node later initiated its own RBF.

Recommended action

Treat as a correctness/security fix worth including in release notes. Review related abort paths to ensure no other stale state remains. Consider whether the panic path and wrong DiscardFunding events warrant a CVE; the commit itself does not claim security relevance, but the state inconsistency could affect channel safety.

Security signals we found

01

State inconsistency after aborted RBF: stale higher feerate persisted in contribution record

02

Potential panic in subsequent local RBF due to violated feerate assumptions

03

Incorrect wallet reclaim events (DiscardFunding) for UTXOs still committed to a prior splice round

04

Append-only contribution log with rollback on abort

05

Test added/updated to reproduce and verify abort behavior

Risk score

Why this scored 57/100

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