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

net_processing: add a global delay queue for sending txs

Public commit record

What the developer wrote

Authored by Anthony Towns

90/100 · Strong
net_processing: add a global delay queue for sending txs

Without the per-peer rate limiting, nodes can act as an amplifier for
transaction spam -- receiving many transactions from one node, but
relaying each of them to over 100 other nodes. Limit the impact of this
by providing a global rate limit.

This is implemented using dual token buckets, one that consumes a
token for every transaction, and one that consumes a token for every
serialized byte. This rate limits both per-tx resource usage (eg INV
messages) and overall relay bandwidth.

Main bucket parameters:
* Count: 14tx/s rate, 420tx (30s) capacity
* Size: 12MB/600s rate (4-6 blocks per target block interval), 50MB capacity

The size bucket is expected to be large enough to almost never have an
impact in normal usage, even during transaction storms, and is primarily
intended to mitigate attack-like scenarios.

Outbound connections get a separate pair of buckets, with rates boosted
by a 2.5x multiplier.

This avoids the excessive memory and CPU usage due to the 100x multiplier
from the queues being per-peer.

Note that this also reduces the size of INV messages we send for general
tx relay back to a more reasonable level of under 600 txs in 99.999%
of cases.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a global rate limiter to how many transaction announcements (INV messages) a Bitcoin node sends out. Before, each peer had its own queue, so a node could receive one transaction and announce it to over 100 peers, acting like an amplifier for spam and wasting bandwidth and CPU. The new code caps both the number of transactions announced per second and the total bytes announced, with higher limits for outbound peers. It also changes transaction broadcast to use a single shared backlog sorted by mempool quality, rather than per-peer queues. This is a defensive hardening change, not an active vulnerability fix, and the commit message explicitly frames it as mitigating transaction-spam amplification.

Recommended action

Treat as a hardening improvement rather than an urgent vulnerability patch. Reviewers should verify that the global backlog and token-bucket logic do not introduce new denial-of-service paths (e.g., lock contention on m_inv_to_send_mutex, unfair prioritization, or edge cases when no peers are connected), and confirm the functional test changes adequately cover rate-limited broadcast behavior.

Security signals we found

01

Global rate limiting replaces per-peer queues to prevent transaction-announcement amplification

02

Dual token buckets bound both INV count and relay bandwidth

03

Commit message explicitly describes the change as limiting transaction-spam amplification and excessive memory/CPU usage

04

Backlog ordering uses mempool mining-score topology, potentially affecting which transactions are prioritized for relay

05

New mutex m_inv_to_send_mutex added with lock-ordering annotations relative to mempool.cs

Risk score

Why this scored 63/100

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