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

Use usize for CompactSizeDecoder and add new_with_limit

Public commit record

What the developer wrote

Authored by Mitchell Bagot

73/100 · Adequate
Use usize for CompactSizeDecoder and add new_with_limit

Following the change to CompactSizeEncoder::new to take a usize, the
return types and ranges of the CompactSizeEncoder and CompactSizeDecoder
now differ. Since a device's memory addressing is limited to usize,
returning values beyond that size is largely useless. Converting the
CompactSizeDecoder to return a usize also allows the
cast_to_usize_if_valid function to be merged into the decoder itself.

Convert the CompactSizeDecoder to return a usize. Remove
cast_to_usize_if_valid and introduce its functionality into
CompactSizeDecoder.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens how the library decodes Bitcoin 'compact size' length fields. Previously the decoder could return a 64-bit value, which callers then had to convert to a machine-usable size. Now the decoder itself returns a usize and enforces a configurable upper limit. This is a defensive hardening change: it reduces the chance that a maliciously large length value causes memory problems or integer-conversion bugs later on. It is not a fix for a known active exploit.

Recommended action

Review downstream callers that previously handled u64 compact-size values or LengthPrefixInvalid errors; update them for the new usize output and unified CompactSizeDecoderError. Consider using new_with_limit in contexts where a lower bound than 4 MB is appropriate. No urgent patch is required solely on the basis of this commit.

Security signals we found

01

Bounds checking on decoded length prefixes moved earlier in the decode pipeline

02

Removal of a separate cast/validation step that could be skipped or misused by callers

03

New configurable limit constructor allows per-context stricter caps

04

No new cryptographic or memory-safety primitive introduced; existing DoS cap preserved

Risk score

Why this scored 33/100

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