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

primitives: Simplify and optimize witness decoder

Public commit record

What the developer wrote

Authored by jrakibi

68/100 · Adequate
primitives: Simplify and optimize witness decoder

The current logic for the index space in witness decoder lets an
attacker allocate a claimed size without giving any input, which opens
the door to many DoS attacks, some of which we already handle.

But the current code still lets an attacker force a 16 MB allocation
with ~10 bytes of input.

The new logic pushes bytes blindly into `content` without building the
index space in `push_bytes()`, then in `end()` walks through `content`
to build the index space.

This simplifies the code, gives an important speedup, and avoids:

- the 16 MB up-front allocation we currently have for the index space
- `reserve_batch()` is no longer needed, along with the
`MIN_` and `MAX_VECTOR_ALLOCATE` constants

- we can drop the `cursor` field from the decoder
- the DoS vector where an attacker sends a few bytes to force a large
allocation, since the buffer only grows by the bytes actually received
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a denial-of-service (DoS) weakness in how the rust-bitcoin library decodes Bitcoin transaction witness data. Previously, an attacker could send only about 10 bytes of data and trick the decoder into reserving 16 MB of memory up front. The new code only allocates memory for bytes that have actually arrived, making memory-exhaustion attacks much harder. The commit also simplifies the code and removes several helper functions and constants.

Recommended action

Treat this as a security-hardening fix and include it in the next maintenance release. Users parsing untrusted witness data should upgrade. No immediate CVE is required unless a reproducible crash or OOM exploit is demonstrated, but the DoS relevance is explicitly described in the commit message.

Security signals we found

01

Denial-of-service vector: small input forcing large memory allocation

02

Memory allocation now proportional to bytes actually received

03

Removal of reserve_batch and MAX_VECTOR_ALLOCATE/MIN_VECTOR_ALLOCATE constants

04

Index space built only at finalization in end()

05

Regression test confirms no massive up-front allocation

Risk score

Why this scored 68/100

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