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

Do not allow mempool clusters to exceed configured limits

Public commit record

What the developer wrote

Authored by Suhas Daftuar

95/100 · Strong
Do not allow mempool clusters to exceed configured limits

Include an adjustment to mempool_tests.cpp due to the additional memory used by
txgraph.

Includes a temporary change to the mempool_ephemeral_dust.py functional test,
due to validation checks being reordered. This change will revert once the RBF
rules are changed in a later commit.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This Bitcoin Core commit enforces a new mempool policy: groups of related unconfirmed transactions ('clusters') are now capped by configured size and count limits. Previously these limits existed as settings but were not fully enforced by the new in-memory transaction graph. The patch wires the limits into the graph, rejects submissions that would exceed them, and removes transactions from the mempool when a newly accepted block creates oversized clusters. It also reorders some validation checks so cluster-size rejection happens before certain standardness checks, which is why one functional test was temporarily adjusted.

Recommended action

Treat as a policy-hardening improvement rather than an emergency vulnerability fix. Node operators and miners should review -limitclustersize / -limitclustercount settings. Developers should verify the temporary functional-test change is reverted once RBF rule reordering is finalized, as noted in the commit message.

Security signals we found

01

Denial-of-service hardening: caps mempool cluster memory/CPU exposure

02

New validation rejection: 'too-large-cluster'

03

Mempool eviction path added after block connection

04

Reordering of policy checks relative to ephemeral dust checks

05

Hardcoded cluster constants replaced with configurable limits

Risk score

Why this scored 47/100

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