Eclipse Attack

“Imagine you wake up, look out the window, and every single one of your neighbors has been replaced by a clone of your worst enemy. That’s an Eclipse Attack.”

The TL;DR

In a decentralized network like Bitcoin, security relies on the assumption of perfect information—that everyone can observe the proofs-of-work and the true state of the blockchain. But what if an attacker controls your router? Or, more insidiously, what if they don’t control the infrastructure, but they manage to socially engineer your node into only talking to their nodes?

In an Eclipse Attack, the adversary monopolizes all of a victim’s incoming and outgoing connections, effectively putting the victim in a localized, Truman-Show-esque network bubble. Once eclipsed, the victim is entirely at the attacker’s mercy, happily wasting hash power on obsolete chains or accepting double-spent transactions.

1. The Battlefield: Bitcoin’s Network Anatomy

To understand the exploit, you have to understand how a Satoshi client (specifically, bitcoind v0.9.3, the target of [1]) manages its social life.

A public-IP Bitcoin node maintains two types of connections:

• Outgoing Connections: It actively seeks up to 8 of these to pull information from the network.
• Incoming Connections: It passively accepts up to 117 of these from random nodes trying to connect to it.

To remember who to talk to, the node keeps two databases on disk:

1. The tried table: A VIP list of peers the node has successfully connected to in the past. It has 64 buckets, each holding up to 64 IP addresses.
2. The new table: A massive rolodex of peers the node has heard about (via gossip or DNS seeders) but hasn’t actually tried connecting to yet. It has 256 buckets, each holding up to 64 addresses.

Crucially, the network is unauthenticated. Nodes identify each other purely by IP addresses.

2. The Attack: Building the Bubble

The attack is elegant because it doesn’t require a Man-in-the-Middle position on the victim’s ISP. It’s an off-path attack driven purely by exploiting the protocol’s peer-selection logic.

Phase 1: Poisoning the Well

The attacker systematically overwrites the victim’s memory.

• Flooding tried: By repeatedly initiating unsolicited incoming connections to the victim from various attacker-controlled IPs, the attacker forces the victim to log those IPs into its tried table.
• Trashing new: Because IP addresses are expensive, the attacker doesn’t want to use real IPs to overwrite the massive new table. Instead, they send ADDR (gossip) messages filled with “trash” IP addresses. These are unallocated or reserved IP ranges (like 252.0.0.0/8). The victim blindly files these away in new.

Phase 2: The Reboot

The attack sits dormant until the victim node restarts. This could be natural (ISP outage, software update) or forced (DDoS, packet-of-death, memory exhaustion). When the victim boots back up, it needs to form 8 outgoing connections.

Phase 3: The Trap Closes

The node selects peers using a biased algorithm that heavily favors addresses with fresh timestamps. The formal probability of selecting an address is:

(Where $r$ is the number of rejected addresses so far, and $\tau$ is the age of the address timestamp).

Because the attacker spent the last few hours actively pinging the victim, their malicious IPs have extremely fresh timestamps ($\tau \approx 0$), making them mathematically irresistible to the victim.

• The victim tries to connect to IPs from the new table. They all fail, because they are fake “trash” IPs.
• The victim falls back to the tried table, which is now almost entirely populated by the attacker’s fresh IPs.
• The victim successfully establishes all 8 outgoing connections to the attacker.

Finally, the attacker spins up a custom TCP stack and quickly opens 117 meaningless connections to the victim, consuming all available incoming slots. The victim is now perfectly isolated.

3. The Impact: Why Does This Matter?

You’ve got a node in a box. Now what?

• 0-Confirmation Double Spend: A merchant accepts a transaction immediately (e.g., for a cup of coffee). The attacker sends the valid transaction to the eclipsed merchant, but sends a conflicting double-spend to the real network. The merchant hands over the coffee, completely unaware that the real network is processing the alternate reality.
• N-Confirmation Double Spend: If the attacker eclipses a miner, they can pull off a heavier heist. The attacker feeds a merchant their transaction, while feeding the eclipsed miner an alternate reality where the transaction never happened. The miner builds blocks on this alternate reality.
• Selfish Mining Buff: Selfish mining requires a high ratio of network hash power to succeed. By eclipsing honest miners, the attacker can force them to mine on the attacker’s private blocks, effectively co-opting their computational power and artificially inflating the attacker’s network dominance.

4. The Patches: Securing the Network

The Heilman et al. paper was a wake-up call, proving that even a small botnet of ~400 nodes could successfully eclipse a live Bitcoin node. To prevent this, several botnet-inspired countermeasures were introduced to the Bitcoin core:

1. Test Before Evict: Instead of just randomly overwriting old IPs when a tried bucket gets full, the node now actively pings the old IP first. If the old node is still alive, it keeps it and rejects the new (potentially malicious) one.
2. Feeler Connections: A node now dedicates a short-lived outgoing connection strictly to testing addresses in the new table. If the IP works, it gets promoted to tried. This constantly cleans out “trash” IPs.
3. Anchor Connections: When a node shuts down, it writes the addresses of two active, reliable connections to an anchor table. Upon reboot, it prioritizes connecting to these two anchors, creating a persistent lifeline to the real network.

Reference

[1] Heilman, Ethan, et al. “Eclipse attacks on {Bitcoin’s}{peer-to-peer} network.” 24th USENIX security symposium (USENIX security 15). 2015.