As the most successful cryptocurrency to date, Bitcoin constitutes a target of choice for attackers. While many attack vectors have already been uncovered, one important vector has been left out though: attacking the currency via the Internet routing infrastructure itself. Indeed, by manipulating routing advertisements (BGP hijacks) or by naturally intercepting traffic, Autonomous Systems (ASes) can intercept and manipulate a large fraction of Bitcoin traffic.

This paper presents the first taxonomy of routing attacks and their impact on Bitcoin, considering both small-scale attacks, targeting individual nodes, and large-scale attacks, targeting the network as a whole. While challenging, we show that two key properties make routing attacks practical: (i) the efficiency of routing manipulation; and (ii) the significant centralization of Bitcoin in terms of mining and routing. Specifically, we find that any network attacker can hijack few (<100) BGP prefixes to isolate ∼50% of the mining power—even when considering that mining pools are heavily multi-homed. We also show that on-path network attackers can considerably slow down block propagation by interfering with few key Bitcoin messages.

We demonstrate the feasibility of each attack against the deployed Bitcoin software. We also quantify their effectiveness on the current Bitcoin topology using data collected from a Bitcoin supernode combined with BGP routing data.

The potential damage to Bitcoin is worrying. By isolating parts of the network or delaying block propagation, attackers can cause a significant amount of mining power to be wasted, leading to revenue losses and enabling a wide range of exploits such as double spending. To prevent such effects in practice, we provide both short and long-term countermeasures, some of which can be deployed immediately.

I. INTRODUCTION

With more than 16 million bitcoins valued at ∼17 billion USD and up to 300,000 daily transactions (March 2017), Bitcoin is the most successful cryptocurrency to date. Remarkably, Bitcoin has achieved this as an open and fully decentralized system. Instead of relying on a central entity, Bitcoin nodes build a large overlay network between them and use consensus to agree on a set of transactions recorded within Bitcoin’s core data structure: the blockchain. Anyone is free to participate in the network which boasts more than 6,000 nodes [4] and can usually connect to any other node.

Given the amount of money at stake, Bitcoin is an obvious target for attackers. Indeed, numerous attacks have been described targeting different aspects of the system including: double spending [43], eclipsing [31], transaction malleability [21], or attacks targeting mining [24], [44], [38] and mining pools [23].

One important attack vector has been overlooked though: attacking Bitcoin via the Internet infrastructure using routing attacks. As Bitcoin connections are routed over the Internet—in clear text and without integrity checks—any third-party on the forwarding path can eavesdrop, drop, modify, inject, or delay Bitcoin messages such as blocks or transactions. Detecting such attackers is challenging as it requires inferring the exact forwarding paths taken by the Bitcoin traffic using measurements (e.g., traceroute) or routing data (BGP announcements), both of which can be forged [41]. Even ignoring detectability, mitigating network attacks is also hard as it is essentially a human-driven process consisting of filtering, routing around or disconnecting the attacker. As an illustration, it took Youtube close to 3 hours to locate and resolve rogue BGP announcements targeting its infrastructure in 2008 [6]. More recent examples of routing attacks such as [51] (resp. [52]) took 9 (resp. 2) hours to resolve in November (resp. June) 2015.

One of the reasons why routing attacks have been overlooked in Bitcoin is that they are often considered too challenging to be practical. Indeed, perturbing a vast peer-to-peer network which uses random flooding is hard as an attacker would have to intercept many connections to have any impact. Yet, two key characteristics of the Internet’s infrastructure make routing attacks against Bitcoin possible: (i) the efficiency of routing manipulation (BGP hijacks); and (ii) the centralization of Bitcoin from the routing perspective. First, individuals, located anywhere on the Internet, can manipulate routing to intercept all the connections to not only one, but many Bitcoin nodes. As we show in this paper, these routing manipulations are prevalent today and do divert Bitcoin traffic. Second, few ASes host most of the nodes and mining power, while others intercept a considerable fraction of the connections.

This work In this paper, we present the first taxonomy of routing attacks on Bitcoin, a comprehensive study of their impact, and a list of deployable countermeasures. We consider two general attacks that AS-level attackers can perform. First, we evaluate the ability of attackers to isolate a set of nodes from the Bitcoin network, effectively partitioning it. Second, we evaluate the impact of delaying block propagation by manipulating a small number of key Bitcoin messages. For both exploits, we consider node-level attacks along with more challenging, but also more disruptive, network-wide attacks.

Partitioning attacks The goal of a partition attack is to completely disconnect a set of nodes from the network. This requires the attacker to divert and cut all the connections between the set of nodes and the rest of the network.

We describe a complete attack procedure in which an attacker can verifiably isolate a selected set of nodes using BGP hijacks. Our procedure is practical and only requires basic knowledge of the Bitcoin topology, namely the IP addresses of the nodes the attacker wants to isolate. Due to the complexity of the Bitcoin network (e.g. multi-homed pools, and secret peering agreements between pools), the initial isolated set might contain nodes that leak information from and to the rest of the network. We explain how the attacker can identify and remove these leakage points until the partition is complete.

Delay attacks The goal of a delay attack is to slow down the propagation of blocks towards or from a given set of nodes. Unlike partition attacks, which require a perfect cut, delay attacks are effective even when a subset of the connections are intercepted. As such, attackers can perform delay attacks on connections they are naturally intercepting, making them even harder to detect.

We again describe a complete attack procedure an attacker can run on intercepted Bitcoin traffic so that the delivery of blocks is delayed by up to 20 minutes. The procedure consists of modifying few key Bitcoin messages while making sure that the connections are not disrupted.

Practicality We showcase the practicality of each attack and evaluate their network-wide impact using a comprehensive set of measurements, simulations and experiments.

Regarding partitioning attacks, we show that hijacks are effective in diverting Bitcoin traffic by performing a hijack in the wild against our own nodes. We find that it takes less than 90 seconds to re-route all traffic flows through the attacker once a hijack is initiated. We also show that any AS in the Internet hijacking less than 100 prefixes can isolate up to 47% of the mining power, and this, even when considering that mining pools are multi-homed. Hijacks involving that many prefixes are frequent and already divert Bitcoin traffic.

Regarding delay attacks, we show that an attacker intercepting 50% of a node connections can leave it uninformed of the most recent Bitcoin blocks ~60% of the time. We also show that intercepting a considerable percentage of Bitcoin traffic is practical due to the centralization of Bitcoin at the routing level: one AS, namely Hurricane Electric, can naturally intercept more than 30% of all Bitcoin connections.

Impact on Bitcoin The damages caused to Bitcoin in case of a successful routing attack can be substantial. By isolating a part of the network or delaying the propagation of blocks, attackers can force nodes to waste part of their mining power as some of the blocks they create are discarded. Partitioning also enables the attacker to filter transactions that clients try to include in the blockchain. In both cases, miners lose potential revenue from mining and render the network more susceptible to double spending attacks as well as to selfish mining attacks [24]. Nodes representing merchants, exchanges and other large entities are thus unable to secure their transactions, or may not be able to broadcast them to the network to begin with. The resulting longer-term loss of trust in Bitcoin security may trigger a loss of value for Bitcoin. Attackers may even short Bitcoin and gain from the resulting devaluation [35].

Our work underscores the importance of proposed modifications which argue for encrypting Bitcoin traffic [47] or traffic exchanged among miners [34]. Yet, we stress that not all routing attacks will be solved by such measures since attackers can still disrupt connectivity and isolate nodes by dropping Bitcoin packets instead of modifying them.

Contributions Our main contributions are:

• The first comprehensive study of network attacks on Bitcoin (Section III) ranging from attacks targeting a single node to attacks affecting the network as a whole.
• A measurement study of the routing properties of Bitcoin (Section VI). We show that Bitcoin is highly centralized: few ASes host most of the nodes while others intercept a considerable fraction of the connections.
• A thorough evaluation of the practicality of routing attacks (partitioning and delay attacks). Our evaluation is based on an extensive set of measurements, large-scale simulations and experiments on the actual Bitcoin software and network.
• A comprehensive set of countermeasures (Section IX), which can benefit even early adopters.

While our measurements are Bitcoin-specific, they carry important lessons for other cryptocurrencies which rely on a randomly structured peer-to-peer network atop of the Internet, such as Ethereum [1], Litecoin [9], and ZCash [14], [45].

II. BACKGROUND

A. BGP

Protocol BGP [42] is the de-facto routing protocol that regulates how IP packets are forwarded in the Internet. Routes associated with different IP prefixes are exchanged between neighboring networks or Autonomous Systems (AS). For any given IP prefix, one AS (the origin) is responsible for the original route advertisement, which is then propagated AS-by-AS until all ASes learn about it. Routers then set their next hop and pick one of the available routes offered by their neighbors (this is done independently for each destination).

In BGP, the validity of route announcements is not checked. In effect, this means that any AS can inject forged information on how to reach one or more IP prefixes, leading other ASes to send traffic to the wrong location. These rogue advertisements, known as BGP “hijacks”, are a very effective way for an attacker to intercept traffic en route to a legitimate destination.

BGP hijack An attacker, who wishes to attract all the traffic for a legitimate prefix ( p ) (say, 100.0.0.0/16) by hijacking could either: (i) announce ( p ); or (ii) announce a more-specific (longer)

prefix of $p$. In the first case, the attacker’s route will be in direct competition with the legitimate route. As BGP routers prefer shorter paths, the attacker will, on average, attract 50% of the traffic [30]. In the second case, the attacker will attract all the traffic (originated anywhere on the Internet) addressed to the destination as Internet routers forward traffic according to the longest-match entry. Note that traffic internal to an AS cannot be diverted via hijacking as it does not get routed by BGP but by internal routing protocols (e.g., OSPF).

For instance, in order to attract all traffic destined to $p$, the attacker could advertise 100.0.0.0/17 and 100.0.128.0/17. Routers in the entire Internet would then start forwarding any traffic destined to the original /16 prefix according to the two covering /17s originated by the adversary. Advertising more-specific prefixes has its limits though as BGP operators will often filter prefixes longer than /24 [33]. Yet, we show that the vast majority of Bitcoin nodes is hosted in shorter prefixes (Section VI) and is thus susceptible to hijacking.

By default, hijacking a prefix creates a black hole at the attacker’s location. However, the attacker can turn a hijack into an interception attack simply by making sure she leaves at least one path untouched to the destination [41], [30].

B. Bitcoin

Transactions Transaction validation requires nodes to be aware of the ownership of funds and the balance of each Bitcoin address. All this information can be learned from the Bitcoin blockchain: an authenticated data structure that effectively forms a ledger of all accepted transactions. Bitcoin main innovation lies in its ability to synchronize the blockchain in an asynchronous way, with attackers possibly attempting to disrupt the process. Synchronization is crucial: conflicting transactions attempting to transfer the exact same bitcoins to different destinations may otherwise be approved by miners that are unaware of each other.

Block creation Bitcoin’s blockchain is comprised of blocks, batches of transactions, that are appended to the ledger serially. Each block contains a cryptographic hash of its predecessor, which identifies its place in the chain, and a proof-of-work. The proof-of-work serves to make block creation difficult and reduces the conflicts in the system. Conflicts, which take the form of blocks that extend the same parent, represent alternative sets of accepted transactions. Nodes converge to a single agreed version by selecting the chain containing the highest amount of computational work as the valid version (usually the longest chain). The proof-of-work also serves to limit the ability of attackers to subvert the system: they cannot easily create many blocks, which would potentially allow them to create a longer alternative chain that will be adopted by nodes and thus reverse the transfer of funds (double spend).

The difficulty of block creation is set so that one block is created in the network every 10 minutes on average which is designed to allow sufficient time for blocks to propagate through the network. However, if delays are high compared to the block creation rate, many forks occur in the chain as blocks are created in parallel. In this case, the rate of discarded blocks (known as the orphan rate or the fork rate) increases and the security of the protocol deteriorates [20], [26], [49]. Newly created blocks are propagated through the network using a gossip protocol. In addition to the propagation of blocks, nodes also propagate transactions between them that await inclusion in the chain by whichever node creates the next block.

Network formation Bitcoin acts as a peer-to-peer network with each node maintaining a list of IP addresses of potential peers. The list is bootstrapped via a DNS server, and additional addresses are exchanged between peers. By default, each node randomly initiates 8 unencrypted TCP connections to peers in different /16 prefixes. Nodes additionally accept connections initiated by others (by default on port 8333). The total number of connections nodes can make is 125 by default.

Nodes continually listen to block announcements which are sent via INV messages containing the hash of the announced block. If a node determines that it does not hold a newly announced block, it sends a GETDATA message to a single neighbor. The peer then responds by sending the requested information in a BLOCK message. Blocks that are requested and do not arrive within 20 minutes trigger the disconnection of the peer and are requested from another. Transaction propagation occurs with a similar sequence of INV, GETDATA, and TX messages in which nodes announce, request, and share transactions that have not yet been included in the blockchain.

Mining pools Mining pools represent groups of miners that divide block creation rewards between them in order to lower the high economic risk associated with infrequent (but high) payments. They usually operate using the Stratum protocol [15]. The pool server is connected to a bitcoind node that acts as a gateway to the Bitcoin network. The node collects recent information regarding newly transmitted transactions and newly built blocks which are then used to construct a new block template. The template header is then sent via the Stratum server to the miners who attempt to complete it to a valid block. This is done by trying different values of the nonce field in the header. If the block is completed, the result is sent back to the Stratum server, which then uses the gateway node to publish the newly formed block to the network.

Multi-homing Mining pools often use multiple gateways hosted by different Internet Service Providers. We refer to the number of different ISPs a pool has as its multi-homing degree.

III. ROUTING ATTACKS ON BITCOIN

In this section, we give an overview of the two routing attacks we describe in this paper: (i) partitioning the Bitcoin network (Section III-A); and (ii) delaying the propagation of blocks. For each attack, we briefly describe its effectiveness and challenges as well as its impact on the Bitcoin ecosystem (Section III-B).

A. Partitioning the Bitcoin Network

In this attack, an AS-level adversary seeks to isolate a set of nodes $P$ from the rest of the network, effectively partitioning

the Bitcoin network into two disjoint components. The actual content of $P$ depends on the attacker’s objectives and can range from one or few merchant nodes, to a set of nodes holding a considerable percentage of the total mining power.

Attack The attacker first diverts the traffic destined to nodes in $P$ by hijacking the most-specific prefixes hosting each of the IP address. Once on-path, the attacker intercepts the Bitcoin traffic (e.g., based on the TCP ports) and identifies whether the corresponding connections cross the partition she tries to create. If so, the attacker drops the packets. If not, meaning the connections are contained within $P$, she monitors the exchanged Bitcoin messages so as to detect “leakage points”. Leakage points are nodes currently within $P$, which maintain connections with nodes outside of $P$, that the attacker cannot intercept, namely “stealth” connections. The attacker can detect these nodes automatically and isolate them from others in $P$ (Section IV). Eventually, the attacker isolates the maximal set of nodes in $P$ that can be isolated.

Example We illustrate the partition attack on the simple network in Fig. 1 that is composed of 8 ASes, some of which host Bitcoin nodes. Two mining pools are depicted as a green (left) and a red (right) region. Both pools are multi-homed and have gateways in different ASes. For instance, the red (right) pool has gateways hosted in AS4, AS5, and AS6. We denote the initial Bitcoin connections with blue lines, and those that have been diverted via hijacking with red lines. Dashed black lines represent private connections within the pools. Any AS on the path of a connection can intercept it.

Consider an attack by AS8 that is meant to isolate the set of nodes $P = {A, B, C, D, E, F}$. First, it hijacks the prefixes advertised by AS1, AS2 and AS6, as they host nodes within $P$, effectively attracting the traffic destined to them. Next, AS8 drops all connections crossing the partition: i.e., $(A, J)$, $(B, J)$ and $(F,G)$.

Observe that node $F$ is within the isolated set $P$, but is also a gateway of the red pool with which $F$ most likely communicates. This connection may not be based on the Bitcoin protocol and thus it cannot be intercepted (at least, not easily). As such, even if the attacker drops all the Bitcoin connections she intercepts, node $F$ may still learn about transactions and blocks produced on the other side and might leak this information within $P$. Isolating $P$ as such is infeasible. However, AS8 can identify that node $F$ is the leakage point during the attack and exclude it from $P$, essentially isolating $I’ = {A, B, C, D, E}$ instead. This $I’$ is actually the maximum subset of $P$ that can be isolated from the Bitcoin network.

Practicality We extensively evaluate the practicality of isolating sets of nodes of various sizes (Section VII). We briefly summarize our findings. First, we performed a real BGP hijack against our own Bitcoin nodes and show that it takes less than 2 minutes for an attacker to divert Bitcoin traffic. Second, we estimated the number of prefixes to hijack so as to isolate nodes with a given amount of mining power. We found that hijacking only 39 prefixes is enough to isolate a specific set of nodes which accounts for almost 50% of the overall mining power. Through a longitudinal analysis spanning over 6 months, we found that much larger hijacks happen regularly and that some of them have already impacted Bitcoin traffic. Third, we show that, while effective, partitions do not last long after the attack stops: the two components of the partition quickly reconnect, owing to natural churn. Yet, it takes hours for the two components to be densely connected again.

Impact The impact of a partitioning attack depends on the number of isolated nodes and how much mining power they have. Isolating a few nodes essentially constitutes a denial of service attack and renders them vulnerable to 0-confirmation double spends. Disconnecting a considerable amount of mining power can lead to the creation of two different versions of the blockchain. All blocks mined on the side with the least mining power will be discarded and all included transactions are likely to be reversed. Such an attack would cause revenue loss for the miners on the side with least mining power and a prominent risk of double spends. The side with the most mining power would also suffer from an increased risk of selfish mining attacks by adversaries with mining power.

B. Slowing down the Bitcoin network

In a delay attack, the attacker’s goal is to slow down the propagation of new blocks sent to a set of Bitcoin nodes without disrupting their connections. As with partitioning, the attack can be targeted, aimed at selected nodes, or network-wide, aimed at disrupting the ability of the entire network to reach consensus [20]. Unlike partitioning attacks though, an attacker can delay the overall propagation of blocks towards a node even if she intercepts a subset of its connections.

Attack Delay attacks leverage three key aspects of the Bitcoin protocol: (i) the asymmetry in the way Bitcoin nodes exchange blocks using INV, GETDATA, and BLOCK messages (Section II); (ii) the fact that these messages are not protected against tampering (unencrypted, no secure integrity checks); and (iii) the fact that a Bitcoin node waits for 20 minutes after having requested a block from a peer before requesting it again from another peer. These protocol features enable an attacker intercepting even one direction of the victim’s connection to delay the propagation of a block, as long as this connection is traversed by either the actual BLOCK message or the corresponding GETDATA.

Specifically, if the attacker intercepts the traffic from the victim, she can modify the content of the GETDATA message the victim uses to ask for blocks. By preserving the message length and structure and by updating the TCP and Bitcoin checksums, the modified message is accepted by the receiver and the connection stays alive. If the attacker intercepts the traffic towards a node, she can instead corrupt the content of the BLOCK message such that the victim considers it invalid. In both cases, the recipient of the blocks remains uninformed for 20 minutes.

Example As an illustration, consider Fig. 2, and assume that AS8 is the attacker and C, the victim. Suppose that A and B both advertise a block (say, block X) to C via an INV message and that, without loss of generality, the message from A arrives at C first. C will then send a GETDATA message back to A requesting block X and start a 20 minute timeout count. By modifying the content of the GETDATA node A receives, AS8 indirectly controls what node A will send to node C. This way the attacker can delay the delivery of the block by up to 20 minutes while avoiding detection and disconnection. Alternatively, AS8 could modify the BLOCK message.

Practicality We verified the practicality of delay attacks by implementing an interception software which we used against our own Bitcoin nodes. We show that intercepting 50% of a node connections is enough to keep the node uninformed for 63% of its uptime (Section VIII).

We also evaluated the impact that ASes, which are naturally traversed by a lot of Bitcoin traffic, could have on the network using a scalable event-driven simulator. We found that due to the relatively high degree of multi-homing that pools employ, only very powerful coalitions of network attackers (e.g., all ASes based in the US) could perform a network-wide delay attack. Such an attack is thus unlikely to occur in practice.

Impact Similarly to partitioning attacks, the impact of a delay attack depends on the number and type (e.g., pool gateway) of impacted nodes. At the node-level, delay attacks can keep the victim eclipsed, essentially performing a denial of service attack or rendering it vulnerable to 0-confirmation double spends. If the node is a gateway of a pool, such attacks can be used to engineer block races, and waste the mining power of the pool. Network-wide attacks increase the fork rate and render the network vulnerable to other exploits. If a sufficient number of blocks are discarded, miners revenue is decreased and the network is more vulnerable to double spending. A slowdown of block transmission can be used to launch selfish mining attacks by adversaries with mining power.

IV. Partitioning Bitcoin

In this section, we elaborate on partition attacks in which an AS-level adversary seeks to isolate a set of nodes P. We first describe which partitions are feasible by defining which connections may cause information leakage (Section IV-A) to the isolated set. We then discuss how an attacker may better select a P that is feasible, if she has some view of the Bitcoin topology (Section IV-B). Next, we walk through the entire attack process, starting with the interception of Bitcoin traffic, the detection of leakage points and the adaptation of P until the partition is successfully created (Section IV-C). In particular, we present an algorithm which, given a set of nodes P, leads the attacker to isolate the maximal feasible subset. Finally, we prove that our algorithm is correct (Section IV-D).

A. Characterizing feasible partitions

An attacker can isolate a set of nodes P from the network if and only if all connections (a, b) where a ∈ P and b /∈ P can be intercepted. We refer to such connections as vulnerable and to connections that the attacker cannot intercept as stealth.

Vulnerable connections: A connection is vulnerable if: (i) an attacker can divert it via a BGP hijack; and (ii) it uses the Bitcoin protocol. The first requirement enables the attacker to intercept the corresponding packets, while the second enables her to identify and then drop or monitor these packets.

As an illustration, consider Fig. 3a, and assume that the attacker, AS8, wants to isolate P = {A, B, C}. By hijacking the prefixes pertaining to these nodes the attacker receives all traffic from nodes A and B to node C, as well as the traffic from node D to node A. The path the hijacked traffic follows is depicted with red dashed lines and the original path with blue lines. As all nodes communicate using the Bitcoin protocol, their connections can easily be distinguished, as we explain in Section IV-C. Here, AS8 can partition P from the rest of the network by dropping the connection from node D to node A.

Stealth connections: A connection is stealth if the attacker cannot intercept it. We distinguish three types of stealth connections: (i) intra-AS; (ii) intra-pool; and (iii) pool-to-pool.

intra-AS: An attacker cannot intercept connections within the same AS using BGP hijack. Indeed, internal traffic does not get routed by BGP, but by internal routing protocols (e.g., OSPF, EIGRP). Thus, any intra-AS connection crossing the partition border renders the partition infeasible. Such connections represent only 1.14% of all the possible connection nodes can create (this percentage is calculated based on the topology we inferred in Section VI).

As an illustration, consider Fig. 3b and assume that the attacker, AS8, wants to isolate $P = {A, B, C}$. By hijacking the corresponding BGP prefixes, AS8 can intercept the connections running between nodes $A$ and $B$ to node $C$. However, she does not intercept the intra-AS connection between $A$ and $X$. This means that node $X$ will inform node $A$ of the blocks mined in the rest of the network, and node $A$ will then relay this information further within $P$. Thus, $P = {A, B, C}$ is not feasible. Yet, observe that isolating $I = {B, C}$ is possible. In the following, we explain how the attacker can detect that $A$ maintains a stealth connection leading outside of the partition and dynamically adapt to isolate $I$ instead.

intra-pool: Similarly to intra-AS connections, an attacker might not be able to cut connections between gateways belonging to the same mining pool. This is because mining pools might rely on proprietary or even encrypted protocols for internal communication.

As an illustration, consider Fig. 3c and assume that the attacker, AS8, wants to isolate $P = {A, B, C, D}$. By hijacking the corresponding prefixes, she would intercept and cut all Bitcoin connections between nodes $A, B, C, D$ and nodes $E, F$. However, nodes $A$ and $F$ would still be connected internally as they belong to the same (green) pool. Again, observe that while isolating $P = {A, B, C, D}$ is not feasible, isolating $I = {B, C, D}$ from the rest of the network is possible.

pool-to-pool: Finally, an attacker cannot intercept (possibly encrypted) private connections, corresponding to peering agreements between mining pools. From the attacker’s point of view, these connections can be treated as intra-pool connections and the corresponding pair of pools can be considered as one larger pool. Note that such connections are different than public initiatives to interconnect all pools, such as the Bitcoin relays [13]. Unlike private peering agreements, relays cannot act as bridges to the partition (see Appendix E).

B. Preparing for the attack

In light of these limitations the attacker can apply two techniques to avoid having stealth connections crossing the partition she creates. First, she can include in $P$ either all or none of the nodes of an AS, to avoid intra-AS connections crossing the partition. This can be easily done as the mapping from IPs to ASNs is publicly available [11]. Second, she can include in $P$ either all or none of the gateways of a pool, to avoid intra-pool connections crossing the partition. Doing so requires the attacker to know all the gateways of the mining pools she wants to include in $P$. Inferring the gateways is outside the scope of this paper, yet the attacker could use techniques described in [36] and leverage her ability to inspect the traffic of almost every node via hijacking (see Appendix C). Even with the above measures, $P$ may still contain leakage points that the attacker will need to identify and exclude (see below). Yet, these considerations increase the chances of establishing the desired partition as well as reducing the time required to achieve it.

C. Performing the attack

We now describe how a network adversary can successfully perform a partitioning attack. The attack is composed of two main phases: (i) diverting relevant Bitcoin traffic; and (ii) enforcing the partition. In the former phase, the adversary diverts relevant Bitcoin traffic using BGP hijacking. In the latter phase, the attacker cuts all vulnerable connections that cross the partition and excludes from $P$ nodes which are identified as leakage points. Leakage points are nodes that are connected to the rest of the network via stealth connections.

Intercept Bitcoin traffic: The attacker starts by hijacking all the prefixes pertaining to the Bitcoin nodes she wants to isolate, i.e. all the prefixes covering the IP addresses of nodes in $P$. As a result, she receives all the traffic destined to these prefixes, which she splits into two packet streams: relevant and Algorithm 1: Partitioning algorithm.

Input: $P$, a set of Bitcoin IP addresses to disconnect from the rest of the Bitcoin network; and $S = [pkt_1, \ldots]$, an infinite packet stream of diverted Bitcoin traffic resulting from the hijack of the prefixes pertaining to $P$.

Output: False if there is no node $\in P$ that can be verifiably isolated;

1. enforce_partition($P, S$):
2. begin
3. $U \leftarrow \emptyset$;
4. $L \leftarrow \emptyset$;
5. while $P \setminus (L \cup U) \neq \emptyset$ do
6. for $pkt \in S$ do
7. if $pkt.ip_{\text{src}} \in P \land pkt.ip_{\text{dst}} \notin L$ then
8. $last_seen[pkt.ip_{\text{dst}}] = \text{now}()$;
9. $U \leftarrow U \setminus {pkt.ip_{\text{src}}}$;
10. detect_leakage($U, pkt$);
11. else drop(pkt);
12. end
13. for $src \in P \land src \notin L$ do
14. if $last_seen[src] > \text{now}() – \text{threshold}$ then
15. $U \leftarrow U \cup {src}$
16. end
17. return false;

Irrelevant. Relevant traffic includes any Bitcoin traffic destined to nodes in $P$. This traffic should be further investigated. Irrelevant traffic corresponds to the remaining traffic which should be forwarded back to its legitimate destination.

To distinguish between relevant and irrelevant traffic, the attacker applies a simple filter matching on the IP addresses, the transport protocol and ports used, as well as certain bits of the TCP payload. Specifically, the attacker classifies as irrelevant all non-TCP traffic as well as all traffic with destination IPs which are not included in $P$. In contrast, the attacker classifies as relevant all traffic with destination or source TCP port the default Bitcoin port (8333). Finally, she classifies as relevant all packets which have a Bitcoin header in the TCP payload. Any remaining traffic is considered irrelevant.

Partitioning algorithm: Next, the attacker processes the relevant traffic according to Algorithms 1 and 2. We start by presenting their goal before describing them in more details.

The high-level goal of the algorithms is to isolate as many nodes in $P$ as possible. To do so, the algorithms identify $L$, the nodes that are leakage points, and disconnect them from the other nodes in $P$. Also, the algorithms maintain a set of verifiably isolated nodes $P’ = P \setminus {U \cup L}$, where $U$ corresponds to the nodes that cannot be monitored (e.g., because they never send packets). In particular, Algorithm 2 is in charge of identifying $L$, while Algorithm 1 is in charge of identifying $U$ and performing the isolation itself.

We now describe how the algorithms work. Algorithm 1 starts by initializing $L$ and $U$ to $\emptyset$. For every received packet, the algorithm first decides whether the packet belongs to a connection internal to $P \setminus L$ or to one between a node in $P \setminus L$ and an external node based on the source IP address. If the source IP is in $P \setminus L$, the packet belongs to an internal connection and it is given to Algorithm 2 to investigate if the corresponding node acts as a leakage point (Algorithm 1, Line 10). Otherwise, the packet belongs to a connection that crosses the partition and is dropped (Algorithm 1, Line 12).

Given a packet originated from $P \setminus L$, Algorithm 2 checks whether the sender of the packet is advertising information from outside of $P \setminus L$. Particularly, the attacker checks whether the packet contains an INV message with the hash of a block mined outside of $P \setminus L$ (or the block itself). If it does so, the sender must have a path of stealth connections to a node outside of $P \setminus L$ from which the block was transmitted. Thus the sender is a leakage point and is added to $L$ (Algorithm 2, Line 5). The actual packet is also dropped to prevent this information from spreading.

To detect whether a node in $P \setminus L$ is a leakage point, an attacker should be able to intercept at least one of that node’s connections. Specifically, the node should have a vulnerable connection to another node within $P \setminus L$, so that the attacker can monitor the blocks it advertises. To keep track of the nodes that the attacker cannot monitor, Algorithm 1 maintains a set $U$ which contains the nodes she has not received any packets from for a predefined time threshold. (Algorithm 1, Line 15). Whenever one of these nodes manages to establish a connection that the attacker intercepts, it is removed from $U$ (Algorithm 1, Line 9).

Example: We now show how the algorithms work on the example of Fig. 3b in which the attacker, AS8, aims to isolate $P = {A, B, C}$. By hijacking the prefixes corresponding to these nodes, the attacker intercepts the connections $(B, C)$ and $(A, C)$ and feeds the relevant packets to the algorithms. Recall that the partition is bridged by a stealth (intra-AS) connection between nodes $A$ and $X$ which cannot be intercepted by the attacker. When a block outside $P$ is mined, node $X$ will inform $A$ which then will advertise the block to $C$. The attacker will catch this advertisement and will conclude that node $A$ is a leakage point. After that, the attacker will drop the packet and will add $A$ to $L$. As such, all future packets from $A$ to other nodes within $P \setminus L = {A, B}$ will be dropped. Observe that the partition isolating $P \setminus L = {B, C}$ is indeed the maximum feasible subset of $P$.

Algorithm 2: Leakage detection algorithm.

Input: $U$, a set of Bitcoin IP addresses the attacker cannot monitor; and $pkt$, a (parsed) diverted Bitcoin packet.

drop(pkt);

detect_leakage($U, pkt$):

begin

if contains_block($pkt) \lor contains_inv($pkt) then

if hash($pkt) \in \text{Blocks}(\neg (P \setminus L)) then

$L \leftarrow L \cup {pkt.ip_{\text{src}}}$;

D. Correctness of the partitioning algorithm

We now prove the properties of Algorithm 1.

Theorem 1. Given ( P ), a set of nodes to disconnect from the Bitcoin network, there exists a unique maximal subset ( I \subseteq P ) that can be isolated. Given the assumption that Bitcoin nodes advertise blocks that they receive to all their peers, Algorithm 1 isolates all nodes in ( I ), and maintains a set ( P’ = P \setminus { U \cup L } \subseteq I ) that contains all nodes in ( I ) that have a monitored connection and are thus known to be isolated.

Proof. Consider the set of nodes ( S \subseteq P ) that has a path of stealth connections to some nodes not in ( P ). Clearly, nodes in ( S ) cannot be isolated from the rest of the network by the attacker. Let ( I = P \setminus S ). Notice that ( I ) is the maximal set in ( P ) that can be disconnected by an attacker. Now, notice that every node in ( S ) is placed in sets ( L ) or ( U ) by the algorithm: if the node has a monitored connection and is caught advertising external blocks it is placed in ( L ) (Algorithm 2 Line 5). If it is not monitored then it is placed in ( U ) (Algorithm 1, Line 15).

Notice also that the entire set ( I ) is isolated from the network. If some node has no stealth connection outside, and was removed solely for the lack of monitoring, it is still having all its packets from outside of ( P \setminus L ) dropped – Algorithm 1 Line 12.

V. DELAYING BLOCK PROPAGATION

While partitioning attacks (Section IV) are particularly effective and can be performed by any AS, they require full control over the victim’s traffic and are also highly visible. In this section, we explore delay attacks, which can cause relatively severe delays in block propagation, even when an attacker intercepts only one of the victim’s connections, and wishes the attack to remain relatively undetectable.

In this attack, the adversary delays the delivery of a block by modifying the content of specific messages. This is possible due to the lack of encryption and of secure integrity checks of Bitcoin messages. In addition to these, the attacker leverages the fact that nodes send block requests to the first peer that advertised each block and wait 20 minutes for its delivery, before requesting it from another peer.

The first known attack leveraging this 20 minutes timeout [28] mandates the adversary to be connected to the victim and to be the first to advertise a new block. After a successful block delay, the connection is lost. In contrast, network-based delay attacks are more effective for at least three reasons: (i) an attacker can act on existing connections, namely she does not need to connect to the victim which is very often not possible (e.g., nodes behind a NAT); (ii) an attacker does not have to be informed about recently mined blocks by the victim’s peers to eclipse it; and (iii) the connection that was used for the attack is not necessarily lost, prolonging the attack.

Particularly, the effectiveness of the delay attack depends on the direction and fraction of the victim’s traffic the attacker intercepts. Intuitively, as Bitcoin clients request blocks from one peer at a time, the probability that the attacker will intercept such a connection increases proportionally with the fraction of the connections she intercepts. In addition, Bitcoin connections are bi-directional TCP connections, meaning the attacker may intercept one direction (e.g., if the victim is multi-homed), both, or none at all. Depending on the direction she intercepts, the attacker fiddles with different messages.

In the following, we explain the mechanism that is used to perform the attack if the attacker intercepts traffic from the victim (Section V-A) or to the victim node (Section V-B). While in both cases the attacker does delay block propagation for 20 minutes, the former attack is more effective.

A. The attacker intercepts outgoing traffic

Once a node receives a notification that a new block is available via an INV message, it issues a download request to its sender using a GETDATA message. As an illustration in Fig. 4a the victim requests Block 42 from the first of its peers that advertised the block. Since the attacker intercepts the traffic from the victim to this peer, she can modify this GETDATA message to request an older block, instead of the original one. In Fig. 4a, for example, the attacker replaces the hash corresponding to block 42 with that of block 30. The advantage of doing so, over just dropping the packet, is that the length of the message is left unchanged. Notice that if the packet was dropped the attacker would need to intercept both directions of the connection and update the TCP sequence numbers of all following packets to ensure that the connection is not dropped. If the block is not delivered, the victim node will disconnect after 20 minutes. To avoid a disconnection, the attacker can use another GETDATA, sent within the 20 minute window, to perform the reverse operation. Specifically, she modifies the hash back to the original one, requested by the victim. Since the GETDATA message for blocks and transactions have the same structure, the attacker is more likely to use the latter as these are much more common. In Fig. 4a, for example, she changes the hash of the transaction (Tx #123)

to the hash of block 42. Since the block is delivered within the timeout neither of the nodes disconnects or has any indication of the attack (e.g., an error in the log files).

B. The attacker intercepts incoming traffic

We now describe the mechanism an attacker would use if she intercepts traffic towards the victim, i.e., she can see messages received by the victim, but not the messages that it sends. This attack is less effective compared to the attack working in the opposite direction, as it will eventually result in the connection being dropped 20 minutes after the first delayed block (similarly to [28]). In this case, the attack focuses on the BLOCK messages rather than on the GETDATA. A naive attack would be for the attacker to simply drop any BLOCK message she sees. As Bitcoin relies on TCP though, doing so would quickly kill the TCP connection. A better, yet still simple approach is for the attacker to corrupt the contents of a BLOCK message while preserving the length of the packet (see Fig. 4b). This simple operation causes the BLOCK to be discarded when it reaches the victim, because of a checksum mismatch. Surprisingly though, we discovered (and verified) that the victim will not request the block again, be it from the same or any other peer. After the 20 minute timeout elapses, the victim simply disconnects because its requested block did not arrive on time.

An alternative for the adversary is to replace the hash of the most recent Block with a hash of an older one in all the INV messages the victim receives. This attack however would fail if the attacker intercepts only a fraction of the connections, as the victim will be informed via other connections. As such, this practice is only useful when the attacker hijacks and thus intercepts all the traffic directed to the victim.

VI. HOW VULNERABLE IS BITCOIN TO ROUTING ATTACKS? A COMPREHENSIVE MEASUREMENT ANALYSIS

Evaluating the impact of routing attacks requires a good understanding of the routing characteristics of the Bitcoin network. In this section, we explain the datasets and the techniques used to infer a combined Internet and Bitcoin topology (Section VI-A). We then discuss our key findings and their impact on the effectiveness of the two routing attacks we consider (Section VI-B).

A. Methodology and datasets

Our study is based on three key datasets: (i) the IP addresses used by Bitcoin nodes and gateways of pools; (ii) the portion of mining power each pool possesses; (iii) the forwarding path taken between any two IPs. While we collected these datasets over a period of 6 months, starting from October 2015 through March 2016, we focus on the results from a 10 day period starting from November 5th 2015, as the results of our analysis do not change much through time.

Bitcoin IPs

We started by collecting the IPs of regular nodes (which host no mining power) along with the IPs of the gateways the pools use to connect to the network. We gathered this dataset by combining information collected by two Bitcoin supernodes with publicly available data regarding mining pools. One supernode was connected to $\sim2000$ Bitcoin nodes per day, collecting block propagation information, while the other was crawling the Bitcoin network, collecting the $\sim6,000$ IPs of active nodes each day.

We inferred which of these IPs act as the gateway of a pool in two steps. First, we used block propagation information (gathered by the first supernode), considering that the gateways of a pool are most likely the first to propagate the blocks this pool mines. Particularly, we assigned IPs to pools based on the timing of the INV messages received by the supernode. We considered a given IP to belong to a gateway of a pool if: (i) it relayed blocks of that pool more than once during the 10 day period; and (ii) it frequently was the first to relay a block of that pool (at least half as many times as the most frequent node for that pool). Second, we also considered as extra gateways the IPs of the stratum servers used by each mining pool. Indeed, previous studies [36] noted that stratum servers tend to be co-located in the same prefix as the pool’s gateway. Since the URLs of the stratum servers are public (Section II), we simply resolved the DNS name (found on the pools websites or by directly connecting to them) and add the corresponding IPs to our IP-to-pool dataset.

Mining power

To infer the mining power attached to pools, we tracked how many blocks each pool mined during the 10 days interval [2] and simply assigned them a proportional share of the total mining power.

AS-level topology and forwarding paths

We used the AS-level topologies provided by CAIDA [5] to infer the forwarding paths taken between any two ASes. An AS-level topology is a directed graph in which a node corresponds to an AS and a link represents an inter-domain connection between two neighboring ASes. Links are labeled with the business relationship linking the two ASes (customer, peer or provider). We computed the actual forwarding paths following the routing tree algorithm described in [30] which takes into account the business relationships between ASes.

Mapping Bitcoin nodes to ASes

We finally inferred the most-specific prefix and the AS hosting each Bitcoin node by processing more than 2.5 million BGP routes (covering all Internet prefixes) advertised on 182 BGP sessions maintained by 3 RIPE BGP collectors [10] (rrc00, rrc01 and rrc03). The mapping is done by associating each prefix to the origin AS advertising it and by validating the stability of that origin AS over time (to avoid having the mapping polluted by hijacks).

B. Findings

We now discuss the key characteristics of the Bitcoin network from the Internet routing perspective. We explain which of them constitute enablers or hindrances for an AS-level attacker.

A few ASes host most of the Bitcoin nodes

Fig. 5a depicts the cumulative fraction of Bitcoin nodes as a function of the number of hosting ASes. We see that only 13 (resp. 50) ASes

host 30% (resp. 50%) of the entire Bitcoin network. These ASes pertain to broadband providers such as Comcast (US), Verizon (US) or Chinanet (CN) as well as to cloud providers such as Hetzner (DE), OVH (FR) and Amazon (US). We observe the same kind of concentration when considering the distribution of Bitcoin nodes per IP prefix: only 63 prefixes (0.012% of the Internet) host 20% of the network.

Regarding delay attacks, this high concentration makes Bitcoin traffic more easy to intercept and therefore more vulnerable. With few ASes hosting many nodes, any AS on-path (including the host ASes) is likely to intercept many connections at once, making delay attacks more disruptive. Regarding partition attacks, the effect of the concentration is a bit more nuanced. Indeed, high concentration reduces the total number of feasible partitions because of intra-AS connections that cannot be intercepted (Section IV-A). At the same time, tough, the remaining feasible partitions are much easier to achieve since they require fewer hijacked prefixes (Section IV).

A few ASes naturally intercept the majority of the Bitcoin traffic Large transit providers (i.e., Tier-1s) tend to be traversed by a large fraction of all the Bitcoin connections. Fig. 5b depicts the cumulative percentage of connections that can be intercepted by an increasing number of ASes (e.g., by colluding with each other). We see that only three ASes, namely Hurricane Electric, Level3, and Telianet, can together intercept more than 60% of all possible Bitcoin connections, with Hurricane alone being on path for 32% of all connections.

Regarding delay attacks, these few ASes could act as powerful delay attackers. Regarding partition attacks, this observation does not have any direct implication as partitioning requires a full cut to be effective (Section IV).

90% of Bitcoin nodes are vulnerable to BGP hijacks 93% of all prefixes hosting Bitcoin nodes are shorter than /24, making them vulnerable to a global IP hijack using more-specific announcements. Indeed, prefixes strictly longer than /24 (i.e., /25 or longer) are filtered by default by many ISPs. Observe that the remaining 7% hosted in /24s are not necessarily safe. These can still be hijacked by another AS performing a shortest-path attack, i.e., the attacker, who will advertise a /24 just like the victim’s provider will attract traffic from all ASes that are closer to her in terms of number of hops.

While this finding does not have a direct impact on delay attacks, it clearly helps partition attackers as they can divert almost all Bitcoin traffic to their infrastructure (modulo stealth connections, see Section IV).

Mining pools tend to be distributed and multi-homed Mining pools have a complex infrastructure compared to regular nodes. We found that all pools use at least two ASes to connect to the Bitcoin network, while larger pools such as Antpool, F2Pools, GHash.IO, Kano use up to 5 ASes.

Pool multi-homing makes both network attacks more challenging and is one of the main precaution measures node owners can use against routing attacks. While harder, routing attacks are still possible in the presence of multi-homing as we illustrate in Section VIII.

Bitcoin routing properties are stable over time While numerous nodes continuously join and leave the Bitcoin network, the routing properties highlighted in this section are stable. As validation, we ran our analysis daily over a 4 month period. We found that the same IPs were present on average for 15.2 consecutive days (excluding IPs that were seen only once). Moreover, 50 ASes hosted each day 49.5% of Bitcoin clients (standard deviation: 1.2%) while 24.7% of Bitcoin nodes are found daily in just 100 prefixes (standard deviation: 1.77%).

VII. PARTITIONING BITCOIN: EVALUATION

In this section, we evaluate the practicality and effectiveness of partitioning attacks by considering four different aspects of the attack. First, we show that diverting Bitcoin traffic using BGP hijacks works in practice by performing an actual hijack targeting our own Bitcoin nodes (Section VII-A). Second, we show that hijacking fewer than 100 prefixes is enough to isolate a large amount of the mining power due to Bitcoin’s centralization (Section VII-B). Third, we show that much larger hijacks already happen in the Internet today, some already diverting Bitcoin traffic (Section VII-C). Fourth, we show that Bitcoin quickly recovers from a partition attack once it has stopped (Section VII-D).

A. How long does it take to divert traffic with a hijack?

We hijacked and isolated our own Bitcoin nodes which were connected to the live network via our own public IP prefixes. In the following, we describe our methodology as well as our findings with regard to the time it takes for a partition to be established.

Methodology We built our own virtual AS with full BGP connectivity using Transit Portal (TP) [46]. TP provides virtual ASes with BGP connectivity to the rest of the Internet by proxying their BGP announcements via multiple worldwide deployments, essentially acting as a multi-homed provider to the virtual AS. In our experiment, we used the Amsterdam TP deployment as provider and advertised 184.164.232.0/22 to it. Our virtual AS hosted six bitcoin nodes (v/Satoshi:0.13.0/). Each node had a public IP in 184.164.232.0/22 (.1 to .6 addresses) and could therefore accept connections from any other Bitcoin node in the Internet.

---

Useful information for enthusiasts:

• [1]YouTube Channel CryptoDeepTech
• [2]Telegram Channel CryptoDeepTech
• [3]GitHub Repositories CryptoDeepTools
• [4]Telegram: ExploitDarlenePRO
• [5]YouTube Channel ExploitDarlenePRO
• [6]GitHub Repositories Keyhunters
• [7]Telegram: Bitcoin ChatGPT
• [8]YouTube Channel BitcoinChatGPT
• [9] Bitcoin Core Wallet Vulnerability
• [10] BTC PAYS DOCKEYHUNT
• [11] DOCKEYHUNT
• [12]Telegram: DocKeyHunt
• [13]ExploitDarlenePRO.com
• [14]DUST ATTACK
• [15]Vulnerable Bitcoin Wallets
• [16] ATTACKSAFE SOFTWARE
• [17] LATTICE ATTACK
• [18] RangeNonce
• [19] BitcoinWhosWho
• [20] Bitcoin Wallet by Coinbin
• [21] POLYNONCE ATTACK
• [22] Cold Wallet Vulnerability
• [23] Trezor Hardware Wallet Vulnerability
• [24] Exodus Wallet Vulnerability
• [25] BITCOIN DOCKEYHUNT

Contact me via Telegram: @ExploitDarlenePRO