Bitcoin P2P Network Resilience: How Topology Attacks Threaten Consensus

Bitcoin's consensus mechanism gets most of the security attention, but the peer-to-peer network that carries transactions and blocks between nodes is equally critical. If an attacker can control what a node sees, they can undermine consensus without ever breaking a hash or forging a signature. Eclipse attacks, Sybil floods, BGP hijacking, and block withholding all exploit the network layer to isolate honest nodes, delay block propagation, or partition the network into disconnected segments.

This article details the attack surface of Bitcoin's P2P topology, the defenses that Bitcoin Core has deployed over the past decade, and why network-layer resilience matters for every system built on top of Bitcoin.

How Eclipse Attacks Isolate Bitcoin Nodes

An eclipse attack monopolizes all of a victim node's incoming and outgoing connections, replacing honest peers with attacker-controlled ones. Once eclipsed, the victim sees only the attacker's version of the blockchain. The attacker can feed stale blocks, withhold new ones, or selectively relay transactions to enable double-spend fraud.

The seminal research on this attack came from Heilman, Kendler, Zohar, and Goldberg in their 2015 USENIX paper “Eclipse Attacks on Bitcoin's Peer-to-Peer Network”. Their findings were stark: an attacker controlling just 32 distinct /24 IP address blocks (or a botnet of roughly 4,600 nodes) could eclipse a victim with over 85% probability in the worst case for the attacker.

What an eclipsed node enables

Once a node is isolated, several downstream attacks become possible:

• Feeding the victim a forked chain to accept a double-spent transaction
• Amplifying a 51% attack by preventing the victim from seeing the honest chain
• Enabling selfish mining by controlling when the victim learns about competing blocks
• Filtering specific transactions to censor payments or prevent time-sensitive broadcasts

The restart vector

A key insight from the Heilman paper is that node restarts create a window of vulnerability. Before Bitcoin Core's countermeasures, an attacker could flood the victim's address manager (addrman) with attacker-controlled addresses, then force or wait for a restart. On reboot, the node would select outbound peers entirely from the poisoned address table, completing the eclipse.

Sybil Attacks: Flooding the Network with Fake Peers

Where an eclipse attack targets a specific victim, a Sybil attack floods the broader network with malicious nodes. The attacker creates hundreds or thousands of identities to gain disproportionate influence over peer discovery, address propagation, and connection selection across many nodes simultaneously.

In April 2026, Bitcoin developer Jameson Lopp warned of over 200,000 fake node addresses being gossiped across the network daily. These “ghost nodes” advertised IP addresses that were unreachable, polluting the address tables of legitimate nodes and making it harder for new nodes to find honest peers. Against a backdrop of roughly 23,000 genuine public nodes, this represented a nearly 10:1 ratio of fake to real addresses in gossip traffic.

Eclipse vs. Sybil: An eclipse attack isolates a single node by controlling all its connections. A Sybil attack poisons the broader network's peer discovery. The two are often combined: Sybil nodes pollute address tables, then eclipse attacks exploit the polluted state to isolate specific targets.

Why Sybil attacks are harder on Bitcoin than on most networks

Bitcoin's proof-of-work consensus makes Sybil attacks on block production prohibitively expensive: each mining identity requires real hashrate. But the P2P layer itself has no proof-of-work requirement for connecting as a peer. The cost of spinning up thousands of listening nodes is negligible compared to the cost of mining. Bitcoin Core's defenses therefore focus on limiting the influence any single source can have over a node's address table and connection slots.

BGP Hijacking: Attacking the Internet Layer

Border Gateway Protocol (BGP) hijacking operates below the Bitcoin protocol entirely, manipulating Internet routing to intercept or delay Bitcoin traffic between nodes. In 2017, Apostolaki, Zohar, and Vanbever published “Hijacking Bitcoin: Routing Attacks on Cryptocurrencies”, revealing how concentrated Bitcoin's network infrastructure actually is.

Their analysis of BGP data found that just 13 Autonomous Systems (ASes) hosted 30% of the entire Bitcoin network, and 50 ASes hosted 50%. Three Tier-1 providers (Hurricane Electric, Level3, and Telianet) could together intercept over 60% of all possible Bitcoin connections. By hijacking fewer than 100 BGP prefixes, an attacker could isolate roughly 50% of Bitcoin's mining power, with the diversion taking less than two minutes to propagate.

Partition and delay attacks

BGP-level attackers can execute two classes of attacks:

• Partition attacks split the network into isolated components that mine independently, enabling double-spends when the partition heals
• Delay attacks selectively slow block propagation between regions, increasing orphan rates and wasting mining resources

Unlike eclipse attacks that target individual nodes, BGP hijacking can partition entire geographic regions or AS clusters simultaneously. The attack is invisible to the Bitcoin protocol itself: nodes believe they are communicating with their peers normally, but traffic is being routed through the attacker.

Block Withholding and Selfish Mining

Block withholding exploits the P2P relay layer differently. Rather than isolating a victim, a selfish miner withholds valid blocks they have found, releasing them strategically to gain an unfair share of block rewards. Research has shown that a miner with as little as 33% of the network hashrate can profit above their fair share through selfish mining strategies.

The attack depends on the miner's ability to propagate their withheld block faster than the competing honest block once they choose to release it. This makes block propagation speed a security-relevant metric: faster propagation reduces the advantage of selfish miners.

The Erebus Attack: Nation-State-Scale Eclipse

The Erebus attack, disclosed in 2020, demonstrated a more sophisticated form of eclipse that operates at the Autonomous System level. Unlike the Heilman eclipse attack (which requires direct IP address manipulation) or BGP hijacking (which requires control-plane manipulation), Erebus is a data-plane attack. An AS that sits on the routing path between a victim and its peers can silently intercept and manipulate Bitcoin traffic without any BGP announcements.

This makes Erebus particularly relevant for nation-state adversaries. A country's dominant ISP often acts as a routing bottleneck for a significant fraction of its domestic Bitcoin nodes. The attack is stealthy because it requires no detectable routing changes and leaves no trace in BGP monitoring systems.

Bitcoin Core's Defense Architecture

Bitcoin Core has evolved substantial defenses against these topology attacks over the past decade. The following sections cover the major mechanisms, roughly in the order they were introduced.

AddrMan: bucketed address management

The address manager (AddrMan) is Bitcoin Core's database of known peer addresses. It uses a bucketing system designed to limit any single attacker's ability to dominate a node's view of the network. Addresses are stored in two tables:

• The “new” table holds 1,024 buckets of addresses that have been gossiped but not yet connected to
• The “tried” table holds 256 buckets of addresses that the node has successfully connected to in the past

Bucket assignment uses cryptographic hashing with a randomly generated 256-bit key unique to each node. The bucket a given address lands in depends on both the address itself and the source that gossiped it. This means an attacker controlling one source can only influence a subset of buckets (64 out of 1,024 in the new table), making it far harder to dominate the entire address space.

Connection diversity and outbound slots

Bitcoin Core maintains a structured set of outbound connections designed to resist manipulation:

Block-relay-only connections are critical for partition resistance. Because they do not participate in transaction relay or address gossip, they reveal nothing about the node's network topology to an attacker performing traffic analysis. An adversary who has mapped a node's full-relay connections may still miss its block-relay-only connections entirely.

Anchor connections

Introduced in Bitcoin Core PR #17428, anchor connections persist block-relay-only peers across restarts. On shutdown, the node writes its current block-relay-only peers to an anchors.dat file. On restart, these peers are reconnected with highest priority before any addresses from AddrMan are tried.

This directly counters the restart-based eclipse vector from the Heilman paper. Even if an attacker has successfully polluted AddrMan, the node will reconnect to at least two known-good block-relay-only peers from its previous session, maintaining a lifeline to the honest network.

ASMAP: AS-aware bucketing

Standard AddrMan bucketing uses /16 IP prefixes to diversify connections. The problem is that a single Autonomous System can control address space across many different /16 prefixes, rendering the diversification ineffective against AS-level attackers like those described in the Erebus paper.

ASMAP, introduced experimentally in Bitcoin Core 0.20 (2020), replaces /16-based bucketing with IP-to-ASN mapping. Instead of diversifying by IP prefix, nodes diversify by Autonomous System number. This ensures that even if an AS controls thousands of IP addresses across many /16 ranges, all those addresses map to the same AS and compete for the same bucket slots.

Netgroup-based eviction

When inbound connection slots fill up, Bitcoin Core must decide which connections to evict for new arrivals. The eviction algorithm prioritizes removing peers from the largest netgroup (the /16 prefix group with the most connections). This prevents an attacker from monopolizing inbound slots by connecting from a single address range. Eviction also protects long-lived connections and peers that have provided useful data (recent blocks, valid transactions), making it harder for newly connecting attacker nodes to displace established honest peers.

Defense in depth: No single mechanism stops all topology attacks. AddrMan bucketing limits address pollution, anchor connections protect restarts, block-relay-only connections hide topology, ASMAP defends against AS-level adversaries, and netgroup eviction protects inbound slots. Each addresses a different attack surface.

BIP 324: Encrypted P2P Transport

Before BIP 324, all Bitcoin P2P traffic was transmitted in plaintext. Any network observer (ISP, state actor, or coffee-shop Wi-Fi operator) could identify Bitcoin traffic by its distinctive message structure, observe which transactions a node originated, and even tamper with messages in transit.

BIP 324 introduced the v2 transport protocol, which encrypts all P2P communication using an authenticated encryption scheme based on the elliptic curve Diffie-Hellman key exchange. Support was added in Bitcoin Core v26.0 and enabled by default in v27.0. When two v2-capable nodes connect, they perform a key exchange and all subsequent messages are encrypted and authenticated. If either peer does not support v2, they fall back to the legacy plaintext protocol.

What BIP 324 defends against

• Passive surveillance: observers can no longer trivially identify Bitcoin traffic or determine which transactions a node originated
• Man-in-the-middle tampering: encrypted and authenticated messages prevent silent modification of P2P traffic
• Traffic analysis for eclipse preparation: identifying a node's peers by observing its traffic patterns becomes significantly harder

BIP 324 does not prevent an attacker who controls a peer from behaving maliciously. It protects the transport layer between honest peers against third-party observers and intermediaries.

Tor, I2P, and CJDNS: Network-Layer Privacy

Bitcoin Core supports multiple anonymity networks to provide network-layer privacy and resist IP-based targeting:

Running across multiple networks simultaneously provides meaningful resilience. A node connected over both clearnet and Tor is harder to eclipse than one using only clearnet, because the attacker must control peers on both networks. Bitcoin Core's connection logic includes network diversification: it attempts to maintain outbound connections across different network types rather than concentrating on one.

Tor-only nodes and eclipse risk

Nodes that connect exclusively over Tor face a specific tradeoff. Tor provides IP privacy, but the Tor network has a smaller peer population than the clearnet. An attacker running many Tor-based Sybil nodes can more easily dominate a Tor-only node's view of the network. Running a node with both clearnet and Tor connections mitigates this risk while still benefiting from Tor's privacy properties for a subset of connections.

Compact Blocks and Block Propagation Speed

Compact blocks, specified in BIP 152 and merged into Bitcoin Core in June 2016, dramatically reduced block propagation latency. Instead of transmitting full blocks (which can be several megabytes), a node sends the 80-byte block header plus a short 6-byte identifier for each transaction. The receiving node reconstructs the block from its own mempool and only requests the few transactions it is missing.

This typically reduces a multi-megabyte block to roughly 15 KB on the wire: about a 98% reduction. Faster propagation narrows the window for selfish mining and block withholding, because a withheld block's advantage diminishes when honest blocks propagate across the network in sub-second timeframes.

Erlay: Efficient Transaction Relay

Erlay (BIP 330) proposes replacing Bitcoin's flood-based transaction announcement model with a combination of limited direct relay and periodic set reconciliation using the Minisketch data structure. This would reduce transaction relay bandwidth by approximately 40% with negligible latency impact.

Beyond bandwidth savings, Erlay has security implications. Lower bandwidth costs make it practical for nodes to maintain more outbound connections without proportional bandwidth increases. More connections mean better partition resistance and a higher bar for eclipse attacks. As of mid-2026, Erlay remains under active development and code review, with deployment expected in a future Bitcoin Core release.

Time-Dilation Attacks: When Eclipse Meets Lightning

A 2020 paper by Riard and Naumenko, “Time-Dilation Attacks on the Lightning Network”, demonstrated how eclipse attacks on Bitcoin full nodes backing Lightning channels can enable theft of channel funds. The attack works by eclipsing a Lightning node's underlying Bitcoin node and then delaying block delivery. The victim's node falls behind the chain tip, unable to detect that a counterparty has broadcast a revoked channel state on-chain.

Their measurements found that eclipsing a node for as little as two hours was sufficient to steal the total channel capacity. Running just 500 Sybil nodes allowed an attacker to eclipse 47% of newly deployed lightweight clients, priming them for time-dilation exploitation.

This research underscores that P2P network attacks are not abstract threats: they have concrete financial consequences for Lightning Network participants and any Layer 2 protocol that depends on timely access to on-chain state.

Defense Summary: Attack Surface vs. Countermeasures

Why P2P Resilience Matters for Layer 2 Protocols

Every Bitcoin Layer 2 inherits the P2P network's attack surface. A Lightning watchtower that cannot see new blocks is useless. A statechain operator whose Bitcoin node is eclipsed might miss conflicting on-chain transactions. A Spark operator running a node that falls behind the chain tip could fail to detect a fraudulent exit attempt, because watchtower functionality depends on real-time chain visibility.

For Layer 2 operators and infrastructure providers, P2P hardening is not optional. Running nodes with ASMAP enabled, connecting across multiple networks (clearnet, Tor, I2P), using BIP 324 v2 transport, and maintaining anchor connections are baseline operational requirements rather than nice-to-have configurations.

Operational baseline for Layer 2 nodes: Enable ASMAP for AS-aware peer diversification. Run connections across at least two network types (clearnet plus Tor or I2P). Ensure BIP 324 v2 transport is active (default since Bitcoin Core v27.0). Monitor peer diversity and connection stability.

What the Current Threat Landscape Looks Like

The April 2026 Sybil event (200,000+ ghost node addresses flooding gossip) shows that network-layer attacks are not theoretical: they are actively occurring. The low cost of announcing fake addresses makes this category of attack particularly persistent. While Bitcoin Core's defenses prevent these fake addresses from dominating outbound connection selection, they can still degrade peer discovery for new nodes joining the network and waste bandwidth on connection attempts to unreachable addresses.

The ongoing concentration of Bitcoin nodes within a small number of Autonomous Systems remains a structural risk. Even with ASMAP, the network's geographic and infrastructure diversity is limited by real-world hosting patterns. Future improvements like Erlay (enabling more connections at lower bandwidth cost) and continued growth of Tor and I2P peer populations will incrementally improve resilience, but the fundamental tension between an open, permissionless network and resistance to Sybil flooding remains unresolved.

Building on a Resilient Foundation

Developers building on Bitcoin's P2P network (whether running full nodes, Lightning nodes, or Layer 2 infrastructure like Spark) should treat network-layer security as a first-class concern. The Spark documentation covers operator node requirements, and the Bitcoin node implementation comparison provides guidance on selecting and configuring nodes for production environments.

For a deeper look at related network security topics, see our research on Dandelion and network privacy and the chain reorganization protection mechanisms that complement P2P defenses at the consensus layer.

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.