This paper is included in the Proceedings of the 24th USENIX Security Symposium
August 1214, 2015 Washington, D.C.
Open access to the Proceedings of the 24th USENIX Security Symposium
is sponsored by USENIX
Eclipse Attacks on Bitcoins Peer-to-Peer NetworkEthan Heilman and Alison Kendler, Boston University; Aviv Zohar, The Hebrew University of
Jerusalem and MSR Israel; Sharon Goldberg, Boston University
USENIX Association 24th USENIX Security Symposium 129
Eclipse Attacks on Bitcoins Peer-to-Peer Network
Ethan Heilman Alison Kendler Aviv Zohar Sharon GoldbergBoston University Hebrew University/MSR Israel
AbstractWe present eclipse attacks on bitcoins peer-to-peer net-work. Our attack allows an adversary controlling a suffi-cient number of IP addresses to monopolize all connec-tions to and from a victim bitcoin node. The attacker canthen exploit the victim for attacks on bitcoins miningand consensus system, including N-confirmation doublespending, selfish mining, and adversarial forks in theblockchain. We take a detailed look at bitcoins peer-to-peer network, and quantify the resources involved inour attack via probabilistic analysis, Monte Carlo simu-lations, measurements and experiments with live bitcoinnodes. Finally, we present countermeasures, inspired bybotnet architectures, that are designed to raise the bar foreclipse attacks while preserving the openness and decen-tralization of bitcoins current network architecture.
While cryptocurrency has been studied since the1980s [22, 25, 28], bitcoin is the first to see widespreadadoption.A key reason for bitcoins success is its baked-in decentralization. Instead of using a central bank toregulate currency, bitcoin uses a decentralized networkof nodes that use computational proofs-of-work to reachconsensus on a distributed public ledger of transactions,aka., the blockchain. Satoshi Nakamoto  argues thatbitcoin is secure against attackers that seek to shift theblockchain to an inconsistent/incorrect state, as long asthese attackers control less than half of the computa-tional power in the network. But underlying this securityanalysis is the crucial assumption of perfect information;namely, that all members of the bitcoin ecosystem canobserve the proofs-of-work done by their peers.
While the last few years have seen extensive researchinto the security of bitcoins computational proof-of-work protocol e.g., [14, 29, 36, 37, 45, 49, 50, 52, 58, 60],less attention has been paid to the peer-to-peer network
used to broadcast information between bitcoin nodes (seeSection 8). The bitcoin peer-to-peer network, whichis bundled into the core bitcoind implementation, aka.,the Satoshi client, is designed to be open, decentralized,and independent of a public-key infrastructure. As such,cryptographic authentication between peers is not used,and nodes are identified by their IP addresses (Section 2).Each node uses a randomized protocol to select eightpeers with which it forms long-lived outgoing connec-tions, and to propagate and store addresses of other po-tential peers in the network. Nodes with public IPs alsoaccept up to 117 unsolicited incoming connections fromany IP address. Nodes exchange views of the state of theblockchain with their incoming and outgoing peers.
Eclipse attacks. This openness, however, also makes itpossible for adversarial nodes to join and attack the peer-to-peer network. In this paper, we present and quantifythe resources required for eclipse attacks on nodes withpublic IPs running bitcoind version 0.9.3. In an eclipseattack [27, 61, 62], the attacker monopolizes all of thevictims incoming and outgoing connections, thus iso-lating the victim from the rest of its peers in the net-work. The attacker can then filter the victims viewof the blockchain, force the victim to waste computepower on obsolete views of the blockchain, or cooptthe victims compute power for its own nefarious pur-poses (Section 1.1). We present off-path attacks, wherethe attacker controls endhosts, but not key network in-frastructure between the victim and the rest of the bit-coin network. Our attack involves rapidly and repeatedlyforming unsolicited incoming connections to the victimfrom a set of endhosts at attacker-controlled IP addresses,sending bogus network information, and waiting until thevictim restarts (Section 3). With high probability, thevictim then forms all eight of its outgoing connections toattacker-controlled addresses, and the attacker also mo-nopolizes the victims 117 incoming connections.
Our eclipse attack uses extremely low-rate TCP con-nections, so the main challenge for the attacker is to
130 24th USENIX Security Symposium USENIX Association
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-statethat holds several contiguous IP address blocks and seeksto subvert bitcoin by attacking its peer-to-peer network,and (2) botnet attacks, launched by bots with addresses indiverse IP address ranges. We use probabilistic analysis,(Section 4) measurements (Section 5), and experimentson our own live bitcoin nodes (Section 6) to find thatwhile botnet attacks require far fewer IP addresses, thereare hundreds of organizations that have sufficient IP re-sources to launch eclipse attacks (Section 4.2.1). For ex-ample, we show how an infrastructure attacker with 32distinct /24 IP address blocks (8192 address total), or abotnet of 4600 bots, can always eclipse a victim with atleast 85% probability; this is independent of the numberof nodes in the network. Moreover, 400 bots sufficed intests on our live bitcoin nodes. To put this in context,if 8192 attack nodes joined todays network (containing 7200 public-IP nodes ) and honestly followed thepeer-to-peer protocol, they could eclipse a target withprobability about ( 81927200+8192 )
8 = 0.6%.Our attack is only for nodes with public IPs; nodes
with private IPs may be affected if all of their outgoingconnections are to eclipsed public-IP nodes.
Countermeasures. Large miners, merchant clientsand online wallets have been known to modify bit-coins networking code to reduce the risk of network-based attacks. Two countermeasures are typically rec-ommended : (1) disabling incoming connections, and(2) choosing specific outgoing connections to well-connected peers or known miners (i.e., use whitelists).However, there are several problems with scaling this tothe full bitcoin network. First, if incoming connectionsare banned, how do new nodes join the network? Sec-ond, how does one decide which specific peers to con-nect to? Should bitcoin nodes form a private network?If so, how do they ensure compute power is sufficientlydecentralized to prevent mining attacks?
Indeed, if bitcoin is to live up to its promise as an openand decentralized cryptocurrency, we believe its peer-to-peer network should be open and decentralized as well.Thus, our next contribution is a set of countermeasuresthat preserve openness by allowing unsolicited incom-ing connections, while raising the bar for eclipse attacks(Section 7). Today, an attacker with enough addressescan eclipse any victim that accepts incoming connectionsand then restarts. Our countermeasures ensure that, withhigh probability, if a victim stores enough legitimate ad-dresses that accept incoming connections, then the vic-tim be cannot eclipsed regardless of the number of IPaddresses the attacker controls. Our countermeasures 1,2, and 6 have been deployed in bitcoind v0.10.1; we alsodeveloped a patch  with Countermeasures 3,4.
1.1 Implications of eclipse attacks
Apart from disrupting the bitcoin network or selectivelyfiltering a victims view of the blockchain, eclipse attacksare a useful building block for other attacks.
Engineering block races. A block race occurs whentwo miners discover blocks at the same time; one blockwill become part of the blockchain, while the other or-phan block will be ignored, yielding no mining rewardsfor the miner that discovered it. An attacker that eclipsesmany miners can engineer block races by hording blocksdiscovered by eclipsed miners, and releasing blocks toboth the eclipsed and non-eclipsed miners once a com-peting block has been found. Thus, the eclipsed minerswaste effort on orphan blocks.
Splitting mining power. Eclipsing an x-fraction ofminers eliminates their mining power from the rest ofthe network, making it easier to launch mining attacks(e.g., the 51% attack ). To hide the change in min-ing power under natural variations , miners could beeclipsed gradually or intermittently.
Selfish mining. With selfish mining [14,29,37,60], theattacker strategically withholds blocks to win more thanits fair share of mining rewards. The attacks successis parameterized by two values: , the ratio of miningpower controlled by the attacker, and , the ratio of hon-est mining power that will mine on the attackers blocksduring a block race. If is large, then can be small. Byeclipsing miners, the attacker increases , and thus de-creases so that selfish mining is easier. To do this, theattacker drops any blocks discovered by eclipsed minersthat compete with the blocks discovered by the selfishminers. Next, the attacker increases by feeding onlythe selfish miners view of the blockchain to the eclipsedminer; this coopts the eclipsed miners compute power,using it to mine on the selfish-miners blockchain.
Attacks on miners can harm the entire bitcoin ecosys-tem; mining pools are also vulnerable if their gatewaysto the public bitcoin network can be eclipsed. Eclipsingcan also be used for double-spend attacks on n