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

Emit DiscardFunding before SpliceFailed

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

70/100 · Adequate
Emit DiscardFunding before SpliceFailed

Reverse the event ordering at all emission sites so that
Event::DiscardFunding is emitted before Event::SpliceFailed. If the
user retries the splice when handling SpliceFailed, the contributed
inputs would still be locked. A subsequent DiscardFunding would then
incorrectly unlock inputs that are now committed to the new attempt.
Emitting DiscardFunding first avoids this by ensuring inputs are
unlocked before any retry occurs.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit fixes an ordering bug in how LDK tells the user about a failed splice. Previously, the 'splice failed' notice was sent before the 'you may now unlock your funds' notice. If a user automatically retried the splice upon seeing the failure, their old inputs could still be locked, and the later unlock message would accidentally free inputs that were now being used by the retry. The commit simply reverses the order so funds are unlocked before the failure notice is delivered, and updates tests to match.

Recommended action

Review the new ordering at all splice-failure emission sites to confirm no site was missed, and ensure downstream consumers of these events do not rely on the old order. The change is safe to apply and is accompanied by tests.

Security signals we found

01

State-management bug in event ordering for failed splicing

02

Potential double-spend / input-reuse hazard if user retries splice automatically

03

Fix is purely reordering of existing events; no new cryptographic checks

04

Tests updated and an assertion added to prevent regression

Risk score

Why this scored 45/100

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