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