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

Return `BestBlock` when deserializing chain-synced structs

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Return `BestBlock` when deserializing chain-synced structs

The deserialization of `ChannelMonitor`, `ChannelManager`, and
`OutputSweeper` is implemented for a `(BlockHash, ...)` pair rather
than on the object itself. This ensures developers are pushed to
think about initial chain sync after deserialization and provides
the latest chain sync state conviniently at deserialization-time.

In the previous commit we started storing additional recent block
hashes in `BestBlock` for use during initial sync to ensure we can
handle reorgs while offline if the chain source loses the
reorged-out blocks. Here, we move the deserialization routines to
be on a `(BestBlock, ...)` pair instead of `(BlockHash, ...)`,
providing access to those recent block hashes at
deserialization-time.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how Lightning Dev Kit (LDK) deserializes (reloads from disk) important chain-following objects like ChannelMonitor and ChannelManager. Previously, deserialization returned just a single latest block hash paired with the object. Now it returns a BestBlock structure that includes the latest block hash plus a short history of recent block hashes. This is a defensive, API-shaping change intended to make downstream developers handle initial chain sync more safely after a restart, especially if the Bitcoin chain source has lost blocks from a reorganization while the node was offline. It is not a patch for an active exploit; it is a hardening/refactoring change that improves resilience against reorgs during startup.

Recommended action

Treat this as a hardening/API improvement rather than an urgent vulnerability fix. Downstream projects using LDK should update their deserialization call sites from (BlockHash, ChannelMonitor/ChannelManager) to (BestBlock, ChannelMonitor/ChannelManager) and use BestBlock.block_hash (and any future BestBlock fields) when registering chain listeners. Review initial chain-sync logic to ensure it can disconnect/reconnect the recent blocks now exposed by BestBlock. No immediate patch deployment is required solely on the basis of this commit.

Security signals we found

01

API change pushes developers to use richer chain-sync state on startup

02

BestBlock carries recent block hashes to handle reorgs while offline

03

Deserialization target changed from (BlockHash, _) to (BestBlock, _) for ChannelMonitor, ChannelManager, OutputSweeper

04

Persistence helpers (read_channel_monitors, etc.) updated to return BestBlock

05

Documentation and examples updated to use .block_hash field of BestBlock

06

No new input validation, bounds checking, or memory-safety code visible in diff

Risk score

Why this scored 29/100

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