Eclipse Attacks on Bitcoin's Peer-To-Peer Network
Total Page：16
File Type：pdf, Size：1020Kb
Eclipse Attacks on Bitcoin’s Peer-to-Peer Network ∗ Ethan Heilman∗ Alison Kendler∗ Aviv Zohar† Sharon Goldberg∗ ∗Boston University †Hebrew University/MSR Israel Abstract While the last few years have seen extensive research We present eclipse attacks on bitcoin’s peer-to-peer net- into the security of bitcoin’s computational proof-of- work. Our attack allows an adversary controlling a suffi- work protocol e.g., [14, 29, 36, 37, 45, 49, 50, 52, 58, 60], cient number of IP addresses to monopolize all connec- less attention has been paid to the peer-to-peer network tions to and from a victim bitcoin node. The attacker can used to broadcast information between bitcoin nodes (see then exploit the victim for attacks on bitcoin’s mining Section 8). The bitcoin peer-to-peer network, which and consensus system, including N-confirmation double is bundled into the core bitcoind implementation, aka., spending, selfish mining, and adversarial forks in the the Satoshi client, is designed to be open, decentralized, blockchain. We take a detailed look at bitcoin’s peer- and independent of a public-key infrastructure. As such, to-peer network, and quantify the resources involved in cryptographic authentication between peers is not used, our attack via probabilistic analysis, Monte Carlo simu- and nodes are identified by their IP addresses (Section 2). lations, measurements and experiments with live bitcoin Each node uses a randomized protocol to select eight nodes. Finally, we present countermeasures, inspired by peers with which it forms long-lived outgoing connec- botnet architectures, that are designed to raise the bar for tions, and to propagate and store addresses of other po- eclipse attacks while preserving the openness and decen- tential peers in the network. Nodes with public IPs also tralization of bitcoin’s current network architecture. accept up to 117 unsolicited incoming connections from any IP address. Nodes exchange views of the state of the 1 Introduction blockchain with their incoming and outgoing peers. Eclipse attacks. This openness, however, also makes it While cryptocurrency has been studied since the possible for adversarial nodes to join and attack the peer- 1980s [22, 25, 28], bitcoin is the first to see widespread to-peer network. In this paper, we present and quantify adoption.A key reason for bitcoin’s success is its baked- the resources required for eclipse attacks on nodes with in decentralization. Instead of using a central bank to public IPs running bitcoind version 0.9.3. In an eclipse regulate currency, bitcoin uses a decentralized network attack [27, 61, 62], the attacker monopolizes all of the of nodes that use computational proofs-of-work to reach victim’s incoming and outgoing connections, thus iso- consensus on a distributed public ledger of transactions, lating the victim from the rest of its peers in the net- aka., the blockchain. Satoshi Nakamoto [52] argues that work. The attacker can then filter the victim’s view bitcoin is secure against attackers that seek to shift the of the blockchain, force the victim to waste compute blockchain to an inconsistent/incorrect state, as long as power on obsolete views of the blockchain, or coopt these attackers control less than half of the computa- the victim’s compute power for its own nefarious pur- tional power in the network. But underlying this security poses (Section 1.1). We present off-path attacks, where analysis is the crucial assumption of perfect information; the attacker controls endhosts, but not key network in- namely, that all members of the bitcoin ecosystem can frastructure between the victim and the rest of the bit- observe the proofs-of-work done by their peers. coin network. Our attack involves rapidly and repeatedly forming unsolicited incoming connections to the victim ∗This is the full version of a paper that ap- from a set of endhosts at attacker-controlled IP addresses, peared at 24th USENIX Security Symposium, sending bogus network information, and waiting until the Washington, DC., August 2015. First posted victim restarts (Section 3). With high probability, the March 20, 2015; updated July 2, 2015. victim then forms all eight of its outgoing connections to 1 attacker-controlled addresses, and the attacker also mo- tim be cannot eclipsed regardless of the number of IP nopolizes the victim’s 117 incoming connections. addresses the attacker controls. Our countermeasures 1, Our eclipse attack uses extremely low-rate TCP con- 2, and 6 have been deployed in bitcoind v0.10.1; we also nections, so the main challenge for the attacker is to developed a patch [40] with Countermeasures 3,4. obtain a sufficient number of IP addresses (Section 4). We consider two attack types: (1) infrastructure attacks, modeling the threat of an ISP, company, or nation-state 1.1 Implications of eclipse attacks that holds several contiguous IP address blocks and seeks Apart from disrupting the bitcoin network or selectively to subvert bitcoin by attacking its peer-to-peer network, filtering a victim’s view of the blockchain, eclipse attacks and (2) botnet attacks, launched by bots with addresses in are a useful building block for other attacks. diverse IP address ranges. We use probabilistic analysis, (Section 4) measurements (Section 5), and experiments Engineering block races. A block race occurs when on our own live bitcoin nodes (Section 6) to find that two miners discover blocks at the same time; one block while botnet attacks require far fewer IP addresses, there will become part of the blockchain, while the other “or- are hundreds of organizations that have sufficient IP re- phan block” will be ignored, yielding no mining rewards sources to launch eclipse attacks (Section 4.2.1). For ex- for the miner that discovered it. An attacker that eclipses ample, we show how an infrastructure attacker with 32 many miners can engineer block races by hording blocks distinct /24 IP address blocks (8192 address total), or a discovered by eclipsed miners, and releasing blocks to botnet of 4600 bots, can always eclipse a victim with at both the eclipsed and non-eclipsed miners once a com- least 85% probability; this is independent of the number peting block has been found. Thus, the eclipsed miners of nodes in the network. Moreover, 400 bots sufficed in waste effort on orphan blocks. tests on our live bitcoin nodes. To put this in context, Splitting mining power. Eclipsing an x-fraction of if 8192 attack nodes joined today’s network (containing miners eliminates their mining power from the rest of ≈ 7200 public-IP nodes [4]) and honestly followed the the network, making it easier to launch mining attacks peer-to-peer protocol, they could eclipse a target with (e.g., the 51% attack [52]). To hide the change in min- 8192 8 probability about ( 7200+8192 ) = 0:6%. ing power under natural variations [19], miners could be Our attack is only for nodes with public IPs; nodes eclipsed gradually or intermittently. with private IPs may be affected if all of their outgoing Selfish mining. With selfish mining [14,29,37,60], the connections are to eclipsed public-IP nodes. attacker strategically withholds blocks to win more than Countermeasures. Large miners, merchant clients its fair share of mining rewards. The attack’s success and online wallets have been known to modify bit- is parameterized by two values: a, the ratio of mining coin’s networking code to reduce the risk of network- power controlled by the attacker, and g, the ratio of hon- based attacks. Two countermeasures are typically rec- est mining power that will mine on the attacker’s blocks ommended [3]: (1) disabling incoming connections, and during a block race. If g is large, then a can be small. By (2) choosing ‘specific’ outgoing connections to well- eclipsing miners, the attacker increases g, and thus de- connected peers or known miners (i.e., use whitelists). creases a so that selfish mining is easier. To do this, the However, there are several problems with scaling this to attacker drops any blocks discovered by eclipsed miners the full bitcoin network. First, if incoming connections that compete with the blocks discovered by the selfish are banned, how do new nodes join the network? Sec- miners. Next, the attacker increases g by feeding only ond, how does one decide which ‘specific’ peers to con- the selfish miner’s view of the blockchain to the eclipsed nect to? Should bitcoin nodes form a private network? miner; this coopts the eclipsed miner’s compute power, If so, how do they ensure compute power is sufficiently using it to mine on the selfish-miner’s blockchain. decentralized to prevent mining attacks? Indeed, if bitcoin is to live up to its promise as an open Attacks on miners can harm the entire bitcoin ecosys- and decentralized cryptocurrency, we believe its peer-to- tem; mining pools are also vulnerable if their gateways peer network should be open and decentralized as well. to the public bitcoin network can be eclipsed. Eclipsing Thus, our next contribution is a set of countermeasures can also be used for double-spend attacks on non-miners, that preserve openness by allowing unsolicited incom- where the attacker spends some bitcoins multiple times: ing connections, while raising the bar for eclipse attacks 0-confirmation double spend. In a 0-confirmation (Section 7). Today, an attacker with enough addresses transaction, a customer pays a transaction to a mer- can eclipse any victim that accepts incoming connections chant who releases goods to the customer before seeing and then restarts. Our countermeasures ensure that, with a block confirmation i.e., seeing the transaction in the high probability, if a victim stores enough legitimate ad- blockchain [18].