Eclipse Attack

What Is an Eclipse Attack?

An eclipse attack is a network-level attack where an adversary takes control of all peer connections to a target node. Unlike a Sybil attack, which floods the network with fake identities, an eclipse attack specifically targets a single victim node. The goal is to isolate that node from the rest of the network so the attacker can feed it false information: hiding new blocks, censoring transactions, or presenting a forged version of the chain.

The name comes from the idea that the attacker "eclipses" the victim's view of the network, like a moon blocking out the sun. The victim node believes it is communicating with the broader Bitcoin network, but every message it sends and receives passes through adversary-controlled peers. This makes the attack particularly dangerous: the victim has no obvious indication that anything is wrong.

Eclipse attacks were formally described in the 2015 paper "Eclipse Attacks on Bitcoin's Peer-to-Peer Network" by Heilman, Kendler, Zohar, and Goldberg. The research demonstrated that an attacker with as few as a handful of IP addresses could eclipse a Bitcoin node under certain conditions, prompting significant changes to Bitcoin Core's networking code.

How It Works

Bitcoin nodes maintain connections to a set of peers to relay transactions and blocks. A typical Bitcoin Core node maintains 8 outbound connections (initiated by the node) and accepts up to 117 inbound connections (initiated by others). The attacker's strategy targets both types.

Populating the Peer Table

Bitcoin Core stores known peer addresses in two tables: the "new" table (addresses the node has heard about but never connected to) and the "tried" table (addresses the node has successfully connected to before). Each table is divided into buckets, and addresses are assigned to buckets using a hash function based on the address and the node's own identity.

The attacker floods the victim's tables through several methods:

1. Sending unsolicited addr messages containing thousands of adversary-controlled IP addresses
2. Connecting to the victim from many different IP addresses, populating the tried table with attacker entries
3. Using botnets or cloud infrastructure to generate a large pool of IP addresses under attacker control

Over time, the attacker's addresses crowd out legitimate peer addresses in both tables. The attacker does not need to displace every honest entry: they only need enough presence that when the victim selects peers, it consistently picks attacker nodes.

Executing the Eclipse

The eclipse becomes effective when the victim restarts or drops and re-establishes connections. At that point:

1. The victim selects outbound peers from its tried and new tables, which are now dominated by attacker addresses
2. All 8 outbound connections land on attacker-controlled nodes
3. The attacker also fills inbound connection slots by initiating connections from their IP pool
4. The victim is now fully isolated: every peer is the attacker

# Simplified view of an eclipsed node's peer table
# All connections route through adversary nodes

Victim Node Peers:
  Outbound [1/8]: attacker-node-A:8333
  Outbound [2/8]: attacker-node-B:8333
  Outbound [3/8]: attacker-node-C:8333
  ...
  Outbound [8/8]: attacker-node-H:8333
  Inbound [1/117]: attacker-node-I:8333
  Inbound [2/117]: attacker-node-J:8333
  ...

Honest network blocks: #800,001, #800,002, #800,003
Victim sees:           #800,001 (stale)

Attack Goals and Exploitation

Once a node is eclipsed, the attacker can manipulate the victim's view of the network in several ways. The specific exploitation depends on whether the victim is a miner, a merchant, or a Lightning node.

Double Spending

The most direct exploit targets merchants who accept zero-confirmation transactions. The attacker sends a transaction paying the eclipsed merchant, who sees it arrive and considers it valid. Meanwhile, the attacker broadcasts a conflicting transaction (spending the same UTXOs) to the real network. Since the merchant never sees the conflicting transaction or the blocks confirming it, they deliver goods or services based on a transaction that will never confirm. Even merchants waiting for confirmations are vulnerable if the attacker can withhold blocks long enough to present a shorter, fake chain to the victim.

This risk is closely related to replace-by-fee double spends, but eclipse attacks are more powerful because the victim cannot see the replacement transaction at all.

Selfish Mining Amplification

If the eclipsed node is a miner, the attacker can withhold blocks from them, causing them to mine on stale chain tips. The eclipsed miner wastes hash power on blocks the network has already passed. The attacker can then redirect this wasted work to benefit their own mining operation, effectively borrowing the victim's hash rate.

Transaction Censorship and Time Manipulation

The attacker controls what the victim sees, enabling additional exploits:

• Transaction filtering: the attacker can prevent specific transactions from reaching the victim, censoring payments or contract interactions
• Timestamp manipulation: by feeding blocks with skewed timestamps, the attacker can manipulate the victim's perception of time, potentially affecting timelock-based contracts
• N-confirmation double spend: by presenting a fake chain with fewer blocks, the attacker can make the victim believe a transaction has fewer confirmations than it actually does on the real chain

Bitcoin Core Mitigations

Following the 2015 disclosure, Bitcoin Core implemented numerous defenses that make eclipse attacks significantly harder. These mitigations have been refined over subsequent releases.

Address Table Bucketing

Bitcoin Core uses a deterministic bucketing scheme for its new and tried tables. Addresses are assigned to buckets based on a keyed hash of the IP address and the source that advertised it. This means an attacker controlling a single IP range cannot dominate all buckets: their addresses cluster into a limited number of buckets, leaving room for honest peers.

// Simplified bucket assignment logic
// bucket = Hash(key, source_group, address_group) % num_buckets
//
// "new" table: 1024 buckets, 64 entries each
// "tried" table: 256 buckets, 64 entries each
//
// Same source group -> same bucket subset
// Attacker needs diverse source IPs to fill more buckets

Outbound Connection Diversity

Bitcoin Core selects outbound peers from different address groups (typically /16 IP ranges) to ensure network diversity. It also maintains 2 additional "block-relay-only" outbound connections that do not participate in address gossip, making them invisible to the attacker and harder to target.

Feeler Connections

Bitcoin Core periodically makes short-lived "feeler" connections to random addresses from the new table. If the connection succeeds, the address is moved to the tried table. This continuously verifies that the tried table contains reachable, legitimate peers and dilutes any attacker-injected entries.

Anchors and Restart Protection

Since version 0.21, Bitcoin Core persists its block-relay-only connections across restarts in an anchors.dat file. On startup, the node reconnects to these anchor peers before selecting new outbound connections. This prevents the attacker from exploiting restart events to capture all outbound slots simultaneously.

Eclipse Attacks on the Lightning Network

Eclipse attacks pose heightened risks for Lightning Network nodes. A Lightning node that cannot see the latest blockchain state may miss critical channel updates, with direct financial consequences.

Consider a scenario where an attacker eclipses a Lightning node and then broadcasts an old, revoked channel state on-chain. Normally, the victim would detect this revoked commitment transaction and respond with a justice transaction to claim the penalty. But if the victim is eclipsed, they never see the revoked broadcast and miss the dispute window. The attacker successfully steals funds using outdated channel state.

This is why watchtowers are critical infrastructure for Lightning nodes. A watchtower monitors the blockchain on behalf of the node and can submit justice transactions even if the node itself is offline or eclipsed. Running watchtowers on separate network infrastructure from the main node provides defense-in-depth against eclipse attacks.

Eclipse attacks can also enable routing attacks on Lightning by manipulating the victim's view of channel gossip messages. The attacker can feed false channel updates, causing the victim to route payments through attacker-controlled channels where fees can be extracted or HTLCs can be intercepted.

Protection Strategies

Node operators can take several steps to reduce their exposure to eclipse attacks beyond the built-in Bitcoin Core mitigations:

• Run multiple connections across diverse networks: use both IPv4 and IPv6, and consider Tor connections as an additional network layer. An attacker must eclipse all network types simultaneously to succeed.
• Use manual peer additions: configure trusted peers with the addnode option in bitcoin.conf. These persistent connections ensure at least some peers are known-honest, breaking any potential eclipse.
• Verify blocks from multiple sources: cross-reference block data against public block explorers or secondary nodes. If your node's chain tip diverges from public sources, investigate immediately.
• Monitor peer diversity: regularly inspect your node's peer list using bitcoin-cli getpeerinfo. Look for suspicious patterns like all peers sharing the same AS number or IP range.
• Run watchtowers for Lightning channels: as discussed above, watchtowers provide a critical safety net against eclipse-enabled channel theft.

# bitcoin.conf: manual peer additions for eclipse resistance
# Add trusted peers across diverse networks
addnode=trusted-peer-1.example.com:8333
addnode=trusted-peer-2.example.com:8333

# Check current peer diversity
bitcoin-cli getpeerinfo | jq '[.[] | .network] | group_by(.) | map({(.[0]): length}) | add'
# Expected output: {"ipv4": 6, "ipv6": 2, "onion": 2}

Risks and Considerations

Eclipse attacks remain a real threat despite the significant mitigations implemented in modern Bitcoin Core releases. The attack surface has narrowed considerably: the original 2015 attack required only a few machines, while current mitigations demand substantially more resources. However, well-funded adversaries (state actors, large criminal organizations) may still possess sufficient infrastructure.

The risk is especially acute for nodes running on restricted networks, behind NAT without port forwarding (limiting them to outbound-only connections), or on cloud infrastructure where the attacker can predict or control network topology. Nodes accepting zero-conf channels or zero-confirmation payments should be particularly cautious, as eclipse attacks directly enable double-spend exploits against these use cases.

For a deeper understanding of network-level privacy and routing protections in the Lightning context, see the research article on onion routing and Lightning privacy. For more on how Lightning channel security works and the role of penalty mechanisms, see the payment channels deep dive.

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.