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

p2p: Drop unsolicited CMPCTBLOCK from non-HB peer

Public commit record

What the developer wrote

Authored by David Gumberg

88/100 · Strong
p2p: Drop unsolicited CMPCTBLOCK from non-HB peer

Processing unsolicited CMPCTBLOCK's from a peer that has not been marked
high bandwidth is not well-specified behavior in BIP-0152, in fact the
BIP seems to imply that it is not permitted:

"[...] method is not useful for compact blocks because `cmpctblock`
blocks can be sent unsolicitedly in high-bandwidth mode"

See https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#separate-version-for-segregated-witness

This partially mitigates a mempool leak described in
[#28272](https://github.com/bitcoin/bitcoin/issues/28272), but that
particular issue will persist for peers that have been selected as high
bandwidth.

This also mitigates potential DoS / bandwidth-wasting / abusive
behavior that is discussed in the comments of #28272.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This Bitcoin Core change tightens the rules for a fast block-relay feature called compact blocks (BIP 152). Previously, any peer could send a compact block announcement without being asked. Now, if a peer sends one without being marked as a 'high-bandwidth' peer and without the node having requested the block from them, the message is ignored. The commit says this partly closes a known mempool information leak and reduces the risk of bandwidth-wasting abuse, but it is only a partial fix because high-bandwidth peers can still send unsolicited compact blocks.

Recommended action

Review whether the remaining exposure through high-bandwidth peers is acceptable, and consider additional mempool privacy hardening for issue #28272. Operators should upgrade to include this partial mitigation.

Security signals we found

01

Unsolicited network message now dropped

02

Partial mitigation of reported mempool privacy leak (#28272)

03

DoS/bandwidth-waste mitigation mentioned by committer

04

BIP 152 behavior clarification/enforcement

05

Test changes add explicit solicitation (headers/getdata) before compact block sends

Risk score

Why this scored 58/100

Our methodology →
Potential impact 14/30
Exploitability 13/25
Stealth signal 9/15
Affected reach 10/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.