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

Persist outbound channel info in inbound HTLCs

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Persist outbound channel info in inbound HTLCs

We need these fields to generate a correct PaymentForwarded event if we need to
claim this inbound HTLC backwards after restart and it's already been claimed
and removed on the outbound edge.
✓ 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 data-loss bug in the Lightning Dev Kit (LDK) routing/payment-forwarding logic. When LDK forwards a payment through a node and then restarts, it may need to claim the inbound payment (HTLC) even though the outbound side has already been settled. Previously, after restart LDK only remembered the outbound amount, not which outbound channel or peer the payment went to. That meant it could emit an incomplete or incorrect 'PaymentForwarded' event and possibly mishandle the post-restart claim. The patch now persists the full outbound hop details (channel ID, peer, funding outpoint, user channel ID, and amount) inside the stored inbound HTLC state so the event can be reconstructed correctly after restart.

Recommended action

Treat as a reliability/accounting bug fix rather than an exploitable vulnerability. Users running LDK nodes that route payments should upgrade to avoid incorrect PaymentForwarded events and potential post-restart HTLC handling inconsistencies. No immediate emergency response is indicated.

Security signals we found

01

Data persistence gap in cross-channel HTLC state

02

Post-restart event reconstruction could be incorrect or incomplete

03

Fix is additive and backward-compatible via TLV upgradable enum

04

No explicit cryptographic, authorization, or network validation change

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.