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

p2p: make SendCmpct encode/decode idempotent

Public commit record

What the developer wrote

Authored by yancy

88/100 · Strong
p2p: make SendCmpct encode/decode idempotent

Normalizing the mode bit makes serialization/deserealiztion _not_
idempotent. That's due to the checksum that's created before
normalization which if serialized again, no longer has the same
checksum. This cases a failure to serialize the same `SendCmpct` which
was received if the mode bit is anything other then 0 or 1.
Furthermore, the spec https://bips.dev/152/ defines only 0
(low-bandwidth mode) or 1 (high-bandwidth mode) so anything other than
0 or 1 is unspecified and should result in an error.

As quoted from spec https://bips.dev/152/:
The first integer SHALL be interpreted as a boolean (and MUST have a
value of either 1 or 0)
✓ 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 change fixes a serialization bug in how the rust-bitcoin library handles a Bitcoin peer-to-peer message called `sendcmpct`. Previously, if a malformed or unusual message arrived with a mode value other than 0 or 1, the library would silently normalize it to true/false. That normalization changed the message bytes, so if the library later tried to re-send the exact message it had received, the message checksum would no longer match, causing a serialization failure. The patch now rejects any mode value other than 0 or 1, matching the BIP 152 specification, and reports a clear decoding error instead of silently altering the data.

Recommended action

Review whether any other P2P message decoders silently normalize multi-value fields into booleans or smaller types, as similar idempotency issues may exist elsewhere. Consider adding roundtrip tests for all P2P messages with edge-case byte values.

Security signals we found

01

Non-idempotent encode/decode roundtrip for network messages

02

Silent normalization of out-of-spec protocol field

03

Checksum mismatch on re-serialization of received messages

04

Validation now enforces BIP 152 boolean constraint (0 or 1)

Risk score

Why this scored 37/100

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