1

Exploring the Attack Surface of Blockchain:A Systematic Overview

Muhammad Saad, Jeffrey Spaulding, Laurent Njilla, Charles Kamhoua,Sachin Shetty, DaeHun Nyang, and Aziz Mohaisen

Abstract—In this paper, we systematically explore the attacksurface of the Blockchain technology, with an emphasis on publicBlockchains. Towards this goal, we attribute attack viability inthe attack surface to 1) the Blockchain cryptographic constructs,2) the distributed architecture of the systems using Blockchain,and 3) the Blockchain application context. To each of thosecontributing factors, we outline several attacks, including selfishmining, the 51% attack, Domain Name System (DNS) attacks,distributed denial-of-service (DDoS) attacks, consensus delay(due to selfish behavior or distributed denial-of-service attacks),Blockchain forks, orphaned and stale blocks, block ingestion,wallet thefts, smart contract attacks, and privacy attacks. Wealso explore the causal relationships between these attacks todemonstrate how various attack vectors are connected to oneanother. A secondary contribution of this work is outliningeffective defense measures taken by the Blockchain technology orproposed by researchers to mitigate the effects of these attacksand patch associated vulnerabilities.

Index Terms—Blockchain; Security; Attack Surface; Applica-tions; Peer-to-Peer Systems

I. INTRODUCTION

Blockchain technology is being explored in many inno-vative applications, such as cryptocurrencies [1]–[3], smartcontracts [4], [5], communication systems [6], [7], health care[8], [9], Internet of Things [10], [11], financial systems [12],[13], censorship resistance [14], electronic voting [15], [16],and distributed provenance [17]–[19], among others. UsingBlockchain’s transparent and fully distributed peer-to-peerarchitecture, these applications benefit from an append-onlymodel in which “transactions” accepted in the Blockchaincannot be modified [18], [20], [21]. The transparency ofthe Blockchain enables storing publicly verifiable and unde-niable records [22]. Furthermore, the Blockchain’s peer-to-peer system provides verifiable ledger maintenance withouta centralized authority, thus addressing the single point-of-failure and single point-of-trust [23]. For instance, Bitcoin (apopular cryptocurrency using Blockchain technology) takesadvantage of the aforementioned properties, making it easyto verify the history of financial transactions [24], [25].

Despite the functional features that Blockchain brings tothe design space of these applications [43], recent reportshave highlighted the security risks associated with this tech-nology [10], [44]–[47]. For instance, in June 2016 an unknownattacker managed to drain $50 million USD from “The DAO”,

M. Saad, J. Spaulding, and A. Mohaisen are with the Department ofComputer Science at the University of Central Florida, Florida 32816, USA.L. Njilla is with the Air Force Research Laboratory, Rome, NY, USA. C.Kamhoua is with the Army Research Laboratory, MD, USA. S. Shetty is withthe Old Dominion University, VA, USA. D. Nyang is with INHA University,Incheon, South Korea. The work of D. Nyang was done while visiting theUniversity of Central Florida.

a decentralized autonomous organization that operates onBlockchain-based smart contracts, or pre-programmed rulesthat govern the organization [48]. In August 2016, bitcoinsworth $72 million USD were stolen from the exchange plat-form Bitfinex in Hong Kong [49]. In June 2017, Bitfinex alsoexperienced a distributed denial-of-service (DDoS) attack thatled to its temporary suspension. Several exchanges of Bitcoinand Ethereum (a Blockchain-based distributed computing plat-form) have also suffered from DDoS attacks and DNS attacksfrequently, hampering the service availability to the users.

Often times these attacks are launched on blockchain-applications due to their popularity or the capital involved intheir system. For instance, with Bitcoin, such attacks can causedevaluation of the cryptocurrency, loss of mining rewards,or even closure of cryptocurrency exchanges [29]. Bitcoin’sBlockchain is also targeted with dust or spam transactionsto delay the processing of legitimate transactions. In May,August, and November 2017, memory pools of Bitcoin wereflooded with dust transactions to create stalls and delays intransaction verification, and to increase Bitcoin mining fee[33]. The transaction stall in November 2017, for example,resulted in a payment delay of $700 million USD worthbitcoins [50]. Often the intent of such attacks is to motivatethe Bitcoin users to move to other cryptocurrencies with fastertransaction processing time.

Due to a publicly verifiable nature, Blockchain-based cryp-tocurrencies are vulnerable to several fraudulent activities. Mt.Gox, a Bitcoin currency exchange in Japan, was attacked bytwo malicious users who stole $460 million USD worth ofbitcoins [51]. The attackers gathered useful information fromBitcoin’s Blockchain and engineered a fake transaction rippleto increase the market price. Due to such activities, Mt. Goxsuffered a heavy loss and eventually became bankrupt.

In May and June 2018, five Blockchain-based cryptocurren-cies; namely, Monacoin, Bitcoin Gold, Zencash, Verge, andLitecoin Cash, were targeted by a 51% attack [52], leading toa loss of $5 million USD. The attackers in each cryptocurrencywere able to gain more than 51% of the networks’ hash ratewhich was used to rearrange transactions and prevent otherminers from computing blocks. As a result, they were able togain control over the Blockchain and perform double-spendingon valuable transactions [53], [54].

The security of Blockchain systems is important for theiracceptability by potential users [55]. For example, investorstake the security of Bitcoin into account when studying therisks associated with their investments and use of this tech-nology. Understanding the threats associated with Blockchainsystems in general is a first step towards realizing the potentialof applications built on it. To this end, this work is dedicated

arX

iv:1

904.

0348

7v1

[cs

.CR

] 6

Apr

201

9

2

TABLE IATTACK VECTORS RELATED TO THE ATTACK CLASS IN BLOCKCHAIN SYSTEMS. WE ALSO SHOW, BY REFERENCING TO THE PRIOR WORK, HOW EACH

ATTACK AFFECTS THE ENTITIES INVOLVED WITH BLOCKCHAIN SYSTEMS. FOR INSTANCE, ORPHANED BLOCKS AFFECT THE BLOCKCHAIN, THE MINERS,AND THE MINING POOLS.

Attacks Blockchain Miners Mining Pools Exchanges Application Users

Blockchain Structure Forks [26] XOrphaned blocks [27] X X X

Peer-to-Peer System

DNS hijacks [28] X X X XBGP hijacks [29] X X XEclipse attack [30] X XMajority attack [31] X X XSelfish mining [32] X X XDDoS attacks [33] X X XConsensus Delay [34] X X XBlock Withholding [34] X XTimejacking attacks [35] X X XFinney attacks [36] X X X

Blockchain Application

Blockchain Ingestion [37] XWallet theft [38] X X XDouble-spending [39] X XCryptojacking [40] X XSmart contract DoS [41] X X X≈ Reentracy attacks [42] X X≈ Overflow attacks [42] X X≈ Replay attacks [41] X X X X≈ Short address attacks [42] X≈ Balance attacks [41] X X

to an in-depth look at the attack surface of Blockchain.

We envision that Blockchain will be used in many appli-cations, and we report on the attacks that could compromisethose applications. Namely, the taxonomy of Blockchain at-tacks in this paper is classified into three broad categories: 1)attacks associated with the mathematical techniques used forcreating the ledger (e.g., Blockchain forks, stale blocks, or-phaned blocks, etc.), 2) attacks associated with the peer-to-peerarchitecture used in the Blockchain system, (e.g., selfish min-ing, the 51% attack, consensus delay, DDoS attack, DomainName System (DNS) attacks, Fork After Withholding (FAW)Attacks, etc.), and 3) attacks associated with the applicationcontext that uses the Blockchain technology (e.g., Blockchainingestion, double-spending, wallet theft [56], etc.). In thispaper, we mainly focus on the attack surface of public andpermissionless Blockchains. Public Blockchains are suitablefor applications that provide open access to system resourceswhile preserving user anonymity. These attributes are wellsuited for a system that has a weak trust model and highprovenance assurance requirements. The weak trust modelresults from an application’s tolerance for adversaries who cangame the system while staying anonymous. On the other hand,high provenance means that anyone can access the publiclyavailable resources to transparently audit data. For instance,in Bitcoin and Ethereum, any user can join the network byrunning an Ethereum software client on their machine andparticipating in transaction processing. Since the Blockchain ispublic, anyone outside the system can validate the authenticityof transactions and blocks. Therefore, public Blockchainsremain a dominant component among Blockchain applicationsas shown by the popularity of Bitcoin and Ethereum. On theother hand, the weak trust model exposes public Blockchainsto a wide variety of attacks, allowing adversaries to easily

compromise the system [57]. Therefore, while the publicBlockchains are useful for an open access system, they are notsuitable for closed environments where the weak trust modelcreates attack opportunities.

To address the shortcomings of public Blockchains andreduce the attack opportunities, private and permissionedBlockchains are now used for various applications [58]. In pri-vate Blockchains, the access to system resources is restricted toa chosen set of peers [59], [60]. These peers are screened priorto their induction in the application. Since the informationabout peers is known, their identities can be tied (or attributed)to their behavior in order to prevent attacks. Although privateBlockchains still act as agents of trust in permissioned settings,they are not significantly exposed to adversarial attacks due toa stronger trust model. Since the aim of this work is to exploreand understand the attack surface of Blockchains, it is naturalto focus more on the public Blockchains. However, wherevernecessary, we will also discuss the security and performanceof private Blockchains as well.Contributions. In summary, we make the following contribu-tions int this paper. (1) We survey the possible attacks relatedto the design constructs of Blockchains, the peer-to-peerarchitecture, and the application-oriented use of Blockchains.(2) We explore the origins of these attacks and the ways inwhich they affect Blockchain applications and their users.(3) We also show the relationship between a sequence ofattacks to outline how one attack can facilitate the possibilityof other attacks. Understanding these links can help devise acommon cure that can fix multiple problems at the same time.(4) Building on top of the prior work [45], [57], [61], for eachattack class, we also explore the possible defense strategiesthat have been proposed to harden the security of Blockchains.Since many attacks related to a specific class have a common

3

TABLE IIIMPLICATIONS OF EACH ATTACK ON THE BLOCKCHAIN SYSTEM IN THE LIGHT OF THE PRIOR WORK. FOR INSTANCE, FORKS CAN LEAD TO CHAIN

SPLITTING AND REVENUE LOSS. AS A RESULT OF A FORK, ONE AMONG THE CANDIDATE CHAINS IS SELECTED BY THE NETWORK WHILE THE OTHERSARE INVALIDATED. THIS LEADS TO INVALIDATION OF TRANSACTION AND REVENUE LOSS TO MINERS.

Attacks Chain Splitting Revenue Loss Partitioning Malicious Mining Delay Info Loss TheftBlockchainSplitting

Forks [26] X XOrphaned Blocks [27] X

P2PSystem

DNS hijacks [28] X X XBGP hijacks [29] X X XEclipse attacks [30] XMajority attacks [31] X X XSelfish mining [32] X XDDoS attacks [33] X XConsensus Delay [34] X XBlock Withholding [34] X XTimejacking attacks [35] X X X XFinney attacks [36] X

BlockchainApplication

Blockchain Ingestion [37] XWallet theft [38] X XDouble-spending [39]Cryptojacking [40] X X XSmart contract DoS [41] X X X≈ Reentracy attacks [42] X X≈ Overflow attacks [42] X≈ Replay attacks [41] X X≈ Short address attacks [42] X X≈ Balance attacks [41] X X

defense or remedy, while others remain as open problems, wediscuss combined countermeasures for each class. Moreover,by highlighting the lessons learned, we also provide futureresearch directions towards a more systematic treatment ofthe Blockchain attack surface. (5) In Table I and Table II,we provide an overview of the Blockchain attack surface. Weascribe various attacks to attack classes with their implications.Organization. The rest of the paper is organized as follows.In section II, we provide the motivation of this work. In sec-tion III, we give an overview of Blockchain its operations.In section IV, we review the design constructs of Blockchainthat enable various attacks, such as Blockchain forks, staleand orphaned blocks. In section V, we look into the featuresof distributed networks that create possibilities for the 51%attack, DNS attacks, DDoS attacks, consensus delays, etc. Wefurther describe the aspects of peer-to-peer architecture thatenable the possibility of their potential misuse in Blockchainapplications. In section VI, we outline the application-specificvulnerabilities found in Blockchain and assess the threats thatthey face. That is followed by discussion and open directionsin section VIII, and the concluding remarks in section IX.

II. MOTIVATION AND TARGET AUDIENCE

The motivation of this work is to derive attention to-wards the security vulnerabilities of Blockchain systems viaa systematic and comprehensive study. Recently, Blockchaintechnology has gained significant attention and its applicationsare being explored in various domains [62], [63]. Blockchainsare capable of augmenting trust and provide provenance in dis-tributed systems. While acknowledging their merits [64]–[66],we argue that it is important to understand their shortcomings,

particularly related to security, as evident by the large securitysurface. To that end, our work is an effort to highlight potentialvulnerabilities in Blockchains, with an emphasis on popularpublic Blockchain applications. We systematically analyzevarious attack vectors and study their relationships. Alongside,we also survey countermeasures and defenses to the variousattack surface elements, and provide future research directions.

Since various research and technology sections are in-terested in using Blockchains, it is intuitive to explore adeeper understanding of Blockchains’ attack surface to estab-lish foundations for their security. For instance, using publicBlockchains in the financial sector may prevent fraud anddata tampering, by the simply utilizing Blockains’ proper-ties, although that also may expose sensitive information offinancial transactions to adversaries. Similarly, organizationsthat are exploring Blockchain-based smart systems [34], [67],while might benefit immensely in addressing functional re-quirements, need to be aware of the programming languages’constraints and shortcomings, as well as compilation bugsthat may lead to data breach and critical assets loss. For thisresearch-driven efforts, we believe our work has the potentialto offer future directions toward designing more secure androbust Blockchain solutions that may overcome some of thosechallenges as outlined in the rest of this survey. Some of thesechallenges include constructing new consensus algorithms thatare secure, scalable, and energy efficient [68]. Additionally,they must also have the capability to prevent race conditionsthat lead to attacks such as selfish mining, double-spending,majority attacks, and orphaned blocks [69], [70]. To facilitatethe process of addressing those challenges, we supplement ourwork by surveying the existing countermeasures proposed inthe literature. These countermeasures can be used as building

4

User A

Transaction 4 Generated

User B

Miner Validates Selected TransactionsComputes Block. (Transaction 2 Not Selected)

Miner

Block Hash Previous Block HashMerkel RootNumber of Transactions

Coinbase RewardTransaction 1Transaction 3Transaction 4

3.

B1 B2 B3 B4 B5

Blockchain

Memory Pool

Transaction 1Transaction 2Transaction 3Transaction 4

Block Added4.

1.

Transaction 4 Added to the Memory Pool

2.

Block 5 (B5)

Memory Pool

Transaction 2

State of Memory Pool After Block 5

5.

Fig. 1. Transaction life-cycle in a PoW-based cryptocurrency. User A generates a transaction for user B. The transaction is stored in the memory pool alongwith other unconfirmed transactions. Miner validates transactions from memory pool, and computes a block. A valid block is added to the Blockchain.

blocks for more secure and robust solutions.In summary, the target audience of this work include both

academics, who are interested in understanding the attacklandscape of Blockchains, as well as practitioners, who mightbe interested in understanding the existing solutions to thoseattacks, to utilize as building blocks, and both benefiting froma systematic analysis of the Blockchain attack surface.

III. OVERVIEW OF BLOCKCHAIN AND ITS OPERATIONS

Conceptually, Blockchain can be viewed as a repository ofdata that is tamper-evident due to its replication over all nodesin a peer-to-peer system. Transactions represent the eventsthat drive the Blockchain application (e.g., in cryptocurren-cies, tokens are the transactions exchanged among the users).Blockchain applications use various consensus algorithms fortrust among peers over the state of the ledger. Moreover, theconsensus algorithms ensure a consistent and transparent viewof the Blockchain, thereby resolving conflicts and forks. Thisis, no block is added to the Blockchain, until it fulfills the con-ditions outlined by the consensus algorithm. Moreover, eachalgorithm has unique functional and operational properties thatdrive the consensus over the Blockchain.

While the consensus algorithms in Blockchains may vary,however, the Blockchain data structure and its network archi-tecture remain consistent across all applications. For instance,in the two popular Blockchain applications, namely Bitcoinand Peercoin, the consensus algorithms are proof-of-work andproof-of-stake, respectively. Although they different in the waythe consensus is conducted, the two applications have thesame Blockchain data structure in which the chain progressesin an append-only model and each block is linked to theprevious block through a one-way hash function. In bothcryptocurrencies, the system replicas are connected in a peer-to-peer model, maintaining a single copy of the ledger. In thefollowing, we briefly discuss the popular consensus algorithmsalong with the fundamental cryptographic primitives that areused in Blockchains.

A. Consensus AlgorithmsSome of the notable consensus algorithms used in

Blockchains include proof-of-work (PoW), proof-of-stake(PoS), proof-of-activity (PoA), proof-of-capacity (PoC), proof-of-burn (PoB), proof-of-knowledge (PoK), and the practical

Byzantine fault tolerance (PBFT) [71]–[75]. The most popularconsensus algorithm widely used in Blockchains is PoW,followed by PoS and PBFT. We discuss them in the following.

Proof-of-Work. In PoW Blockchains, peers in the network tryto solve a computationally expensive mathematical challenge.For instance, the challenge in Bitcoin is to come up witha nonce that when hashed with block data produces a hashvalue that is less than a target threshold set by the system.All peers in the system use their computational power tosolve the mathematical challenge. The peer who comes upwith the solution wins the block race and mines a new block.Once a block is broadcast to the network, each peer verifiesthe solution and appends the block to his Blockchain. Theprobability of winning a block race is proportional to thecomputational power of participants. At the same time, thereis a time restriction on the block mining [76], [77]. In Bitcoin,the block time is set to 10 minutes. In other words, the networkexpects a new solution to the block puzzle after every 10minutes. However, as the computational power increases, thechance of discovering a new block under 10 minutes increases.To address that, the network dynamically adjusts the difficultyof the challenge according to the change in the computationalpower of the miners. Oftentimes, more than one miner cancome up with a valid solution leading to Blockchain forks andstale and orphaned blocks, which we discuss in section IV.

In Figure 1, we illustrate the transaction life-cycle in aproof-of-work (PoW)-based Blockchain application. User A(sender) generates a transaction for user B (receiver). Thetransaction is broadcast to the entire peer-to-peer networkwhere it is temporarily stored in a transaction repositoryknown as the memory pool (mempool). In a peer-to-peernetwork, the mempool is a space allocated in the RAM ofa full node that stores and relays transactions to other peers.To maintain the state of the Blockchain, there are special nodesin the network known as the miners or verifiers, responsiblefor verifying transactions and computing a block. The minersquery the mempool and select the transactions of their choiceto put into blocks. Usually transactions pay a mining fee whichcan be viewed as an incentive given to the miners to mine thetransaction. Naturally, miners give priority to the transactionsthat pay higher mining fee. Transactions that are not selectedby the miners, stay in the mempool until some other minerselects them for a new block. Transactions that do not get

5

Primary

Replica

Replica

Replica

Client Pre-Prepare Request Commit Prepare Reply

Fig. 2. Overview of PBFT protocol. The client issues a transaction to theprimary replica. The primary replica then forwards it to other replicas whojointly execute a four-phased protocol and approve the transaction. Assumingf faulty replicas, the primary would require confirmation from at least 3f+1replicas. PBFT is employed in permissioned and private blockchains.

mined for a long time, eventually get discarded.Proof-of-Stake. The second most popular consensus algorithmin public Blockchains is proof-of-stake (PoS) [78], [79]. PoSwas introduced to address the energy inefficiency of PoW. InPoS, the mining power of a user is determined by the totalnumber of coins he owns. For each new block, an auction iscarried out to select the candidate miner. Users place a bidon the block and the one with the highest bid is selected asa miner. Therefore, in contrast to PoW, the hashing poweris replaced by the volume of assets owned by the user. Themore coins a users owns, the higher his chances of winning theblock race. The replace of energy intensive mining with stake-based mining, makes PoS energy efficient and secure againstthe majority attacks (section V-B). Unlike PoW, in PoS, allthe cryptocurrency tokens are released prior to creation of thegenesis block [80]. Therefore, when a new block is mined, itdoes not introduce new coins in the system. However, minersare rewarded with transaction fee for their contributions.PBFT. The third most popular Blockchain consensus protocolis called the practical byzantine fault tolerance (PBFT) [81],[82] protocol. PBFT is widely used in private and permis-sioned Blockchains, where the network has a stronger trustmodel compared to PoS and PoW. In PBFT Blockchains, thesystem is transposed into a group of active and passive repli-cas. Among the active replicas, a primary replica is selectedwho receives transactions from a client and sends them tothe active replicas for execution. The process of executionis carried out in four stages, namely, pre-prepare, prepare,commit, and reply stage. In the pre-prepare phase, primarysends transactions to all the active replicas. In the prepare andcommit phase, each active replica signs the transaction andexchange it with all the other replicas. In the reply stage, allthe active replicas send their response to the primary replica.The primary collects all the signed transactions and puts themin a block. In Figure 2, we show the transaction verificationprocess in a PBFT Blockchain. Notice that compared to PoWand PoS, PBFT has a higher message complexity.

In Table III, we compare the popular consensus algorithmsused in the Blockchain applications. Notice that permissionlessBlockchains have low throughput and high confirmation time.Bitcoin has transaction throughput of 3–7 transactions persecond. In contrast, permissioned Blockchains have a high

Transactions

prev: H( ) prev: H( ) prev: H( )

H( )

Transactions Transactions

Fig. 3. Cryptographic constructs of blocks in a Blockchain. Notice that theentire hash of the previous block goes into the header of the next block.Therefore, if an attacker makes changes in the data of a block, he will berequired to change data in all subsequent blocks and correctly execute theconsensus protocol for each block. Since this is infeasible in practice, thereforeBlockchains are considered tamper-proof.

throughput and and low confirmation time. In terms of security,PBFT has low fault tolerance (≈ 33%) compared to PoW andPoS (≈ 50%). However, since permissioned Blockchains havea stronger trust model, therefore, they are less vulnerable toadversarial attacks. It can also be observed in Table III, publicBlockchains are more scalable than private Blockchains [83],[84]. This can be attributed to the message complexity in-volved in the transaction verification and the tolerance forByzantine nodes. Since PBFT has high message complexityand low Byzantine fault tolerance, therefore, it cannot scalewell beyond few hundred nodes. Therefore, each consensusscheme has its own benefits and limitations. Therefore, de-pending upon the application model, a consensus scheme canbe selected to meet the requirements.

B. Blockchain StructureWhile the consensus schemes in Blockchains may vary,

the cryptographic constructs of Blockchain are fundamentallythe same across all applications [85], [86]. Each block in aBlockchain consists of a header and a payload. The headerincludes the primary information, such as the hash of theprevious block, the merkle root, and the block timestamp. Thehash pointer connects each block to the previous block, therebyforming a chain. Since hash functions are one-way and arecollision resistant, Blockchain benefits from their properties tobecome immutable and tamper-proof [87], [88]. In Figure 3,we illustrate this model of Blockchain, where blocks are linkedthrough hash functions.

In a Blockchain application, all nodes are connected in apeer-to-peer architecture. This means that they use the gossipprotocol to communicate information, including transactionsand blocks. Ideally, each peer is expected to maintain a copyof Blockchain. However, due to the append-only model, thegrowing size of Blockchain can put space constraint at thenode. To address that, various Blockchain applications allowthe segmentation of nodes into full nodes and lightweightnodes. The full nodes maintain a complete copy of Blockchainand participate in transaction and block propagation. On theother hand, the lightweight nodes only keep the block headerfor the verification of a newly published block.

As stated earlier, several attacks on Blockchain technologyare related to the constructs of the Blockchain itself, thebehavior of certain miners, and the peer-to-peer architectureit is built upon. In the subsequent sections, we explore the

6

TABLE IIIAN OVERVIEW OF POPULAR CONSENSUS ALGORITHMS USED IN BLOCKCHAINS. NOTICE THAT PUBLIC AND PERMISSIONED BLOCKCHAINS USING POW,POS, AND DPOS HAVE HIGH SCALABILITY, LOW THROUGHPUT, AND HIGH CONFIRMATION TIMES. IN CONTRAST, PERMISSIONED BLOCKCHAINS USING

PBFT AND RAFT HAVE LOW SCALABILITY, LOW CONFIRMATION TIME, AND HIGH THROUGHPUT.

Properties PoW PoS DPoS PBFT RAFTBlockchain Type Permisssionless Permissionless Permissionless Permissioned PermissionedParticipation Cost Yes Yes Yes No NoTrust Model Untrusted Untrusted Untrusted Semi-trusted Semi-trustedScalability High High High Low LowThroughput <10 <1,000 <1,000 <10,000 >10,000Byzantine Fault Tolerance 50% 50% 50% 33% –Crash Fault Tolerance 50% 50% 50% 33% 50%Confirmation Time >100s <100s <100s <10s <10s

OldRules

OldRules

OldRules

OldRules

OldVersion

NewRules

NewRules

NewRules

NewRules

NewVersion

Fork

Fig. 4. Hard Fork resulting from set of peers following conflicting rules dueto different client software versions. Hard forks can be irreversible at timesand may lead to a permanent split in the Blockchain application.

possible attacks associated with the Blockchain structure,attacks associated with the peer-to-peer architecture used inthe Blockchain system, and attacks associated with the appli-cation services that use Blockchain technology (i.e., Bitcoinor Ethereum). We also supplement each section with possiblecountermeasures that have been proposed by researchers toaddress those attacks.

IV. BLOCKCHAIN STRUCTURE ATTACKS

In this section, we look at the attacks related to the designconstructs of the Blockchain. These attacks emerge from thepotential vulnerabilities of the Blockchain structures and assuch, they can compromise any Blockchain-based application.

A. Blockchain Forks

A fork represents a condition in which nodes in the networkhave diverging views about that state of the Blockchain persist-ing over long periods of time or even indefinitely. These forkscan be created unintentionally through protocol malfunctionsor incompatibilities in client software upgrades. Forks canalso be caused by malicious intents such as implanting “Sybilnodes” that follow conflicting validation rules or by carryingout “selfish mining” in race conditions as discussed furtherin section V-A. Another form of fork occurs when users ofa Blockchain application create a child application from theparent application. For example, in 2017, a group of Bitcoindevelopers decided to increase the block size limit from 1MBto 8MB by developing a new Bitcoin client that was capableof accepting 8MB blocks. However, their proposal was notaccepted by the majority of users, therefore, they created ahard fork on Bitcoin and released a new cryptocurrency calledBitcoin Cash. Bitcoin Cash was the child application of the

parent Bitcoin, with new rules and regulations. Therefore,forks can also be created to launch a new application.

Jan 3, 2009 Bitcoin genesis block established

Dec 27, 2014 Bitcoin XT forked on Bitcoin Core

Jan 15, 2016 Bitcoin Unlimited launched

Feb 10, 2016 Bitcoin Classic forked on BitcoinCore

Aug 1, 2017 Bitcoin Cash launched

Aug 23, 2017 Segregated Witness (Segwit) fork

Nov 1, 2017 Bitcoin Gold launched

Nov 15, 2017 Segwit2x fork

Nov 28, 2017 Protest fork

TIMELINE 1: Major Bitcoin Forks

Intentional forks can either be soft or hard, the latter ofwhich occurs when new blocks that the network accepts appearinvalid to pre-fork nodes. Soft forks, however, occur whensome blocks appear invalid to post-fork nodes. In either case,a Blockchain fork represents an inconsistent state that canbe exploited by adversaries to cause confusion, fraudulenttransactions, and distrust within network [89].

Figure 4 demonstrates a hard fork example that results frompeers following conflicting rules about the state of Blockchain.Such hard forks may lead to a split in cryptocurrency. Amajor hard fork on Bitcoin occurred during August 2017,which led to the creation of Bitcoin Cash [90]. Another hardfork on Bitcoin occurred during October 2017, when BitcoinGold [91] was created. Some other notable forks in Bitcoininclude Bitcoin Classic, Bitcoin XT, and Bitcoin Unlimited.However, due to insufficient user-base and miners, they couldnot succeed as a separate cryptocurrency.

When hackers stole more than one third of the total digitalcash owned by “The DAO” [48], Ethereum used a hard forkto roll back transactions and retrieve millions of dollars’ worthof ether (the “fuel” for the Ethereum network). However, thisrequired consensus by the majority of nodes in the network.

7

In such a scenario, if a consensus delay happens due to amajority attack or a DDoS event, fraudulent activities becomesomewhat difficult to deal with and prolonged delays canultimately cause devaluation of cryptocurrency. In November2017, the second version of Segregated Witness (SegWit2x)hard fork was proposed in Bitcoin, which aimed to increasethe block size to 2MB. However, due to lack of consensus bythe majority, the planned hard fork was canceled. In Timeline1, we provide a list of major forks on Bitcoin. These forksresulted from a group of miners introducing new rules anda faction of peers switching to those rules. All these forksintroduced a new version of Bitcoin. This is, we note that afork may diminish if peers discontinue to follow the new rulesand switch back to the old ones. For instance, this has beenwitnessed in SegWit fork. Initially, a faction of network peersswitched to SegWit version of Bitcoin, however, when theymoved back to the old version in a protest, the fork ended.

B. Stale Blocks and Orphaned BlocksTwo forms of inconsistencies can occur with the consensus

process that can leave valid blocks out of the Blockchain.The first form is a “stale block”, which is a block that wassuccessfully mined but is not accepted in the current bestBlockchain (i.e., the most-difficult-to-recreate chain). Staleblocks occur mostly in the public Blockchains due to raceconditions. In race conditions, the miners actively try to findthe next block, and it is possible that two or more miners cancome up with a valid solution. The network eventually acceptsone of the winning blocks and discards the rest. As a result,the all other valid blocks unaccepted become stale blocks asthey do not get attached to the main Blockchain. We will seein section V-A that a form of Blockchain attack known as“selfish mining” can also lead to the creation of stale blocksin the network, which deprives an honest miner of its reward.

The other form of inconsistency is an “orphaned block”: ablock whose parent block’s hash field points to an unauthen-tic block that is detached from the Blockchain [92]. Theseinconsistencies can be introduced by an attacker or caused byrace conditions in the work of the miners. Stale blocks maybe initially accepted by the majority of the network, but theycan be rejected later when proof of a longer Blockchain (i.e.,the current best) is received that does not include that block.

Figure 5 demonstrates a chain where stale and orphanedblocks can be found. The first orphaned block in Bitcoin wasfound on March 18, 2015, and that was the beginning of aperiod in which most orphaned blocks were created. The trendreduced in 2016, and from June 2017 to the date of this paper,no orphaned block has been added to the list [93]. Orphanedblocks are more frequently found in cryptocurrencies whereaverage block computation time is small. In Figure 6, weplot the number of orphaned blocks that occurred in Bitcoinand Ethereum from July 2016 to May 2018. In Ethereum, theorphaned blocks are called Uncle blocks. The data in the figurehas been normalized using min-max normalization to scale thedata in the range [0, 1]. The min-max scaling is conducted asz = xi−min(x)

max(x)−min(x) . It can be observed from the figure that asof June 2017, no orphaned block has been found in Bitcoin.On the other hand, in Ethereum, Uncle blocks have increasedsince November 2017.

Block 1 Block 2 Block 3

Block 5

Block 2

Block 4

Fig. 5. Stale vs. orphaned blocks. Note that the stale block (block 2, bottom,and block 4) are valid but they are not part of the Blockchain. Orphanedblock (block 5) does not have its parent block (block 4) in the Blockchain.

In cryptocurrencies such as Ethereum and Bitcoin, thedifficulty is a measure of how long it takes to compute a block,which is defined by a target value set by the network [94].Based on the hashing power, the target is adjusted to keepblock time under a predefined range (10 minutes for Bitcoinand 12 seconds for Ethereum). The difficulty is recomputedbased on the hashing power and the time taken by a series ofprevious blocks: if hashing power increases, the probability offinding a block under the expected time increases.

To adjust the probability, the difficulty is raised by increas-ing the target value. In (1), we show how the expected time tocompute a block E(T ) varies with the difficulty D and hashrate of the network Hr. Here, E(T ) is measured in seconds,D is the number of hashes required to solve the current target,and Hr is measured in hashes/second, that a target device canproduce over a given string. Hr is the aggregate hashing powerof all the miners Hi for i = 1, 2, . . . , n. In (2), we calculatethe time Tb (seconds), it takes for a single miner in Hi tocompute a block, given a fixed block time set by the networkTn. For Bitcoin and Ethereum, the average block computationtime Tn is 600 seconds and 12 seconds, respectively.

Hr =

n∑i=1

Hi, E(T ) =D

Hr(1)

Tb =Tn ×Hr

HiTb =

Tn ×∑n

i=1 Hi

Hi(2)

From (1), it can be observed that when Hr remains constantand the difficulty D is reduced, the expected block time E(T )decreases. Intuitively, lower E(T ) means that in a definednetwork time Tn, more blocks will be produced. However,in the Blockchain, only one block can be accepted. Such asituation will lead to more orphaned blocks in the system.In Figure 7, we plot difficulty, hash rate, block time andorphaned blocks (also called uncle blocks) in Ethereum. Itcan be noted in 7(f) that as the expected block time (from (2))decreases, the number of orphaned and uncle blocks increases.In Ethereum, this trend is high due to short block intervalswhich increase the possibility of block collision. Orphanedblocks may also occur due to unpredictable delays in blockpropagation. A valid block may not reach majority of thenetwork peers due to network churns and propagation delays.In contrast, a competing block is able to easily propagatethrough the network and get accepted by the majority. There-fore, network behavior and delay distribution may also affectthe number of orphaned blocks in a Blockchain system [92].

8

0

0.2

0.4

0.6

0.8

1

07/0

1/16

09/0

1/16

11/0

1/16

01/0

1/17

03/0

1/17

05/0

1/17

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

Orphaned BlocksExpected Time

Fig. 6. Orphaned Blocks in Bitcoin and Uncle blocks in Ethereum over thelast two years. Notice that in Bitcoin, the rate of orphaned blocks has reduced.

TABLE IVEVOLUTION OF MINING HARDWARE. SINCE 2014, ONLY ASIC CHIPS,

WITH UPGRADED VERSIONS, ARE BEING USED FOR MINING.

Type Model Hash Rate(MH/s) Year

CPU Xeon E5530 7.14 2009GPU Radeon 5890 245 2010GPU Radeon 6990 800 2011FPGA Xilinx Spartan 245 2012FPGA Xilinx Spartan 850 2012ASIC ASIC 130nm 12K 2013ASIC ASIC 28nm 500k 2014ASIC ASIC 20nm 750k 2014

C. Vulnerabilities in Consensus Mechanism

1) Proof-of-Work: The most widely used consensus proto-col in cryptocurrencies is proof-of-work (PoW) which servesas an evidence for the effort put behind the computation of avalid block. As outlined in (1), the effort for computation of ablock can be characterized as the number of hashes requiredto meet the difficulty parameter D set by the network. Asthe aggregate hash power of the network Hr increases, thedifficulty is raised to keep the standard block time Tn withina defined range (10 minutes for Bitcoin).

In 7(a) and 7(d), we show the increase in difficulty andthe aggregate hash rate of Bitcoin and Ethereum, respectively.Since mining in PoW is a lottery-based system, miners usesophisticated hardware with high hash rate to increase theirchances of winning the lottery. Among all PoW-based cryp-tocurrencies, Bitcoin has the maximum hash rate. In particular,and since 2010, miners in Bitcoin have switched from CentralProcessing Unit (CPU), to graphics processing unit (GPUs) in2011, to Field Programmable Gate Array (FPGA) in 2012–13,and finally to Application Specific Integrated Circuit (ASIC)chips since 2014 to date [95]. We show this evolution ofBitcoin hardware, along with the hash rate, in Table IV.

One of the major problems with PoW is the excessive wasteof energy to find a valid solution [96]. At present, Bitcoin

and Ethereum use 71.12 Terawatt-hours and 4.2 Terawatt-hours (TWh) of electricity per-year, respectively, to find hashesrequired for valid PoW [97]–[99]. In Figure 8, we showthe electricity consumption of Bitcoin compared to severalcountries. Other than the excessive consumption of electricity,centralization of hashing rate among a few mining pools makesthe Blockchain application vulnerable to attacks includingthe majority attacks and double-spending (discussed in sec-tion V-B and section VI-B), whereby if a miner acquires themajority of a network’s hash rate, the miner will be able togain control over the system.

2) PoS: (PoS) was introduced by King and Nadal in 2012[100] to make Blockchain applications more energy-efficientand raise the cost of a majority attack. Unlike PoW, which islottery-based, PoS uses a stake-based deterministic approachto select a validator and to publish a new block [101]. Inthis approach, the validator is chosen by a bidding process,whereby candidate validators make a bid of their stake. Thestake is the balance owned by the candidate validator and isused to deter cheating in the system. The candidate with thehighest bid is chosen to mine the next block and if he triesto trick the system with bogus transactions he risks losing hiscommitted stake (balance). The process is deterministic sincea validator is chosen prior to each bidding process. Therefore,blocks are published on their expected time without timedeviations or delays. Moreover, to launch a majority attack ona PoS-based cryptocurrency, the attacker is required to acquiremore than 50% of the cryptocurrency tokens [102]. While it isrelatively easier to acquire 50% hash rate in PoW, it is difficultto obtain 50% coin. Therefore, compared to PoW, the cost forlaunching a majority attack in PoS application is relativelyhigh, which makes the attack less feasible.

Although PoS serves as a “green” mining alternative of PoWand raises the attack cost for the majority attacks, it has somemajor caveats that have prevented its widespread adoption bythe Blockchain community. In PoS, a rich validator may keepon winning the bid for the next block to be validated, andaccumulate the block reward. As such, the rich validators inthe system gets richer for block confirmation, which makesPoS applications centralized around those validators. Thischallenges the fundamental premise of Blockchain technologyas a decentralized system [103]. Moreover, unlike PoW, inwhich miners with limited resources may still have a chanceof winning the lottery, small bidders in PoS are certain to losethe bid for each coming block.

3) PBFT: As pointed out in section III-B, in PBFT-basedprivate Blockchains, the system is grouped into a set ofreplicas that process transactions and contribute towards theblock formation [71], [104]. The primary replica is responsiblefor ordering transactions and obtaining approvals from otherreplicas. Once sufficient approvals are received, the primarycomputes a block and broadcasts it to the network. PBFTis considered to be energy efficient with high transactionthroughput. However, it works under the assumption that theprimary replica faithfully executes the protocol and does nottamper with the ordering of transactions and blocks. Thisassumption may lead to a vulnerabilities in the permissionedBlockchains. If the primary replica is compromised it may:

1) discard the approvals obtained from other replicas and

9

0

0.2

0.4

0.6

0.8

1

07/0

1/16

09/0

1/16

11/0

1/16

01/0

1/17

03/0

1/17

05/0

1/17

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

Hash RateDifficulty

(a) Change in difficulty and hash rate of Bitcoinnetwork during 2016-17

0

0.2

0.4

0.6

0.8

1

07/0

1/16

09/0

1/16

11/0

1/16

01/0

1/17

03/0

1/17

05/0

1/17

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

Actual TimeExpected Time

(b) Expected time E(T ) calculated from (2)plotted against the actual time

0

0.2

0.4

0.6

0.8

1

07/0

1/16

09/0

1/16

11/0

1/16

01/0

1/17

03/0

1/17

05/0

1/17

07/0

1/17

09/0

1/17

11/0

1/17

01/0

1/18

03/0

1/18

05/0

1/18

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

BitcoinEthereum

(c) Orphaned Blocks per day plotted against theexpected block time.

0

0.2

0.4

0.6

0.8

1

10/0

1/15

01/0

1/16

04/0

1/16

07/0

1/16

10/0

1/16

01/0

1/17

04/0

1/17

07/0

1/17

10/0

1/17

01/0

1/18

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

DifficultyHash Rate

(d) Change in difficulty and hash rate ofEthereum network during 2015-18.

0

0.2

0.4

0.6

0.8

1

10/0

1/15

01/0

1/16

04/0

1/16

07/0

1/16

10/0

1/16

01/0

1/17

04/0

1/17

07/0

1/17

10/0

1/17

01/0

1/18

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

Actual TimeExpected Time

(e) Expected time E(T ) calculated from (2)plotted against the actual time

0

0.2

0.4

0.6

0.8

1

10/0

1/15

01/0

1/16

04/0

1/16

07/0

1/16

10/0

1/16

01/0

1/17

04/0

1/17

07/0

1/17

10/0

1/17

01/0

1/18

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

Block TimeUncle Blocks

(f) Uncle Blocks per day plotted against theexpected block time.

Fig. 7. Effect of hash rate and difficulty on the rate of orphaned blocks in Bitcoin and uncle blocks in Ethereum. For Ethereum, notice that when the difficultysharply decreases with constant hash rate around October 2017, the expected and the actual time of block computation decreases sharply. As a result, thenumber of Uncle blocks increases. The sharp decrease in the difficulty is associated to a byzantium fork that reduced block rewards per block.

Colom

bia

Switz

erla

nd

C-Rep

ublic

Bitcoi

nChi

le

Austria

0

10

20

30

40

50

60

70

80

TW

h p

er

year

59.462.1

67.371.2 71.7 72

Fig. 8. Energy Profile of Bitcoin and other countries. C-Republic refers toCzech Republic. Note that Bitcoin’s consumption is compare able to countries.

prematurely abort the execution,2) rearrange the sequence of transactions to delay the veri-

fication process and block generation,3) withhold transactions or blocks from other replicas,

and/or4) invalidate transactions even after obtaining approvals.

As such, private Blockchains always are subjected to the riskof a malicious primary who may compromise the system.However, since the identity of the primary is usually knownto everyone, malicious activities of a primary can be trackedback, eventually.

Another key challenge in PBFT-based private Blockchains istheir limited scalability and low tolerance to Byzantine nodes.Low scalability results from the O(n2) message complexityassociated with the processing of a single transaction, as shownin Figure 2. In PBFT, transaction execution is carried out infour phases, namely pre-prepare, prepare, commit, and reply.In the prepare and commit phase, each peer is required to sendmessage to every other peer in the network. In aggregate, thisleads to enormous communication overhead which cannot beexpected to work efficiently at a large scale. Therefore, whenthe network size grows, the performance of PBFT is degradedsignificantly. This is the key reason why PBFT-based privateBlockchains suffer from low scalability.

Finally, another limitation of PBFT-based privateBlockchains is their low fault tolerance. Each transactionrequires approval from 3f+1 replicas, where f is the numberof faulty replicas or Byzantine nodes. In comparison withPoW and PoS, where the network can withstand up to 50%malicious entities, PBFT can only tolerate 33% maliciousreplicas. Provided that PBFT already suffers from lowscalability, a lower fault tolerance increases the opportunityfor an adversary to place malicious replicas in the network.Currently, Bitcoin has over 10,000 active full nodes [105].This means that it can tolerate up to 5,000 faulty nodes. Thecost of compromising 5,000 nodes is high, and the attackis therefore infeasible. However, in a PBFT-based privateBlockchain that consists of a 100 nodes, an attacker cansucceed only by controlling 33 nodes. Low fault tolerance isa major challenge in PBFT-based Blockchain applications.

Considering the features and shortcomings of existing con-

10

sensus algorithms, there is a need for new consensus mecha-nisms that are secure, scalable, and energy efficient. Currently,this remains an active research area, with some notable recentprogress made in this direction [106]–[108].

D. Countering Blockchain Structure AttacksResolving soft forks in a Blockchain network is a relatively

easy process. All peers in the network can come to a consensusabout the true state of the Blockchain and resume activitiesfrom there. Resolving hard forks can be challenging becauseconflicting chains can be lengthy with transaction activitiesdating back to the time of the conflict. Although the stakes ofrolling back from a hard fork are high, they can be resolvedby the same principle of consensus as discussed earlier. Aswas the case with Ethereum, a hard fork was used to retrievemoney for the investors after “The DAO” was attacked [48].Ultimately, the process of solving a fork depends upon theagreement of peers in the network and their stake in the fork.

In Ethereum, uncle blocks are also rewarded and madepart of the Blockchain. Recently, the number of orphanedblocks in Bitcoin has decreased due to the shift towardshighly centralized mining networks and thus reducing theprobability of orphaned blocks prevalent in decentralized min-ing networks. However centralized mining has other issuessuch as unfairness in the network and the 51% attack. Theother solution to avoid stale or orphaned blocks involvesdynamic adjustment of network’s difficulty [109]. In Bitcoin,the difficulty is adjusted every two weeks (2016 blocks). Inthe meantime, if there is a sharp increase in the hash rateof the network or more miners join in, then the expectedtime of finding new block decreases (2). As a result, thereis a higher likelihood of producing stale blocks. Therefore, adynamic difficulty adjustment helps in reducing the number ofstale and orphaned blocks. While there are effective techniquesto counter forks and orphaned blocks, the area of consensusremains open. Research efforts need to be dedicated to makePoW more energy efficient, and PoS, more decentralized.In PBFT-based private blockchains, the key issue is limitedscalability due to high message complexity. Moreover, PBFThas low fault tolerance which makes it vulnerable to attacks.In section V-H, we provide more details about making PBFTmore scalable and secure.

V. BLOCKCHAIN’S PEER-TO-PEER SYSTEM

The underlying peer-to-peer architecture is the primaryreason why certain guarantees are provided by a Blockchain,including security and accessibility. Counter intuitively, thispeer-to-peer architecture that the Blockchain resides on ac-tually contributes to several attacks including selfish mining,the 51% attack, DNS attacks, distributed denial-of-serviceattacks, eclipse attacks, fork after withholding attacks, andconsensus delay. In this section, we explore how these attackscan compromise the Blockchain applications.

A. Selfish MiningThe selfish mining attack [110] is a strategy opted by certain

miners who attempt to increase their rewards by deliberatelykeeping their blocks private [32], [111], [112]. Rather than

b1 b2 bn

bn+1

bn+1 bn+2 bn+3

Mh

Ms

Fig. 9. Illustration of Selfish Mining. Selfish behavior of Ms forks the chainat bn+1 and discards Mh’s block. Mh’s block becomes a stale block.

releasing them to the public upon discovery, these selfishminers continue to mine their own private blocks to obtain alonger chain than the public Blockchain. These activities leadto a block race between the public chain of honest miners andthe private chain of selfish miners. Once the public Blockchainstarts approaching the length of their private chain, selfishminers release their blocks to claim block rewards. Havingexceptional mining power may further help selfish miners winthe block race. In Figure 9, we demonstrate how a selfishmining attack is carried out.

Consider a Blockchain with blocks (b1, b2, . . . , bn). Supposean honest miner Mh has successfully mined the next blockbn+1 and he publishes it. All the peers in the network validateand accept his block. At the same time, a selfish miner Ms

also computes the block bn+1. Instead of publishing his block,Ms chooses to withhold it and successfully mines two moreblocks bn+2 and bn+3. Despite Mh ’s block being added tothe Blockchain, we show that Mh can still be cheated whilehaving a majority of network’s confidence in his block. Let thehash value of Mh’s block bn+1 be lower than both the targetthreshold and Ms’s block bn+1. If only these two blocks werepresented to the network, Mh’s block would be chosen (dueto its greater computational complexity) over Ms’s block andappended to the public Blockchain.

However, after some time, Ms releases all of his blocksbn+1 , bn+2, and bn+3 and forks the Blockchain at bn+1

. Due to the design protocols of Blockchain, the networkwill invariably shift to the longer chain belonging to Ms anddiscard the block bn+1 of Mh. The effort put forth by Mh

in computing his block will be wasted due to selfish behaviorof Ms. The incentive in adopting this selfish mining strategyis maximizing block rewards by publishing a longer chain.It should be noted that excluding the Mh’s block bn+1 fromthe Blockchain does not destroy the block, rather it leads toanother significant problem in the network known as “staleblocks” as shown in section IV-B.

Selfish mining attacks can produce undesirable results forthe rest of the network by invalidating the blocks of honestminers who contribute to the Blockchain. Furthermore, all thetransactions in the honest miner’s block also get rejected. Ina situation where two selfish miners compete to add theirchains to the network, the chances of a “Blockchain fork”arise section IV-A. These forks can cause a delay of consensusin the network, which can further lead to other potential attackssuch as “double-spending” and “fork after withholding”, asdiscussed in section VI-B. One selfish activity in the networkhas the potential to disrupt the overall network, and thereforeit is imperative to study their relationship with one another.

11

B. The Majority Attack

The majority attack also known as the 51% attack is wellknown vulnerability in Blockchain-based applications that canbe exploited when a single attacker, a group of Sybil nodes,or a mining pool in the network attains the majority ofthe network’s hash rate to manipulate the Blockchain. Withmajority of network’s hash rate, the attackers are able to1) prevent transactions or blocks from being verified (thusmaking them invalid), 2) reverse transactions during the timethey are in control to allow double-spending, 4) fork themain Blockchain and split the network, and 3) prevent otherminers (verifiers) from finding any blocks for a short periodof time. Under race conditions, the attackers with over 50%hash rate are guaranteed to over take other miners and appendtheir blocks in the Blockchain with high probability [52].Also, these blocks can possibly have fraudulent or double-spent transactions. For example, if an attacker performs atransaction in exchange for any product with Alice, it canreplicate the same transaction with Bob and put it on theblock. Transactions on Blockchains are not reversible, andonly one transaction can be considered valid. In the following,we elaborate the prospects of double-spending with majorityattacks along with the mathematical primitives.

1) Caveats and realities: Mining pools do not always need51% of the network’s hashing power to carry out the fraudulentactivities. As such, even with less hashing power, similarobjectives can be achieved with a significant probability ofsuccess. To understand this issue, consider the scenario inwhich a malicious mining pool with significant hash ratecarries out a transaction Tx with a receiver. At the sametime, it generates a fraudulent double-spent transaction Tyfrom the same parent transaction to trick the receiver. Thereceiver, on the other hand, waits for k confirmations beforereleasing the product to the miner. The k confirmations meanthat k subsequent blocks have been mined by the network aftermining the transaction Tx. During this process, the maliciousminer keeps mining blocks on his end with the double-spenttransaction Ty and hopes to fork the Blockchain after hereceives the product from the recipient. By forking the chain,the malicious miner will be able to invalidate the chain withtransaction Tx, and will replace it with his own chain withdouble-spent transaction Ty.

To launch a successful attack, the malicious miner needsto publish a longer chain with valid PoW so that the networkswitches to his forked version. Miner’s success depends on hishash rate x as a fraction of the network’s hash rate and thenumber of confirmations k. To find the probability of successP (s) for the attacker, let x be the fraction of miner’s hashingpower and y be the fraction of remaining hashing power, wherex+ y = 1 [110]. The success probability is:

P (s) =

{1 , if x > y

(xy )k , if x < y

2) Numerical results: In Figure 10, we show how P (s)changes with varying hash rate. Note that if the miner acquireshalf of the network’s hash rate, he can trick the recipient with100% success rate. Moreover, an attacker with hash rate lessthan 50% can still succeed in forking the main chain and

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14

Su

cce

ss P

rob

ab

ility

P(s

)

Number of blocks (k)

x = 0.49x = 0.45x = 0.40x = 0.35

Fig. 10. Change in the success probability P (s) of majority attack withvarying hashing power x and number of confirmations k. Notice that with0 confirmations, an attacker can always double-spend with any magnitude ofhash power. In that case we describe the user to be optimistic.

TABLE VATTACK COST REQUIRED TO LAUNCH THE 51% ATTACK ON THE TOP SIX

BLOCKCHAIN-BASED CRYPTOCURRENCIES. HERE CAP DENOTES THEMARKET CAP IN USD, ALGO DENOTES THE ALGORITHM USED FOR

BLOCK CONSENSUS, AND COST DENOTES THE ATTACK COST IN USD FORLAUNCHING THE 51% ATTACK FOR ONE HOUR.

SYSTEM CAP ALGO HASH RATE COST

BITCOIN 112.7B SHA-256 35,604 PH/s 486KETHEREUM 49.5B Ethash 222 TH/s 347KB.CASH 14.9B SHA-256 5,023 PH/s 68KLITECOIN 5.7B Scrypt 327 TH/s 60KDASH 2.1B X11 2 PH/s 15KMONERO 2.3B CryptoNight 365 MH/s 17K

cheating the receiver.3) Applications and implications: A Blockchain-based ap-

plication for Internet of Things (IoT), known as “The Tangle”[113] can be theoretically compromised with one-third of thehash power. Bahack et al. [114] show that the majority attacksare highly feasible with one quarter of the network’s hashingpower. There are online services such as Nicehash, that renthashing power to miners on hourly basis [115].

A malicious mining pool can rent the computation powerfor a few hours and launch the majority attack on the targetedcryptocurrency. Since major blockchain systems have a highaggregate hash rate, the renting cost to launch the 51% attackon them is (naturally) high. In Table V, we outline the topsix Blockchain-based cryptocurrencies, and the cost requiredto successfully launch the 51% attack, based on data obtainedfrom “51crypto” [116]. We notice that Dash with a marketcap of 2.3 Billion USD can be compromised for one hour byspending only 17,000 USD (8× 10−4% of the market cap).

4) Case studies: A 51% attack is not beyond the realm ofpossibilities. In July 2014, a Bitcoin mining pool “GHash.IO”acquired over 51% of the hash rate for one day [31], whichraised many concerns in the press and media about Bitcoinand its vulnerabilities, and shed light on the general problemin Bitcoin-based systems. Although no malicious activity wascarried out, “GHash.IO” later shrunk in size when miners left

12

TABLE VILOCATION OF FULL NODES IN THREE MAJOR CRYPTOCURRENCIES. – IN BITCOIN REFERS TO THE NODES THAT USE TOR SERVICES AND THEIR

LOCATION CANNOT BE IDENTIFIED.

Bitcoin Ethereum LitecoinRank Country Nodes Country Nodes Country Nodes

1 Unite States 2445 (24.98%) United States 6549 (37.99%) United States 79 (24.38%)2 Germany 2445 (24.98%) China 2202 (12.77%) Russia 36 (11.12%)3 China 675 (6.90%) Canada 1118 (6.49%) Germany 19 (6.49%)4 France 663 (6.77%) Russia 846 (4.91%) China 17 (5.21%)5 Netherlands 475 (4.85%) Germany 783 (4.54%) Netherlands 17 (5.21%)6 Canada 369 (3.77%) United Kingdom 559 (3.24%) United Kingdom 16 (4.91%)7 — 368 (3.76%) Netherlands 470 (2.73%) France 11 (3.42%)8 United Kingdom 307 (3.14%) South Korea 429 (2.49%) Brazil 11 (3.42%)9 Russia 296 (3.02%) France 399 (2.31%) Canada 11 (3.42%)

10 Japan 219 (2.24%) Japan 279 (1.62%) Hong Kong 11 (3.42%)

its pool and eventually closed in October 2016. In August2016, a group of attackers, known as “51 crew”, hijackedtwo Ethereum Blockchains, namely Krypton and Shift, andmanaged to hijack 21,465 Kryptons worth of digital currencyby double-spending. In May 2018, a group of malicious minersacquired 51% hash rate in Bitcoin Gold and stole $18 millionUSD worth of cryptocurrency [117]. In June 2018, four othernotable Blockchain-based cryptocurrencies were also attacked;namely Monacoin, Zencash, Verge, and Litecoin Cash.

C. Network AttacksBlockchain applications are decentralized and use peer-to-

peer network architecture as the medium of communicationbetween the network entities. In this section, we will look intothe attacks associated with the peer-to-peer network and wewill use Bitcoin network as our example to provide details ofthese attacks. The attacks associated to the Blockchain networkinclude among others, the DNS attacks, spatial partitioning,and Eclipse attacks. For each of these attacks, the goal of theattacker is to isolate users and miners from the real network,limit their access to the network resources, or create partitionin the network and enforce conflicting rules among the peers.

1) DNS Attacks: When a node joins the Bitcoin network forthe first time, it is not aware of the active peers in the network.To discover the active peers (identified by their IP addresses)in the network, a bootstrapping mechanism is required. TheDomain Name System (DNS) can be used as a bootstrappingmechanism, and DNS seeds are queried by nodes upon joiningthe network to obtain further information about other activepeers. The initial DNS query returns one or more DNS Arecords along with their corresponding IP addresses of peersthat are accepting incoming connections. Once the new nodeestablishes connections to the peers, it can send addr commandwith port numbers to establish connections with other peers.

It has been mentioned in the developer’s guide of Bitcoinsystems [28] that the DNS opens a wide attack surface tothe Bitcoin networks in general. Namely, the DNS resolutionis vulnerable to man-in-the-middle attacks (at the resolverside), cache poisoning, and stale records, among many others.For this attack, an adversary can either inject an invalid listof seeder nodes in the open source Blockchain software, orpoison DNS cache at the resolver. By default, the Blockchain

Bitcoin Network33.33.33.3

Attacker's Network22.22.22.2

1.

2.

3.

Attacker User

Attacker poisons DNS cache

dig see

d.bitco

in

.sipa.b

e.

22.22.

22.2

4.User routedto Attacker'sNetwork

Fig. 11. DNS resolution attack on Bitcoin. The attacker poisons DNS cacheand modifies the data. When a user queries the server to obtain IP addressesof peers who are accepting connections, he is routed to attacker’s network.The attacker can game the user by feeding him fake blocks and transactions.

software client has a list of seeders that allow the networkdiscovery. If the attacker injects a fake list of seeders, the userwill be compromised. As a result, the adversary can poten-tially isolate Blockchain peers and lead them to a counterfeitnetwork. In Figure 11, we illustrate how a DNS attack can becarried out by poisoning DNS cache. A node in Bitcoin net-work has an IP address of 33.33.33.3 (for illustration purposeonly) while the attacker’s node in a counterfeit network has anIP address 22.22.22.2. The attacker poisons the DNS cache tolure the user into the counterfeit network. The user makes theDNS query dig seed.bitcoin.sipa.be. and instead of respondingwith 33.33.33.3, the DNS resolver returns 22.22.22.2. As aresult, the user connects to malicious nodes in the counterfeitnetwork and malicious nodes may feed false blocks to the user.For more on DNS security, we refer to the work in [118].

2) BGP hijacks and spatial partitioning: There are twotypes of nodes in most Blockchain applications, namely fullnodes and lightweight nodes. Full nodes are the actual partici-pants in the network responsible for relaying blocks and trans-actions and maintaining an updated copy of the Blockchain.Lightweight nodes do not maintain a Blockchain and only

13

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14 16

CD

F o

f F

ull

No

de

s

ASes and Organizations (x100)

OrganizationsASes

Fig. 12. Distribution of full nodes in Bitcoin across ASes and ISPs (orga-nizations). Notice that less than 50 ASes and ISPs host more than 50% ofnodes showing that the network is centralized and vulnerable to BGP attacks.

use the services of full nodes to get access to the network.Since lightweight nodes draw their view of the Blockchainfrom the full nodes, when a full node is compromised all ofits associated lightweight nodes are also compromised. Fullnodes in a Blockchain network are spatially distributed acrossthe Internet. In Table VI, we show the spatial spread of fullnodes in three major Bitcoin systems (cryptocurrency). In eachsystem, a majority of the nodes is located in United States,Germany, China, and Russia. The flow of traffic on the Internetis controlled by Internet Service Providers (ISPs), which ownone or more Autonomous Systems (ASes), responsible forhandling traffic routing. [119], [120].

Spatial concentration of nodes within an AS or an ISPmakes them vulnerable to routing attacks such as BGP hi-jacking. An adversarial AS can hijack the traffic for a targetAS that hosts a majority of the Blockchain application nodes.This can disrupt the flow of valuable information, includingtransactions and blocks, to the nodes being hosted by thetarget AS. When the victim nodes are miners or mining pools,the attacker can substantially reduce the hash rate of theBlockchain application, thereby affecting the system activities.In a mining pool, the miners communicate using stratumoverlay protocol. The stratum servers act as a dropzone whereminers submit their PoW. Stratum servers have a public IPaddress that makes them vulnerable to routing attacks andflood attacks. Apostolaki et al. [29] studied that by hijackingfewer than 100 border gateway protocol (BGP) prefixes inBitcoin, an attacker can isolate up to 50% of the network’shash rate. They further explored that 60% of all Bitcointraffic traverses only three internet service providers (ISPs).Every month, over a 100 Bitcoin nodes suffer from routingattacks and BGP hijacks. Furthermore, they estimated thatthe routing attacks can delay block propagation by up to 20minutes. As mentioned in section IV-B, the average blockcomputation time in Bitcoin is 10 minutes. Therefore, therouting attacks can delay the propagation of two or moreblocks to a group of nodes. Such delays increase the likelihoodof other attacks including Blockchain fork, consensus delay,and double-spending.

TABLE VIITOP 5 MINING POOLS PER HASH RATE, ASES, AND ORGANIZATIONS.

65.7% OF MINING DATA GOES THROUGH ONLY THREE ORGANIZATIONS.ALIBABA ALONE HAS A VIEW OF AT LEAST 60% OF THE MINING DATA.WE EXCLUDE THE REMAINING 12 MINING POOLS FROM THE STUDY AS

THEIR TOTAL CONTRIBUTION TO HASH RATE IS MINIMAL.

Mining Pool H. Rate % ASes ISP

BTC.com 25% AS37963 AlibabaAS45102 AliBaba

Antpool 12.4% AS45102 AliBabaViaBTC 11.7% AS45102 AliBabaBTC.TOP 10.3% AS45102 AliBaba

F2Pool 6.3% AS45102 AliBabaAS58563 Chinanet

12 others 34.3% — —

To verify their results and further analyze the spatialvulnerability of Bitcoin network, we replicated their studyand noticed that Bitcoin network has further centralized withrespect to ASes and ISPs. We crawled data from “Bitnodes”,an online service that maintains information related to fullnodes in Bitcoin [105]. In Figure 12, we plot the CDF ofthe spatial distribution of full nodes across ASes and ISPs inthe world. In Table VII, we show the distribution of miningpools across ASes and ISPs in Bitcoin. Notice that 60% of thehash rate is solely intercepted by AliBaba. Our results showthat compared to the prior work by Apostolaki et al. [29],the Bitcoin network has further centralized and become morevulnerable to routing attacks.Case studies. Over the last few years, a number of BGPattacks have been launched against ASes that host miningpools or cryptocurrency exchanges. In 2014, a maliciousISP in Canada announced BGP prefixes belonging to majorISPs including Amazon, OVH, Digital Ocean, LeaseWeb, andAlibaba, and intercepted the traffic routed to mining pools. Asa result, the attacker made a fortune of 83,000 USD. In April2018, BGP attacks were launched against MyEtherWallet.com,an open source web application used for exchanging Ethereumtokens online. Attackers managed to steal 152,000 USD fromthe web application [121].

3) Eclipse Attacks: Blockchain’s peer-to-peer system isalso vulnerable to a form of attack known as the eclipse attack[30], [112], [122], in which a group of malicious nodes isolatesits neighboring nodes using IP addresses, thereby compro-mising their incoming and outgoing traffic. For example inBitcoin, a node can actively connect to all the other nodesin the network, forming a node cluster. In the node cluster,every peer is aware of the IP address of all other peers. Withsufficient compromised nodes in a cluster, the attacker canisolate honest nodes and change their Blockchain view. Hecan control their incoming and outgoing traffic and feed themwith fake information regarding Blockchain and transactions.

In Figure 13, we illustrate this attack procedure. As longas the honest node maintains a connection with one otherhonest node, it is likely to receive the correct informationto maintain the true state of the Blockchain. However, whenthe connection between the honest nodes is compromised,they will get surrounded by malicious nodes and become

14

Fig. 13. Eclipse attack on a cryptocurrency network. Here, blue nodes represent the honest nodes following the true state of Blockchain while the red nodesrepresent the malicious nodes that form a cluster around the blue nodes. If the connection between the honest nodes is compromised, the malicious nodes mayfeed fake blocks to the honest nodes and partition them from the network. As a result, the honest nodes end up having the wrong view of the Blockchain.

vulnerable to the eclipse attack. When such nodes are fedwith fake transactions and blocks, they eventually develop thewrong view of the state of Blockchain and become part of themalicious node cluster. Furthermore, if another honest nodeestablishes a connection with the malicious node cluster, itis also exposed to the same vulnerability which leads to thecascade effect of propagation of fake transactions and blocks.

D. Distributed Denial of Service Attacks

One of the most common attacks on online services is thedistributed denial-of-service (DDoS) attack [123]. Blockchaintechnology, and despite being a peer-to-peer system, is stillprone to DDoS attacks. Blockchain-based applications, suchas Bitcoin and Ethereum, have repeatedly suffered from theseattacks [124]–[128]. DDoS attacks manifest themselves ina number of ways, depending upon the application nature,network architecture, and peers behavior. For example, in theBitcoin network, the 51% attack can lead to denial-of-service.Specifically, if a group of miners acquire a significant hashingpower, they can prevent other miners from adding their minedblocks to the Blockchain, invalidate ongoing transactions, andcause service failure in the network. Intentional forks; forksthat are the result of malicious behavior; can turn into hardforks, resulting in similar outcomes of denial-of-service.

1) Stress testing: Another possibility for the attack is dueto the limited number of transactions per block a Blockchainapplication can process in a given time. For example, onaverage, it takes the Bitcoin network 10 minutes to mine ablock, which has a maximum size of 1MB. Although thesize of transactions in Bitcoin varies, the average size of atransaction in Bitcoin is approximately 500 bytes, allowingapproximately 2,000 transactions per block on average—themaximum number of transactions added to a block in Bitcoinis reported to be 2,210 [93]. Furthermore, the average timeneeded to mine a block, based on the predefined difficulty, isapproximately 10 minutes. As such, for all current transactionsin the network to be successfully included in the Blockchain,their number may not exceed 200 transactions per minute.Taking that into account, and the fact that each transactionrequires a minimum of two peers (identified by two differentpublic identifiers) to be involved in a transaction, the totalactive peers served by the network per minute (i.e. wherea block containing their transaction will be mined) will notexceed 200 peers. Given these constraints, the throughput of

0

0.2

0.4

0.6

0.8

1

07/0

1/16

09/0

1/16

11/0

1/16

01/0

1/17

03/0

1/17

05/0

1/17

07/0

1/17

09/0

1/17

11/0

1/17

01/0

1/18

03/0

1/18

05/0

1/18

Norm

aliz

ed V

alu

e

Dates (mm/dd/yy)

Mempool SizeFee

Fig. 14. Bitcoin mempool size and average fee paid to the miner. It can beobserved from the figure that as the mempool size is increases, the fee paidto the miners also increases.

Bitcoin is 3-7 transactions per second. Throughput of Bitcoinis low compared to mainstream payment processors such asVisa Credit that can verify up to 2,000 transactions per second.

An adversary may exploit the aforementioned operationalreality of the Bitcoin system by introducing Sybil identities;the same adversary also may control multiple wallets. Further-more, using those identities, the adversary may issue severaldust transactions (e.g., 0.001 BTC per transaction) betweenthe various Sybil identities under his control. By introducing alarge number of transactions of small value over a short periodof time, the network will be congested by creating blockscontaining those transactions, and service to legitimate usersin the network will be denied. As a result of this congestionthe adversary may as well launch other attacks; e.g., double-spending of tokens not mined due to the congestion.

One may argue that miners may choose which transactionsto include in a block. However, this is discouraged by designin Bitcoin, as outlined by Satoshi. Blocks today even includetransactions of value as low as 0.0001 BTC, which makesflooding the network with low-value transactions possible.

2) Mempool flooding: Another form of DDoS attack iscarried out at the memory pools (mempools) of the cryp-tocurrencies to increase the mining fee. As outlined in Fig-ure 1, mempools act as a cache of unconfirmed transactions.

15

Although the block size is limited in the cryptocurrencies, themempool size has no size limit. However, users estimate thesize of mempools to prioritize their transactions. If there aremore transactions in the mempool, then the competition formining becomes high. To prioritize their transactions, usersstart paying more mining fees as an incentive for miners. Saadet al. [33], identified a low cost DDoS attack on Blockchainapplications in which the adversary along with Sybil nodesmay flood the mempools with unconfirmed transactions. Suchan attack creates panic among the legitimate users who aretempted to pay higher mining fee to prioritize their transactionswhile the attacker’s transactions do not get mined. As a result,the attacker launches a DDoS attack.

3) Case Studies: In Bitcoin, malicious users have beenflooding the mempool with dust transactions to make legit-imate users pay higher mining fees. On November 11, 2017,the Bitcoin mempool size exceeded 115k unconfirmed transac-tions, resulting in $700 million USD worth of transaction stall[50]. In June 2018, again the mempool was attacked with 4,500unconfirmed spam transactions which increased the mempoolsize by 45MB. The increased size led to a spike in the miningfee and legitimate users were propelled to pay higher fee toget their transactions mined [129]. In Figure 14, we plot themempool size and the mining fee of Bitcoin over the last twoyears. We use min-max normalization to scale the data points.

4) DDoS Attacks in Private Blockchains: In PBFT-basedprivate Blockchains, a DDoS attack can be launched ifthe adversary controls ≈33% replicas [130]. In the privateBlockchains, the size of the network is known to the par-ticipating nodes, which allows the adversary to calculate thenumber of sybil nodes he needs to introduce in the networkfor an attack. Assuming that the adversary controls f sybilnodes such that the total network size is n < 3f + 1, thenthe attacker will be able to launch a DDoS attack to stop theverification process. For each transaction sent by the primary,the sybil replicas will not reply with their approvals. Since theprimary will need approvals from at least 3f + 1 replicas, itwill not be able to process any transaction, and the systemactivities will be halted leading to a DDoS attack.

In public Blockchains, launching such an attack can becostly. The adversary needs to have either the majority of thetotal hash rate, the majority of stake, or control over 50% net-work peers. Considering that public Blockchain applicationssuch as Bitcoin have more than 10,000 active full nodes [105],it is infeasible for the adversary to launch a successful attack.On the other hand, in private Blockchains, the network sizedoes not grow beyond a few hundred nodes, whereby theadversary needs to control only 33% replicas or just theprimary replica, making the attack on private Blockchainsmore feasible.

E. Block Withholding Attacks

The peer-to-peer network of cryptocurrencies can be ex-ploited to create conflicting views about the Blockchain.Malicious nodes can intentionally mask, forge, or withholdimportant information that needs to be relayed across thenetwork. Some of the known attacks of this nature are “TheFinney Attack” and “Block Withholding Attack” [131].

1) The Finney attack: The Finney attack is a variant ofthe double-spending attack in which a miner delays blockpropagation to double-spend his transaction [132], [133]. Theminer generates a transaction, computes a block, and choosesnot to relay the block. In the meantime, he generates aduplicate of his previous transaction and sends it to a recipient.After the recipient accepts the transaction and delivers theproduct, the miner publishes his previous block with the orig-inal transaction in it. Therefore, the previous transaction sentto the recipient becomes invalid and the miner successfullydouble-spends transaction.

The Finney attack has low success probability due to shortblock intervals and time sensitive attack procedure. The blocktime in Bitcoin and Ethereum are 10 minutes and 15 seconds.If an attacker attempts to launch this attack on Ethereum, itis unlikely that he will be able to 1) generate a double spenttransaction, 2) trick an optimistic receiver, 3) receive productbefore confirmation, and 4) publish a block before any otherminer, within 15 seconds. Since the attack procedure is moretime consuming than the block interval time, Finney attack ishighly infeasible and as such, no case of Finney attack has yetbeen reported on any cryptocurrency.

2) Classical block withholding attack: The block withhold-ing attack is launched against decentralized mining pools withintent to harm the pool operator by withholding a valid PoW.[134], [135]. In decentralized mining pools, all participantsconsume electricity and CPU power to find a nonce whosevalue of a hash with the block is less than the target threshold.Once the valid solution is found, all participants are rewardedbased on their aggregate effort put towards the computationof the solution. Since nonce finding is a lottery-based system,therefore, miners with less hash power may come up with avalid solution before other miners with a higher hash rate. Inthe block withholding attack, a compromised miner in the poolfinds the proof-of-work and chooses not to disclose it to thepool operator. Unaware of the compromised miner, the rest ofthe miners in the pool waste their resources to find the nonceand eventually lose the race. The malicious miner then cancollude with other mining pools and share the PoW with themfor a higher reward, or even publish the block independentlywith a different identity. Due to this unfair behavior of oneminer in the pool, the entire pool is deprived of block rewards.

Another form of withholding attack is possible when twomining pools intentionally try to fork the Blockchain to createa network partition [89]. For instance let there be two miningpools in a cryptocurrency, namely MpA and MpB , and MpAcomputes a valid block but decides not to publish it. MpAwaits for MpB to compute and publish the block. As soonas MpB releases its block, MpA also releases its block andresulting in two valid blocks in the network. This will fork theBlockchain and nodes in the network will have a consensusdisagreement upon receiving two valid blocks. Although thisattack may partition the network, it may also cause loss to bothmining pools. Therefore, no such attack has been reported inany Blockchain application so far.

3) Fork after withholding attack: Another form of with-holding attack is known as the fork after withholding (FAW)attack. Introduced by Kwon et al. [89], FAW is always morerewarding than block withholding attacks. In the following,

16

Node A Node B Node C

VerificationTime v1(t)

VerificationTime v2(t)

block

getdata

inv

block

inv

Fig. 15. Block propagation between nodes A, B, and C. Notice that themaximum time is consumed in block verification, v1(t) and v2(t). Consensusdelay can be caused by propagating false or stale blocks in the network.

we outline the attack procedure of FAW.1) A malicious miner joins two mining pools MpA and

MpB respectively. 2) The miner computes a valid PoW inmining pool MpA. 3) He withholds the solution and onlypublishes the block once MpB also publishes the block. 4) Thenetwork selects one block among the two. 5) The maliciousminer gets rewarded either way.

Kwon et al. [89] also show that if the FAW attack islaunched by two or more mining pools against each other, thenthe bigger mining pool will always win in the race condition.Therefore, the FAW attack is always more profitable thanselfish mining and block withholding.

4) Block Withholding in Private Blockchains: In privateBlockchains, the primary replica can launch a block with-holding attack after receiving a confirmations from otherreplicas. Private Blockchains work under the assumption thatthe primary will faithfully execute the protocol. Moreover, theadversarial model assumes that the attacker controls a subsetof faulty replicas among all the other replicas. However, if theadversary also controls the primary replica, he can withholdblocks and transactions from all other replicas. As shown inFigure 2, the primary receives a transaction request from theclient and sends the transaction to other replicas to obtain theirsignatures. Finally, it computes the block when a sufficientnumber of transactions are processed. However, if the primarygets compromised, he may: 1) withhold a transaction issued bythe client and abort the verification process, 2) delay the ver-ification process by sending the transaction to fewer replicas,3) receive the signatures and discard them, 4) compute a blockand withhold it from the rest of the network. In each case, theprimary can launch a withholding attack to compromise thesystem and delay the transaction processing.

F. Consensus DelayAnother attack associated with the peer-to-peer nature archi-

tecture is the consensus delay, noticed by Geravis et al. [136].In this attack, an attacker may inject false blocks to add latencyor prevent peers from reaching consensus about the state ofthe Blockchain. In Figure 15, we illustrate the delays incurredduring block propagation in Bitcoin. When node A receives ablock, it authenticates the block and sends an inv message toits neighbors including node B. If node B does not have the

block, it sends getdata message back to A. Upon receivingthe getdada message from B, A sends the block to B. Once Bhas the block, it also authenticates the block and sends an invmessage to its neighbors. As Figure 15 shows, the maximumdelay is incurred during authenticity check (v1(t) and v2(t)).The other delays include transmission delays and propagationdelays of messages and block. Transmission delays are subjectto the size of block and messages while the propagation delaysdepend upon the bandwidth of the link between the nodes.

In such conditions, intentional delays can be introducedin the network by propagating stale blocks or double-spenttransactions. The nodes which are not aware of stale blockswill respond with getdata messages and upon receiving theblock, they will waste time in its verification. If an attackercontrols a set of sybil nodes in the node cluster section V-C,it can add significant delays among legitimate nodes in thatcluster. The problem is further exacerbated for time-criticalapplications such as Blockchain-based peer-to-peer gaming,where resolution needs to be achieved within short time.

In PBFT-based private Blockchains, an adversary can alsocause consensus delay by using sybil nodes. As shown inFigure 2, a major component of transaction processing isthe exchange of messages and signatures among participatingreplicas. Especially, in the prepare and commit phase, eachreplica sends its signatures to every other replica. As outlinedin section V-D, if the adversary controls more than 33% ofreplicas, he can launch a DoS attack. On the other hand, ifthe adversary controls fewer replicas, he may still be able tocause consensus delay in transaction processing [137], [138].The sybil nodes can also send bogus signatures to the otherreplicas during the prepare phase and the commit phase. Sinceeach replica is then required to verify signatures, therefore,bogus signatures will cause additional verification overhead.If the sybils continue to send such signatures, they can stallthe completion of the commit phase and eventually cause adelay in the reply phase. As a result, the primary will notreceive the required number of approvals for the transactionverification. This will cause consensus delay and reduce thethroughput of the application.

G. Timejacking AttacksIn Bitcoin systems, such as Bitcoin, full nodes maintain an

internal counter that denotes the network time. The networktime is obtained by receiving a version message ver fromneighboring peers and calculating its median during the boot-straping phase. If the median time of all the neighboring peersexceeds 70 minutes, the network time counter is automaticallyreverted to the system time of the node. This creates an attackopportunity for malicious nodes which may connect to thetarget node as shown in Figure 13. In such case, the attackercan feed varying timestamps with median value exceeding 70minutes. Furthermore, in Bitcoin, for example, a node rejectsa block if its timestamp exceeds the network time by 120minutes. An attacker can compute a new block and set itstimestamp ahead of network’s timestamp by 50 minutes. Theattacker then, along with Sybil nodes, can slow the networktime of a target node by launching a timejacking attack againstit. As a result, the difference between the block time and thetarget node’s counter will exceed 120 minutes. As a result, if

17

the target node is presented with the block, it will reject itand all the subsequent blocks. The target node eventually getsisolated from the activities of the main network.

H. Countering Peer-to-Peer AttacksPrior research has been conducted to address the problem of

selfish mining, and researchers have suggested several possiblesolutions [110], [139]–[141]. Solat and Potop-Butucaru [142]proposed a “lifetime” for blocks that prevents block with-holding by selfish miners. If the expected lifetime of a blockexpires (calculated by the honest miners), it is rejected by thenetwork. Heilman [140] impedes the profitability of selfishminers by introducing a defense scheme called “FreshnessPreferred.” Heilman [140] builds on top of the previous workby Eyal and Sirer [110] by adding unforgeable timestampsto blocks and prefers blocks with more recent timestampscompared to older ones. His work reduces the incentive forselfish miners to withhold their blocks for long periods of time.Eyal [26] modeled a game between two mining pools carryingout block withholding and discovered miner’s dilemma, whereboth mining pools suffer a loss in equilibrium.

Majority attacks have also been widely discussed with coun-termeasures proposed to overcome a monopoly in Blockchainnetworks. Miller et al. [143] proposed changes to the PoWpuzzle in Bitcoin in order to restrict coalitions of miningpools for majority attacks. Their proposed design incorpo-rates nonoutsourceable puzzles in PoW, in which miningpools that outsource their mining work risk losing miningrewards. Saad et al. [144] leveraged the expected transactionconfirmation height and the block publishing height to detectselfish mining behavior in PoW-based Blockchains. Using therelationship between the two features, they created a “truthstate” for each published block in order to distinguish betweena legitimate block and a selfishly mined block. Also addressingthe 51% attack, Bastiaan [31] introduced the concept of “twophase proof-of-work” (2P-PoW). 2P-PoW is a continuous-timeMarkov chain (CTMC) model that incorporates two challengesfor miners to solve instead of one. The states of the CTMCsprevent the pool from increasing beyond an alarming size byshrinking incentive for miners in the pool. 2P-PoW preventslarge pools from creating a hegemony by either outsourcing amajor chunk of their hash rate or exposing the private keys ofthe pool operator.

Johnson et al. [145] proposed a game-theoretic approachto address DDoS attacks against mining pools. Other counter-measures include putting a cap on the minimum amount in thetransaction that a sender can have or increasing the block sizeto accommodate more transactions. Yet another approach is toreduce the difficulty in mining blocks so that more blocks canbe mined with no transactions going to waste. Each of thesepropositions have their own caveats.

Increasing the block size might not be sufficient, since apowerful adversary can still stress the network by generat-ing dust transactions. On the other hand, reducing difficultywill reduce the block time but it will increase the numberof orphaned blocks in the system and the overall size ofthe Blockchain. At the time of writing this paper, Bitcoinand Ethereum Blockchain size was recorded to be 162 GBand 450 GB, respectively [146]. Saad et al. [33] proposed

fee-based and age-based countermeasures to prevent DDoSattack on Blockchain mempools. In their work, they shiftedthe transaction filtering process from the mining pools tothe mempools. Their proposed countermeasures optimize themempool size and raise the attack cost for the attacker whilefavoring legitimate users in the system.

To prevent DNS-based attacks, extensive research has beencarried out to equip the Blockchain systems with DNS attackdefenses [147]–[149]. Apostolaki et al. [29] proposed long-and short-term solutions for routing attacks. They proposerouting-aware peer selections to maximize diversity of internetpaths and limit the vantage points for attacks. They also pro-posed peer behavior monitoring to check abrupt disconnectionsand unusual latency in block delivery.

Other solutions to prevent delay attacks include end-to-end encryption for message propagation. Another possibleapproach to prevent spatial partitioning is the decentralizedhosting of mining pools and full nodes over the Internet. Asshown in Table VI. 50% of Ethereum nodes are located withintwo countries, which makes them vulnerable to a nation-stateadversary. In order to prevent that, new nodes must be hostedon cloud services that have a higher geographical spread andnetwork diversity. The dimensions we explored in this paperencourage additional research on Blockchain technology in theareas regarding DNS and DDoS attacks.

To counter block withholding attacks [131], [141], [150],[151], Schrijve et al. [152] introduced an incentive-compatiblereward scheme that discourages a malicious miner from carry-ing out withholding attacks against the targeted mining pool.Rosenfeld [153] introduced a Honeypot technique to lurerogue miners into a “trap”, thereby catching the miner whowithholds valid solutions. Bag and Sakurai [151] proposedadditional incentives for finding a valid solution for a blockin order to prevent mining collusion. Concurrent to their priorwork, Bag et al. [150] introduced a new scheme that blindsthe miners in the pool from the current target to obfuscatetheir ability to distinguish between a partial and full PoW.Their proposed solution also binds the pool operator to fairlydistribute the reward to the winning miner.

The FAW attack can be countered by introducing times-tampped beacons in the assignment given to the miners bythe pool operators [89]. As a response to each assignment,the miners calculate the partial proof-of-work and send theresponse to the pool operator embedded with the beacon value.The beacon value is updated after a few seconds to catch amalicious miner if he withhold the valid solution and laterpropagates it in the network. However, the authors also noticedthat this solution may not be practical in some situationsand conclude that FAW attacks remain an open problem forthe research community to address. To address the securityissues in private Blockchains, several variants of PBFT protcolhave been proposed. Those protocols try to increase thefault tolerance beyond 33% [154], [155] and use hardwareassistance to detect the behavior of faulty replicas [156]. Thekey challenge in private Blockchains is the high messagecomplexity that restricts the scalability. As a result, in a smallnetwork, the adversary can easily compromise 33% replicas.To address this issue, Liu et al. [156] proposed a scalableByzantine consensus with hardware assisted secret sharing,

18

which reduces the message complexity of PBFT to O(n).This can be leveraged to construct large private Blockchainnetworks that can withstand various forms of attacks.

VI. APPLICATION ORIENTED ATTACKS

The Blockchain and associated peer-to-peer system areseparate from the application services using them. Based onthe nature of the Blockchain applications, they have theirown vulnerabilities and attack surface. Therefore, we expect asignificant number of attacks related to various applications,which we address in this section. Our analysis is primarily onapplications such as cryptocurrencies and smart contracts.

A. Blockchain Ingestion and Anonymity

Public Blockchains have a weak notion of anonymity, andthey provide open data accessibility to the public. As such, theanalysis of the public Blockchain can reveal useful informationto an adversary. This process is known as Blockchain ingestionand it might not be desirable to the Blockchain application orits users. For example, a credit card company in the open mar-ket can use data analytics to delve into public information onthe Blockchain and optimize its own schemes to compete withthe digital currency. To demonstrate the potential exploitationof the public data, Fleder et al. [37] used graph analysis tocreate directed links between Blockchain data of Bitcoin andassociated identities of the wallet users.Mt. Gox incident. In 2013, two attackers exploited thepublic nature of Bitcoin Blockchain to carry out fraudulenttransactions and create a fake demand of bitcoins at multipleexchanges. The main target of attack was Mt. Gox; the biggestBitcoin exchange in Japan in 2013. The attackers frequentlycarried out a sequence of fraudulent transactions at Mt. Gox.Since the Blockchain is public, the rate of transactions wasnoted by other exchanges too and it was assumed as if theoverall demand of the coins had increased. As a result, theprice of Bitcoin increased from $150 USD to $1,000 USDtowards the end of 2013. The trade carried out at Mt. Goxby the attackers was not backed by the real coins, whicheventually led to the bankruptcy of the exchange.Illegal Activities. Anonymity in Blockchain-based cryptocur-rencies provides lucrative opportunities for miscreants to carryout fraudulent activities. As such, cryptocurrencies have be-come a popular source of funds transfer for illicit activitiesassociated with the Deep Web [157], [158]. Since the use of fiatcurrency leaves traces on Blockchains that can be tracked bylaw enforcement, cryptocurrencies on the other hand, preservethe anonymity of the user. This is a key reason why variouscountries have banned the use of cryptocurrencies [159].

Blockchains are tamper-proof, append-only, and decentral-ized; once a transaction is committed, it cannot be reversed.This has led to various irreversible scam activities online,where users are tricked into sending money through BitcoinATMs. Furthermore, the absence of a central authority makesit harder to claim fraud and expect reimbursement. Therefore,design constructs of Blockchain applications can be exploitedto facilitate cyber crimes and online frauds.

B. Double-Spending

In cryptocurrencies, double-spending refers to the use ofa one-time transaction twice or multiple times. To illustratedouble-spending with an example, consider the followingscenario. In cryptocurrency operations, a transaction transfersthe ownership of asset from a sender’s address to the receiver’spublic address, and the value of the transaction is signed bythe signer with a private key. Once the transaction is signed, itis broadcast to the network upon which the receiver validatesthe transaction. The validation at the recipient’s end happenswhen the receiver looks up the unspent transaction output ofthe sender, verifies the sender’s signature, and waits for thetransaction to be mined into a valid block. The process takesa few minutes depending upon the size of the mempool, thethroughput of the network, priority factor of the transaction,and the block computation time of the cryptocurrency. InBitcoin, the average time of block mining is 10 minutes.

In an environment of fast transactions [54], [160] or if areceiver is optimistic, he may release the product to the senderbefore the transaction gets mined into the Blockchain. Assuch, this gives the sender an opportunity to sign the sametransaction and send it to another recipient. This behavior ofsigning the same transaction with a private key and sendingit to two different receivers is known as double-spending. Indouble-spending there are two transactions derived from thesame unspent transaction output of the sender, and only one ofthem gets incorporated into the Blockchain. In Figure 16, weillustrate how a double-spending attack can be carried out in acryptocurrency. Consensus delay in the network section V-F,BGP attacks, flood attack on mempools, or the 51% attack sec-tion V-B can cause additional latency in the verificationand propagation process, which increase the chances of anadversary to perform double-spending. In March 2013, dueto a soft fork, a successful double-spending transaction worth$10,000 USD was carried out in Bitcoin.

C. Cryptojacking

Cryptojacking is a form of an attack that is launchedon web and cloud-based services to illegally perform PoWfor Blockchain-based cryptocurrencies without consent [161],[162]. The most recent as well as the most prevalent formof cryptojacking is the in-browser cryptojacking, which turnswebsites into mining pools [163]. PoW requires processorintensive mathematical calculations which usually involvesfinding a target hash value. As the aggregate hash rate ofthe cryptocurrency network increases, the associated difficultyto compute a block also increases. To meet the difficultyrequirements, sophisticated hardware such as GPUs and ASICchips [91] are used by miners. Mining pools expand theirhashing capability by inviting more miners to join their pooland purchasing expensive hardware with better computationcapabilities. As a result, the mining process in major Bitcoinsystems becomes an expensive and competitive game thatprevents small miners from mining blocks independently.

1) Cloud-based Cryptojacking: To compensate for that,malicious miners have found a way of to expand their hashpower by hijacking processors of remote devices for mining.This attack is known as the covert mining, or cryptojacking

19

User B User C

Miner Validates Selected TransactionsComputes Block. (Transaction 3 Rejected)

Miner

Block Hash Previous Block HashMerkel RootNumber of Transactions

Coinbase RewardTransaction 2Transaction 4Transaction 5

3.

B1 B2 B3 B4 B5

Blockchain

Memory Pool

Transaction 2Transaction 3Transaction 4Transaction 5

Block Added4.

Block 5 (B5)

User A BalanceTransaction 1

Transac

tion 2

1.

Transaction 3

2.

Fig. 16. Double-spending attack carried out by User A. User A has Transaction 1 in his balance. Using that as an input, he generates Transaction 2 and sendsit to user B. Then he generates Transaction 3 from the an already spent Transaction 1. When miner queries the mempool, he can either select Transaction 2or Transaction 3. If Transaction 3 gets rejected, user C suffers the loss.

0

20

40

60

80

100

06/0

1/17

07/0

1/17

08/0

1/17

09/0

1/17

10/0

1/17

11/0

1/17

12/0

1/17

01/0

1/18

02/0

1/18

03/0

1/18

04/0

1/18

05/0

1/18

06/0

1/18

07/0

1/18

Po

pu

larity

In

de

x

Dates (yy/mm/dd)

CryptojackingCoinhiveMonero

(a) Google popularity index

0

20

40

60

80

100

0 5 10 15 20 25 30

% C

PU

Usa

ge

Time (Seconds)

browar.bzseriesfree.to

megapastes.comlegendaoficial.net

(b) Percentage CPU usage by four cryptojackingwebsites when JavaScript is enabled

0

20

40

60

80

100

0 5 10 15 20 25 30

% C

PU

Usa

ge

Time (Seconds)

browar.bzseriesfree.to

megapastes.comlegendaoficial.net

(c) Percentage CPU usage by four cryptojackingwebsites when JavaScript is disabled

Fig. 17. (a) shows the Google search index for the terms “Cryptojacking”, “Coinhive”, and “Monero.” Notice that towards the end of 2017, there has beena rise in the Google search for the three terms which coincides with timing of large scale cryptojacking attack. In (b) and (c) we show the effect of fourcryptojacking websites with an without JavaScript enabled. Cryptojacking consumes high CPU power upto 100% which can affect critical CPU operations.

attack, and it involves hijacking a target device to performPoW calculations for the attacker. Initially, these attacks werelaunched against cloud service providers, where malicioususers performed covert mining operations on virtual machinesand exhausted cloud resources. This behavior was first noticedby Tahir et al. [40], where they also proposed countermeasuresin the form of a software tool called “MineGuard” to effec-tively detect and stop covert mining operations in cloud.

2) Web Cryptojacking: Cryptojacking was brought to theweb in 2017, and has been soaring in popularity as shownin Figure 17(a). Web-based cryptojacking is used by attack-ers who inject malicious JavaScript code into websites thatsecretly mine tokens without the consent of their visitors. Inbrowser-based cryptojacking, the web browser on the clientdevice executes JavaScript code that establishes a WebSocketconnection with a remote dropzone server. The server thensends the target to the client, which computes hashes for PoWand transmits them back to the server. During this process, thedevice owner remains unknown of this background activityand seamlessly continues to browse the website. In-browsercryptojacking not only poses a major privacy threat, it alsoharms the performance of the visiting device, since PoW-based hash computations are processor-intensive and may leadto excessive CPU usage and battery drainage. To furtherfacilitate these attacks, online platforms such as coinhive andcrypto-loot [164], [165] emerged in 2017, to provide simplecode snippets for the attackers and website owners. Thoseservices bind websites with their platform service and perform

cryptojacking on the website’s visitors machines.Coinhive is the most popular platform for cryptojacking

attacks on websites, and it is linked to the cryptocurrencycalled Monero [166]. In Figure 19, we provide the JavaScriptcryptojacking code used by attackers to bind victim website totheir account at Coinhive. The code listing shows that when abrowser loads coinhive.min.js file, it establishes a WebSocketconnection with coinhive server and passes the attacker’s keyto bind with the dropzone server. It then receives a target andsubmits the corresponding hashes to the server over the samesocket connection [167]. The throttling parameter controlsthe hash rate of the victim device and is adjustable to therequirement of the attacker.

In Figure 17(b) and Figure 17(c), we plot the processorusage of four cryptojacking websites with JavaScript enabledand disabled. It can be noticed that each website uses differentCPU power when JavaScript is enabled, indicating varyingthresholds of throttling parameters. Figure 17 also shows thatwhen the JavaScript is disabled, the browser cannot executethe malicious script and is unable to perform cryptojacking.

In-browser cryptojacking is a relatively new attack relatedto the PoW-based Blockchain applications, therefore no priorresearch is available that looks into the operations and effectsof this attack. However, owing to the incidents reported in thenews, it can be inferred that cryptojacking is becoming popularover time. In 17(a), we show the popularity index of the terms“Cryptojacking”, “Coinhive”, and “Monero”, as recorded byGoogle analytics based on the search count [168]. The results

20

(a) Cryptojacking (b) Coinhive (c) Monero

Fig. 18. Heatmap of the global distribution of Google searches for each term. Notice that US is the most prevalent country in all three search results. Moreoverthere is more similarity in the search for Coinhive and Monero.

<scriptsrc="./Welcome_files/coinhive.min.js"></script>

<script>var miner = new

coinhive.Anonymous("attacker-key",{throttle: 0.1});miner.start();

</script>

Fig. 19. Malicious JavaScript code that links a website to Coinhive.

in 17(a), show that since October 2017, there has been a rise inthe search for each term, indicating the interest shown by theusers in cryptojacking. Additionally, in Figure 18, we showthe global distribution of these searches.

3) Case studies: Cryptojacking is considered as an emerg-ing threat to the security and privacy of Bitcoin systems, bythe research community. Symantec’s latest Internet SecurityThreat Report (ISTR) reveals that cryptojacking attacks onwebsites have increased by 8500% during 2017 [169]. InFebruary 2018, a large scale cryptojacking attack was launchedthat compromised more than 4000 websites worldwide includ-ing the websites of UK National Health Service (NHS) and USFederal Judiciary [167]. UK’s National Cyber Security Centre(NCSC) has declared cryptojacking a “significant threat” in itsyearly cyber security report [170].

D. Wallet Theft

Where credentials, such as keys, associated with peers inthe system are stored in a digital wallet, the “wallet theft”attack arises with certain implications on the application.For example, in Bitcoin, the wallet is stored un-encryptedby default, allowing an adversary to learn the credentialsassociated with it and the nature of transactions issued by it.Even when a wallet is safely guarded on the host, launchinga malware attack on the host will allow the adversary to stealthe wallet. Finally, with many third-party services enablingstorage of wallets, those services can also be compromisedand the wallets can be leaked to an adversary [48].Case studies. In December 2017, $63 million USD worthbitcoins were stolen from the wallet of a cryptocurrencycompany, NiceHash [171]. During the hack, the entire contentsin NiceHash’s Bitcoin wallet were stolen. In November 2017,Tether Treasury wallet was hacked and $31 million USDworth bitcoins were stolen from it. Also in November 2017,$280 million USD worth of ether was locked up after a userdeleted the code in the digital wallet hosted by a companynamed Parity Technologies. In July 2016, the social mediaBlockchain “Steemit” was attacked and $85,000 USD worth

TABLE VIIITOP 5 SOFTWARE VERSIONS USED BY BITCOIN FULL NODES ALONG WITH

THEIR RELEASE DATE, LAG FROM THE DATE OF COLLECTION IN DAYS,AND PERCENTAGE OF USERS. THE RECENT VERSION 0.16.0 HAS NOT

BEEN ADOPTED BY THE MAJORITY OF NETWORK AS YET.

Index Version Release Date Lag Users %1 B. Core v0.16.0 02-26-2018 59 36.28%2 B. Core v0.15.1 11-11-2017 166 27.52%3 B. Core v0.15.0.1 09-19-2017 219 5.01%4 B. Core v0.14.2 06-17-2017 313 4.67%5 B. Core v0.15.0 04-22-2017 369 2.05%

digital currency was stolen from 260 accounts. In January2015, Bitstamp’s Bitcoin wallet was hacked, resulting in aloss of $5.1 million USD worth bitcoins [172].Key Exposure and Theft. A well-known problem inBlockchain-based cryptocurrencies is private key exposure andtheft. If the attacker acquires the private key belonging to auser, he can sign and generate a new transaction on behalfof the user, and possibly spend his balance to unauthorizedrecipients. Brengel et al. [173] studied the key leakage inBitcoin by studying the Bitcoin Blockchain for ECDSA noncereuse. Their results show that ECDSA nonce reuse is misusedin Bitcoin to generate transactions on behalf of users. Sim-ilarly, Breitner et al. [174] performed cryptanalytics attackson Bitcoin, Ethereum, and Ripple to expose their privatekeys. They used a lattice-based algorithm to compute privateECDSA keys that were used in biased signatures.Software Client Vulnerabilities. Public Blockchain applica-tions such as Bitcoin and Ethereum have open-source softwareclients that enable users to connect with the network. Overtime, new software versions are released, implementing newrules and upgrades. An upgrade is also released to patchvulnerability in an old version. In Bitcoin, the Bitcoin Corev0.15 and below are vulnerable to denial-of-service attacks.This vulnerability was patched in the newly released v0.16.However, not all nodes download the newly released version.They continue with the old software client and remain exposedto its vulnerabilities. In Table VIII, we show the diversity inadoption of a Bitcoin software client. Notice that only 36.28%of the nodes are using the most updated software version thatis immune to the denial-of-service attack.

Moreover, the open-source code can be exploited by anadversary to release a new update with a malicious code andbugs. If a user installs the software, it can provide access tothe attacker who can launch various attacks including DDoS,balance theft, etc.. It is therefore necessary to download the

21

software client from a trusted platform.

E. Attacks in Smart ContractsAs new applications are built on top of Blockchain, their

own limitations along with Blockchain vulnerabilities, create anew attack surface. Smart contracts belong to the generation ofBlockchain 2.0 and in this section, we will explore the attackpossibilities in smart contracts. The most well known smartcontract application in digital world is Ethereum, which usesSolidity programming language for coding contracts. Solidity[175] is a contract oriented language, influenced by Javascript,Python and C++. Deficiencies in programming language, ex-ecution environment, and coding style can lead to a seriesof attacks. In Figure 20, we demonstrate a vulnerable smartcontract code that steals a sender’s balance. “The DAO” had asimilar vulnerability in their smart contract which resulted ina loss of $50 million USD. Some of the well known attackson Ethereum smart contracts include reentrancy attack, overand under flow attacks, replay attacks, short address attacksand reordering attacks [42], [176].

1) Reentrancy attacks: In reentrancy attack, if the user doesnot update the balance before sending ether, an attacker cansteal all the ether stored in the contract by recursively makingcalls to the call.value() method in a ERC20 token. As such, acareless user may lose his entire balance in the contract if heforgets to update his balance.

2) DoS attacks: DoS attack in smart contract enablesa malicious actor to keep funds and authority to himself.Consider an example of a smart contract auction in whicha malicious bidder tries to become the leader of an auctionillustrated in Figure 22. The vulnerable contract preventsrefunds to the old leader of the contract and makes the attackerthe new leader. Moreover, it cancels all the bid() requestssent by other bidders and keeps the attacker as the leaderof the auction. Another form of DoS attack in Ethereumsmart contract involves exploiting the gas limit set by thecontract Figure 21. In Ethereum, if the overall gas consumedby the smart contract upon execution exceeds the gas limit,the contract transaction fails. An attacker can exploit this byadding multiple addresses with refund needs. Upon execution,the gas required to refund those addresses may exceed the totalgas limit, thereby cancelling the final transaction.

3) Overflow attacks: An overflow in a smart contract hap-pens when the value of the type variable (2256) is exceeded.For instance, in a smart contact of online betting, if someonesends large amount of ether, exceeding (2256), the value of thebet would be set to 0. Although exchange of an ether valuegreater than (2256) is unrealistic, but it remains a programmingvulnerability in smart contracts written in Solidity.

4) Short address attacks: The short address attack exploitsa bug in Ethereum’s virtual machine to make extra tokenson limited purchases. The short address attack is mostlyapplicable on ERC20 tokens. For this attack, the attackercreates an Ethereum wallet ending with 0 digit. Then he makesa purchase on the address by removing the last 0. If thecontract has a sufficient balance, then the buy function doesnot check the sender’s address and Ethereum’s virtual machineappends missing 0 to complete the address. As a result, foreach 1000 tokens bought, the machine returns 256000 tokens.

// Vulnerable Smart Contractmapping (address -> uint) private userBalance;function withdraw() public {

uint WithdrawAmount = userBalance[msg.sender];if (!(msg.sender.call.value(WithdrawAmount)())) {

throw; } // Caller's code executed and it canmake recursive call to withdraw() again.userBalance[msg.sender] = 0;

}

Fig. 20. Reentrancy attack on smart contract code [41]. A major problemwith calling external contracts is that they alter the control flow of the codethat the running contract does not anticipate. In this contract, an external callis made before the user’s balance is set to 0.

// DoS attackcontract Malicious_Auction {

address presentLeader;uint maxBid;function bid() payable {

require(msg.value > maxBid);require(presentLeader.send(maxBid)); //

Refund the old leader, if it fails thenrevert

presentLeader = msg.sender;maxBid = msg.value;}}

Fig. 21. DoS attack on a vulnerable smart contract in which the maliciousbidder may revert funds to the old leader and prevent other bidders fromcalling the bid() function. As such the malicious bidder remains the leader ofthe auction for as long as he wants.

5) Forcible balance transfer: In vulnerable smart contractcodes, forcible balance transfer to the contract can occurwithout a fallback function. This can be used to exhaust thegas limit and disallow the final transaction.

F. Replay attacks

The replay attack involves making one transactions on twodifferent Blockchains. For instance, when a cryptocurrencyforks into two separate currencies, users hold equal assets onboth ledgers. A user has an option of carrying out a transactionon any one of the two chains. In replay attacks, the attackersniffs the transaction data on one ledger and replays it on theother ledger. As such, the user loses assets on both chains. Asimple case can be drawn from Ethereum.

In Ethereum, a transaction signed on one Blockchain is validon all Blockchains. Therefore, a transactions made on a testnetwork can be replicated on the public network to steal funds.Although Ethereum has taken countermeasures to preventreplay attacks by incorporating chainID in transactions, userswho do not enable this wallet feature remain vulnerable.

G. Countering Application Oriented Attacks

Attacks on Blockchain applications have various possiblecountermeasures. For example, to secure blocks, it is advisedto keep backups of the wallet and secure the keys used forsigning transactions. Passwords are easy to compromise, andusing a strong password is required as a defence against brute-force attack. However, changing passwords does not changethe keys secured by them, making those keys vulnerable dueto a previous compromised password. Wallet encryption, astandard practice in the original Bitcoin design, is highly rec-ommended to cope with vulnerable keys. Other mechanisms to

22

// DoS attack on Gas Limitstruct Payee {

address addr;uint256 value;}

Payee[] payees;uint256 nextPayeeIndex;function payOut() {

uint256 i = nextPayeeIndex;while (i < payees.length && msg.gas > 200000) {

payees[i].addr.send(payees[i].value);i++;}

nextPayeeIndex = i;}

Fig. 22. DoS attack exploiting the gas limit in a vulnerable smart contract.The attacker initiates a list of addresses that demonstrate the need for therefund. Once all the addresses are refunded, the overall gas used by the smartcontract exceeds its gas limit.

mapping (address => uint256) public userBalance;// Vulnerable codefunction transfer(address _to, uint256 _value) {

// Check if the sender has sufficient balancerequire userBalance[msg.sender] >= _value);// Compute new balance

userBalance[msg.sender] -= _value;userBalance[_to] += _value; }

Fig. 23. Overflow attack. When the sender’s balance is being checked, thecontract code does not take into the account if the balance exceeds the value2256. In such a case, the balance will be set to 0 by default and overflowattack can be launched.

cope with wallet security include insurance, which technicallydoes not address the problem by remedying its consequences.A backup of the keys and wallet is essential because if thekeys are lost, then access to wallet is not possible, and ifsome attacker deletes the wallet, all the coins are lost.

New models of cryptocurrency, such as “Zcash”, providechain anonymity to the transactions, the users, and the amountexchanged. As such, the shielded architecture of “Zcash”Blockchain prevents block ingestion attacks. The double-spending attack is easily addressed in fast networks, but notwhen the network is characterized by high latency and longerblock mining times. One possible approach to deal with theproblem is utilizing one-time (or a few time) signatures, suchas XMSS [177], which reveal the private key of the user if hetries to double-spend. However, this requires the change in thecurrent signature algorithms that Blockchain applications haveused. Other proposals include reducing the difficulty parameterof a Blockchain to enable swift block mining, which is areasonable approach, except that it would further facilitateselfish mining and the rate of stale blocks.

All major attacks on smart contracts in Ethereum are eitherrelated to the vulnerabilities in programming platforms or care-less programming practices. These attacks can be prevented bypatching vulnerabilities in Ethereum virtual machine (EVM)and avoiding programming mistakes in smart contracts. [42].

To counter covert mining in cloud, [40] et al. proposed“MineGuard” that detects anomalous use of processor in Vir-tual Machines. To mitiage in-browser cryptojacking, reputableweb browsers, including Chrome and Firefox have, launchedweb extensions that actively detect WebSocket connectionsthat trasnmit PoW [178]–[180]. However, as of now, theextensions use a blacklisting approach to spot the WebSockettraffic which has its limitations. For example, an attacker with

contract Vulnerable {function () payable {

revert(); }function somethingBad() {

require(this.balance > 0);// Do something bad}}

Fig. 24. Vulnerable contract code that allows forcible balance transfer to thecontract without a fallback function.

access to the blacklist can easily circumvent detection by usinga relay server between the host and the dropzone server. As ofnow, cryptojacking and its defences are open challenges andrequire more attention from the community.

VII. RELATED WORK

The work surveyed for paper includes the prior researchefforts towards the study of Blockchain applications andtheir security vulnerabilities. In doing so, we also con-sulted the Comprehensive Academic Bitcoin Research Archive(CABRA) [181], a comprehensive list of over 900 researchpapers that keep track of ongoing research in Blockchainsystems. CABRA is influenced by a chronological list ofBlockchain papers maintained by Brett Scott [182]. From theseuseful repositories, we curated a list of relevant papers for thisstudy, as starting pointers.

There have been several attempts at understanding the attacksurface of Blockchains by various surveys, which we contrastto our work in the following. Towards analyzing the attacksurface of Blockchains, Li et al. [183] surveyed various se-curity aspects of Blockchains by studying popular Blockchainapplications including Bitcoin, Ethereum, and Monero. Theyevaluated the robustness of Blockchain applications againstpopular attacks and the risk factor associated with each attack.Although comprehensive in the survey of attacks, their work,however, does not look into countermeasures. Conti et al. [57]surveyed security and privacy of Bitcoin. Although Bitcoinis a motivating example to analyze the attack surface ofBlockchains in general, however, Blockchains have evolvedbeyond Bitcoin and their attack surface has increased accord-ingly. Furthermore, their work does not cover new attacksrelated to Blockchain applications such as cryptojacking,among others. Tara et al. [184], explored the utilization ofthe Blockchain technology in providing distributed securityservices. They mainly focused on the use of Blockchainsto provide services including authentication, confidentiality,provenance, and integrity assurance. In contrast, our work isdedicated to the abuse of Blockchains and their applications.Anderson et al. [185], looked into the use of new consen-sus schemes in emerging Blockchain applications such asNamecoin and Peercoin. They also surveyed various securityfeatures of these applications with an emphasis on smartcontracts. In a similar context, Atzei et al. [61] also exploredvarious attacks limited to Ethereum smart contracts. Comparedto the existing literature, our work goes beyond the state-of-the-art in outlining new attacks, their implications, theirdefenses, and relevant case studies.

Kiran and Stanett [187] perform risk analysis on Bit-coin, spanning its vulnerabilities and attack surface. Theyalso explore the risk factors associated with the economics

23

TABLE IXCOUNTERMEASURES AND THEIR EFFECTIVENESS RELATED TO THE ATTACKS SURFACE OF BLOCKCHAINS. HERE, #, , H#DENOTE OPEN PROBLEM,

FEASIBLE SOLUTIONS, AND INFEASIBLE SOLUTIONS.

ATTACKS COUNTERMEASURES EFFECTIVE?

Blockchain Structure Forks Joint consensus [48] #Orphans Increase block time [109]

Peer-to-Peer System

DNS hijacks Routing-awareness [29], [147] #BGP hijacks Routing-awareness [29], [147] #Eclipse attacks Peer monitoring [112] #Majority attacks Two-phased proof-of-work [31] H#Selfish mining Time-stamping blocks [139]–[142] #DDoS attacks Increase block size [33] #Consensus Delay Peer monitoring [112] #Block Withholding Enforce PoW submission [142] H#Timejacking attacks Synchronized clocking #Finney attacks Increase block reward [36] H#

Blockchain Application

Blockchain Ingestion Encrypted Blockchains [186] H#Wallet theft Backups, wallet insurance [38] Double-spending OTS schemes [177] H#Cryptojacking Mineguard [40] Smart contract DoS Patch EVM [41] #≈ reentracy attacks Patch EVM [42] #≈ replay attacks Secure programming [42] ≈ overflow attacks Patch EVM [41] #≈ short address attacks Patch EVM [42] #≈ balance attacks Secure programming [41]

of Bitcoin and cryptocurrency market in general, includingdeflation, volatility, and complicity. Becker et al. [96], out-lined challenges and security risks associated with PoW-basedBlockchain applications. Moubarak et al. [188] explored thesecurity challanges of three major Blockchain applications,namely Bitcoin, Ethereum, and Hyperledger. However, theirwork was more directed towards the application attacks anddid not consider the attacks related to the Blockchain’s cryp-tographic constructs and P2P fabric.

Carlsten et al. [189], analyzed the security features ofBitcoin in the absence of Block rewards. Since the numberof coins in Bitcoin are deterministic and the coinbase rewardswill eventually end when all the coins are mined, the stake ofminers in the system will take a paradigm shift which mightinfluence the security properties of Bitcoin. As such, there is animplicit belief that this might not change the attack surface ofBitcoin. However, in [189], the authors outline the limitationsof this belief and present new attack avenues and their effects.

As Blockchain applications are evolving, they are beingtargeted with new and more sophisticated attacks every day.In this paper, we look into the prior work and also cover theemerging vulnerabilities and attacks on Blockchain applica-tions. We also report the major incidents and case studiesrelated to each attack and provide future directions for researchand analysis. In Table IX, we outline the possible counter-measures and their effectiveness for each attack discussed inour work. The criterion of determining the effectiveness ofa countermeasure is how fully or partially it addresses theproblem. For instance, one way to reduce orphaned blocks isto increase the block time in Ethereum. However, this may also

add a penalty to the transaction verification time. Therefore,this solution partially addresses the problem. Additionally, inFigure 25, we provide an illustration of various attacks andtheir countermeasures. Note that some countermeasures mayaddress more than one attack, thereby indicating a commoncure. This can be used to motivate future research directionsin prioritizing defenses.

A. Blockchain Structure Attacks

Analyzing the problems associated to Blockchain’s math-ematical constructs, Eyal et al. [34], proposed a Byzantinefault tolerant Blockchain protocol that addresses the problemsof Blockchain fork. Decker and Wattenhofer [171] observedinformation propagation in Bitcoin network and introduced amodel that explains the formation of Blockchain forks. Fromtheir results, they concluded that delays in block propagationare the primary cause of Blockchain forks. Kiffer et al.[190] analyzed the design space of Ethereum and studied alarge-scale fork that partitioned Ethereum into two separatenetworks (Ethereum and Ethereum Classic). They furtheranalyzed the impact of the fork on users, mining pools, andthe two networks, by exploring the possible gains and securityvulnerabilities from the outcome.

B. Peer-to-Peer System

Towards routing attacks and spatial partitioning of Bitcoin,Apostolaki et al. [29] noticed that by hijacking fewer than100 border gateway protocol (BGP) prefixes in Bitcoin, anattacker can isolate up to 50% of the network’s hash rate.

24

Fork

Orphans

DNS

BGP

Eclipse

Majority

Selfish Mining

DDoS

Delay

Withholding

Timejacking

Finney

Injestion

Wallet Theft

Double-Spending

Cryptojacking

DoS (SC)

Reentracy

Replay

Overflow

Short Address

Balance

Attacks

Countermeasures

Joint Consensus

Increase Block Time

Time-Stamp Blocks

Routing Awareness

Peer Monitoring

2P-PoW

Enforce Submission

Synchronized Clocks

Increase Reward

Encrypted Blockchain

Backup, Insurance

OTS Signatures

MineGuard

Increase Block Size

Patch EVM

Secure Programming

Fig. 25. Relationship among various attacks on blockchains along withtheir countermeasures. Some attacks have common countermeasures whichprovides future directions towards a common cure.

They further analyzed that Bitcoin hosting is highly centralizedand 13 ISP’s have a view of more than 30% total miningtraffic. High centralization makes Bitcoin vulnerable to routingattacks, delay attacks, and DNS attacks. They also show thatover a 100 Bitcoin nodes become victims to BGP hijacks,every month. In this paper (section V-C), we verify the findingsof Apostolaki et al. [29] and show that over time, Bitcoinnetwork has further centralized with respect to ASes and ISPsoffering greater vulnerability to partitioning attacks.

Bradbury [191] reviewed various attacks on Bitcoin, namely,the 51% attack, code-based attacks, double-spending, and dusttransactions. Inspired from the Block Withholding (BWH)attack, Kwon et al. [89] presented the Fork After Withholding(FAW) attack which guarantees more rewards to the miningpools. In nash equilibrium, when two mining pools carryout BWH attack against each other, they both suffer a loss.However in current Bitcoin system, the rewards for FAWattacks are at least 56% more than BWH attacks.

Eyal and Sirer [110] modeled the mining process ofBlockchains and concluded that Bitcoin mining protocol is notincentive compatible. They also postulated that higher rewardscan lead to new miners joining the selfish mining pool and assuch, can lead to the possibility of a majority attack. Optimalselfish mining strategies have been studied by Sapirshtein etal. [139]. In their work, they analyzed the fraction of resourcesrequired to carry out a successful selfish mining attack. Theyalso provide bounds under which a Blockchain system can beconsidered secure against such an attack. Heilman [140] andSolat and Potop-Butucaru [142] proposed countermeasures for

selfish mining and block withholding. Heilman used unforge-able timestamps to raise the threshold of mining power to carryout selfish mining. Bastiaan [31] proposed a defense againstthe 51% attack by a stochastic analysis of two phased proof-of-work (2P-PoW), initially proposed by by Eyal and Sirer [192].2P-PoW prevents the hash rate of a mining pool from growingbeyond a limit. It does so by forcing the pool owners to eitherreduce their hash power or give up their private keys.

The domain of DDoS attacks on Blockchains and mempoolsremain an open problem and as such, countermeasures arebeing proposed which include: increasing throughput, increas-ing block size, and limiting the size of the transactions. SinceDDoS attacks manifest themselves in a different way in a peer-to-peer architecture, as opposed to a centralized system, theirprevention also requires non-conventional approaches [33].

C. Blockchain Application Attacks

Prior work has been done to look in to the attack av-enues related to the Blockchain applications including, double-spending, smart contracts, wallet thefts etc.. However, asnew applications are emerging, and Blockchains are evolvinginto Blockchain 3.0, their attack surface is broadening andposing new challenges for security and privacy. Rosenfeld[193] performed quantitative analysis on successful double-spending scheme under varying hash rate and number ofconfirmations. Solà et al. [53] use a modified signature schemethat exposes the private key of the double-spender in fasttransactions. Their proposed method protects an optimisticuser in Bitcoin who might be willing to deliever the productbefore the confirmation of the received transaction. Atzei etal. [46] analyzed possible attacks on Ethereum smart contractswith emphasis on the DAO attacks. They categorize theattacks based on the vulnerabilities associated with Ethereumprogramming language “Solidity”, Ethereum Virtual Machine(EVM), and the Ethereum Blockchain. Chen et al. [194]introduced an adaptive gas cost mechanism for Ethereum todefend against under-priced denial-of-service attacks. Luu etal. [195], investigated various possibilities through which anadversary can compromise smart contracts in Ethereum. Theyalso developed a symbolic execution tool OYENTE, whichactively finds and patches bugs in Ethereum smart contracts.

To observe Blockchain ingestion attacks and privacy leakageon Bitcoin, Fanti and Viswanath [196] studied the anonymityproperties of Bitcoin’s peer-to-peer and concluded that thenetwork has weak security properties. To enhance privacy andanonymization in Bitcoin, Ziegeldorf et al. [197] proposeddecentralized mixing services and shuffle protocols that reducethe chances of transaction tractability. Although conventionalattacks on Blockchains have been addressed by the commu-nity, new attacks such as cryptojacking and mempool floodinghave not been explored in depth. By drawing attention to themin this paper, we hope that active research will be carried ourto build countermeasures for these attacks.

VIII. DISCUSSION AND OPEN DIRECTIONS

Blockchains have become popular in recent years owing tothe increasing use of decentralized systems and the growingneed for tamper-proof data management. As such, they are

25

being used in several domains such as IoT, health care,electronic voting, e-government solutions, and supply chain[198]–[205]. However, prior to the integration of such legacysystems with Blockchains, it is pertinent to fully understandtheir security properties and the attack surface. It might bepossible that a conventional application, hoping to improve itssecurity model, may further be exposed to a higher risk byusing Blockchains. For example, delay-sensitive applicationsin supply chains cannot afford unusual latency in transactionpropagation and data-sensitive applications such as electronicvoting cannot afford a double-spent transaction. While theseattacks might be infeasible in conventional client-server model,using Blockchains might create new attack avenues for them.An adversary can launch consensus delay attacks to stallinformation propagation in the supply chain or create a double-spent transaction to invalidate the vote of a legitimate user.Moreover, as mentioned in section IV, once a fraudulentactivity is part of the Blockchain, the system will require amajor hard fork to reverse the transaction. Therefore, the useof Blockchains may bring new attack avenues on an otherwisesecure application. In the light of these changes, we believeit is important and timely to perform a systematic treatmentof Blockchain attack surface to expose its vulnerabilities andoutline new threat models for emerging applications. As anoutcome of our research, in the following, we discuss the keylessons learned as well as the open directions that can navigatethe future research.

A. Key Lessons

From our analysis, we noticed that the peer-to-peer ar-chitecture of Blockchains is the most dominant class of theBlockchain attack surface. In public Blockchains particularly,the topological asymmetry of the network can be easilyexploited to compromise the system. Moreover, and since thepublic Blockchains are permissionless, the network remainsimpartial towards legitimate users as well as the adversary.This property further weakens the security model since theadversary has an open access to all the resources.

Moreover, the network layer allows external entities toinfluence the internal operations of the Blockchain application.For example, an ISP, external to the Blockchain network, canhijack BGP prefixes to isolate peers. If such an attack islaunched against a mining pool, the hash rate of the networkwill be affected leading to transaction stall. Other externaladversaries include competing Blockchain applications, nationstates, cloud service providers, and DNS servers, that candisrupt the flow of traffic to affect the activities of the targetBlockchain application. While the effect of external entitiescan be reduced by using private Blockchains, however, thismay only partially solve the problem. Private Blockchains canstrengthen the network conditions by limiting the exposure ofsystem information, however, they also limit the scope of theapplication by allowing selective peers to participate.

Another takeaway from our work is the need to developenergy efficient and secure consensus protocols that maysubstitute PoW and PoS. Through Bitcoin, we have learnedthat PoW is highly energy inefficiency. Moreover, PoW alsoleads to the race conditions in Blockchains in which miners

compete for block rewards [206]. The race condition eventu-ally facilitates attacks such as selfish mining, the 51% attack,double-spending, forks, and stale blocks. To address the energyinefficiency and avoid race conditions, PoS has been proposedthat uses an auction process for block mining. However, wehave shown that PoS can create network centralization andunfairness in system. Although PBFT has served well as analternative to PoS and PoW in private Blockchains, however, itsuffers from high message complexity and low scalability. Thisstands as a major challenge for its usage in public Blockchains.

We have also shown that the increasing programming flex-ibility of smart contracts have made conventional Blockchainapplications more vulnerable. In Ethereum, for example, thereentrancy attack and the overflow attack can be launched tosteal the user’s balance. Such attacks cannot be launched onBitcoin, Ripple, and Zcash which do not offer programmingflexibility to users. Additionally, we have reported that theuse of a Blockchains at the application layer also createsnew attack avenues. For example, by exploiting the open-source client software, an attacker can get access to his privatekeys and balance. Therefore, the application-oriented use ofBlockchains needs to be carefully addressed to avoid attacks.

In summary, the key takeaways of our work point towards:1) more secure deployment of Blockchains in distributedenvironment, 2) development of fair and efficient consensusalgorithms, and 3) careful interaction of Blockchain layer withthe application layer to avoid vulnerabilities and attacks.

B. Open Challenges

Some of the open challenges in the Blockchains attacksurface are shown in Table IX. It can be observed that routingattacks do not have effective countermeasures and currentBlockchain applications have not taken initiatives to addressthem. For example, as shown in Table VII, if a maliciousISP hijacks ASes owned by Alibaba, it can hijack more than50% of the Bitcoin hash rate. As a result, block generation inBitcoin will stall, leading to delays in transaction confirmation.If we analyze the spatial behavior of Bitcoin [105], weobserve an increase in the centralization of nodes over time,indicating that the network is not responding to the threats of ahijack. Also shown in Table IX, certain policies of Blockchainapplications have created attack avenues that remain an openproblem. In Bitcoin and Ethereum, the block size limit andthe block generation time have led to flooding attacks anddelays [33]. These applications should revise their policies toprevent such attacks. Furthermore, a developing problem thatmost Blockchain applications are likely to encounter in futureis their high storage footprint. Due to the append-only model,Blockchains linearly grow in size leading to a high storagecost. While this problem appears trivial in cryptocurrencies, itwill become significant when Blockchains will be introducedin data intensive applications such as supply chains. A naïvesolution is the use of payment channel networks to offload thetransaction activity from the main Blockchain [207], [208].However, the use of payment channels obscures the datatransparency on the main Blockchain and may also suffer fromprivacy issues. Therefore, more research is required to comeup with effective solutions.

26

IX. CONCLUSION

In this paper, we explore the attack surface of Blockchaintechnology. We attribute attacks to the cryptographic con-structs of the blockchain, the underlying communication ar-chitecture, and the context in which they are applied. Indoing so, we highlight major threats and ongoing defenseresearch activities. We believe that various attacks againstBlockchain can be still launched, not withstanding the currentand existing defenses, and that some of those attacks can beused to facilitate several others. By outlining these attacks andsurveying their countermeasures, we highlight new researchdirections that need to be pursued towards more secure andeffective use of Blockchains.Acknowledgement. This work is supported by Air ForceMaterial Command award FA8750-16-0301.

REFERENCES

[1] L. Mauri, S. Cimato, and E. Damiani, “A comparative analysisof current cryptocurrencies,” Proceedings of the 4th InternationalConference on Information Systems Security and Privacy, ICISSP, Funchal, Madeira - Portugal, Jan. 2018, pp. 127–138. [Online].Available: https://doi.org/10.5220/0006648801270138

[2] G. Danezis and S. Meiklejohn, “Centrally banked cryptocurrencies,”in Proceedings of the 2016 Annual Network and Distributed SystemSecurity Symposium (NDSS), San Diego, CA, Feb. 2016. [Online].Available: http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/centrally-banked-cryptocurrencies.pdf

[3] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, andE. W. Felten, “Research perspectives and challenges for bitcoin andcryptocurrencies,” IACR Cryptology ePrint Archive, vol. 2015, p. 261,2015. [Online]. Available: http://eprint.iacr.org/2015/261

[4] A. E. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:The blockchain model of cryptography and privacy-preserving smartcontracts,” in Proceedings of the 37th IEEE Symposium on Securityand Privacy (Oakland), San Jose, CA, May 2016, pp. 839–858.[Online]. Available: https://doi.org/10.1109/SP.2016.55

[5] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi,G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Z. Béguelin, “Formal verificationof smart contracts: Short paper,” in Proceedings of the 23rdACM Conference on Computer and Communications Security(CCS), Vienna, Austria, Oct. 2016, pp. 91–96. [Online]. Available:http://doi.acm.org/10.1145/2993600.2993611

[6] P. K. Sharma, S. Rathore, and J. H. Park, “Distarch-scnet:Blockchain-based distributed architecture with li-fi communicationfor a scalable smart city network,” IEEE Consumer ElectronicsMagazine, vol. 7, no. 4, pp. 55–64, 2018. [Online]. Available:https://doi.org/10.1109/MCE.2018.2816745

[7] K. Fan, Y. Ren, Y. Wang, H. Li, and Y. Yang, “Blockchain-basedefficient privacy preserving and data sharing scheme of content-centricnetwork in 5g,” IET Communications, vol. 12, no. 5, pp. 527–532,2018. [Online]. Available: https://doi.org/10.1049/iet-com.2017.0619

[8] R. Guo, H. Shi, Q. Zhao, and D. Zheng, “Secure attribute-basedsignature scheme with multiple authorities for blockchain in electronichealth records systems,” IEEE Access, vol. 6, pp. 11 676–11 686, 2018.[Online]. Available: https://doi.org/10.1109/ACCESS.2018.2801266

[9] D. Rakic, “Blockchain technology in healthcare,” in Proceedings ofthe 4th International Conference on Information and CommunicationTechnologies for Ageing Well and e-Health, Funchal, Madeira,Portugal, March 2018., pp. 13–20. [Online]. Available: https://doi.org/10.5220/0006531600130020

[10] E. F. Jesus, V. R. L. Chicarino, C. V. N. de Albuquerque, and A. A.de A. Rocha, “A survey of how to use blockchain to secure internet ofthings and the stalker attack,” Security and Communication Networks,vol. 2018, pp. 9 675 050:1–9 675 050:27, 2018. [Online]. Available:https://doi.org/10.1155/2018/9675050

[11] P. K. Sharma, S. Singh, Y. Jeong, and J. H. Park, “Distblocknet:A distributed blockchains-based secure SDN architecture for iotnetworks,” IEEE Communications Magazine, vol. 55, no. 9, pp.78–85, 2017. [Online]. Available: https://goo.gl/UBv1Sf

[12] H. Hyvärinen, M. Risius, and G. Friis, “A blockchain-based approachtowards overcoming financial fraud in public sector services,” Business& Information Systems Engineering, vol. 59, no. 6, pp. 441–456,2017. [Online]. Available: https://doi.org/10.1007/s12599-017-0502-4

[13] F. Holotiuk, F. Pisani, and J. Moormann, “The impact of blockchaintechnology on business models in the payments industry,” in TowardsThought Leadership in Digital Transformation: 13. InternationaleTagung Wirtschaftsinformatik, St.Gallen, Switzerland, Feb, 2017.[Online]. Available: http://aisel.aisnet.org/wi2017/track09/paper/6

[14] E. Heilman, F. Baldimtsi, and S. Goldberg, “Blindly signedcontracts: Anonymous on-blockchain and off-blockchain bitcointransactions,” in Financial Cryptography and Data Security -International Workshops, BITCOIN, VOTING, and WAHC, ChristChurch, Barbados, Feb 2016,, pp. 43–60. [Online]. Available:https://doi.org/10.1007/978-3-662-53357-4_4

[15] G. G. Dagher, P. B. Marella, M. Milojkovic, and J. Mohler,“Broncovote: Secure voting system using ethereum’s blockchain,”in Proceedings of the 4th International Conference on InformationSystems Security and Privacy, ICISSP, Funchal, Madeira - Portugal,Jan 2018, pp. 96–107. [Online]. Available: https://doi.org/10.5220/0006609700960107

[16] F. S. Hardwick, R. N. Akram, and K. Markantonakis, “E-votingwith blockchain: An e-voting protocol with decentralisation andvoter privacy,” CoRR, vol. abs/1805.10258, 2018. [Online]. Available:http://arxiv.org/abs/1805.10258

[17] M. M. Eljazzar, M. A. Amr, S. S. Kassem, and M. Ezzat, “Mergingsupply chain and blockchain technologies,” Computing ResearchRepository (CoRR), vol. abs/1804.04149, 2018. [Online]. Available:https://goo.gl/5wMVJS

[18] G. Baruffaldi and H. Sternberg, “Chains in chains - logic andchallenges of blockchains in supply chains,” in 51st HawaiiInternational Conference on System Sciences (HICSS), HiltonWaikoloa Village, Hawaii, USA, Jan 2018. [Online]. Available:http://aisel.aisnet.org/hicss-51/in/digital_supply_chain/3

[19] N. Fotiou and G. C. Polyzos, “Decentralized name-based securityfor content distribution using blockchains,” in IEEE Conference onComputer Communications Workshops, INFOCOM, San Francisco,CA, USA, Apr 2016, pp. 415–420. [Online]. Available: https://doi.org/10.1109/INFCOMW.2016.7562112

[20] M. Zhang and Y. Ji, “Blockchain for healthcare records: A dataperspective,” PeerJ PrePrints, vol. 6, p. e26942, 2018. [Online].Available: https://doi.org/10.7287/peerj.preprints.26942v1

[21] M. Mettler, “Blockchain technology in healthcare: The revolution startshere,” in 18th IEEE International Conference on e-Health Networking,Applications and Services, Munich, Germany, Sep 2016, pp. 1–3.[Online]. Available: https://doi.org/10.1109/HealthCom.2016.7749510

[22] G. Zyskind, O. Nathan, and A. Pentland, “Decentralizing privacy:Using blockchain to protect personal data,” in 2015 IEEE Symposiumon Security and Privacy Workshops, SPW, San Jose, CA, USA, May2015, pp. 180–184. [Online]. Available: https://goo.gl/kTNim3

[23] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell,A. Miller, A. Poelstra, J. Timón, and P. Wuille, “Enabling blockchaininnovations with pegged sidechains,” 2014.

[24] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Online,https://bitcoin.org/bitcoin.pdf, 2008.

[25] T. Ruffing, P. Moreno-Sanchez, and A. Kate, “P2P mixing andunlinkable bitcoin transactions,” in Proceedings of the 2017Annual Network and Distributed System Security Symposium(NDSS), San Diego, CA, Feb.–Mar. 2017. [Online]. Available:https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/p2p-mixing-and-unlinkable-bitcoin-transactions/

[26] I. Eyal, “The miner’s dilemma,” in Proceedings of the 36thIEEE Symposium on Security and Privacy (Oakland). San Jose,CA: IEEE, May 2015, pp. 89–103. [Online]. Available: https://doi.org/10.1109/SP.2015.13

[27] C. Decker and R. Wattenhofer, “Information propagation in the bitcoinnetwork,” in 13th IEEE International Conference on Peer-to-PeerComputing, IEEE P2P , Trento, Italy, Sep 2013, pp. 1–10. [Online].Available: https://doi.org/10.1109/P2P.2013.6688704

[28] —, “Bitcoin developer guide.” [Online]. Available: https://bitcoin.org/en/developer-guidepeer-discovery

[29] M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking bitcoin:Routing attacks on cryptocurrencies,” in Proceedings of the 38thIEEE Symposium on Security and Privacy (Oakland). San Jose,CA: IEEE, May 2017, pp. 375–392. [Online]. Available: https://doi.org/10.1109/SP.2017.29

[30] Y. Marcus, E. Heilman, and S. Goldberg, “Low-resource eclipseattacks on ethereum’s peer-to-peer network,” IACR CryptologyePrint Archive, vol. 2018, p. 236, 2018. [Online]. Available:http://eprint.iacr.org/2018/236

27

[31] M. Bastiaan, “Preventing the 51%-attack: a stochastic analysis oftwo phase proof of work in bitcoin,” 2015. [Online]. Available:https://goo.gl/nJsMzV

[32] T. Leelavimolsilp, L. Tran-Thanh, and S. Stein, “On the preliminaryinvestigation of selfish mining strategy with multiple selfishminers,” CoRR, vol. abs/1802.02218, 2018. [Online]. Available:http://arxiv.org/abs/1802.02218

[33] M. Saad, M. T. Thai, and A. Mohaisen, “POSTER: deterringddos attacks on blockchain-based cryptocurrencies through mempooloptimization,” in Proceedings of Asia Conference on Computer andCommunications Security, ASIACCS, Incheon, Republic of Korea, Jun2018, pp. 809–811. [Online]. Available: https://goo.gl/4kgiCM

[34] I. Eyal, A. E. Gencer, E. G. Sirer, and R. van Renesse, “Bitcoin-ng:A scalable blockchain protocol,” in Proceedings of the 13th USENIXSymposium on Networked Systems Design and Implementation(NSDI), Santa Clara, CA, Mar. 2016, pp. 45–59. [Online]. Available:https://goo.gl/VGN4yw

[35] C. A. Vyas and M. Lunagaria, “Security concerns and issues forbitcoin,” in the proceedings of National Conference cum Workshop onBioinformatics and Computational Biology, NCWBCB, 2014.

[36] H. Finney, “The finney attack(the bitcoin talk forum).”[37] M. Fleder, M. S. Kester, and S. Pillai, “Bitcoin transaction graph

analysis,” CoRR, vol. abs/1502.01657, 2015. [Online]. Available:http://arxiv.org/abs/1502.01657

[38] T. Bamert, C. Decker, R. Wattenhofer, and S. Welten, “Bluewallet: Thesecure bitcoin wallet,” in International Workshop on Security and TrustManagement. Springer, 2014, pp. 65–80.

[39] S. Dilhani, Elli, “Transaction verification model over double spendingfor peer-to-peer digital currency transactions based on Blockchainarchitecture,” 2012, pp. 24–31.

[40] R. Tahir, M. Huzaifa, A. Das, M. Ahmad, C. A. Gunter,F. Zaffar, M. Caesar, and N. Borisov, “Mining on someoneelse’s dime: Mitigating covert mining operations in clouds andenterprises,” in Proceedings of the 20th International Symposiumon Research in Attacks, Intrusions and Defenses (RAID), Atlanta,GA, USA, Sep. 2017, pp. 287–310. [Online]. Available: https://doi.org/10.1007/978-3-319-66332-6_13

[41] Ethereum, “Ethereum contract security techniques and tips.” [Online].Available: https://github.com/ethereum/wiki/wiki/Safety

[42] M. Grincalaitis, “The ultimate guide to audit a smart contract,” Sep2017. [Online]. Available: https://goo.gl/TD7suo

[43] S. Underwood, “Blockchain beyond bitcoin,” Commun. ACM,vol. 59, no. 11, pp. 15–17, 2016. [Online]. Available: http://doi.acm.org/10.1145/2994581

[44] X. Li, P. Jiang, T. Chen, X. Luo, and Q. Wen, “A survey on thesecurity of blockchain systems,” CoRR, vol. abs/1802.06993, 2018.[Online]. Available: http://arxiv.org/abs/1802.06993

[45] I.-C. Lin and T.-C. Liao, “A survey of blockchain security issues andchallenges.” IJ Network Security, vol. 19, no. 5, pp. 653–659, 2017.

[46] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attackson ethereum smart contracts sok,” in Proceedings of the 6thInternational Conference on Principles of Security and Trust -Volume 10204, 2017, pp. 164–186. [Online]. Available: https://doi.org/10.1007/978-3-662-54455-6_8

[47] M. C. K. Khalilov and A. Levi, “A survey on anonymity andprivacy in bitcoin-like digital cash systems,” IEEE CommunicationsSurveys and Tutorials, vol. 20, no. 3, pp. 2543–2585, 2018. [Online].Available: https://doi.org/10.1109/COMST.2018.2818623

[48] D. Siegel, “Understanding The DAO Attack,” https://www.coindesk.com/understanding-dao-hack-journalists/.

[49] C. Baldwin, “Bitcoin worth 72 million stolen from bitfinex exchangein Hong Kong,” http://reut.rs/2gc7iQ9, Aug 2016.

[50] F. Memoria, “700 million stuck in 115,000 unconfirmed bitcoin trans-actions,” Nov 2017. [Online]. Available: https://www.cryptocoinsnews.com/700-million-stuck-115000-unconfirmed-bitcoin-transactions/

[51] R. McMillan, “The inside story of mt. gox, bitcoin’s 460 million usddisaster,” 2014. [Online]. Available: https://www.wired.com/2014/03/bitcoin-exchange/

[52] B. Community, “The 51% attack,” October 2017. [Online]. Available:https://learncryptography.com/cryptocurrency/51-attack

[53] C. Pérez-Solà, S. Delgado-Segura, G. Navarro-Arribas, andJ. Herrera-Joancomartí, “Double-spending prevention for bitcoinzero-confirmation transactions,” IACR Cryptology ePrint Archive, vol.2017, p. 394, 2017. [Online]. Available: http://eprint.iacr.org/2017/394

[54] G. O. Karame, E. Androulaki, and S. Capkun, “Double-spendingfast payments in bitcoin,” in Proceedings of the 19th ACMConference on Computer and Communications Security (CCS),Raleigh, NC, Oct. 2012, pp. 906–917. [Online]. Available: http://doi.acm.org/10.1145/2382196.2382292

[55] M. Pilkington, “Blockchain technology: principles and applications,”Research handbook on digital transformations, p. 225, 2016.

[56] A. Dmitrienko, D. Noack, and M. Yung, “Secure wallet-assisted offlinebitcoin payments with double-spender revocation,” in Proceedingsof Asia Conference on Computer and Communications Security(ASIACCS), Abu Dhabi, United Arab Emirates, Apr 2017, pp. 520–531. [Online]. Available: http://doi.acm.org/10.1145/3052973.3052980

[57] M. Conti, S. K. E, C. Lal, and S. Ruj, “A survey on security andprivacy issues of bitcoin,” CoRR, vol. abs/1706.00916, 2017. [Online].Available: http://arxiv.org/abs/1706.00916

[58] T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, and K. Tan,“BLOCKBENCH: A framework for analyzing private blockchains,”in International Conference on Management of Data, SIGMODConference, Chicago, IL, USA, May 2017, pp. 1085–1100. [Online].Available: https://doi.org/10.1145/3035918.3064033

[59] G. Baralla, S. Ibba, M. Marchesi, R. Tonelli, and S. Missineo,“A blockchain based system to ensure transparency and reliabilityin food supply chain,” in International Workshops on ParallelProcessing, Turin, Italy, Aug 2018, pp. 379–391. [Online]. Available:https://doi.org/10.1007/978-3-030-10549-5_30

[60] A. Ahmad, M. Saad, M. Bassiouni, and A. Mohaisen,“Towards blockchain-driven, secure and transparent audit logs,”in International Conference on Mobile and Ubiquitous Systems:Computing, Networking and Services, MobiQuitous, New YorkCity,USA, Nov 2018, pp. 443–448. [Online]. Available:https://doi.org/10.1145/3286978.3286985

[61] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks onethereum smart contracts sok,” in Proceedings of the 6th InternationalConference on Principles of Security and Trust - Volume 10204. NewYork, NY, USA: Springer-Verlag New York, Inc., 2017, pp. 164–186.[Online]. Available: https://doi.org/10.1007/978-3-662-54455-6_8

[62] A. Ouaddah, A. A. E. Kalam, and A. A. Ouahman, “Fairaccess: a newblockchain-based access control framework for the internet of things,”Security and Communication Networks, vol. 9, no. 18, pp. 5943–5964,2016. [Online]. Available: https://doi.org/10.1002/sec.1748

[63] K. Christidis and M. Devetsikiotis, “Blockchains and smart contractsfor the internet of things,” IEEE Access, vol. 4, pp. 2292–2303, 2016.[Online]. Available: https://doi.org/10.1109/ACCESS.2016.2566339

[64] A. Miller, I. Bentov, R. Kumaresan, and P. McCorry, “Sprites: Paymentchannels that go faster than lightning,” CoRR, vol. abs/1702.05812,2017. [Online]. Available: http://arxiv.org/abs/1702.05812

[65] J. Lind, O. Naor, I. Eyal, F. Kelbert, P. R. Pietzuch, and E. G. Sirer,“Teechain: Reducing storage costs on the blockchain with offlinepayment channels,” in Proceedings of the 11th ACM InternationalSystems and Storage Conference, (SYSTOR) HAIFA, Israel, Jun 2018, p.125. [Online]. Available: http://doi.acm.org/10.1145/3211890.3211904

[66] L. Lundbaek, A. C. D’Iddio, and M. Huth, “Optimizing governedblockchains for financial process authentications,” CoRR, vol.abs/1612.00407, 2016. [Online]. Available: https://goo.gl/DwDEkW

[67] M. Minaei, P. Moreno-Sanchez, and A. Kate, “R3C3: cryptographicallysecure censorship resistant rendezvous using cryptocurrencies,” IACRCryptology ePrint Archive, vol. 2018, p. 454, 2018. [Online].Available: https://eprint.iacr.org/2018/454

[68] G. Bissias, B. N. Levine, A. P. Ozisik, G. Andresen, andA. Houmansadr, “An analysis of attacks on blockchain consensus,”CoRR, vol. abs/1610.07985, 2016. [Online]. Available: http://arxiv.org/abs/1610.07985

[69] S. Goldberg and E. Heilman, “Technical perspective: The rewards ofselfish mining,” Commun. ACM, vol. 61, no. 7, p. 94, 2018. [Online].Available: https://doi.org/10.1145/3213006

[70] F. Ritz and A. Zugenmaier, “The impact of uncle rewardson selfish mining in ethereum,” in IEEE European Symposiumon Security and Privacy Workshops,EuroS&P W, London, UnitedKingdom. IEEE, Apr 2018, pp. 50–57. [Online]. Available:https://doi.org/10.1109/EuroSPW.2018.00013

[71] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry,S. Meiklejohn, and G. Danezis, “Consensus in the age ofblockchains,” CoRR, vol. abs/1711.03936, 2017. [Online]. Available:http://arxiv.org/abs/1711.03936

[72] M. Bellare and P. Rogaway, “Random oracles are practical: Aparadigm for designing efficient protocols,” in Proceedings of the1st ACM Conference on Computer and Communications Security,Fairfax, Virginia, USA, Nov 1993, pp. 62–73. [Online]. Available:http://doi.acm.org/10.1145/168588.168596

[73] A. Juels and J. G. Brainard, “Client puzzles: A cryptographiccountermeasure against connection depletion attacks,” in Proceedingsof the Network and Distributed System Security Symposium, (NDSS),San Diego, California, USA, 1999. [Online]. Available: http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/juels.pdf

28

[74] A. Castor, “A short guide to Blockchain consensus protocols,” May2017. [Online]. Available: https://goo.gl/kdR2r4

[75] M. Saad and A. Mohaisen, “Towards characterizing blockchain-basedcryptocurrencies for highly-accurate predictions,” in IEEE Conferenceon Computer Communications Workshops, INFOCOM Workshops,Honolulu, HI, USA. IEEE, April 2018, pp. 704–709. [Online].Available: https://doi.org/10.1109/INFCOMW.2018.8406859

[76] D. Fullmer and A. S. Morse, “Analysis of difficulty control in bitcoinand proof-of-work blockchains,” CoRR, vol. abs/1812.10792, 2018.[Online]. Available: http://arxiv.org/abs/1812.10792

[77] M. Bartoletti, S. Lande, and A. S. Podda, “A proof-of-stake protocolfor consensus on bitcoin subchains,” in In Financial Cryptography andData Security - FC Workshops, Sliema, Malta, Apr 2017, pp. 568–584.[Online]. Available: https://doi.org/10.1007/978-3-319-70278-0_36

[78] W. Y. M. M. Thin, N. Dong, G. Bai, and J. S. Dong, “Formal analysisof a proof-of-stake blockchain,” in 23rd International Conference onEngineering of Complex Computer Systems, ICECCS 2018, Melbourne,Australia, December 12-14, 2018. IEEE, 2018, pp. 197–200. [Online].Available: https://doi.org/10.1109/ICECCS2018.2018.00031

[79] G. Gui, A. Hortaçsu, and J. Tudon, “A memo on the proof-of-stakemechanism,” CoRR, vol. abs/1807.09626, 2018. [Online]. Available:http://arxiv.org/abs/1807.09626

[80] T. Duong, A. Chepurnoy, L. Fan, and H. Zhou, “Twinscoin: Acryptocurrency via proof-of-work and proof-of-stake,” in Proceedingsof the 2nd ACM Workshop on Blockchains, Cryptocurrencies, andContracts, BCC@AsiaCCS 2018, Incheon, Republic of Korea, June 4,2018, S. V. Lokam, S. Ruj, and K. Sakurai, Eds. ACM, 2018, pp.1–13. [Online]. Available: https://doi.org/10.1145/3205230.3205233

[81] S. D. Angelis, L. Aniello, R. Baldoni, F. Lombardi, A. Margheri,and V. Sassone, “PBFT vs proof-of-authority: Applying the CAPtheorem to permissioned blockchain,” in Proceedings of the SecondItalian Conference on Cyber Security, Milan, Italy, February 6th - to- 9th, 2018., ser. CEUR Workshop Proceedings, E. Ferrari, M. Baldi,and R. Baldoni, Eds., vol. 2058. CEUR-WS.org, 2018. [Online].Available: http://ceur-ws.org/Vol-2058/paper-06.pdf

[82] H. Sukhwani, J. M. Martínez, X. Chang, K. S. Trivedi, and A. Rindos,“Performance modeling of PBFT consensus process for permissionedblockchain network (hyperledger fabric),” in 36th IEEE Symposium onReliable Distributed Systems, SRDS 2017, Hong Kong, Hong Kong,September 26-29, 2017. IEEE Computer Society, 2017, pp. 253–255.[Online]. Available: https://doi.org/10.1109/SRDS.2017.36

[83] S. Kim, Y. Kwon, and S. Cho, “A survey of scalability solutionson blockchain,” in International Conference on Information andCommunication Technology Convergence, ICTC 2018, Jeju Island,Korea (South). IEEE, Oct 2018, pp. 1204–1207. [Online]. Available:https://doi.org/10.1109/ICTC.2018.8539529

[84] A. Chauhan, O. P. Malviya, M. Verma, and T. S. Mor, “Blockchainand scalability,” in International Conference on Software Quality,Reliability and Security Companion, QRS Companion, Lisbon,Portugal. IEEE, July 2018, pp. 122–128. [Online]. Available:https://doi.org/10.1109/QRS-C.2018.00034

[85] J. A. Garay and A. Kiayias, “Sok: A consensus taxonomy in theblockchain era,” IACR Cryptology ePrint Archive, vol. 2018, p. 754,2018. [Online]. Available: https://eprint.iacr.org/2018/754

[86] C. Cachin and M. Vukolic, “Blockchain consensus protocols inthe wild (keynote talk),” in International Symposium on DistributedComputing, DISC, Vienna, Austria, Oct 2017, pp. 1:1–1:16. [Online].Available: https://doi.org/10.4230/LIPIcs.DISC.2017.1

[87] O. Konashevych and M. Poblet, “Is blockchain hashing an effectivemethod for electronic governance?” in Annual Conference onLegal Knowledge and Information Systems Annual Conference,Groningen, The Netherlands, ser. Frontiers in Artificial Intelligenceand Applications, M. Palmirani, Ed., vol. 313. IOS Press, Dec2018, pp. 195–199. [Online]. Available: https://doi.org/10.3233/978-1-61499-935-5-195

[88] F. Chen, Z. Liu, Y. Long, Z. Liu, and N. Ding, “Secure scheme againstcompromised hash in proof-of-work blockchain,” in InternationalConference on Network and System Security, Hong Kong, China,ser. Lecture Notes in Computer Science, M. H. Au, S. Yiu,J. Li, X. Luo, C. Wang, A. Castiglione, and K. Kluczniak, Eds.,vol. 11058. Springer, Aug 2018, pp. 1–15. [Online]. Available:https://doi.org/10.1007/978-3-030-02744-5_1

[89] Y. Kwon, D. Kim, Y. Son, E. Vasserman, and Y. Kim, “Be selfish andavoid dilemmas: Fork after withholding (faw) attacks on bitcoin,” inProceeding of ACM CCS, Dallas, TX, Oct.–Nov. 2017, pp. 195–209.[Online]. Available: http://doi.acm.org/10.1145/3133956.3134019

[90] M. A. Javarone and C. S. Wright, “From bitcoin to bitcoincash: a network analysis,” in Proceedings of the 1st Workshop

on Cryptocurrencies and Blockchains for Distributed Systems,CRYBLOCK@MobiSys, Munich, Germany, Jun 2018, pp. 77–81.[Online]. Available: https://goo.gl/AYJ68C

[91] T. Hanke, “Asicboost - A speedup for bitcoin mining,” CoRR, vol.abs/1604.00575, 2016. [Online]. Available: https://goo.gl/izrW1m

[92] L. A. de la Porte, “The bitcoin transaction system,” Utrecht. Nether-lands, 2012.

[93] “Bitcoin block explorer - Blockchain,” http://bit.ly/1srPhPs.[94] B. Community, “Difficulty in Bitcoin.” [Online]. Available: https:

//en.bitcoin.it/wiki/Difficulty[95] Greene, “A brief history of bitcoin mining hardware,” Feb

2018. [Online]. Available: https://thenextweb.com/hardfork/2018/02/02/a-brief-history-of-bitcoin-mining-hardware/

[96] J. Becker, D. Breuker, T. Heide, J. Holler, H. P. Rauer, andR. Böhme, “Can we afford integrity by proof-of-work? scenariosinspired by the bitcoin currency,” in The Economics of InformationSecurity and Privacy, 2013, pp. 135–156. [Online]. Available:https://doi.org/10.1007/978-3-642-39498-0_7

[97] A. de Vries, “Bitcoin’s growing energy problem,” Joule, vol. 2, no. 5,pp. 801–805, 2018.

[98] A. Kang, “Bitcoin’s growing pains: Intermediation and the need for aneffective loss allocation mechanism,” Mich. Bus. & Entrepreneurial L.Rev., vol. 6, p. 263, 2016.

[99] Digiconomist, “Bitcoin energy consumption index,” 2018. [Online].Available: https://digiconomist.net/bitcoin-energy-consumption

[100] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency withproof-of-stake,” self-published paper, August, vol. 19, 2012.

[101] P. Gazi, A. Kiayias, and A. Russell, “Stake-bleeding attacks onproof-of-stake blockchains,” IACR Cryptology ePrint Archive, vol. 5,p. 248, 2018. [Online]. Available: http://eprint.iacr.org/2018/248

[102] A. Kiayias, I. Konstantinou, A. Russell, B. David, and R. Oliynykov,“A provably secure proof-of-stake blockchain protocol,” IACRCryptology ePrint Archive, vol. 2016, p. 889, 2016. [Online].Available: http://eprint.iacr.org/2016/889

[103] P.-Y. Chang, M.-S. Hwang, and C.-C. Yang, “A blockchain-basedtraceable certification system,” in International Conference on Securitywith Intelligent Computing and Big-data. Springer, 2017, p. 363.

[104] Y. Yang, “Linbft: Linear-communication byzantine fault tolerancefor public blockchains,” CoRR, vol. abs/1807.01829, 2018. [Online].Available: http://arxiv.org/abs/1807.01829

[105] Bitnodes, “Global bitcoin nodes distribution.” [Online]. Available:https://bitnodes.earn.com/

[106] R. Pass and E. Shi, “Thunderella: Blockchains with optimisticinstant confirmation,” in International Conference on the Theoryand Applications of Cryptographic Techniques, Tel Aviv, Israel, ser.Lecture Notes in Computer Science, J. B. Nielsen and V. Rijmen,Eds., vol. 10821. Springer, April 2018, pp. 3–33. [Online]. Available:https://doi.org/10.1007/978-3-319-78375-8_1

[107] T. Rocket, “Snowflake to avalanche: A novel metastable consensusprotocol family for cryptocurrencies,” 2018.

[108] C. Berger and H. P. Reiser, “Scaling byzantine consensus: A broadanalysis,” in Workshop on Scalable and Resilient Infrastructures forDistributed Ledgers, Rennes, France. ACM, Dec 2018, pp. 13–18.[Online]. Available: https://doi.org/10.1145/3284764.3284767

[109] Y. Velner, J. Teutsch, and L. Luu, “Smart contracts make bitcoinmining pools vulnerable,” in Financial Cryptography and DataSecurity Sliema, Malta, April 2017, pp. 298–316. [Online]. Available:https://doi.org/10.1007/978-3-319-70278-0_19

[110] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining isvulnerable,” in Financial Cryptography and Data Security. Springer,2014, pp. 436–454.

[111] C. Grunspan and R. Pérez-Marco, “On profitability of selfishmining,” CoRR, vol. abs/1805.08281, 2018. [Online]. Available:http://arxiv.org/abs/1805.08281

[112] K. Nayak, S. Kumar, A. Miller, and E. Shi, “Stubborn mining:Generalizing selfish mining and combining with an eclipse attack,”in IEEE European Symposium on Security and Privacy, EuroS&P2016, Saarbrücken, Germany, March 21-24, 2016, 2016, pp. 305–320.[Online]. Available: https://doi.org/10.1109/EuroSP.2016.32

[113] “Thetangle.org - iota tangle explorer and statistics.” [Online].Available: https://thetangle.org/

[114] L. Bahack, “Theoretical bitcoin attacks with less than half of thecomputational power (draft),” arXiv preprint arXiv:1312.7013, 2013.

[115] Nicehash, “Largest crypto-mining marketplace.” [Online]. Available:https://www.nicehash.com/

[116] B. Community, “Pow 51% attack cost.” [Online]. Available:https://www.crypto51.app/

[117] J. Roberts, “Bitcoin spinoff hacked in rare ’51% attack’.” [Online].Available: http://fortune.com/2018/05/29/bitcoin-gold-hack/

29

[118] A. R. Kang, J. Spaulding, and A. Mohaisen, “Domain name systemsecurity and privacy: Old problems and new challenges,” CoRR, 2016.[Online]. Available: http://arxiv.org/abs/1606.07080

[119] L. Gao, “On inferring autonomous system relationships in theinternet,” IEEE/ACM Trans. Netw., vol. 9, no. 6, pp. 733–745, 2001.[Online]. Available: https://doi.org/10.1109/90.974527

[120] M. Kumar and S. Kumar, “Improving routing in large networks insideautonomous system,” Int. J. Systems Assurance Engineering andManagement, vol. 5, no. 3, pp. 383–390, 2014. [Online]. Available:https://doi.org/10.1007/s13198-013-0179-0

[121] A. Greenberg, “Hacker redirects traffic from 19 internet providers tosteal bitcoins,” Jun 2017. [Online]. Available: https://www.wired.com/2014/08/isp-bitcoin-theft/

[122] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg,“Eclipse attacks on bitcoin’s peer-to-peer network,” in USENIXSecurity Symposium, Washington, D.C., USA, Aug 2015, pp.129–144. [Online]. Available: https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman

[123] A. Wang, A. Mohaisen, and S. Chen, “An adversary-centricbehavior modeling of ddos attacks,” in 37th IEEE InternationalConference on Distributed Computing Systems, (ICDCS), Atlanta,GA, USA, Jun 2017, pp. 1126–1136. [Online]. Available: https://doi.org/10.1109/ICDCS.2017.213

[124] M. Vasek, M. Thornton, and T. Moore, “Empirical analysis of denial-of-service attacks in the bitcoin ecosystem,” in Financial Cryptographyand Data Security. Springer, 2014, pp. 57–71.

[125] P. Muncaster, “World’s largest bitcoin exchange bitfinex crippled byDDoS,” http://bit.ly/2kqo6HU, Jun 2017.

[126] C. Cimpanu, “Bitcoin trader hit by "severe DDoS attack" as bitcoinprice nears all-time high,” http://bit.ly/2lA5iT6, Feb 2017.

[127] Jeffrey Wilcke, “The ethereum network is currently undergoing a DoSattack,” http://bit.ly/2cwlB0D, Oct 2016.

[128] Vitalik Buterin, “Ethereum responds to recent DDoS attack,” http://bit.ly/2gcrn9d, Sep 2016.

[129] C. Mempool, “Report: Bitcoin (btc) mempool shows backloggedtransactions, increased fees if so?” Jun 2018. [Online]. Available:https://goo.gl/LsU6Hq

[130] M. Castro and B. Liskov, “Practical byzantine fault tolerance andproactive recovery,” ACM Trans. Comput. Syst., vol. 20, no. 4, pp. 398–461, 2002. [Online]. Available: https://doi.org/10.1145/571637.571640

[131] D. K. Tosh, S. Shetty, X. Liang, C. A. Kamhoua, K. A. Kwiat, andL. Njilla, “Security implications of Blockchain cloud with analysisof block withholding attack,” in Proceedings of the 17th IEEE/ACMInternational Symposium on Cluster, Cloud and Grid Computing.IEEE Press, 2017, pp. 458–467.

[132] Mark, “The finney attack,” Oct 2017. [Online]. Available: https://bitcoincoreacademy.com/the-finney-attack/

[133] S. Exchange, “What is a finney attack?” [Online]. Available: https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack

[134] L. Luu, R. Saha, I. Parameshwaran, P. Saxena, and A. Hobor,“On power splitting games in distributed computation: The case ofbitcoin pooled mining,” in IEEE 28th Computer Security FoundationsSymposium, CSF 2015, Verona, Italy, 13-17 July, 2015, 2015, pp.397–411. [Online]. Available: https://doi.org/10.1109/CSF.2015.34

[135] S. Exchange, “What is a block withholding attack?” [Online].Available: https://goo.gl/ccAsAi

[136] A. Gervais, H. Ritzdorf, G. O. Karame, and S. Capkun, “Tamperingwith the delivery of blocks and transactions in bitcoin,” in ACMSIGSAC Conference on Computer and Communications Security,Denver, CO, USA, Oct 2015, pp. 692–705. [Online]. Available:http://doi.acm.org/10.1145/2810103.2813655

[137] M. Castro and B. Liskov, “Practical byzantine fault tolerance,” inUSENIX Symposium on Operating Systems Design and Implementation(OSDI), New Orleans, Louisiana, USA, M. I. Seltzer and P. J. Leach,Eds. USENIX Association, Feb 1999, pp. 173–186. [Online].Available: https://dl.acm.org/citation.cfm?id=296824

[138] H. Xu, Y. Long, Z. Liu, Z. Liu, and D. Gu, “Dynamic practicalbyzantine fault tolerance,” in IEEE Conference on Communicationsand Network Security, CNS, Beijing, China. IEEE, May 2018, pp.1–8. [Online]. Available: https://doi.org/10.1109/CNS.2018.8433150

[139] A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish miningstrategies in bitcoin,” in Financial Cryptography and Data Security.Springer, 2016, pp. 515–532.

[140] E. Heilman, “One weird trick to stop selfish miners: Fresh bitcoins, asolution for the honest miner,” in Financial Cryptography and DataSecurity. Springer, 2014, pp. 161–162.

[141] N. T. Courtois and L. Bahack, “On subversive miner strategies andblock withholding attack in bitcoin digital currency,” arXiv preprintarXiv:1402.1718, 2014.

[142] S. Solat and M. Potop-Butucaru, “Zeroblock: Preventing selfish miningin bitcoin.” arXiv preprint arXiv:1605.02435, 2016.

[143] A. Miller, A. E. Kosba, J. Katz, and E. Shi, “Nonoutsourceablescratch-off puzzles to discourage bitcoin mining coalitions,” in ACMSIGSAC Conference on Computer and Communications Security,Denver, CO, USA, Oct 2015, pp. 680–691. [Online]. Available:http://doi.acm.org/10.1145/2810103.2813621

[144] M. Saad, L. Njilla, C. Kamhoua, and A. Mohaisen, “Counteringselfish mining in blockchains,” CoRR, 2018. [Online]. Available:https://www.cs.ucf.edu/~mohaisen/doc/cnc19bc.pdf

[145] B. Johnson, A. Laszka, J. Grossklags, M. Vasek, and T. Moore, “Game-theoretic analysis of DDoS attacks against bitcoin mining pools,” inFinancial Cryptography and Data Security. Springer, 2014, p. 72.

[146] J. Göbel and A. E. Krzesinski, “Increased block size and bitcoinblockchain dynamics,” in 27th International TelecommunicationNetworks and Applications Conference, ITNAC Melbourne, Australia,Nov 2017, pp. 1–6. [Online]. Available: https://goo.gl/rz4zoB

[147] P. Silva, “Dnssec: The antidote to DNS cache poisoning and other dnsattacks,” A F5 Networks, Inc. Technical Brief, 2009.

[148] T. Peng, C. Leckie, and K. Ramamohanarao, “Survey of network-baseddefense mechanisms countering the DoS and DDoS problems,” ACMComputing Surveys (CSUR), vol. 39, no. 1, p. 3, 2007.

[149] J. Etheridge and R. Anton, “System and method for detecting and coun-tering a network attack,” Sep. 13, 2002, US Patent App. 10/243,631.

[150] S. Bag, S. Ruj, and K. Sakurai, “Bitcoin block withholding attack:Analysis and mitigation,” IEEE Trans. Information Forensics andSecurity, vol. 12, no. 8, pp. 1967–1978, 2017. [Online]. Available:https://doi.org/10.1109/TIFS.2016.2623588

[151] S. Bag and K. Sakurai, “Yet another note on block withholdingattack on bitcoin mining pools,” in 19th International Conference onInformation Security ISC, Honolulu, HI, USA, Sep 2016, pp. 167–180.[Online]. Available: https://doi.org/10.1007/978-3-319-45871-7_11

[152] O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden, “Incentivecompatibility of bitcoin mining pool reward functions,” in 20thInternational Conference on Financial Cryptography and DataSecurity FC, Christ Church, Barbados, Feb 2016, pp. 477–498.[Online]. Available: https://doi.org/10.1007/978-3-662-54970-4_28

[153] M. Rosenfeld, “Analysis of bitcoin pooled mining reward systems,”CoRR, 2011. [Online]. Available: http://arxiv.org/abs/1112.4980

[154] G. S. Veronese, M. Correia, A. N. Bessani, L. C. Lung, andP. Veríssimo, “Efficient byzantine fault-tolerance,” IEEE Trans.Computers, vol. 62, no. 1, pp. 16–30, 2013. [Online]. Available:https://doi.org/10.1109/TC.2011.221

[155] T. Distler, C. Cachin, and R. Kapitza, “Resource-efficient byzantinefault tolerance,” IEEE Trans. Computers, vol. 65, no. 9, pp. 2807–2819,2016. [Online]. Available: https://doi.org/10.1109/TC.2015.2495213

[156] J. Liu, W. Li, G. O. Karame, and N. Asokan, “Scalablebyzantine consensus via hardware-assisted secret sharing,” IEEETrans. Computers, vol. 68, no. 1, pp. 139–151, 2019. [Online].Available: https://doi.org/10.1109/TC.2018.2860009

[157] C. Janze, “Are cryptocurrencies criminals best friends? examiningthe co-evolution of bitcoin and darknet markets,” in AmericasConference on Information Systems, AMCIS, Boston, USA,August 2017. [Online]. Available: http://aisel.aisnet.org/amcis2017/InformationSystems/Presentations/2

[158] R. Stokes, “Virtual money laundering: the case of bitcoin andthe linden dollar,” Information & Communications TechnologyLaw, vol. 21, no. 3, pp. 221–236, 2012. [Online]. Available:https://doi.org/10.1080/13600834.2012.744225

[159] S. Williams, “Bitcoin banned countries,” 2017, https://tinyurl.com/y8r5gdhl.

[160] G. O. Karame, E. Androulaki, M. Roeschlin, A. Gervais, andS. Capkun, “Misbehavior in bitcoin: A study of double-spending andaccountability,” ACM Trans. Inf. Syst. Secur., vol. 18, no. 1, pp. 2:1–2:32, 2015. [Online]. Available: http://doi.acm.org/10.1145/2732196

[161] M. Nadeau, “What is cryptojacking? how to prevent, detect, andrecover from it,” May 2018. [Online]. Available: https://goo.gl/DdGq1i

[162] R. Li and C. Kyle, “What is cryptojacking?” Jan 2018. [Online].Available: https://hackerbits.com/programming/what-is-cryptojacking/

[163] M. Saad, A. Khormali, and A. Mohaisen, “End-to-end analysis ofin-browser cryptojacking,” CoRR, vol. abs/1809.02152, 2018. [Online].Available: http://arxiv.org/abs/1809.02152

[164] Coinhive, 2018. [Online]. Available: https://coinhive.com/[165] CryptoLoot, “Earn more from your visitors,” 2018. [Online]. Available:

https://crypto-loot.com/[166] M. Community, “Monero: Home,” 2018. [Online]. Available:

https://getmonero.org/

30

[167] J. Condliffe, “A cryptojacking attack hit thousands of websites,including government ones,” 2018. [Online]. Available: https://goo.gl/FPgTo9

[168] Google, “Google analytics and trends,” 2018. [Online]. Available:https://goo.gl/9sSpGL

[169] D. Singh, “Cryptojacking attacks rose by 8,500% globally in 2017:report,” 2018. [Online]. Available: https://goo.gl/qpGcZy

[170] NCSC, “The cyber threat to uk business 2017-2018 report,” Apr 2018.[Online]. Available: https://www.ncsc.gov.uk/cyberthreat

[171] B. Peterson, “Thieves stole potentially millions of dollars in bitcoin ina hacking attack on a cryptocurrency company,” Dec 2017. [Online].Available: https://goo.gl/znceAF

[172] W. Duggan, “The 12 biggest cryptocurrency hacks inhistory.” [Online]. Available: https://www.benzinga.com/fintech/17/11/10824764/12-biggest-cryptocurrency-hacks-in-history

[173] M. Brengel and C. Rossow, “Identifying key leakage of bitcoinusers,” in International Symposium on Research in Attacks, Intrusions,and Defenses RAID, Heraklion, Crete, Greece, ser. Lecture Notes inComputer Science, M. Bailey, T. Holz, M. Stamatogiannakis, andS. Ioannidis, Eds., vol. 11050. Springer, Sept 2018, pp. 623–643.[Online]. Available: https://doi.org/10.1007/978-3-030-00470-5_29

[174] J. Breitner and N. Heninger, “Biased nonce sense: Lattice attacksagainst weak ecdsa signatures in cryptocurrencies,” Cryptology ePrintArchive, Report 2019/023, 2019, https://eprint.iacr.org/2019/023.

[175] M. Wohrer and U. Zdun, “Smart contracts: security patterns in theethereum ecosystem and solidity,” in 2018 International Workshopon Blockchain Oriented Software Engineering, IWBOSE@SANER,Campobasso, Italy, Mar 2018, pp. 2–8. [Online]. Available:https://doi.org/10.1109/IWBOSE.2018.8327565

[176] ConsenSys, “Consensys/smart-contract-best-practices.” [Online].Available: https://github.com/ConsenSys/smart-contract-best-practices/blob/master/docs/known_attacks.md

[177] A. Hülsing, D. Butin, S. Gazdag, and A. Mohaisen, “Xmss:extended hash-based signatures,” 2015. [Online]. Available: https://www.ietf.org/id/draft-irtf-cfrg-xmss-hash-based-signatures-10.txt

[178] AntiMiner, “Anti miner - no 1 coin minerblock,” 2018. [Online].Available: https://goo.gl/BiwzUU

[179] CoinMiner, “Coin miner block,” 2018. [Online]. Available: https://goo.gl/MWPNv4

[180] AdGuard, “Adguard adblocker,” 2018. [Online]. Available: https://goo.gl/AXg186

[181] C. Decker, “cdecker/btcresearch,” Jan 2018. [Online]. Available:https://github.com/cdecker/btcresearch

[182] B. Scott, “Bitcoin academic research.” [On-line]. Available: https://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/edit#gid=0

[183] X. Li, P. Jiang, T. Chen, X. Luo, and Q. Wen, “A survey on thesecurity of blockchain systems,” CoRR, vol. abs/1802.06993, 2018.[Online]. Available: http://arxiv.org/abs/1802.06993

[184] T. Salman, M. Zolanvari, A. Erbad, R. Jain, and M. Samaka, “Securityservices using blockchains: A state of the art survey,” CoRR, vol.abs/1810.08735, 2018. [Online]. Available: http://arxiv.org/abs/1810.08735

[185] L. Anderson, R. Holz, A. Ponomarev, P. Rimba, and I. Weber, “Newkids on the block: an analysis of modern blockchains,” CoRR, vol.abs/1606.06530, 2016. [Online]. Available: http://arxiv.org/abs/1606.06530

[186] G. Kappos, H. Yousaf, M. Maller, and S. Meiklejohn, “An empiricalanalysis of anonymity in zcash,” CoRR, vol. abs/1805.03180, 2018.[Online]. Available: http://arxiv.org/abs/1805.03180

[187] M. Kiran and M. Stanett, “Bitcoin risk analysis,” NEMODE PolicyPaper, 2015. [Online]. Available: http://hdl.handle.net/10454/10717

[188] J. Moubarak, E. Filiol, and M. Chamoun, “On blockchain securityand relevant attacks,” in IEEE Middle East and North AfricaCommunications Conference, MENACOMM, 2018, pp. 1–6. [Online].Available: https://doi.org/10.1109/MENACOMM.2018.8371010

[189] M. Carlsten, H. A. Kalodner, S. M. Weinberg, and A. Narayanan, “Onthe instability of bitcoin without the block reward,” in Proceedingsof the ACM Conference on Computer and Communications SecuritySIGSAC, Vienna, Austria, Oct 2016, pp. 154–167. [Online]. Available:http://doi.acm.org/10.1145/2976749.2978408

[190] L. Kiffer, D. Levin, and A. Mislove, “Stick a fork in it:Analyzing the ethereum network partition,” in Proceedings ofthe 16th ACM Workshop on Hot Topics in Networks HotNets,Palo Alto, CA, USA, Nov 2017, pp. 94–100. [Online]. Available:http://doi.acm.org/10.1145/3152434.3152449

[191] D. Bradbury, “The problem with bitcoin,” Computer Fraud & Security,vol. 2013, no. 11, pp. 5–8, 2013.

[192] I. Eyal and E. G. Sirer, “How to disincentivize large bitcoin miningpools,” http://bit.ly/1srPhPs, June 2014.

[193] M. Rosenfeld, “Analysis of hashrate-based double spending,” CoRR,vol. abs/1402.2009, 2014. [Online]. Available: https://goo.gl/MREcpK

[194] T. Chen, X. Li, Y. Wang, J. Chen, Z. Li, X. Luo, M. H. Au,and X. Zhang, “An adaptive gas cost mechanism for ethereumto defend against under-priced dos attacks,” in 13th InternationalConference on Information Security Practice and Experience ISPEC,Melbourne, VIC, Australia, Dec 2017, pp. 3–24. [Online]. Available:https://doi.org/10.1007/978-3-319-72359-4_1

[195] L. Luu, D. Chu, H. Olickel, P. Saxena, and A. Hobor, “Makingsmart contracts smarter,” in ACM SIGSAC Conference on Computerand Communications Security, Vienna, Austria, E. R. Weippl,S. Katzenbeisser, C. Kruegel, A. C. Myers, and S. Halevi,Eds. ACM, Oct 2016, pp. 254–269. [Online]. Available: https://doi.org/10.1145/2976749.2978309

[196] G. C. Fanti and P. Viswanath, “Anonymity properties of the bitcoinP2P network,” CoRR, vol. abs/1703.08761, 2017. [Online]. Available:http://arxiv.org/abs/1703.08761

[197] J. H. Ziegeldorf, R. Matzutt, M. Henze, F. Grossmann, andK. Wehrle, “Secure and anonymous decentralized bitcoin mixing,”Future Generation Comp. Syst., vol. 80, pp. 448–466, 2018. [Online].Available: https://doi.org/10.1016/j.future.2016.05.018

[198] T. M. Fernández-Caramés and P. Fraga-Lamas, “A review on theuse of blockchain for the internet of things,” IEEE Access, vol. 6,pp. 32 979–33 001, 2018. [Online]. Available: https://doi.org/10.1109/ACCESS.2018.2842685

[199] G. Perboli, S. Musso, and M. Rosano, “Blockchain in logistics andsupply chain: A lean approach for designing real-world use cases,”IEEE Access, vol. 6, pp. 62 018–62 028, 2018. [Online]. Available:https://doi.org/10.1109/ACCESS.2018.2875782

[200] G. Wood, “Ethereum: A secure decentralised generalised transactionledger,” Ethereum Project Yellow Paper, vol. 151, 2014.

[201] K. Lee, J. I. James, T. G. Ejeta, and H. Kim, “Electronic voting serviceusing Blockchain,” The Journal of Digital Forensics, Security and Law:JDFSL, vol. 11, no. 2, p. 123, 2016.

[202] P. Noizat, “Blockchain electronic vote,” Handbook of Digital Currency:Bitcoin, Innovation, Financial Instruments, and Big Data, p. 453, 2015.

[203] T. I. Ron and S. Attias, “The effect of Blockchain technology in thegaming regulatory environment.” Gaming Law Review, vol. 21, no. 6,pp. 459–460, 2017.

[204] G. Karame, “On the security and scalability of bitcoin’s blockchain,”in ACM SIGSAC Conference on Computer and CommunicationsSecurity, Vienna, Austria, Oct 2016, pp. 1861–1862. [Online].Available: https://doi.org/10.1145/2976749.2976756

[205] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technicalsurvey on decentralized digital currencies,” IEEE CommunicationsSurveys and Tutorials, vol. 18, no. 3, pp. 2084–2123, 2016. [Online].Available: https://doi.org/10.1109/COMST.2016.2535718

[206] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf,and S. Capkun, “On the security and performance of proof ofwork blockchains,” in ACM SIGSAC Conference on Computer andCommunications Security, Vienna, Austria, Oct 2016, pp. 3–16.[Online]. Available: https://doi.org/10.1145/2976749.2978341

[207] S. Werman and A. Zohar, “Avoiding deadlocks in paymentchannel networks,” in International Workshop on Data PrivacyManagement, Cryptocurrencies and Blockchain Technology DPM andCBT, Barcelona, Spain, Sept 2018, pp. 175–187. [Online]. Available:https://doi.org/10.1007/978-3-030-00305-0_13

[208] R. Yu, G. Xue, V. T. Kilari, D. Yang, and J. Tang, “Coinexpress: Afast payment routing mechanism in blockchain-based payment channelnetworks,” in International Conference on Computer Communicationand Networks ICCCN, Hangzhou, China, Aug 2018, pp. 1–9. [Online].Available: https://doi.org/10.1109/ICCCN.2018.8487351