Eclipse Attacks on Bitcoin: How Adversaries Isolate Nodes and How the Network Defends

An eclipse attack is one of the most targeted threats a Bitcoin node can face. Unlike a broad denial-of-service flood, an eclipse attack isolates a single victim by controlling every one of its peer connections. The attacker becomes the victim's entire view of the Bitcoin network, feeding it stale blocks, withholding transactions, or presenting a fabricated chain. The consequences range from double-spend fraud against merchants to amplified selfish mining and even theft of Lightning channel funds.

The foundational research on Bitcoin eclipse attacks was published by Heilman, Kendler, Zohar, and Goldberg at USENIX Security 2015. Their paper demonstrated that an attacker with a modest number of IP addresses could monopolize all of a victim node's connections, triggering a cascade of protocol-level exploits. Since then, Bitcoin Core has implemented a layered set of defenses: bucketed address tables, feeler connections, anchor peers, block-relay-only connections, ASN-aware peer selection, and multi-network diversity across clearnet, Tor, and I2P.

How Eclipse Attacks Work

A Bitcoin node maintains two kinds of TCP connections: outbound connections it initiates and inbound connections it accepts from others. Bitcoin Core defaults to 8 full-relay outbound connections and 2 block-relay-only outbound connections, plus up to roughly 115 inbound slots. An eclipse attack succeeds when the adversary controls all of these connections simultaneously, cutting the victim off from every honest peer.

Filling Inbound Slots

Inbound connections are the easier half of the attack. Any node on the internet can open a TCP connection to a listening Bitcoin node. If the attacker spins up enough sockets from enough IP addresses, it can saturate all inbound slots before honest peers connect. This requires no special privilege: the attacker simply needs more addresses than the honest network reaches.

Poisoning Outbound Selection

Outbound connections are harder to control because the victim chooses them. Bitcoin Core selects outbound peers from its address manager (AddrMan), an internal database of known node addresses. The attacker must flood AddrMan with addresses it controls so that, when the victim restarts and picks new outbound peers, every selection lands on an attacker node.

The Heilman et al. paper showed that this is feasible. AddrMan consists of two tables: the "new" table holds addresses the node has heard about through peer discovery gossip but never connected to, and the "tried" table holds addresses it has successfully connected to in the past. The new table has 1,024 buckets of 64 slots each, while the tried table has 256 buckets. The attacker floods the new table with addresses it controls, waits for the victim to restart, and hopes the random selection algorithm draws exclusively from the poisoned pool.

The restart trigger: Eclipse attacks against outbound connections are most effective immediately after a node restarts, because that is when outbound peers are re-selected from AddrMan. An attacker who can cause a victim to restart (for example, by exploiting a crash-inducing bug) dramatically increases the probability of a successful eclipse. This is why Bitcoin Core's anchor connection mechanism specifically targets the restart window.

Attack Resources

The 2015 paper estimated that an attacker with addresses spanning 32 distinct /24 IP blocks could achieve a high probability of eclipsing a node. The key insight is that the attacker does not need to own these addresses permanently: short-lived cloud instances or botnet nodes suffice, as long as the addresses populate AddrMan before the victim's next restart. The cost of such an attack is orders of magnitude lower than a 51% hashrate attack, making it a practical threat for targeted exploitation.

What an Eclipsed Node Enables

Once a node sees only attacker-controlled peers, several exploits become possible. The severity depends on the role the eclipsed node plays in the network.

Double-Spending Against Merchants

A merchant running an eclipsed node can be tricked into accepting a double-spend. The attacker sends a transaction paying the merchant and feeds it to the eclipsed node while broadcasting a conflicting transaction (spending the same inputs to the attacker's own address) to the real network. The merchant sees confirmations on the attacker's private chain while the honest network confirms the conflicting transaction. The merchant ships goods or credits the payment, and the attacker keeps both the goods and the bitcoin.

This variant is especially dangerous for zero-confirmation acceptance, but it also works against nodes that require one or two confirmations if the attacker has enough hashrate to extend a short private chain.

Selfish Mining Amplification

Selfish mining is a strategy where a miner withholds discovered blocks and releases them strategically to waste honest miners' work. An eclipse attack amplifies this: the attacker can eclipse specific miners, preventing them from learning about the honest chain tip. The eclipsed miners waste hashrate extending a stale branch, effectively donating their work to the attacker. This lowers the hashrate threshold at which selfish mining becomes profitable from the theoretical 33% down toward smaller fractions.

Lightning Channel Theft via Time Dilation

Riard and Gleb Naumenko described time-dilation attacks on the Lightning Network in 2020. By eclipsing a Lightning node, the attacker delays the victim's view of new blocks. The victim does not realize that the chain has advanced, so it fails to detect and respond to malicious channel close attempts. The attacker broadcasts an outdated channel state (one that favors the attacker) and, because the victim is unaware, the penalty transaction window expires. The research suggested that stealing the full channel capacity might require keeping a node eclipsed for as little as two hours.

This attack does not require any hashrate. It exploits the fact that Lightning's security model depends on watchtowers and nodes monitoring the chain for revoked states. If the node cannot see the chain, it cannot enforce justice transactions.

Damage Potential Comparison

Bitcoin Core's Layered Defenses

Bitcoin Core has not relied on a single countermeasure. Instead, it has deployed a series of complementary defenses since the Heilman et al. paper, each targeting a different phase of the eclipse attack lifecycle. The result is a defense-in-depth architecture that raises the cost of eclipse attacks by orders of magnitude compared to the 2015 baseline.

AddrMan Bucketing and Keyed Hashing

The address manager uses keyed hash functions to assign addresses to buckets. Each node generates a random secret key at first startup, which seeds the hash computation. For the new table, the bucket is determined by both the address's network group and the source peer's network group. For the tried table, only the address's own network group matters.

This design means an attacker cannot predict which buckets its addresses will land in, and a single source peer can only reach a limited subset of new-table buckets. Even if the attacker controls many addresses, the deterministic-but-unpredictable hashing spreads them across the table rather than concentrating them in the buckets the victim is most likely to draw from.

Feeler Connections

Introduced in Bitcoin Core 0.13.1 as a direct response to the 2015 paper, feeler connections are short-lived outbound connections made to addresses in the new table. Their purpose is to verify that an address is reachable before promoting it to the tried table. Before feelers, research found that 72% to 95% of tried-table entries were stale, meaning the node had no recent evidence they were real. Feelers keep the tried table populated with addresses the node has recently verified, making it harder for an attacker to dominate with addresses that only exist on paper.

Block-Relay-Only Connections

Bitcoin Core maintains 2 outbound connections that relay only blocks, not transactions or address gossip. These connections are harder for an attacker to detect because the node does not advertise its address to these peers or relay transactions through them. If an attacker is monitoring transaction relay patterns to map the network topology, block-relay-only connections are invisible. They serve as a safety net: even if all 8 full-relay outbound connections are compromised, the 2 block-relay-only connections may still reach honest peers.

Anchor Connections

Bitcoin Core PR #17428 introduced anchor connections, which persist the node's block-relay-only peers to an anchors.dat file. On restart, the node reconnects to these anchors before accepting any new connections. This directly addresses the restart vulnerability: instead of drawing all outbound peers from a potentially poisoned AddrMan, the node starts with peers it was already connected to. Up to 2 anchor connections are maintained, and because they are block-relay-only, they are harder for the attacker to have identified and replaced before the restart.

Anchors are not a complete solution: Anchor connections help a node find honest peers after a restart, but they do not prevent an attacker from filling all remaining inbound and outbound slots. They reduce the probability of a total eclipse by ensuring that at least some connections survive across restarts, but they work best in combination with the other defenses described here.

ASN-Aware Peer Selection (ASMap)

Traditional peer diversification grouped addresses by their /16 IP prefix (the first 16 bits). This is a rough proxy for network diversity, but large autonomous systems can span many /16 blocks while small ISPs may share a single /16 range. Bitcoin Core PR #16702 introduced ASMap support, allowing a node to diversify outbound connections by autonomous system number (ASN) instead of IP prefix.

With ASMap enabled, the node loads a compact IP-to-ASN mapping (generated from public BGP routing data using the asmap tooling) and ensures its outbound connections span different autonomous systems. This makes it significantly harder for a single hosting provider or ISP to supply enough addresses to fill all outbound slots. The feature is opt-in via the -asmap configuration flag.

Multi-Network Diversity

Bitcoin Core supports connections over clearnet (IPv4/IPv6), Tor, I2P, and CJDNS. Each network has its own address space, so an attacker who dominates clearnet addresses still cannot fill connection slots reserved for Tor or I2P peers. Bitcoin Core PR #27213 automated this: after filling outbound slots with random addresses, the node adds peers from reachable networks it is not yet connected to.

Running a node across multiple networks forces the attacker to simultaneously dominate several independent address pools, each with its own Sybil cost structure. However, small networks like CJDNS may have too few honest peers to provide meaningful diversity: Bitcoin Core developers have discussed deprecating CJDNS support due to its small address pool, which could actually increase eclipse risk if a node relies on it exclusively.

Inbound Peer Eviction Logic

When all inbound slots are full, Bitcoin Core does not simply reject new connections. Instead, it evaluates existing inbound peers and may evict one to make room. The eviction logic protects peers that have demonstrated value: peers with the lowest ping times, the most recently sent transactions, the most recently sent blocks, and peers on distinct network groups are all protected from eviction. This means an attacker who fills all inbound slots early can still lose those slots to honest peers who connect later and demonstrate superior network behavior.

Defense Timeline

Ongoing Research and Open Problems

Despite the defenses deployed since 2015, eclipse attacks remain an active area of research. Several newer attack variants challenge the assumption that existing countermeasures are sufficient.

The Erebus Attack

The Erebus attack, described by Tran et al., demonstrated that a malicious ISP-level adversary (one controlling a large autonomous system) can eclipse a node without needing to own any IP addresses at all. By manipulating BGP routing, the ISP can intercept and reroute the victim's outbound connections to pass through attacker-controlled infrastructure. ASMap mitigates this by diversifying across ASNs, but the attack remains possible against nodes that have not enabled ASMap or that connect through a small number of upstream ISPs.

V2 Transport and Remaining Gaps

BIP 324 introduced encrypted and authenticated peer-to-peer transport (v2). While encryption prevents passive eavesdropping and makes man-in-the-middle attacks harder, it does not inherently prevent eclipse attacks. A 2026 analysis published on arXiv noted that an attacker who can establish connections to a victim can still eclipse it regardless of whether those connections use v1 or v2 transport: the fundamental issue is peer selection, not wire-level encryption.

Unsolved Challenges

• AddrMan poisoning remains possible if the attacker can operate enough addresses across enough network groups to statistically dominate outbound selection over time
• Nodes behind NAT or firewalls that do not accept inbound connections are harder to eclipse (attackers cannot fill inbound slots), but they contribute less to the network's overall resilience
• Lightweight clients that rely on a small number of peers for block headers are inherently more vulnerable than full nodes
• The opt-in nature of ASMap means most nodes still rely on /16 bucketing, leaving them exposed to Erebus-style attacks

Practical Node Hardening

Node operators who want to minimize eclipse risk can take several steps beyond the defaults. These recommendations reflect the cumulative guidance from the Heilman et al. paper, the Bitcoin Core review process, and the Bitcoin Optech documentation.

• Enable ASMap by downloading a recent IP-to-ASN mapping and passing -asmap= to bitcoind
• Run the node on multiple networks (clearnet plus Tor or I2P) to diversify the address pools used for outbound peer selection
• Manually add trusted peers with -addnode= to ensure at least some connections reach known honest nodes
• Avoid unnecessary restarts: each restart is a window where outbound peers are re-selected from AddrMan
• Monitor peer diversity using bitcoin-cli getpeerinfo and check that connections span multiple ASNs and network groups
• Keep Bitcoin Core updated: each release integrates new hardening measures against the latest known attack variants

Why Eclipse Defenses Matter for Layer 2 Protocols

Eclipse attacks are not just a base-layer concern. Any protocol that depends on monitoring the Bitcoin blockchain for security-critical events inherits the eclipse risk of the underlying node. Lightning nodes must watch for revoked channel states. Statechain protocols rely on seeing the chain to detect fraudulent exits. Rollups that post data to Bitcoin need honest chain views to verify inclusion.

Spark, as a Bitcoin Layer 2, ultimately settles on the Bitcoin base layer. The security of Spark's unilateral exit mechanism depends on users being able to broadcast pre-signed exit transactions and have them confirmed on the real chain. If a user's Bitcoin node is eclipsed during an exit, the user could be unaware that a competing transaction has been confirmed, undermining the safety guarantees that make self-custodial Layer 2 protocols viable. This is why the robustness of Bitcoin's peer-to-peer network is directly relevant to every protocol building on top of it.

For a deeper analysis of how topology attacks affect Bitcoin's peer-to-peer network structure and consensus propagation, see our research on Bitcoin P2P network topology resilience. Developers building on Spark can explore the Spark SDK documentation to understand how the protocol's settlement model interacts with base-layer security assumptions.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.