Skip to main content

Review of Hijacking Bitcoin: Routing Attacks on Cryptocurrencies

When Internet routing becomes unstable, the decentralized overlay above it moves with it.

This article revisits Maria Apostolaki, Aviv Zohar, and Laurent Vanbever's paper Hijacking Bitcoin: Routing Attacks on Cryptocurrencies from a defensive perspective. The paper's central contribution is not an attack on Bitcoin's consensus algorithm, but a model that treats the underlying Internet routing system as an attack surface.

Unless stated otherwise, the values and Bitcoin behavior in this document refer to data collected by the paper in 2015–2016 and conditions at its publication in 2017. They cannot be generalized directly to the current network.

Safety boundary: Advertising real prefixes without authorization or intercepting someone else's traffic can cause outages and legal harm. This article explains the paper's threat model, evidence, limitations, and defenses—not procedures for reproducing the attacks.

Paper information​

ItemDetails
AuthorsMaria Apostolaki, Aviv Zohar, Laurent Vanbever
Publication2017 IEEE Symposium on Security and Privacy, pp. 375–392
DOI10.1109/SP.2017.29
Public paperarXiv 1605.07524v2
Data analyzedBitcoin and BGP observations from October 2015 to March 2016
Central questionCan an AS-level attacker partition Bitcoin connections or delay block propagation?

Background: the routing underlay beneath the overlay​

Bitcoin nodes establish TCP connections with peers and propagate transactions and blocks. Logically, this is a distributed peer-to-peer overlay, but the packets still cross Autonomous Systems (ASes) operated by ISPs and transit providers.

Bitcoin overlay:  node A ───── peer connection ───── node B
                         ↓                        ↓
Internet underlay:    origin AS ─ transit AS ─ destination AS

BGP and prefixes​

BGP-4 exchanges IP-prefix reachability and path attributes such as AS_PATH between ASes. Two distinct stages are involved.

  1. Control plane: When multiple BGP routes exist for the same prefix/NLRI, local policy and the BGP decision process select the best route and install it in the routing table.
  2. Forwarding plane: Actual packets are forwarded through the installed entry with the longest prefix matching the destination address.

An attacker can therefore alter the traffic path by creating a competing route that changes control-plane selection or by announcing a more-specific prefix that wins the forwarding plane's longest-prefix match.

The base BGP specification does not cryptographically prove authorization for every announcement. Reducing this to "BGP trusts any route," however, misses operational reality. Real defenses combine policies and extensions such as prefix and AS-path filtering, Internet Routing Registries, RPKI-based Route Origin Validation (ROV), and monitoring.

What RPKI does and does not guarantee​

An RPKI Route Origin Authorization (ROA) is a signed object identifying an AS authorized to originate a prefix. Origin validation from RFC 6811 can classify a route as Valid, Invalid, or NotFound, but it does not validate the entire AS_PATH. BGPsec, defined in RFC 8205, is a separate extension that provides a sequence of signatures showing that participating ASes authorized propagation of a BGP UPDATE to the next AS. It does not prove that actual data packets follow the same AS path.

ROV is therefore an important root defense, but it cannot independently eliminate every route leak, path manipulation, or attacker already on a legitimate path.

The paper's threat model​

The paper considers two types of AS-level attacker.

AttackerCapabilityConstraint
Naturally on-path ASObserve, drop, or delay packets that traverse itCannot affect connections outside its path
AS performing a BGP hijackDivert routes toward target prefixes through itselfSubject to announcement propagation, filtering, detection, and response

The attacker neither breaks Bitcoin's proof of work nor steals private keys. Instead, it prevents nodes from receiving one another's blocks on time, weakening the communication assumptions on which consensus depends.

Structure of the two attacks​

1. Partition attack​

The goal is to disconnect every link between a chosen set of nodes and the rest of the Bitcoin network, forming two components. The paper models diverting traffic for prefixes that contain target nodes and then dropping only the Bitcoin connections that cross the partition.

This selective control requires stronger conditions than a simple blackhole hijack. The attacker must construct an interception hijack that preserves an untouched path for returning traffic to its legitimate destination, continues forwarding connections inside each side, and blocks only connections across the boundary. Without a return path, the result is an obvious total outage rather than a partition procedure in which leakage points can be observed and adjusted.

The need for a complete cut is an important constraint. Even one stealth connection that the attacker cannot intercept—such as a connection within the same AS, within a mining pool, or privately between pools—can carry block information across the partition. The paper's algorithm identifies such leakage points and finds the largest actually isolatable subset, which may be smaller than the original target.

If successful, the two sides generate blocks in parallel, potentially increasing forks and stale blocks. After reconnection, blocks and transactions on the chain with less accumulated work may be rolled back, increasing mining-revenue losses and double-spending risk.

2. Delay attack​

The goal is to delay delivery of new blocks to a particular node. Bitcoin's v1 transport in 2017 was plaintext and lacked cryptographic integrity, while the client at the time waited up to 20 minutes for a block requested from one peer. The paper's result depends not only on the proportion of intercepted connections but also on traffic direction.

  • When observing traffic from the victim to a peer, the attacker can modify GETDATA. The paper shows that a later request within the timeout can still deliver the original block, allowing the connection to remain open.
  • When observing only traffic from a peer to the victim, the attacker can corrupt BLOCK. In this case, the victim disconnects after the first delayed block's 20-minute timeout, so the effect is not persistent.

Delay is therefore possible by intercepting one direction of some connections, but an attacker cannot always avoid disconnecting them. The effect and duration depend on which direction of which connection is visible.

The 20-minute value and specific message-handling behavior belong to the implementation at the time. The more general lesson is that request state concentrated on one peer and unauthenticated transport increase the power of on-path manipulation.

PropertyPartitionDelay
Required visibilityEvery connection crossing the boundarySome connections can be enough
Primary actionSelective packet drop after interceptionPlaintext message modification and delayed delivery at the time
Detection signalsLarge-scale disconnects, route changesRTT, block latency, request/response anomalies
Main outcomeNetwork split, forks, rollback riskStale blocks, wasted mining power

Measurement and experiment design​

The paper combines several kinds of evidence instead of reaching its conclusion from one experiment.

  1. One Bitcoin supernode connected to about 2,000 nodes per day and recorded block-propagation times, while another supernode acting as a crawler collected about 6,000 active IPs per day.
  2. The authors inferred AS-level forwarding paths using CAIDA AS topology and business relationships.
  3. About 2.5 million routes from 182 BGP sessions at three RIPE RIS collectors mapped Bitcoin IPs to prefixes and origin ASes.
  4. About four billion BGP updates over six months were analyzed for hijack candidates based on origin changes.
  5. Live route diversion and the delay prototype were tested only with prefixes and nodes owned by the research team.
  6. The authors ran 1,050 VMs with Bitcoin Core v0.12.1 in testnet mode on an isolated virtual switch and measured partition recovery with a 50/50 drop rule. This was not an observation of the public testnet.
  7. A separate event-driven simulator and a delay experiment on the team's own Bitcoin Core v0.12.0 node evaluated network-wide effects and targeted delay.

The combination of real observations, limited live experiments, a testbed, and simulation is the paper's strongest methodological feature.

Main results​

All values below are limited to the topology observed by the paper at the time.

  • Thirteen ASes hosted 30% of public Bitcoin nodes, and 50 ASes hosted 50%.
  • Sixty-three prefixes hosted 20% of the nodes.
  • Three ASes—Hurricane Electric, Level 3, and TeliaNet—were on the path of more than 60% of possible Bitcoin connections; Hurricane Electric alone was estimated at 32%.
  • Ninety-three percent of prefixes hosting Bitcoin nodes were shorter than /24, potentially exposing them to the paper's more-specific-hijack model.
  • In experiments with prefixes owned by the researchers, more than half of connections moved onto the attack path within 20 seconds of the hijack, and all observed traffic did so within 90 seconds.
  • The feasible partition calculated by hijacking 39 selected prefixes could isolate an estimated 47% of mining power.
  • When intercepting 50% of connections over an attack period of about 200 hours, the experiment nodes spent an average 63.21% of the measured period with a chain shorter than the reference node's and without knowledge of the newest block. This is the observed proportion of the entire attack period, not an increase over a baseline.
  • By contrast, passive on-path delay across the entire network was limited by pool multi-homing unless a very powerful coalition of ASes participated.

These results do not reduce to the single statement that "Bitcoin is centralized." The number of application nodes and the diversity of network paths are different metrics. Even with many nodes, common failure points arise when their paths concentrate in a small number of ASes and prefixes.

Strengths​

Cross-layer threat model​

The paper connects consensus, the P2P protocol, TCP, and BGP into one attack path. It quantifies the contradiction between a distributed overlay and a concentrated underlay, which is easy to miss when analyzing each layer separately.

Explaining both success and failure conditions​

The paper does not exaggerate partitioning as universally possible; it explicitly accounts for connections within an AS, within a pool, and between pools. It also shows that delay can be powerful at the node level yet constrained network-wide by multi-homing.

Limited live experiments and ethical boundaries​

According to Appendix F, the routing experiments advertised only prefixes assigned to the team by Transit Portal, and isolation and delay targeted only the team's nodes. Avoiding intentional harm to normal connections with external nodes was part of the experimental design.

Limitations​

The results are a snapshot of the 2015–2016 topology​

Hosting ASes, mining-pool gateways, client versions, timeouts, and peer selection change over time. Reusing values such as 39 prefixes, 47%, or 63.21% as current risk estimates requires measuring them again with the same methodology.

Some paths were inferred rather than observed​

Paths calculated from CAIDA relationships and routing trees cannot fully reproduce traffic engineering, private peering, or hot-potato routing. The paper also acknowledges that private pool connections were not directly known.

The hijack-detection heuristic can produce false positives​

The paper treated an origin AS different from the previous month as a hijack candidate and excluded multiple-origin prefixes. This is useful for large-scale trends, but it does not provide ground truth that perfectly distinguishes malicious hijacks from legitimate operational changes.

Protocol evolution affects some attack assumptions​

The delay attack depends on plaintext without integrity protection and on request timeouts at the time. BIP 324 now provides opportunistic encryption and AEAD packet integrity for the v2 P2P transport, weakening the assumption of the same low-cost message modification. It does not authenticate peer identity, however, and compatibility with v1 remains. More importantly, encryption does not prevent packet drops or route diversion.

Reading defenses by layer​

Internet-routing layer​

  • Prefix owners should publish accurate ROAs, and operators should handle Invalid announcements through ROV policy.
  • Automate updates to prefix filtering based on IRR/RPKI, max-prefix controls, and AS-path policy.
  • Use multiple upstream and physical paths, but verify actual path diversity so differently named providers do not converge on the same transit AS.
  • Monitor BGP updates, origin changes, and more-specific announcements from external observation points as well.
  • Validating UPDATE propagation beyond origin validation requires a separate mechanism such as BGPsec. Its guarantee is limited to signed segments negotiated by BGPsec and does not continue through unsigned segments crossing unsupported ASes. It also does not guarantee data-plane paths, availability, protection from packet drops, or protection from a malicious AS on a legitimate path.

Defenses deployable by Bitcoin node and pool operators today​

  • Place mining gateways and upstreams on different ASes and physical paths, and use external observations to verify that private relays do not share the same routing fate.
  • Collect RTT, block-arrival latency, simultaneous disconnects, peer distribution, and route changes as alert signals. Do not make automatic blocking or reconnection decisions from one metric alone.
  • Maintain multiple supported reachable networks and use BIP 324 v2 transport where available, without mistaking it for route-hijack protection.
  • If peers or tunnels are pinned manually, check that they do not all converge on the same provider or transit path. A single VPN may simply move the failure domain to the VPN provider.

Proposals requiring client support and separate validation​

The paper's proposals for routing-aware peer selection, adding extra peers during anomalies, and receiving block fragments from several peers resemble client-policy or protocol redesigns rather than operational commands.

  • AS and path information is dynamic and source-dependent, so it requires trustworthy observation and stale-data handling.
  • Anomaly-triggered connections should not immediately discard existing peers and should constrain connection budgets, cooldowns, and address-group diversity. They must not concentrate connections on attacker-supplied addresses and enlarge the eclipse or Sybil attack surface.
  • Parallel block retrieval should be adopted only after validating a DoS model and regression performance, including duplicate traffic, bandwidth amplification, and peer-resource exhaustion.

The key is to defend transport integrity and route availability separately. Encryption raises the cost of modification but cannot prevent blackholes; ROV reduces incorrect origins but cannot stop packet drops by a legitimate on-path AS.

Questions to verify again in 2026​

  1. Across how many ASes, prefixes, and transit paths are today's reachable nodes and mining gateways distributed?
  2. What is the real proportion of BIP 324 v2 versus v1 connections, and how are downgrades and active MitM attempts observed?
  3. How much AS diversity does Bitcoin Core's current peer-selection and multi-network outbound policy provide?
  4. Do compact blocks, relay networks, and private pool links create independent paths across a partition, or do they share the same routing failure domain?
  5. After RPKI ROV deployment, which categories of the paper's more-specific origin hijack are blocked, and which route leaks and on-path attacks remain?

Until these questions are answered, the attack success rates reported in 2017 should not be cited as current risk values.

Evaluation​

CriterionScoreReason
Problem formulation5/5First systematic connection between cryptocurrency and inter-domain routing
Methodology4/5Combines observation, experiments, and simulation, but infers some paths and pool topology
Reproducibility4/5Publishes data and tools but depends on a live routing environment and historical snapshot
Direct applicability today3/5Routing lessons remain valid, but Bitcoin transport and topology have evolved
Overall4/5The cross-layer analysis method has lasted longer than the numerical results
  • DNS Rebinding — another boundary problem where application identity and network endpoints diverge
  • SSRF Exploitation Guide — treating server-side network reachability as a trust boundary
  • Host Header Attacks — risks from confusing protocol metadata with the actual destination

References​