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

p2p: calculate v1 checksum on original payload

Public commit record

What the developer wrote

Authored by Nick Johnson

90/100 · Strong
p2p: calculate v1 checksum on original payload

A differential fuzz test found a malformed v1 message which *passed*
its checksum validation due to the checksum being calculated on a
re-encoded payload instead of the raw payload bytes. Due to wiggle room
in the p2p spec, re-encoded payloads can differ from the raw bytes which
results in a different checksum.

This change calculates the checksum on the fly agianst the raw payload
bytes to avoid the ambiguity.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a bug in how Bitcoin peer-to-peer network messages are validated. The software was checking message checksums against a re-encoded version of the message payload rather than the original bytes received over the network. Because the protocol allows some wiggle room in encoding, a re-encoded payload can have a different checksum than the original raw bytes. This meant a malformed message could pass checksum validation when it should have been rejected. The fix computes the checksum directly from the raw bytes as they arrive, removing that ambiguity.

Recommended action

Review whether any other protocol versions or message decoders in the crate compute checksums over re-encoded payloads and apply the same raw-byte hashing pattern. Consider adding regression tests from the differential fuzz corpus and verify that the new checksum engine correctly handles partial/chunked payload reads.

Security signals we found

01

checksum validation bypass due to canonicalization/re-encoding

02

differential fuzz test finding

03

peer-to-peer protocol message integrity issue

04

hash computed over re-encoded data instead of raw input

Risk score

Why this scored 62/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/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.