BGP Hijacking

What Is BGP Hijacking?

BGP hijacking is a routing attack in which a network operator falsely announces ownership of IP address ranges (prefixes) that belong to someone else. The Border Gateway Protocol (BGP) is the system that directs traffic between autonomous systems (ASes) on the internet: ISPs, cloud providers, enterprises, and hosting companies. When an AS announces a prefix, neighboring networks accept the announcement and propagate it further, building global routing tables that determine how packets travel across the internet.

BGP was designed in the 1980s for reachability and cooperation between networks, not for verifying ownership claims. There is no built-in mechanism to confirm that an AS actually controls the IP addresses it advertises. This trust-based design means any autonomous system can broadcast a fraudulent route announcement, causing some or all internet traffic destined for the legitimate owner to flow through the attacker's network instead.

For Bitcoin, this is a serious concern. The Bitcoin peer-to-peer network relies on internet routing to propagate blocks and transactions between nodes. An attacker who can manipulate BGP routes can intercept, delay, or drop Bitcoin traffic: partitioning the network, censoring transactions, or enabling double-spend attacks.

How It Works

A BGP hijack typically follows a predictable pattern. The attacker needs control of an autonomous system, which can be an ISP they operate, a compromised network, or even a small AS number purchased from a regional internet registry.

1. The attacker identifies the target IP prefixes. For a Bitcoin attack, these would be prefixes hosting Bitcoin nodes, mining pools, or other critical infrastructure.
2. The attacker's AS broadcasts a BGP announcement claiming to own those prefixes. To maximize effectiveness, they announce more-specific prefixes (for example, two /24 announcements to override a legitimate /23), since BGP routers prefer longer prefix matches.
3. Neighboring ASes accept the false announcement and propagate it. Within minutes, a significant portion of internet traffic destined for those prefixes is rerouted through the attacker's network.
4. The attacker can then inspect, modify, delay, or drop the intercepted traffic before optionally forwarding it to the real destination.

Partition Attacks on Bitcoin

In a partition attack, the hijacker isolates a group of Bitcoin nodes from the rest of the network. The isolated segment continues mining and processing transactions on its own fork, unaware that the broader network is building a different chain. Research by Apostolaki, Zohar, and Vanbever (2017 IEEE S&P) demonstrated that hijacking fewer than 100 BGP prefixes could isolate approximately 50% of Bitcoin's mining power, and that diverting Bitcoin traffic via BGP takes less than 2 minutes.

When the partition is lifted, the shorter chain is discarded under Bitcoin's longest-chain rule. All transactions confirmed only on the discarded chain are reversed, creating opportunities for double spending. Miners on the shorter chain also lose their block subsidies and fees.

Delay Attacks

A more subtle variant is the delay attack. An on-path ISP can selectively delay block propagation by tampering with Bitcoin P2P messages. The same 2017 research showed that an attacker could delay blocks reaching a target node by up to 20 minutes while remaining undetected. Intercepting just 50% of a node's connections keeps it uninformed for 63% of its uptime.

Delay attacks are particularly dangerous because they are hard to detect. The victim node still receives blocks, just late. This wastes mining power, enables selfish mining strategies, and can facilitate transaction censorship.

Traffic Interception

Before Bitcoin Core 27.0 enabled BIP 324 encrypted transport by default, all Bitcoin P2P communication was plaintext. An attacker performing a BGP hijack could trivially identify Bitcoin traffic, read transaction contents, map which nodes originated specific transactions, and modify messages in transit. Even with encryption, an active man-in-the-middle can intercept connections unless peers verify session IDs out-of-band.

Real-World Incidents

BGP hijacking is not theoretical. Multiple cryptocurrency-targeting incidents have been documented:

2014 Bitcoin Mining Pool Hijack

From February to May 2014, an attacker used a compromised administrator account at a Canadian ISP to broadcast fraudulent BGP routes. The hijack redirected miners from legitimate pools to attacker-controlled servers, exploiting the unauthenticated Stratum mining protocol to issue reconnect commands. The attacker hijacked 51 networks across 19 ISPs, including Amazon and Digital Ocean, stealing approximately $83,000 in Bitcoin and other cryptocurrencies over four months.

2018 Amazon Route 53 Hijack

In April 2018, attackers hijacked BGP prefixes belonging to Amazon's Route 53 DNS service. Traffic for five Class C networks was rerouted to a malicious DNS server, redirecting users of MyEtherWallet.com to a phishing site. The attack lasted approximately two hours and resulted in roughly $150,000 in stolen Ethereum.

2022 KLAYswap and Celer Bridge Attacks

In February 2022, attackers hijacked IP space belonging to a South Korean hosting provider to intercept a JavaScript library loaded by KLAYswap users, stealing approximately $1.9 million. Six months later, a separate BGP hijack targeted Amazon IP space to impersonate Celer Bridge infrastructure, resulting in $235,000 in losses across 32 victims.

Why It Matters for Bitcoin

The Bitcoin network is more centralized at the routing layer than most people realize. Research has found that only 13 autonomous systems host 30% of the entire Bitcoin network, and 50 ASes host half of all nodes. Three Tier-1 ISPs: Hurricane Electric, Level3 (now Lumen), and Telianet: can observe over 60% of all possible Bitcoin connections.

This routing centralization means that nation-state actors or large ISPs can perform BGP hijacking at scale with relatively little effort. A state that controls its national ISP infrastructure could partition its country's Bitcoin nodes from the global network, censor specific transactions, or surveil all Bitcoin activity crossing its borders. This threat model extends beyond Bitcoin to any cryptocurrency or Layer 2 network that relies on internet routing.

For node operators and infrastructure providers, understanding BGP-level risks is essential to building resilient systems. Solutions like Spark that operate as a Layer 2 on Bitcoin inherit these network-layer risks and must account for them in their security models.

Mitigations

BIP 324: Encrypted P2P Transport

BIP 324 introduced opportunistic encryption for Bitcoin node-to-node communication using ChaCha20-Poly1305 authenticated encryption. Enabled by default since Bitcoin Core 27.0 (April 2024), it prevents passive eavesdropping and makes Bitcoin traffic harder to identify. Before BIP 324, all Bitcoin P2P traffic was plaintext, allowing ISPs to trivially detect, monitor, and tamper with it.

BIP 324 is a significant improvement, but it provides opportunistic encryption rather than authenticated encryption. An active man-in-the-middle attacker (which a BGP hijacker is) can still intercept connections unless peers verify session IDs through an out-of-band channel.

Tor and Onion Routing

Bitcoin Core natively supports Tor for node communication. Connections made over Tor's .onion addresses never traverse the public BGP routing system, making them immune to BGP hijacking. However, running Bitcoin exclusively over Tor introduces different risks: research has shown that Tor-only nodes are more susceptible to Sybil attacks and eclipse attacks via malicious exit nodes. A recommended approach is to maintain a mix of clearnet and Tor connections.

RPKI (Resource Public Key Infrastructure)

RPKI allows IP address holders to cryptographically sign Route Origin Authorizations (ROAs) that bind prefixes to authorized autonomous systems. Networks that implement Route Origin Validation (ROV) can automatically reject BGP announcements that conflict with signed ROAs.

As of 2025, approximately 52% of routed IPv4 address space and 62% of IPv6 space are covered by ROAs. All major backbone providers and Tier-1 ISPs now perform ROV. However, nearly half of all IP address blocks remain uncovered, particularly among smaller networks and government organizations. RPKI adoption continues to grow: ROA counts increased 23% in 2025, reaching over 344,000 total records.

Diverse Peer Connections

Node operators can reduce BGP hijacking risk by connecting to peers across multiple autonomous systems. A single honest peer connection is sufficient to detect a partition attack, since the honest peer will relay blocks and transactions from the legitimate chain. Operators can manually add peers in diverse ASes using the -addnode configuration option. Mining pools already practice multi-homing across at least two ASes as standard operational security.

# Add peers across diverse autonomous systems
bitcoind -addnode=node1.example.com -addnode=node2.example.org

# Connect via Tor for BGP-immune connections
bitcoind -proxy=127.0.0.1:9050 -addnode=onionaddr.onion

BGP Monitoring

Real-time monitoring services such as BGPStream, RIPE RIS, and Kentik can alert operators to anomalous route announcements affecting their IP prefixes. Node operators should watch for sudden changes in round-trip time, unexpected shifts in peer distribution across ASes, or simultaneous disconnections from multiple peers, all of which can indicate an active BGP hijack.

Risks and Considerations

No Complete Solution Exists

RPKI adoption is growing but remains incomplete. Even with universal RPKI deployment, BGP path validation (verifying the entire AS path, not just the origin) requires additional standards like ASPA (Autonomous System Provider Authorization), which covered only about 0.5% of internet ASes as of early 2025. Full protection against BGP hijacking at the routing layer remains years away.

ISP-Level Attackers Are Hard to Defend Against

An ISP that legitimately carries a node's traffic does not need to perform a BGP hijack at all: it is already on the path. It can inspect, delay, or modify traffic without any detectable routing anomaly. BIP 324 helps against passive observation, but active interception by the node's own ISP remains a challenge that only Tor or VPN tunnels can address.

Trade-offs Between Privacy and Resilience

Using Tor protects against BGP hijacking but increases exposure to eclipse attacks via malicious Tor nodes. Using clearnet provides resilience against Tor-specific attacks but exposes connections to BGP-level manipulation. The recommended approach for privacy-conscious operators is a hybrid configuration: some connections over Tor, some over clearnet, ideally through multiple ISPs.

Layer 2 Networks Inherit the Risk

Lightning Network nodes, Spark operators, and other Layer 2 infrastructure all communicate over the same internet routing fabric. A BGP hijack targeting Lightning node IP addresses could disrupt channel operations, intercept HTLC traffic, or partition the Lightning gossip network. Layer 2 operators should apply the same mitigations as on-chain node operators: encrypted transport, diverse connectivity, and active monitoring.

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.