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

validation: make `IsInitialBlockDownload()` lock-free

Public commit record

What the developer wrote

Authored by Lőrinc

83/100 · Strong
validation: make `IsInitialBlockDownload()` lock-free

`ChainstateManager::IsInitialBlockDownload()` is queried on hot paths and previously acquired `cs_main` internally, contributing to lock contention.

Cache the IBD status in `m_cached_is_ibd`, and introduce `ChainstateManager::UpdateIBDStatus()` to latch it once block loading has finished and the current chain tip has enough work and is recent.
Call the updater after tip updates and after `ImportBlocks()` completes.

Since `IsInitialBlockDownload()` no longer updates the cache, drop `mutable` from `m_cached_is_ibd` and only update it from `UpdateIBDStatus()` under `cs_main`.

Update the new unit test to showcase the new `UpdateIBDStatus()`.

Co-authored-by: Patrick Strateman <patrick.strateman@gmail.com>
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
✓ 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 is a performance optimization, not a security fix. It changes how Bitcoin Core decides whether it is still downloading the historical blockchain (Initial Block Download, or IBD). Previously, every check for IBD status had to grab a global lock, which could slow down busy code paths. Now the status is cached in an atomic variable and only updated at specific safe points. There is no evidence in the commit or supplied references that this fixes a vulnerability or is being exploited.

Recommended action

No security action required. Treat as a normal performance/refactoring change. Reviewers may want to verify that UpdateIBDStatus() is called on all relevant tip-update paths and that the lock-free read cannot observe a stale true value indefinitely, but the commit explicitly documents this trade-off.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 14/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 9/10
Evidence quality 5/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.