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

De-dup decode_htlcs from monitor only if channel is closed

Public commit record

What the developer wrote

Authored by Valentine Wallace

73/100 · Adequate
De-dup decode_htlcs from monitor only if channel is closed

We recently added support for reconstructing
ChannelManager::decode_update_add_htlcs on startup, using data present in the
Channels. However, we failed to prune HTLCs from this rebuilt map if a given
inbound HTLC was already forwarded to the outbound edge and in the outbound
holding cell (this bug could've caused us to double-forward HTLCs, fortunately
it never shipped).

As part of fixing this bug, we clean up the overall pruning approach by:
1. If the Channel is open, then it is the source of truth for what HTLCs are
outbound+pending (including pending in the holding cell)
2. If the Channel is closed, then the corresponding ChannelMonitor is the
source of truth for what HTLCs are outbound+pending

Previously, we would only consider the monitor's pending HTLCs, which ignored
holding cell HTLCs.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
✓ Specific, 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 LDK's Lightning node restart logic. When a node restarts and rebuilds its list of HTLCs (payments) that need forwarding, it could have re-forwarded a payment that was already sitting in an outbound 'holding cell' waiting to be sent. The fix makes the open channel the source of truth for pending outbound forwards, and only falls back to the on-chain ChannelMonitor data when the channel is closed. The commit message explicitly says this bug 'never shipped' (i.e., was caught before release).

Recommended action

Treat as a security-relevant correctness fix. Verify the regression test passes and that no other reconstruction paths (e.g., monitor-only recovery) still miss holding-cell or in-flight forwards. Since the vendor states the buggy code never shipped, no emergency response is needed for deployed versions, but the fix should be included in the next release.

Security signals we found

01

Double-forward of HTLC on node restart

02

State reconstruction from ChannelMonitor vs Channel inconsistency

03

Holding-cell HTLCs omitted from deduplication set

04

Regression test added for restart/reload path

05

Commit message states bug 'never shipped'

Risk score

Why this scored 66/100

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