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

p2p: Ignore CMPCTBLOCK from peer that hasn't sent SENDCMPCT

Public commit record

What the developer wrote

Authored by David Gumberg

83/100 · Strong
p2p: Ignore CMPCTBLOCK from peer that hasn't sent SENDCMPCT

This commit also changes the default sendcmpct version in the functional
test to `2`, since this is the version that nodes expect, prior to this
commit, nowhere in the functional test framework was the default version
value used:

git grep -P 'msg_sendcmpct\((?![^)]*version\s*=)' HEAD^

`version=2` is a sensible default, since this is the version nodes
currently expect in the SENDCMPCT handshake.
✓ 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 Bitcoin Core update tightens the rules for compact block messages. Before the change, a peer could send a compressed block (CMPCTBLOCK) even if it had never advertised support for compact blocks via the SENDCMPCT handshake. The fix makes the node ignore such unexpected CMPCTBLOCK messages. The commit also updates the test framework so that simulated peers use the current compact-block version 2 by default. This is a hardening change that reduces the attack surface for malformed or unexpected compact-block traffic, but the commit message does not describe it as a security fix and no exploit is demonstrated.

Recommended action

Treat as a defensive hardening patch. Review whether any downstream logic assumed CMPCTBLOCK implies a prior SENDCMPCT, and verify that the new check does not interfere with legitimate compact-block relay. No urgent security response is indicated by the commit materials alone.

Security signals we found

01

New input-validation gate before deserialization of peer message

02

Peer-state flag (m_provides_cmpctblocks) now enforced for CMPCTBLOCK

03

Functional tests extended to cover unsolicited and solicited CMPCTBLOCK from non-announcing peers

04

Default protocol version in test framework updated to current version 2

Risk score

Why this scored 47/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 7/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.