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

Replace `Cache::block_disconnected` with `blocks_disconnected`

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Replace `Cache::block_disconnected` with `blocks_disconnected`

In 403dc1a48bb71ae794f6883ae0b760aad44cda39 we converted the
`Listen` disconnect semantics to only pass the fork point, rather
than each block being disconnected. We did not, however, update the
semantics of `lightning-block-sync`'s `Cache` to reduce patch size.

Here we go ahead and do so, dropping
`ChainDifference::disconnected_blocks` as well as its no longer
needed.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a follow-up code cleanup in rust-lightning's block synchronization module. It changes how the code handles blockchain reorganizations (when the chain temporarily forks and then switches to a different branch). Previously, the code tracked and notified about each individual block that was disconnected; now it only passes the fork point, matching an earlier change made to the main listener interface. The commit removes an internal list of disconnected blocks and updates the cache API accordingly. There is no direct evidence in the commit that this fixes a security vulnerability.

Recommended action

Treat as a normal refactoring/correctness commit. Reviewers should verify that the new fork-point-only semantics correctly invalidate cached headers during reorgs and that `BestBlock` is constructed with the correct height and hash. No immediate security response is indicated by the commit itself.

Security signals we found

01

API semantic alignment after prior listener disconnect change

02

Removal of per-block disconnect tracking in favor of fork-point notification

03

No explicit security bug, CVE, or vulnerability description in commit

04

Potential for subtle correctness issues around reorg handling if fork point height/hash mismatched

Risk score

Why this scored 21/100

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