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

fuzz: sync reloaded monitors from their own best block

Public commit record

What the developer wrote

Authored by Joost Jager

83/100 · Strong
fuzz: sync reloaded monitors from their own best block

A node's channel monitors can be persisted at different heights, so on
reload they are not all at the same chain tip. Driving them to the tip
through the shared ChainMonitor from the oldest monitor's height replays
blocks that monitors already ahead have seen, which they interpret as a
reorg. That reorg discards force-close claims registered at a later
height, leaving the closed channel with no transaction to broadcast.

Sync each monitor to the tip from its own best block instead, and sync
the manager separately, matching LDK's per-listener startup contract.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a bug in LDK's internal fuzz testing harness (not production code). When the test reloaded saved channel data, it incorrectly synchronized all channel monitors from the oldest monitor's block height. Monitors that were already ahead got blocks replayed, which they interpreted as a blockchain reorganization. That fake reorg could discard already-registered force-close transactions, leaving a closed channel with nothing to broadcast. The fix makes each monitor catch up from its own saved height, matching how LDK expects real callers to do startup sync.

Recommended action

No production deployment action is required; this is a fuzz-test harness fix. Reviewers should confirm the new sync path exercises the same restart scenarios and that no production monitor/ChainMonitor code has the same bug. If a similar pattern exists in production startup code, it should be audited and fixed.

Security signals we found

01

Reorg-induced loss of force-close claim transactions in fuzz harness

02

Incorrect per-monitor startup synchronization in test code

03

Duplicate block replay treated as chain reorganization

04

Fix aligns test harness with LDK's per-listener startup contract

Risk score

Why this scored 26/100

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