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

p2p: add BlockLocator newtype with logarithmic build

Public commit record

What the developer wrote

Authored by Peter Zafonte

73/100 · Adequate
p2p: add BlockLocator newtype with logarithmic build

Replace the bare Vec<BlockHash> in GetBlocksMessage and GetHeadersMessage
with a BlockLocator newtype. Add BlockLocator::build, which constructs a
logarithmic locator based on Bitcoin Core's LocatorEntries() via a
caller-supplied get_ancestor closure, keeping chain state out of this
crate's imports. Cap the locator at MAX_LOCATOR_HASHES (101), matching
Bitcoin Core's MAX_LOCATOR_SZ.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how Bitcoin peer-to-peer messages request blocks and headers. It replaces a plain list of block hashes with a dedicated 'BlockLocator' type and adds a helper to build locators in a logarithmic pattern (like Bitcoin Core). There is no direct security fix here; it is a structural improvement that makes the library behave more like Bitcoin Core and could indirectly reduce network/DoS risks by capping locator size and producing better locators.

Recommended action

No immediate security action required. Treat as a normal refactor/API improvement. Reviewers may want to verify that the new BlockLocator::build logic exactly matches Bitcoin Core's LocatorEntries() and that the MAX_LOCATOR_HASHES cap is enforced during both encoding and decoding.

Security signals we found

01

Adds a hard cap on locator size (MAX_LOCATOR_HASHES = 101), matching Bitcoin Core, which limits memory/serialization exposure

02

Replaces linear/arbitrary locator construction with logarithmic spacing, improving P2P sync behavior and reducing worst-case message sizes

03

No input validation bypass, memory safety bug, or cryptographic issue is visible in the diff

Risk score

Why this scored 21/100

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