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

net processing: Check if we are in ibd before processing block for txdownloadman

Public commit record

What the developer wrote

Authored by sedited

83/100 · Strong
net processing: Check if we are in ibd before processing block for txdownloadman

This avoids wasting work on calculating bloom filters that aren't
consumed during ibd and continuously re-calculated as now blocks get
validated.

Also update the functional test to document that transactions would now
be requested again once out of IBD.

Co-authored-by: Lőrinc <pap.lorinc@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 stops Bitcoin nodes from building unnecessary 'bloom filters' (a data structure used to track recently confirmed transactions) while they are still downloading the historical blockchain (IBD). Previously, the node wasted CPU recalculating these filters for old blocks even though it wasn't accepting new transactions from peers yet. The functional test was updated to reflect that transactions confirmed during IBD will now be requested again once the node is fully synced, because those filters were not built during IBD.

Recommended action

No security action required. Treat as a routine performance and behavior-correctness change. Reviewers may want to confirm that skipping BlockConnected during IBD does not cause any edge cases in transaction reconciliation once IBD completes, but the change is straightforward and well-documented.

Security signals we found

01

Behavior change in transaction download/re-request logic after IBD

02

Performance optimization reducing redundant bloom filter computation

03

Functional test inversion: previously-expected filter membership is now negated

Risk score

Why this scored 21/100

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