What is an Eclipse Attack?
An eclipse attack is a peer-to-peer network attack in which an adversary monopolizes all of a target node’s incoming and outgoing connections. Once surrounded, the victim is “eclipsed” from the rest of the network: it still thinks it is participating normally, but every peer it talks to is controlled by the attacker. The attacker can then feed the victim a manipulated view of the blockchain — stale blocks, fake transactions, or omitted data — to enable double-spending, censorship, or mining-power exhaustion.
Unlike a straightforward DDoS attack that simply overwhelms a node, an eclipse attack is stealthy. The victim keeps running and appears healthy, which makes it far more dangerous: it can be used as a stepping stone for double-spending, for isolating a specific exchange or miner, or for quietly censoring a user’s transactions.
How an Eclipse Attack Works
Blockchain nodes maintain a limited number of peer connections (for example, Bitcoin Core defaults to 8 outbound and up to 117 inbound connections; Ethereum clients use similar limits). An eclipse attack exploits this cap.
The Attack Pattern
- Reconnaissance. The attacker learns the target node’s IP address — often by connecting to it as a peer, reading node advertisements, or scanning the network.
- Peer-table poisoning. The attacker spins up many IP addresses (using botnets, cloud instances, or spoofed packets) and floods the victim’s peer-discovery buffers so that the victim’s candidate peer lists are filled with attacker addresses.
- Connection takeover. When the victim’s existing connections naturally drop or time out, it reconnects using its poisoned table — and every new peer belongs to the attacker.
- Isolation. The victim is now enclosed. The attacker controls exactly what blocks and transactions it sees.
Why It Enables Double-Spending
Once a merchant’s node is eclipsed:
- The attacker sends the merchant a payment, which the eclipsed node reports as confirmed
- Meanwhile, on the real network, the attacker sends the same funds elsewhere or to themselves
- Because the merchant cannot see the true chain, they release goods believing they were paid
This is the on-chain analog of the classic Finney attack, but network-level and far more scalable.
Notable Examples and Attack Vectors
The 2015 “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network”
Researchers at Cornell (Heilman, Kendler, Zohar, Goldberg) published the first detailed eclipse attack against Bitcoin, showing that an attacker could isolate a node using only two machines and a flood of bogus peer addresses. The paper prompted defensive changes such as deterministic random eviction of peers and anchor connections that persist across restarts.
Ethereum Eclipse Attacks
Ethereum’s discovery protocol (Kademlia-based node discovery) has historically been more exposed than Bitcoin’s. A well-known 2016 attack required only one or two attacker-controlled IP addresses and a few hours of work to eclipse a victim’s geth node, again leading to protocol hardening (peer scoring, harder IP rotation, table-filling protections).
Eclipse as a Precursor
Eclipsing is rarely the end goal. It is a building block used to amplify other attacks:
- Selfish mining — eclipse rival miners so they waste hash power on stale chains
- 0-confirmation double-spends — fool merchants who accept unconfirmed transactions
- Validator isolation on proof-of-stake networks — trick an isolated validator into attestations that get it slashed
How to Protect Against Eclipse Attacks
For Node Operators
- Increase peer diversity. Run with more outbound connections and pin a few trusted anchor peers (long-lived connections to known-good nodes) that survive restarts.
- Use multiple network paths. Don’t run a financially sensitive node behind a single ISP or single datacenter — that also exposes you to BGP routing attacks.
- Keep software updated. Eclipse mitigations (peer eviction logic, IP banning, discovery hardening) are continually improved in Bitcoin Core, geth, and Erigon; running old versions keeps known holes open.
- Monitor peer health. Alert if a node’s peers all resolve to the same AS (autonomous system) or suddenly all change at once — a classic eclipse signature.
For Merchants and Exchanges
- Never rely on a single node. Query several geographically and topologically dispersed nodes (or multiple providers) and compare their chain tips before crediting a deposit.
- Wait for multiple confirmations. Eclipse-based double-spends are defeated by finality; require enough confirmations that reorging becomes economically irrational.
Protocol-Level Defenses
Modern clients deploy feelings-based peer scoring, table-bucket separation, and gossip constraints that make flooding a victim’s peer table expensive. Some networks also rotate peer connections on a schedule and limit how many addresses a single peer can introduce.
Frequently Asked Questions
Q: How is an eclipse attack different from a Sybil attack? A: A Sybil attack is about creating many fake identities to subvert a system’s reputation or voting; an eclipse attack is the specific application of Sybil identities to surround and isolate one node’s network connections. Eclipse attacks typically use Sybil nodes.
Q: Can regular users be eclipsed? A: It’s possible but rarely worthwhile for low-value targets. Attackers focus on exchanges, merchants, mining pools, and validators — entities where isolating the node has a clear financial payoff.
Q: Does running my own node protect me? A: Running your own node helps you verify the chain independently, but it does not by itself prevent eclipse. You must also harden peer connections and ideally cross-check with other independent nodes.