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

Emit SpliceFailed event upon reload

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

68/100 · Adequate
Emit SpliceFailed event upon reload

Similarly to when a peer is disconnected, when a node is reloaded any
splice that hasn't reaching FundingNegotiation::AwaitingSignatures will
be reset. This should produce a SpliceFailed event. However, since other
FundingNegotiation variants are not persisted, the data to produced the
SpliceFailed event upon reload is lost. Therefore, opportunistically
persist a SpliceFailed event for these cases such that it is available
upon reload.
✓ 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 the Lightning Dev Kit where a wallet reload could silently drop an in-progress channel splice. Previously, if the program restarted while a splice was in an early negotiation state, the user would never receive a 'SpliceFailed' event, so their funds could appear stuck or the failure could go unnoticed. The fix temporarily saves a failure event during persistence so it can be emitted after the reload, then removes it from storage. It is a reliability/notification fix, not a direct theft or remote-exploitation vulnerability.

Recommended action

Treat as a bug-fix commit with minor operational-security relevance. Reviewers should verify that the appended SpliceFailed events are always truncated after write, that no double-emission occurs on reload, and that the new to_contributed_inputs_and_outputs accessors do not expose sensitive data beyond what was already available via the consuming into_ variant. No immediate security response is indicated.

Security signals we found

01

State loss across persistence boundary leading to missing failure notification

02

Event queue manipulation during serialization (append-write-truncate)

03

Refactoring of disconnect-time splice failure logic into shared macro

04

New read-only accessors for contributed inputs/outputs to support non-destructive event creation

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.