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

private broadcast: limit outstanding txs to count of 10,000

Public commit record

What the developer wrote

Authored by Gregory Sanders

73/100 · Adequate
private broadcast: limit outstanding txs to count of 10,000

Add a belt-and-suspenders feature, limit the amount of
memory and cpu possible when unlucky or simply misconfigured.
The worst case limit is roughly 400kB * 10,000 = 4GB, regardless
of usage pattern.

Before this change, sheer volume of broadcasts, mismatches in
standardness rules, or simply fee mismatches may result in unbounded
growth of memory usage. As the feature may be expanded in
the future, explicit bounds helps reasoning going forward.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a hard cap of 10,000 transactions to Bitcoin Core's private-broadcast queue. Before the change, that queue could grow without bound, potentially consuming large amounts of memory and CPU if many transactions were submitted, if network rules differed between nodes, or if fees were set badly. The patch rejects new submissions once the cap is reached, returning a clear RPC error instead of silently growing. It is a defensive hardening change, not a fix for an active exploit.

Recommended action

Treat as a hardening improvement. Operators using -privatebroadcast should be aware that sendrawtransaction may now fail with 'Private broadcast queue is full' when the queue is saturated; they can use abortprivatebroadcast or wait for broadcasts to complete. No emergency action is required.

Security signals we found

01

Unbounded memory growth in private broadcast queue is bounded

02

New error path returns TransactionError::PRIVATE_BROADCAST_FULL

03

RPC error mapping added: RPC_OUT_OF_MEMORY

04

Defensive resource-limiting ('belt-and-suspenders')

05

No eviction policy: queue rejects rather than drops existing entries

Risk score

Why this scored 45/100

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