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

Properly provide `PaymentPathSuccessful` event for replay claims

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Properly provide `PaymentPathSuccessful` event for replay claims

When a payment was sent and ultimately completed through an
on-chain HTLC claim which we discover during startup, we
deliberately break the payment tracking logic to keep it around
forever, declining to send a `PaymentPathSuccessful` event but
ensuring that we don't constantly replay the claim on every
startup.

However, now that we now have logic to complete a claim by marking
it as completed in a `ChannelMonitor` and not replaying information
about the claim on every startup. Thus, we no longer need to take
the conservative stance and can correctly replay claims now,
generating `PaymentPathSuccessful` events and allowing the state to
be removed.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change fixes a bookkeeping quirk in the Lightning Dev Kit. Previously, when a payment was completed via an on-chain claim discovered during startup, the software deliberately kept the payment record around forever and skipped sending a 'this payment path succeeded' event, to avoid repeatedly replaying the claim every time the node restarted. Now that the software can mark such claims as completed inside the channel monitor, it can safely send the missing success event and clean up the old payment state. This is a correctness and cleanup improvement, not a vulnerability that an attacker can exploit.

Recommended action

Treat as a normal bugfix/correctness patch. No urgent security action required. Users relying on PaymentPathSuccessful events for accounting or UX during on-chain claim replays at startup will now receive them correctly.

Security signals we found

01

Behavioral fix in payment state cleanup after on-chain HTLC claim replay

02

Previously pending payment could remain forever, now properly completed

03

No cryptographic, network, or trust-boundary weakness introduced

04

Test expectations updated to reflect new event emission

Risk score

Why this scored 21/100

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