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

Prefer legacy forward maps on manager read

Public commit record

What the developer wrote

Authored by Valentine Wallace

90/100 · Strong
Prefer legacy forward maps on manager read

We are working on removing the requirement of regularly persisting the
ChannelManager, and as a result began reconstructing the manager's forwards
maps from Channel data on startup in a recent PR, see
cb398f6b761edde6b45fcda93a01c564cb49a13c and parent commits.

At the time, we implemented ChannelManager::read to prefer to use the newly
reconstructed maps, partly to ensure we have test coverage of the new maps'
usage. This resulted in a lot of code that would deduplicate HTLCs that were
present in the old maps to avoid redundant HTLC handling/duplicate forwards,
adding extra complexity.

Instead, always use the old maps in prod, but randomly use the newly
reconstructed maps in testing, to exercise the new codepaths (see
reconstruct_manager_from_monitors in ChannelManager::read).
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit changes how the Lightning Dev Kit (LDK) node restores its record of in-flight payment forwards after a restart. Previously, the code preferred newly reconstructed forward maps built from channel monitor data, which required complex de-duplication logic to avoid processing the same HTLC twice. The commit switches production code to always use the older, persisted forward maps instead, while keeping the new reconstruction path active only in tests (randomly or via an environment variable). It also adds a small guard to avoid pushing duplicate intercept events if a restart re-processes an already-handled intercept forward.

Recommended action

Treat this as a code-quality and reliability change rather than a confirmed security fix. Reviewers should verify that preferring legacy forward maps in production does not reintroduce stale-state issues if the ChannelManager persistence is outdated relative to ChannelMonitors, and that the new duplicate-event suppression correctly covers all intercept-forward restart cases. No immediate patching urgency is indicated by the commit itself.

Security signals we found

01

Behavior change in HTLC forward state restoration after restart

02

Removal of de-duplication logic between legacy and reconstructed forward maps in production path

03

Test-only activation of new reconstruction path via environment variable or random selection

04

Addition of duplicate-event suppression for intercept forwards after restart

Risk score

Why this scored 30/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/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.