Resource Exhaustion Attack

A resource exhaustion attack is the broad category of denial-of-service attacks where the attacker tries to use up a target node's CPU, memory, disk, or bandwidth so the node fails or becomes useless.

The shapes a resource exhaustion attack can take against Bitcoin nodes:

• Mempool spam. Flood the network with low-fee transactions to fill up mempool memory. Mitigated by a size cap on each node's mempool, 300 MB of memory by default in Bitcoin Core. When the mempool is full, the node evicts the transactions paying the lowest fee rate and raises the minimum fee rate it will accept, so the spam has to actually pay competitive fees, which gets expensive.
• CPU exhaustion via expensive scripts. With Bitcoin's original signature scheme, checking each signature means hashing data that grows with the size of the whole transaction, so for a big transaction full of signatures the total work grows roughly with the square of its size. BIP 143 gives a 2015 example: a normal 1 MB block took about 2 seconds to verify, but a single 1 MB transaction with 5,569 signature operations could take 25 seconds. BIP 143, part of the SegWit upgrade, fixed this for the new inputs SegWit introduced, which hash the shared parts of a transaction once and reuse the result. Older-style inputs still work the old way, so Bitcoin Core will not relay a transaction heavier than 400,000 weight units, a tenth of a block. Its code says this cap "mitigates CPU exhaustion attacks."
• Bandwidth flooding. Send oversized or endless INV, addr or getdata messages, or keep asking for data, so the node spends its bandwidth, memory and CPU on garbage. Bitcoin Core rejects any message over 4 MB, disconnects a peer that sends an INV message listing more than 50,000 items, and processes on average no more than one address every ten seconds from each peer. Operators can also cap upload traffic with the -maxuploadtarget setting, which is unlimited by default.
• Connection slot exhaustion. Open many incoming connections to fill the node's inbound slots. Bitcoin Core allows 125 connections by default and keeps 11 of them for connections it opens itself (8 full-relay, 2 block-relay-only and 1 "feeler"), so incoming peers can never take them all.
• Disk exhaustion. Make the node fill up its disk. Bitcoin Core 30.0 (October 2025) fixed two bugs of this kind: an attacker could fill a node's disk by faking connections from the node to itself over a long time, or by sending it invalid blocks over and over.
• Bug exploits. Attacks aimed at specific bugs in node software. CVE-2018-17144, fixed in September 2018, was both a denial-of-service bug and an inflation bug. Bitcoin Core's security advisories list many other fixed bugs where spammed or malformed P2P messages (addr, INV, getdata, headers) could crash a node or use up its memory or CPU.

The defense layers:

• Consensus rules. Limits every node enforces on blocks, such as the block weight limit of 4 million weight units and a cap on signature operations per block, plus SegWit's faster signature hashing.
• Bitcoin Core's relay policy. Rules each node applies to unconfirmed transactions and to its peers: the mempool size cap and eviction, the 400,000 weight-unit cap on the transactions it relays, a default limit of 64 linked unconfirmed transactions in one cluster, message size caps, rate limits, and connection slot management.
• Per-peer consequences. A peer that breaks certain protocol rules is disconnected after a single offense, and its address is "discouraged": the node will not connect out to it or pass its address on, and drops it first when it needs room for new incoming peers. Bitcoin Core used to ban misbehaving peers automatically. Now a ban happens only when the operator sets one with the setban command.
• The economic floor. A full mempool raises the fee rate a transaction needs to get in, and spam that gets mined costs its sender real fees.

Bitcoin Core's own code points out the limit of blocking peers: neither banning nor discouraging an address protects against a denial-of-service attack, because the attacker can reconnect from another IP address. Most of the defenses above work differently. They cap what any single message, transaction or connection can cost a node, whoever sends it.