Eclipse Attack | Bitcoin Glossary | Mapping Bitcoin

Overview

An eclipse attack targets a specific Bitcoin node by controlling all of its incoming and outgoing peer connections. Once the victim node is isolated from the honest network, the attacker can feed it a manipulated view of the blockchain, enabling various downstream attacks such as double spending, selfish mining amplification, or censoring transactions.

How It Works

Normal operation:
┌──────┐    ┌──────┐    ┌──────┐
│Node A│◄──►│Victim│◄──►│Node B│   (Connected to honest peers)
└──────┘    └──┬───┘    └──────┘
               │
          ┌────┴────┐
          │  Node C  │
          └─────────┘

Eclipse attack:
┌───────────┐    ┌───────────┐
│ Attacker  │◄──►│  Victim   │◄──►│ Attacker  │
│  Node 1   │    │   Node    │    │  Node 2   │
└───────────┘    └─────┬─────┘    └───────────┘
                       │
                 ┌─────┴──────┐
                 │  Attacker  │
                 │  Node 3    │    (ALL peers are attacker-controlled)
                 └────────────┘

Attack Methodology

1. Reconnaissance: The attacker identifies the victim node's IP address
2. Address table poisoning: The attacker floods the victim's address table with attacker-controlled IP addresses by sending many addr messages
3. Forced restart: The attacker waits for or induces a node restart (e.g., via resource exhaustion)
4. Connection monopolization: When the victim restarts and connects to peers, it selects from its poisoned address table, connecting exclusively to attacker nodes

Consequences

• Double spending: The attacker can show the victim a different version of the chain, tricking merchants running that node into accepting invalid payments
• Mining power waste: If the victim is a miner, they may mine on a stale or attacker-crafted chain, wasting hash power
• Transaction censorship: The attacker can prevent the victim from seeing or broadcasting specific transactions
• 0-confirmation attacks: Unconfirmed transactions are especially vulnerable since the victim cannot see competing transactions

Mitigations in Bitcoin Core

Bitcoin Core has implemented several countermeasures over the years:

• Diversified peer selection: Outbound connections are chosen from different IP address ranges (different /16 subnets)
• Anchor connections: Two block-relay-only connections are persisted across restarts
• Connection limits per subnet: Limits how many peers can connect from the same IP range
• Feeler connections: Periodically test random addresses to verify they are reachable honest nodes
• Inbound connection limits: Prevent any single IP from opening too many connections

Best Practices for Node Operators

• Run nodes with a static IP and configure trusted peers using the addnode option
• Use Tor or VPN connections alongside clearnet to diversify network paths
• Monitor peer connection diversity and watch for unusual patterns
• Keep Bitcoin Core updated to benefit from the latest eclipse attack mitigations