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

Emit DiscardFunding events for double spent splice transactions

Public commit record

What the developer wrote

Authored by Wilmer Paulino

85/100 · Strong
Emit DiscardFunding events for double spent splice transactions

Once we see a splice transaction become locked, we want to emit a
`DiscardFunding` event for every alternative funding transaction
candidate that may have been negotiated due to RBFs, as they may contain
inputs the user has considered "locked" that do not exist in the
confirmed transaction. If the channel closes before the splice is
locked, we rely on the `ChannelMonitor` to produce these events for us
instead.
✓ 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 change makes LDK tell users when alternative splice funding transactions are no longer needed, so they can safely reuse the bitcoin inputs. Previously, after a splice locked in, leftover RBF versions of the splice transaction might not have been reported as discardable, which could leave inputs stuck or accidentally double-spent by the user elsewhere. There is no direct exploit here; it is a correctness and usability fix in a splicing feature still behind a compile-time flag.

Recommended action

Treat as a low-severity correctness fix. If running splicing-enabled builds, ensure this patch is included so wallet inputs are correctly released. No urgent mitigation required; no CVE or advisory referenced.

Security signals we found

01

Missing event emission for abandoned funding transactions could leave user inputs effectively locked

02

Splicing feature is behind cfg(splicing) and not enabled by default

03

ChannelMonitor fallback handles channel-closure-before-lock case

04

No cryptographic, network, or consensus bug visible in diff

Risk score

Why this scored 32/100

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