Mempool Asymmetric Dos

Injectable Skill: Mempool Asymmetric DoS

L1 trigger: L1_PATTERN=true AND (txpool/ OR mempool/ OR tx_pool OR blob_pool OR reth-transaction-pool detected in recon subsystem map) Inject Into: depth-network-surface or depth-state-trace Language: Go and Rust Finding prefix: [MP-N] Status: v0.1 draft, Round 4 exemplars pending

Orchestrator Decomposition Guide

• Section 1, 2: depth-network-surface (entry cost vs eviction cost)
• Section 3: depth-state-trace (mempool state consistency)
• Section 4: depth-edge-case (boundaries of the pool)

When This Skill Activates

Recon identifies a mempool module. Mempools are uniquely exposed: every RPC client and every peer can insert transactions. The DETER paper (USENIX CCS '21) and MemPurge follow-ups showed that most production mempools had asymmetric cost models exploitable at near-zero attacker cost.

1. The Core Asymmetry Check

The DETER insight: if an attacker can insert transactions with lower cost than it takes to evict them, they can fill the pool faster than honest transactions can reclaim space.

For each mempool:

1. Identify the insert cost in (gas, fee, stake, or other resource): what does the attacker pay per byte of pool space occupied?
2. Identify the eviction threshold: when does a new higher-fee transaction kick out a lower-fee one?
3. Identify the eviction cost to the attacker: to evict an honest transaction, what must the attacker's replacement pay?
4. Compute the ratio: insert_cost / eviction_cost. If this is much less than 1, the pool is asymmetric.

Specific patterns:

1a. Invalid-but-accepted transactions

Transactions that are initially accepted into the pool but will later fail validation (nonce gap, insufficient balance, invalid signature for a new state root). These cost the attacker 0 but occupy space until the validator reprocesses them.

Check: Look for a "pending" vs "valid" split. When is validity re-checked? Can an attacker keep an invalid tx in "pending" indefinitely?

1b. Nonce-gap attacks

A transaction with a nonce 100 above the current nonce is "futureNonce" — it occupies space waiting for the lower-nonce gap to fill. Attacker sends 99 futureNonce placeholders + never sends the gap-filler.

Check: Is there a cap on futureNonce slots per account? What's the eviction policy when the cap is hit? Is the cap per-account or shared?

1c. Replace-by-fee (RBF) exploitation

If an attacker can replace a low-fee tx with a slightly-higher-fee tx indefinitely, they churn pool state and cost honest reorganization work. The Bitcoin min_relay_fee_increment and Ethereum's 10% bump rule address this — verify the implementation.

Check: What is the minimum fee bump for replacement? Is it enforced cumulatively (across multiple replacements) or only per-replacement?

1d. Blob pool asymmetry (post-EIP-4844)

Blob transactions have a separate gas market (blob_gas_price). If the blob pool eviction uses only blob-gas-price but insertion is cheap (or the pool is not strictly separated from legacy), asymmetric exploitation is possible.

Check: Is the blob pool size-capped independently of the main pool? Can an attacker spam blobs to evict legacy txs or vice versa?

Tag: [MP-ASYMMETRIC:{insert-cost}:{eviction-cost}:{ratio}]

2. Eviction Policy Correctness

When the pool is full, which transaction gets evicted?

Patterns to check

• Purely-fee-based: is the "cheapest" metric fee-per-gas, fee-per-byte, or absolute fee? Fee-per-gas is standard; absolute-fee allows large low-rate transactions to displace small high-rate ones.
• Per-sender quota: does any single sender have a hard cap? If not, one attacker fills the pool with one-sender transactions.
• Eviction cost consistency: does eviction correctly update all dependent state (sender's nonce tracking, per-topic indexes, reverse-lookup maps)?
• Deterministic ordering on ties: when two transactions have identical fee, which gets evicted? If it's random, it's non-deterministic across nodes.

Tag: [MP-EVICT:{policy}:{gap}]

3. Propagation Multiplier

A mempool bug is worse if the bad transaction propagates:

1. Does the node broadcast incoming transactions before validating them?
2. Is there a per-peer rate limit on transaction gossip?
3. Does the node track which peer sent which transaction to avoid re-sending?
4. What happens if a peer floods with transactions that all fail validation? Is the peer scored down?

Tag: [MP-PROPAGATE:{behavior}]

4. Ordering and Priority

For transactions that do make it into blocks, the ordering algorithm affects MEV and fairness:

• Priority-fee ordering: verify tie-break is deterministic (hash-based, not insertion-order)
• Fee-market simulation: if the client simulates optimal inclusion, is the simulation correctness verified?
• Bundle / PBS integration: if the mempool hands off to mev-boost or builder, what's the trust boundary? Any injection attack possible?

5. Blob pool specifics (Ethereum post-4844)

1. Blob transactions are large (>128KB each). The pool must cap total blob size.
2. Blob versioning: are versioned hash checks in place?
3. Blob retrieval: if blob data is requested from peers, is there a DoS vector in the retrieval path?
4. Blob expiry: 18-day retention. What happens when blobs are pruned mid-mempool-lifetime?

Tag: [BLOB:{concern}:{bound}]

6. Boundary conditions

Tag: [BOUNDARY:mempool:{state}:{result}]

7. Output schema

• Layer: mempool
• Bug class: asymmetric-cost / eviction-policy / propagation-amplification / ordering / blob-pool
• Preferred evidence tags: [FUZZ-PASS] (parameterized pool harness) > [LSP-TRACE] > [CODE-TRACE]
• Severity baseline: Medium-High; Critical if network-wide eviction of all honest transactions is demonstrated

8. Known bug exemplars (v0.2 — Round 4 verified)

1. DETER — Geth and 4 other Ethereum clients (USENIX CCS '21 + USENIX Security '24) — asymmetric eviction. Attackers send "future" nonce or "latent overdraft" transactions that pass cheap admission checks but are invalid at execution time. They fill the mempool and evict valid victim transactions at much lower cost to attacker than damage caused. Fixed in all major Ethereum clients as of Fall 2023. Mempool Symbolic Fuzzing USENIX '24; DETER 2.0. Skill catch point: Section 1 — the core asymmetry invariant. Insertion cost ≥ eviction damage.

2. MemPurge — Geth pending pool (USENIX '24) — chain-of-txs eviction. Attacker sends chain of ≤65 transactions that appear valid but become invalid after first executes. Attacker pays for only 1 tx worth of fees but evicts 65 honest txs. Combined with ConditionalExhaust, total attack cost ≈ $376 for full pool replacement. Speculative DoS paper; Yaish summary. Skill catch point: Section 1b — model multi-tx transitive validity; admission of tx_1 must account for worst-case state after tx_1 executes, not current state.

3. Geth GetHeadersFrom integer underflow (CVE-2024-32972) — GetHeadersFrom(number, count uint64) received count-1 where count was 0, producing UINT64_MAX and bypassing maxHeadersServe. Single p2p request forced node to stream all headers from latest back to genesis. GHSA-4xc9-8hmq-j652; fix in PR #29534, shipped v1.13.15. Skill catch point: boundary substitution — every p2p request handler with a count/range parameter must have underflow guard (subtraction below 0), overflow guard (u64 wraparound), and upper bound enforcement after arithmetic, not before. (Shared with p2p-dos-and-eclipse.)