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

Drop the need for fork headers when calling `Listen`'s disconnect

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Drop the need for fork headers when calling `Listen`'s disconnect

The `Listen::block_disconnected` method is nice in that listeners
learn about each block disconnected in series. Further, it included
the header of the block that is being disconnected to allow the
listeners to do some checking that the interface is being used
correctly (namely, asserting that the header's block hash matches
their current understanding of the best chain).

However, this interface has some substantial drawbacks. Namely, the
requirement that fork headers be passed in means that restarting
with a new node that has no idea about a previous fork leaves us
unable to replay the chain at all. Further, while when various
listeners were initially written learning about each block
disconnected in series seemed useful, but now we no longer rely on
that anyway because the `Confirm` interface does not allow for it.

Thus, here, we replace `Listen::block_disconnected` with a new
`Listen::blocks_disconnected`, taking only information about the
fork point/new best chain tip (in the form of its block hash and
height) rather than information about previous fork blocks and only
requiring a single call to complete multiple block disconnections
during a reorg.

We also swap to using a single `BestBlock` to describe the new
chain tip, in anticipation of future extensions to `BestBlock`.

This requires removing some assertions on block disconnection
ordering, but because we now provide `lightning-block-sync` and
expect users to use it when using the `Listen` interface, these
assertions are much less critical.
✓ 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 the Lightning Dev Kit (LDK) library is told about blockchain reorganizations. Previously, callers had to provide the full headers of every block being disconnected, one at a time. Now they only provide the new 'fork point' (the last block that is still on both the old and new chain). This makes it easier to recover from deep reorgs or switch to a new node that doesn't have old fork headers. The change removes some internal consistency checks that relied on seeing each disconnected block in order, which slightly weakens defensive assumptions but is described by the authors as acceptable because LDK now provides its own block-sync helper.

Recommended action

Treat as a design-level change rather than an acute vulnerability. Review downstream callers that implement `Listen` directly to ensure they correctly compute the fork point and do not rely on the removed per-block disconnection ordering. Audit the modified `ChannelMonitor` and `Sweeper` reorg handling for edge cases around exactly-height-matched confirmations. Consider regression tests for deep reorgs and for switching block sources without fork headers.

Security signals we found

01

API contract relaxation: listeners lose per-block header verification during reorgs

02

Assertion downgrade: in-order disconnection guarantees replaced by height-decrease check

03

Behavioral change in ChannelMonitor: threshold-conf event retention condition altered from `< height` to `<= new_height`

04

Behavioral change in ChannelMonitor: alternative funding confirmation now cleared when conf_height > new_height instead of equality

05

Sweeper unconfirmation logic changed from hash-match to height comparison

06

No explicit security framing by vendor; appears as routine interface redesign

Risk score

Why this scored 33/100

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