Bandwidth Attack

What Is a Bandwidth Attack?

A bandwidth attack is a type of denial-of-service (DoS) attack that targets a Bitcoin node by flooding it with excessive or malicious peer-to-peer messages. The goal is to exhaust the victim's network bandwidth, memory, or processing power, causing it to slow down, disconnect from peers, or crash entirely. Because Bitcoin's P2P network is open and permissionless, any node can connect and begin sending messages, making bandwidth attacks a persistent concern for node operators.

Unlike an eclipse attack, which aims to isolate a node by controlling all its peer connections, a bandwidth attack focuses on resource exhaustion. The attacker does not need to manipulate the victim's view of the blockchain: they simply want to degrade or disable the node's ability to participate in the network.

How It Works

Bandwidth attacks exploit the Bitcoin P2P protocol by sending messages that are individually valid (or valid-looking) but collectively overwhelming. The attacker takes advantage of asymmetric costs: sending messages is cheap, but processing, storing, and relaying them is expensive for the victim.

INV Message Flooding (CVE-2018-17145)

The most well-documented bandwidth attack on Bitcoin nodes. Inventory (inv) messages announce new transactions or blocks to peers. An attacker floods a victim with inv messages, each containing up to 50,000 transaction hashes. The victim's node queues these for processing but can exhaust available memory before it can handle them all.

This vulnerability, tracked as CVE-2018-17145, was discovered by Braydon Fuller and affected Bitcoin Core versions 0.16.0 and 0.16.1, Bitcoin Knots 0.16.x, all beta versions of bcoin through v1.0.0-pre, and btcd through v0.20.1-beta. It was privately patched and disclosed publicly in September 2020. Litecoin, Namecoin, Decred, and Bitcoin Cash were also affected.

Large Transaction Spam

Attackers craft many transactions at or near the maximum standard size (100,000 vBytes / 400,000 weight units) and broadcast them across the network. Every node that accepts these transactions into its mempool must relay them to peers, consuming bandwidth and memory at each hop. The July 2015 flood attack used this approach, sending hundreds of thousands of low-value transactions and leaving over 80,000 unconfirmed in the mempool. During a 10-day peak, approximately 23% of all transactions were spam, average confirmation delays rose from 20 minutes to over 2.5 hours, and the estimated attack cost was around 201 BTC.

Bloom Filter Abuse

BIP 37 introduced bloom filters to allow lightweight (SPV) clients to request only relevant transactions from full nodes. However, maliciously crafted filters with high false-positive rates forced full nodes to test every transaction against the filter and send far more data than necessary. The computational burden was heavily asymmetric: cheap for the attacker, expensive for the serving node. Bitcoin Core disabled NODE_BLOOM service by default in version 0.19 (2019), and BIP 111 added a service bit so nodes can signal whether they serve bloom filter requests. Compact block filters (BIP 157/158) now provide a safer alternative for light client filtering.

ADDR Message Flooding

The addr message relays peer connection information for decentralized peer discovery. An attacker can flood the network with fabricated addr messages containing fake IP addresses, polluting nodes' address managers. This consumes bandwidth and can serve as preparation for Sybil or eclipse attacks by filling address tables with attacker-controlled entries. Bitcoin Core addressed this with a token-bucket rate limiter (PR #22387) that restricts addr processing to an average of 0.1 addresses per second per connection, with bursts up to 1,000 addresses.

Defenses and Mitigations

Bitcoin Core has implemented multiple layers of defense against bandwidth attacks, combining protocol-level policies, peer management, and network optimizations.

Mempool Policy Rules

Mempool policy serves as the first line of defense by making spam economically costly and rejecting obviously wasteful transactions:

• Minimum relay fee: nodes reject transactions below a configurable feerate threshold, forcing attackers to pay real fees for every spam transaction
• Maximum standard transaction weight of 400,000 WU (100,000 vBytes) prevents single oversized transactions from consuming excessive bandwidth
• Standardness checks reject valid-by-consensus but non-standard transactions, narrowing the attack surface for relay-based spam
• Replace-by-fee rules require replacement transactions to pay an absolute fee at least equal to the sum of replaced transactions, preventing attackers from cheaply cycling through many replacements
• Default mempool size limit of 300 MB evicts the lowest-feerate transactions when full, creating a natural price floor that pushes out spam during congestion

For a deeper look at how mempool economics interact with congestion and fee markets, see Bitcoin mempool congestion economics.

Peer Misbehavior Scoring

Bitcoin Core tracks a per-peer misbehavior score. Each protocol violation adds points: for example, sending an invalid block header or a duplicate version message. When the score reaches 100, the node disconnects the peer and discourages reconnection from that address for 24 hours. This system catches many straightforward protocol-level abuses, though it is less effective against sophisticated attackers who stay within protocol boundaries.

Connection Management

Nodes maintain distinct connection types to limit exposure:

• Block-relay-only connections do not participate in addr or transaction relay, reducing the attack surface for bandwidth-based spam
• Anchor connections (saved in anchors.dat) get highest reconnection priority, making it harder for attackers to displace trusted peers
• Network diversity logic ensures connections span different network types (IPv4, IPv6, Tor, I2P, CJDNS) to resist both bandwidth and eclipse attacks

Protocol-Level Bandwidth Optimizations

Several protocol improvements reduce baseline bandwidth consumption, leaving more headroom to absorb attack traffic:

• Compact blocks (BIP 152): reduces block propagation bandwidth by approximately 98%, sending only short transaction IDs instead of full block data
• Erlay (BIP 330): replaces flood-based transaction announcement with set reconciliation, reducing transaction relay bandwidth by roughly 40% and making bandwidth nearly constant regardless of peer count (still under development as of 2026)
• BIP 324 (v2 transport): provides encrypted P2P communication using ChaCha20-Poly1305. While it does not directly prevent bandwidth attacks from connected peers, it prevents network-level observers (ISPs, state actors) from selectively throttling or manipulating Bitcoin traffic based on message content, and makes BGP hijacking attacks detectable

Bandwidth Attacks vs. Related Attacks

Bandwidth attacks are often confused with eclipse and Sybil attacks, but each targets a different layer of the network:

These attacks often work together: an attacker might use addr message flooding (a bandwidth vector) to pollute address tables as preparation for a Sybil attack, which in turn enables eclipsing specific targets. A bandwidth attack can also serve as a distraction while executing a more targeted eclipse attack.

Historical Incidents

Several real-world events illustrate how bandwidth attacks affect the Bitcoin network:

• July 2015 flood attack: attackers sent hundreds of thousands of low-value transactions over 10 days. Approximately 23% of all transactions during the peak were spam, mempool grew to contain over 80,000 unconfirmed transactions, and roughly 10% of nodes went offline during a follow-up attack in October 2015
• CVE-2018-17145 (InvDoS): a memory exhaustion vulnerability where excessive inv messages could crash affected nodes. Discovered privately and patched before public exploitation, affecting multiple Bitcoin implementations
• 2023 Ordinals congestion: while not a traditional attack, inscription data caused the mempool to swell from approximately 7 million vBytes to nearly 248 million vBytes, demonstrating how even legitimate-but-heavy usage can produce bandwidth-attack-like effects

Why It Matters

Bandwidth attacks threaten the decentralization and reliability of the Bitcoin network. If running a full node requires excessive bandwidth to withstand attacks, fewer individuals and organizations will operate nodes, concentrating the network among well-resourced operators. This makes censorship resistance harder to maintain.

For layer-2 protocols like the Lightning Network and Spark, the health of the base layer matters directly. Nodes that cannot reliably receive and broadcast transactions may miss critical channel state updates, creating security risks for off-chain protocols. Protocol-level bandwidth optimizations benefit the entire stack, from base-layer nodes to the applications built on top.

Risks and Considerations

Evolving Attack Surface

As Bitcoin's protocol evolves, new features can introduce unexpected bandwidth attack vectors. Taproot witness data, Ordinals inscriptions, and novel transaction types all expand the design space that attackers can exploit. Each protocol change requires careful analysis of its bandwidth implications.

Resource-Constrained Nodes

Nodes running on limited hardware (such as Raspberry Pi devices or connections with data caps) are disproportionately vulnerable. The October 2015 attack took approximately 10% of nodes offline, primarily those on memory-constrained hardware. This creates a tension between keeping node requirements low for decentralization and hardening against bandwidth attacks.

Economic Cost of Defense

Mempool policy rules that defend against spam (minimum relay fees, standardness checks) also limit legitimate use cases. Setting the minimum relay fee too high prices out micropayments; setting it too low makes spam cheap. Operators must balance openness with resilience, and these tradeoffs are an ongoing area of debate among Bitcoin Core developers.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.