Content uploaded by Muhammad Saad
Author content
All content in this area was uploaded by Muhammad Saad on Oct 21, 2019
Content may be subject to copyright.
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 attack
surface of the Blockchain technology, with an emphasis on public
Blockchains. Towards this goal, we attribute attack viability in
the 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 those
contributing factors, we outline several attacks, including selfish
mining, 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. We
also explore the causal relationships between these attacks to
demonstrate how various attack vectors are connected to one
another. A secondary contribution of this work is outlining
effective defense measures taken by the Blockchain technology or
proposed by researchers to mitigate the effects of these attacks
and 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], smart
contracts [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. Using
Blockchain’s transparent and fully distributed peer-to-peer
architecture, these applications benefit from an append-only
model in which “transactions” accepted in the Blockchain
cannot be modified [18], [20], [21]. The transparency of
the Blockchain enables storing publicly verifiable and unde-
niable records [22]. Furthermore, the Blockchain’s peer-to-
peer system provides verifiable ledger maintenance without
a centralized authority, thus addressing the single point-of-
failure and single point-of-trust [23]. For instance, Bitcoin (a
popular cryptocurrency using Blockchain technology) takes
advantage of the aforementioned properties, making it easy
to verify the history of financial transactions [24], [25].
Despite the functional features that Blockchain brings to
the design space of these applications [43], recent reports
have highlighted the security risks associated with this tech-
nology [10], [44]–[47]. For instance, in June 2016 an unknown
attacker managed to drain $50 million USD from “The DAO”,
M. Saad, J. Spaulding, and A. Mohaisen are with the Department of
Computer 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 with
the Old Dominion University, VA, USA. D. Nyang is with INHA University,
Incheon, South Korea. The work of D. Nyang was done while visiting the
University of Central Florida.
a decentralized autonomous organization that operates on
Blockchain-based smart contracts, or pre-programmed rules
that govern the organization [48]. In August 2016, bitcoins
worth $72 million USD were stolen from the exchange plat-
form Bitfinex in Hong Kong [49]. In June 2017, Bitfinex also
experienced a distributed denial-of-service (DDoS) attack that
led to its temporary suspension. Several exchanges of Bitcoin
and Ethereum (a Blockchain-based distributed computing plat-
form) have also suffered from DDoS attacks and DNS attacks
frequently, hampering the service availability to the users.
Often times these attacks are launched on blockchain-
applications due to their popularity or the capital involved in
their system. For instance, with Bitcoin, such attacks can cause
devaluation of the cryptocurrency, loss of mining rewards,
or even closure of cryptocurrency exchanges [29]. Bitcoin’s
Blockchain is also targeted with dust or spam transactions
to delay the processing of legitimate transactions. In May,
August, and November 2017, memory pools of Bitcoin were
flooded with dust transactions to create stalls and delays in
transaction 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 worth
bitcoins [50]. Often the intent of such attacks is to motivate
the Bitcoin users to move to other cryptocurrencies with faster
transaction 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 by
two malicious users who stole $460 million USD worth of
bitcoins [51]. The attackers gathered useful information from
Bitcoin’s Blockchain and engineered a fake transaction ripple
to increase the market price. Due to such activities, Mt. Gox
suffered a heavy loss and eventually became bankrupt.
In May and June 2018, five Blockchain-based cryptocurren-
cies; namely, Monacoin, Bitcoin Gold, Zencash, Verge, and
Litecoin Cash, were targeted by a 51% attack [52], leading to
a loss of $5 million USD. The attackers in each cryptocurrency
were able to gain more than 51% of the networks’ hash rate
which was used to rearrange transactions and prevent other
miners from computing blocks. As a result, they were able to
gain control over the Blockchain and perform double-spending
on valuable transactions [53], [54].
The security of Blockchain systems is important for their
acceptability by potential users [55]. For example, investors
take the security of Bitcoin into account when studying the
risks associated with their investments and use of this tech-
nology. Understanding the threats associated with Blockchain
systems in general is a first step towards realizing the potential
of applications built on it. To this end, this work is dedicated
arXiv:1904.03487v1 [cs.CR] 6 Apr 2019
2
TABLE I
ATTACK VE CT ORS R EL ATED TO T HE ATTACK C LA SS IN BLOCKCHAIN SYSTEMS. W E AL SO SH OW,BY R EFE REN CI NG TO T HE P RIO R WOR K,H OW EAC H
ATTACK A FFEC TS T HE EN TI TIE S INV OLVE D WIT H BLO CKC HA IN SY STE MS . FOR INSTANCE, ORP HAN ED B LOC KS A FFEC T TH E BLOCKCHAIN,THE MINERS,
AND THE MINING POOLS.
Attacks Blockchain Miners Mining Pools Exchanges Application Users
Blockchain Structure Forks [26] X
Orphaned blocks [27] X X X
Peer-to-Peer System
DNS hijacks [28] X X X X
BGP hijacks [29] X X X
Eclipse attack [30] X X
Majority attack [31] X X X
Selfish mining [32] X X X
DDoS attacks [33] X X X
Consensus Delay [34] X X X
Block Withholding [34] X X
Timejacking attacks [35] X X X
Finney attacks [36] X X X
Blockchain Application
Blockchain Ingestion [37] X
Wallet theft [38] X X X
Double-spending [39] X X
Cryptojacking [40] X X
Smart 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 compromise
those 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 for
creating the ledger (e.g., Blockchain forks, stale blocks, or-
phaned blocks, etc.), 2) attacks associated with the peer-to-peer
architecture used in the Blockchain system, (e.g., selfish min-
ing, the 51% attack, consensus delay, DDoS attack, Domain
Name System (DNS) attacks, Fork After Withholding (FAW)
Attacks, etc.), and 3) attacks associated with the application
context that uses the Blockchain technology (e.g., Blockchain
ingestion, double-spending, wallet theft [56], etc.). In this
paper, we mainly focus on the attack surface of public and
permissionless Blockchains. Public Blockchains are suitable
for applications that provide open access to system resources
while preserving user anonymity. These attributes are well
suited for a system that has a weak trust model and high
provenance assurance requirements. The weak trust model
results from an application’s tolerance for adversaries who can
game the system while staying anonymous. On the other hand,
high provenance means that anyone can access the publicly
available resources to transparently audit data. For instance,
in Bitcoin and Ethereum, any user can join the network by
running an Ethereum software client on their machine and
participating in transaction processing. Since the Blockchain is
public, anyone outside the system can validate the authenticity
of transactions and blocks. Therefore, public Blockchains
remain a dominant component among Blockchain applications
as shown by the popularity of Bitcoin and Ethereum. On the
other hand, the weak trust model exposes public Blockchains
to a wide variety of attacks, allowing adversaries to easily
compromise the system [57]. Therefore, while the public
Blockchains are useful for an open access system, they are not
suitable for closed environments where the weak trust model
creates attack opportunities.
To address the shortcomings of public Blockchains and
reduce the attack opportunities, private and permissioned
Blockchains are now used for various applications [58]. In pri-
vate Blockchains, the access to system resources is restricted to
a chosen set of peers [59], [60]. These peers are screened prior
to their induction in the application. Since the information
about peers is known, their identities can be tied (or attributed)
to their behavior in order to prevent attacks. Although private
Blockchains still act as agents of trust in permissioned settings,
they are not significantly exposed to adversarial attacks due to
a stronger trust model. Since the aim of this work is to explore
and understand the attack surface of Blockchains, it is natural
to focus more on the public Blockchains. However, wherever
necessary, we will also discuss the security and performance
of private Blockchains as well.
Contributions. In summary, we make the following contribu-
tions int this paper. (1) We survey the possible attacks related
to the design constructs of Blockchains, the peer-to-peer
architecture, and the application-oriented use of Blockchains.
(2) We explore the origins of these attacks and the ways in
which they affect Blockchain applications and their users.
(3) We also show the relationship between a sequence of
attacks to outline how one attack can facilitate the possibility
of other attacks. Understanding these links can help devise a
common cure that can fix multiple problems at the same time.
(4) Building on top of the prior work [45], [57], [61], for each
attack class, we also explore the possible defense strategies
that have been proposed to harden the security of Blockchains.
Since many attacks related to a specific class have a common
3
TABLE II
IMP LIC ATIO NS OF E ACH ATTAC K ON T HE BLOCKCHAIN SYSTEM IN THE LIGHT OF THE PRIOR WORK. FO R INS TANC E,F ORK S CA N LEA D TO CH AI N
SPLITTING AND REVENUE LOSS. AS A RE SU LT OF A FO RK,O NE A MON G TH E CAN DI DATE CH AIN S IS S ELE CT ED BY T HE N ETW ORK W HI LE TH E OTH ER S
AR E INVAL IDATE D. TH IS L EAD S TO IN VALI DATIO N OF TR AN SAC TIO N AN D REV ENU E LO SS TO M IN ERS .
Attacks Chain Splitting Revenue Loss Partitioning Malicious Mining Delay Info Loss Theft
Blockchain
Splitting
Forks [26] X X
Orphaned Blocks [27] X
P2P
System
DNS hijacks [28] X X X
BGP hijacks [29] X X X
Eclipse attacks [30] X
Majority attacks [31] X X X
Selfish mining [32] X X
DDoS attacks [33] X X
Consensus Delay [34] X X
Block Withholding [34] X X
Timejacking attacks [35] X X X X
Finney attacks [36] X
Blockchain
Application
Blockchain Ingestion [37] X
Wallet theft [38] X X
Double-spending [39]
Cryptojacking [40] X X X
Smart 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, we
discuss combined countermeasures for each class. Moreover,
by highlighting the lessons learned, we also provide future
research directions towards a more systematic treatment of
the Blockchain attack surface. (5) In Table I and Table II,
we provide an overview of the Blockchain attack surface. We
ascribe 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 Blockchain
that enable various attacks, such as Blockchain forks, stale
and orphaned blocks. In section V, we look into the features
of distributed networks that create possibilities for the 51%
attack, DNS attacks, DDoS attacks, consensus delays, etc. We
further describe the aspects of peer-to-peer architecture that
enable the possibility of their potential misuse in Blockchain
applications. In section VI, we outline the application-specific
vulnerabilities found in Blockchain and assess the threats that
they face. That is followed by discussion and open directions
in section VIII, and the concluding remarks in section IX.
II. MOT IVATIO N AN D TARGET AUDIENCE
The motivation of this work is to derive attention to-
wards the security vulnerabilities of Blockchain systems via
a systematic and comprehensive study. Recently, Blockchain
technology has gained significant attention and its applications
are being explored in various domains [62], [63]. Blockchains
are 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 security
surface. To that end, our work is an effort to highlight potential
vulnerabilities in Blockchains, with an emphasis on popular
public Blockchain applications. We systematically analyze
various attack vectors and study their relationships. Alongside,
we also survey countermeasures and defenses to the various
attack surface elements, and provide future research directions.
Since various research and technology sections are in-
terested in using Blockchains, it is intuitive to explore a
deeper understanding of Blockchains’ attack surface to estab-
lish foundations for their security. For instance, using public
Blockchains in the financial sector may prevent fraud and
data tampering, by the simply utilizing Blockains’ proper-
ties, although that also may expose sensitive information of
financial transactions to adversaries. Similarly, organizations
that 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 bugs
that may lead to data breach and critical assets loss. For this
research-driven efforts, we believe our work has the potential
to offer future directions toward designing more secure and
robust Blockchain solutions that may overcome some of those
challenges as outlined in the rest of this survey. Some of these
challenges include constructing new consensus algorithms that
are secure, scalable, and energy efficient [68]. Additionally,
they must also have the capability to prevent race conditions
that lead to attacks such as selfish mining, double-spending,
majority attacks, and orphaned blocks [69], [70]. To facilitate
the process of addressing those challenges, we supplement our
work by surveying the existing countermeasures proposed in
the literature. These countermeasures can be used as building
4
User A
Transaction 4
Generated
User B
Miner Validates Selected Transactions
Computes Block. (Transaction 2 Not Selected)
Miner
Block Hash
Previous Block Hash
Merkel Root
Number of Transactions
Coinbase Reward
Transaction 1
Transaction 3
Transaction 4
3.
B1 B2 B3 B4 B5
Blockchain
Memory Pool
Transaction 1
Transaction 2
Transaction 3
Transaction 4 Block Added
4.
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 along
with 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 attack
landscape of Blockchains, as well as practitioners, who might
be interested in understanding the existing solutions to those
attacks, to utilize as building blocks, and both benefiting from
a systematic analysis of the Blockchain attack surface.
III. OVERVIEW OF BLOCKCHAIN AND ITS OPERATIONS
Conceptually, Blockchain can be viewed as a repository of
data that is tamper-evident due to its replication over all nodes
in a peer-to-peer system. Transactions represent the events
that drive the Blockchain application (e.g., in cryptocurren-
cies, tokens are the transactions exchanged among the users).
Blockchain applications use various consensus algorithms for
trust among peers over the state of the ledger. Moreover, the
consensus algorithms ensure a consistent and transparent view
of the Blockchain, thereby resolving conflicts and forks. This
is, no block is added to the Blockchain, until it fulfills the con-
ditions outlined by the consensus algorithm. Moreover, each
algorithm has unique functional and operational properties that
drive 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 Bitcoin
and Peercoin, the consensus algorithms are proof-of-work and
proof-of-stake, respectively. Although they different in the way
the consensus is conducted, the two applications have the
same Blockchain data structure in which the chain progresses
in an append-only model and each block is linked to the
previous block through a one-way hash function. In both
cryptocurrencies, the system replicas are connected in a peer-
to-peer model, maintaining a single copy of the ledger. In the
following, we briefly discuss the popular consensus algorithms
along with the fundamental cryptographic primitives that are
used in Blockchains.
A. Consensus Algorithms
Some 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 popular
consensus 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 try
to solve a computationally expensive mathematical challenge.
For instance, the challenge in Bitcoin is to come up with
anonce that when hashed with block data produces a hash
value that is less than a target threshold set by the system.
All peers in the system use their computational power to
solve the mathematical challenge. The peer who comes up
with the solution wins the block race and mines a new block.
Once a block is broadcast to the network, each peer verifies
the solution and appends the block to his Blockchain. The
probability of winning a block race is proportional to the
computational power of participants. At the same time, there
is a time restriction on the block mining [76], [77]. In Bitcoin,
the block time is set to 10 minutes. In other words, the network
expects a new solution to the block puzzle after every 10
minutes. However, as the computational power increases, the
chance of discovering a new block under 10 minutes increases.
To address that, the network dynamically adjusts the difficulty
of the challenge according to the change in the computational
power of the miners. Oftentimes, more than one miner can
come up with a valid solution leading to Blockchain forks and
stale and orphaned blocks, which we discuss in section IV.
In Figure 1, we illustrate the transaction life-cycle in a
proof-of-work (PoW)-based Blockchain application. User A
(sender) generates a transaction for user B (receiver). The
transaction is broadcast to the entire peer-to-peer network
where it is temporarily stored in a transaction repository
known as the memory pool (mempool). In a peer-to-peer
network, the mempool is a space allocated in the RAM of
a full node that stores and relays transactions to other peers.
To maintain the state of the Blockchain, there are special nodes
in the network known as the miners or verifiers, responsible
for verifying transactions and computing a block. The miners
query the mempool and select the transactions of their choice
to put into blocks. Usually transactions pay a mining fee which
can be viewed as an incentive given to the miners to mine the
transaction. Naturally, miners give priority to the transactions
that pay higher mining fee. Transactions that are not selected
by the miners, stay in the mempool until some other miner
selects 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 the
primary replica. The primary replica then forwards it to other replicas who
jointly execute a four-phased protocol and approve the transaction. Assuming
ffaulty replicas, the primary would require confirmation from at least 3f+1
replicas. PBFT is employed in permissioned and private blockchains.
mined for a long time, eventually get discarded.
Proof-of-Stake. The second most popular consensus algorithm
in public Blockchains is proof-of-stake (PoS) [78], [79]. PoS
was introduced to address the energy inefficiency of PoW. In
PoS, the mining power of a user is determined by the total
number of coins he owns. For each new block, an auction is
carried out to select the candidate miner. Users place a bid
on the block and the one with the highest bid is selected as
a miner. Therefore, in contrast to PoW, the hashing power
is replaced by the volume of assets owned by the user. The
more coins a users owns, the higher his chances of winning the
block race. The replace of energy intensive mining with stake-
based mining, makes PoS energy efficient and secure against
the majority attacks (section V-B). Unlike PoW, in PoS, all
the cryptocurrency tokens are released prior to creation of the
genesis block [80]. Therefore, when a new block is mined, it
does not introduce new coins in the system. However, miners
are rewarded with transaction fee for their contributions.
PBFT. The third most popular Blockchain consensus protocol
is 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 trust
model compared to PoS and PoW. In PBFT Blockchains, the
system is transposed into a group of active and passive repli-
cas. Among the active replicas, a primary replica is selected
who receives transactions from a client and sends them to
the active replicas for execution. The process of execution
is carried out in four stages, namely, pre-prepare, prepare,
commit, and reply stage. In the pre-prepare phase, primary
sends transactions to all the active replicas. In the prepare and
commit phase, each active replica signs the transaction and
exchange it with all the other replicas. In the reply stage, all
the active replicas send their response to the primary replica.
The primary collects all the signed transactions and puts them
in a block. In Figure 2, we show the transaction verification
process in a PBFT Blockchain. Notice that compared to PoW
and PoS, PBFT has a higher message complexity.
In Table III, we compare the popular consensus algorithms
used in the Blockchain applications. Notice that permissionless
Blockchains have low throughput and high confirmation time.
Bitcoin has transaction throughput of 3–7 transactions per
second. 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 the
entire 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 be
required to change data in all subsequent blocks and correctly execute the
consensus protocol for each block. Since this is infeasible in practice, therefore
Blockchains are considered tamper-proof.
throughput and and low confirmation time. In terms of security,
PBFT has low fault tolerance (≈33%) compared to PoW and
PoS (≈50%). However, since permissioned Blockchains have
a stronger trust model, therefore, they are less vulnerable to
adversarial attacks. It can also be observed in Table III, public
Blockchains 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 for
Byzantine nodes. Since PBFT has high message complexity
and low Byzantine fault tolerance, therefore, it cannot scale
well beyond few hundred nodes. Therefore, each consensus
scheme has its own benefits and limitations. Therefore, de-
pending upon the application model, a consensus scheme can
be selected to meet the requirements.
B. Blockchain Structure
While the consensus schemes in Blockchains may vary,
the cryptographic constructs of Blockchain are fundamentally
the same across all applications [85], [86]. Each block in a
Blockchain consists of a header and a payload. The header
includes the primary information, such as the hash of the
previous block, the merkle root, and the block timestamp. The
hash pointer connects each block to the previous block, thereby
forming a chain. Since hash functions are one-way and are
collision resistant, Blockchain benefits from their properties to
become immutable and tamper-proof [87], [88]. In Figure 3,
we illustrate this model of Blockchain, where blocks are linked
through hash functions.
In a Blockchain application, all nodes are connected in a
peer-to-peer architecture. This means that they use the gossip
protocol to communicate information, including transactions
and blocks. Ideally, each peer is expected to maintain a copy
of Blockchain. However, due to the append-only model, the
growing size of Blockchain can put space constraint at the
node. To address that, various Blockchain applications allow
the segmentation of nodes into full nodes and lightweight
nodes. The full nodes maintain a complete copy of Blockchain
and participate in transaction and block propagation. On the
other hand, the lightweight nodes only keep the block header
for the verification of a newly published block.
As stated earlier, several attacks on Blockchain technology
are related to the constructs of the Blockchain itself, the
behavior of certain miners, and the peer-to-peer architecture
it is built upon. In the subsequent sections, we explore the
6
TABLE III
AN OVE RVIE W OF PO PU LAR C ON SEN SU S ALG OR ITH MS U SED I N BLOCKCHAINS. NOTICE THAT PUBLIC AND PERMISSIONED BLOCKCHAINS USING POW,
POS, A ND DP OSHAVE HIGH SCALABILITY,LOW T HRO UG HPU T,AND H IG H CON FIR MATIO N TI MES . IN CONTRAST,PERMISSIONED BLOCKCHAINS USING
PBFT AND RAFT HAVE LO W SCA LA BIL IT Y,LOW CON FIR MATIO N TI ME,AND HIGH THROUGHPUT.
Properties PoW PoS DPoS PBFT RAFT
Blockchain Type Permisssionless Permissionless Permissionless Permissioned Permissioned
Participation Cost Yes Yes Yes No No
Trust Model Untrusted Untrusted Untrusted Semi-trusted Semi-trusted
Scalability High High High Low Low
Throughput <10 <1,000 <1,000 <10,000 >10,000
Byzantine Fault Tolerance 50% 50% 50% 33% –
Crash Fault Tolerance 50% 50% 50% 33% 50%
Confirmation Time >100s <100s <100s <10s <10s
Old
Rules
Old
Rules
Old
Rules
Old
Rules
Old
Version
New
Rules
New
Rules
New
Rules
New
Rules
New
Version
Fork
Fig. 4. Hard Fork resulting from set of peers following conflicting rules due
to different client software versions. Hard forks can be irreversible at times
and 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 in
the Blockchain system, and attacks associated with the appli-
cation services that use Blockchain technology (i.e., Bitcoin
or Ethereum). We also supplement each section with possible
countermeasures that have been proposed by researchers to
address those attacks.
IV. BLOCKCHAIN STRUCTURE ATTACKS
In this section, we look at the attacks related to the design
constructs of the Blockchain. These attacks emerge from the
potential vulnerabilities of the Blockchain structures and as
such, they can compromise any Blockchain-based application.
A. Blockchain Forks
A fork represents a condition in which nodes in the network
have diverging views about that state of the Blockchain persist-
ing over long periods of time or even indefinitely. These forks
can be created unintentionally through protocol malfunctions
or incompatibilities in client software upgrades. Forks can
also be caused by malicious intents such as implanting “Sybil
nodes” that follow conflicting validation rules or by carrying
out “selfish mining” in race conditions as discussed further
in section V-A. Another form of fork occurs when users of
a Blockchain application create a child application from the
parent application. For example, in 2017, a group of Bitcoin
developers decided to increase the block size limit from 1MB
to 8MB by developing a new Bitcoin client that was capable
of accepting 8MB blocks. However, their proposal was not
accepted by the majority of users, therefore, they created a
hard fork on Bitcoin and released a new cryptocurrency called
Bitcoin 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 Bitcoin
Core
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 of
which occurs when new blocks that the network accepts appear
invalid to pre-fork nodes. Soft forks, however, occur when
some blocks appear invalid to post-fork nodes. In either case,
a Blockchain fork represents an inconsistent state that can
be exploited by adversaries to cause confusion, fraudulent
transactions, and distrust within network [89].
Figure 4 demonstrates a hard fork example that results from
peers following conflicting rules about the state of Blockchain.
Such hard forks may lead to a split in cryptocurrency. A
major hard fork on Bitcoin occurred during August 2017,
which led to the creation of Bitcoin Cash [90]. Another hard
fork on Bitcoin occurred during October 2017, when Bitcoin
Gold [91] was created. Some other notable forks in Bitcoin
include Bitcoin Classic, Bitcoin XT, and Bitcoin Unlimited.
However, due to insufficient user-base and miners, they could
not succeed as a separate cryptocurrency.
When hackers stole more than one third of the total digital
cash owned by “The DAO” [48], Ethereum used a hard fork
to roll back transactions and retrieve millions of dollars’ worth
of ether (the “fuel” for the Ethereum network). However, this
required consensus by the majority of nodes in the network.
7
In such a scenario, if a consensus delay happens due to a
majority attack or a DDoS event, fraudulent activities become
somewhat difficult to deal with and prolonged delays can
ultimately cause devaluation of cryptocurrency. In November
2017, the second version of Segregated Witness (SegWit2x)
hard fork was proposed in Bitcoin, which aimed to increase
the block size to 2MB. However, due to lack of consensus by
the majority, the planned hard fork was canceled. In Timeline
1, we provide a list of major forks on Bitcoin. These forks
resulted from a group of miners introducing new rules and
a faction of peers switching to those rules. All these forks
introduced a new version of Bitcoin. This is, we note that a
fork may diminish if peers discontinue to follow the new rules
and switch back to the old ones. For instance, this has been
witnessed in SegWit fork. Initially, a faction of network peers
switched to SegWit version of Bitcoin, however, when they
moved back to the old version in a protest, the fork ended.
B. Stale Blocks and Orphaned Blocks
Two 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 was
successfully mined but is not accepted in the current best
Blockchain (i.e., the most-difficult-to-recreate chain). Stale
blocks occur mostly in the public Blockchains due to race
conditions. In race conditions, the miners actively try to find
the next block, and it is possible that two or more miners can
come up with a valid solution. The network eventually accepts
one of the winning blocks and discards the rest. As a result,
the all other valid blocks unaccepted become stale blocks as
they do not get attached to the main Blockchain. We will see
in section V-A that a form of Blockchain attack known as
“selfish mining” can also lead to the creation of stale blocks
in the network, which deprives an honest miner of its reward.
The other form of inconsistency is an “orphaned block”: a
block whose parent block’s hash field points to an unauthen-
tic block that is detached from the Blockchain [92]. These
inconsistencies can be introduced by an attacker or caused by
race conditions in the work of the miners. Stale blocks may
be initially accepted by the majority of the network, but they
can 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 orphaned
blocks can be found. The first orphaned block in Bitcoin was
found on March 18, 2015, and that was the beginning of a
period in which most orphaned blocks were created. The trend
reduced in 2016, and from June 2017 to the date of this paper,
no orphaned block has been added to the list [93]. Orphaned
blocks are more frequently found in cryptocurrencies where
average block computation time is small. In Figure 6, we
plot the number of orphaned blocks that occurred in Bitcoin
and Ethereum from July 2016 to May 2018. In Ethereum, the
orphaned blocks are called Uncle blocks. The data in the figure
has been normalized using min-max normalization to scale the
data in the range [0,1]. The min-max scaling is conducted as
z=xi−min(x)
max(x)−min(x). It can be observed from the figure that as
of June 2017, no orphaned block has been found in Bitcoin.
On the other hand, in Ethereum, Uncle blocks have increased
since 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. Orphaned
block (block 5) does not have its parent block (block 4) in the Blockchain.
In cryptocurrencies such as Ethereum and Bitcoin, the
difficulty 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 keep
block time under a predefined range (10 minutes for Bitcoin
and 12 seconds for Ethereum). The difficulty is recomputed
based on the hashing power and the time taken by a series of
previous blocks: if hashing power increases, the probability of
finding 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 to
compute a block E(T)varies with the difficulty Dand hash
rate of the network Hr. Here, E(T)is measured in seconds,
Dis the number of hashes required to solve the current target,
and Hris measured in hashes/second, that a target device can
produce over a given string. Hris the aggregate hashing power
of all the miners Hifor i= 1,2, . . . , n. In (2), we calculate
the time Tb(seconds), it takes for a single miner in Hito
compute a block, given a fixed block time set by the network
Tn. For Bitcoin and Ethereum, the average block computation
time Tnis 600 seconds and 12 seconds, respectively.
Hr=
n
X
i=1
Hi, E(T) = D
Hr
(1)
Tb=Tn×Hr
Hi
Tb=Tn×Pn
i=1 Hi
Hi
(2)
From (1), it can be observed that when Hrremains constant
and the difficulty Dis reduced, the expected block time E(T)
decreases. Intuitively, lower E(T)means that in a defined
network time Tn, more blocks will be produced. However,
in the Blockchain, only one block can be accepted. Such a
situation will lead to more orphaned blocks in the system.
In Figure 7, we plot difficulty, hash rate, block time and
orphaned blocks (also called uncle blocks) in Ethereum. It
can 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 intervals
which increase the possibility of block collision. Orphaned
blocks may also occur due to unpredictable delays in block
propagation. A valid block may not reach majority of the
network peers due to network churns and propagation delays.
In contrast, a competing block is able to easily propagate
through the network and get accepted by the majority. There-
fore, network behavior and delay distribution may also affect
the number of orphaned blocks in a Blockchain system [92].
8
0
0.2
0.4
0.6
0.8
1
07/01/16
09/01/16
11/01/16
01/01/17
03/01/17
05/01/17
Normalized Value
Dates (mm/dd/yy)
Orphaned Blocks
Expected Time
Fig. 6. Orphaned Blocks in Bitcoin and Uncle blocks in Ethereum over the
last two years. Notice that in Bitcoin, the rate of orphaned blocks has reduced.
TABLE IV
EVOLUTION 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 2009
GPU Radeon 5890 245 2010
GPU Radeon 6990 800 2011
FPGA Xilinx Spartan 245 2012
FPGA Xilinx Spartan 850 2012
ASIC ASIC 130nm 12K 2013
ASIC ASIC 28nm 500k 2014
ASIC 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 serves
as an evidence for the effort put behind the computation of a
valid block. As outlined in (1), the effort for computation of a
block can be characterized as the number of hashes required
to meet the difficulty parameter Dset by the network. As
the aggregate hash power of the network Hrincreases, the
difficulty is raised to keep the standard block time Tnwithin
a defined range (10 minutes for Bitcoin).
In 7(a) and 7(d), we show the increase in difficulty and
the aggregate hash rate of Bitcoin and Ethereum, respectively.
Since mining in PoW is a lottery-based system, miners use
sophisticated hardware with high hash rate to increase their
chances 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 Central
Processing Unit (CPU), to graphics processing unit (GPUs) in
2011, 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 of
Bitcoin hardware, along with the hash rate, in Table IV.
One of the major problems with PoW is the excessive waste
of 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 hashes
required for valid PoW [97]–[99]. In Figure 8, we show
the electricity consumption of Bitcoin compared to several
countries. Other than the excessive consumption of electricity,
centralization of hashing rate among a few mining pools makes
the Blockchain application vulnerable to attacks including
the majority attacks and double-spending (discussed in sec-
tion V-B and section VI-B), whereby if a miner acquires the
majority of a network’s hash rate, the miner will be able to
gain control over the system.
2) PoS: (PoS) was introduced by King and Nadal in 2012
[100] to make Blockchain applications more energy-efficient
and raise the cost of a majority attack. Unlike PoW, which is
lottery-based, PoS uses a stake-based deterministic approach
to select a validator and to publish a new block [101]. In
this approach, the validator is chosen by a bidding process,
whereby candidate validators make a bid of their stake. The
stake is the balance owned by the candidate validator and is
used to deter cheating in the system. The candidate with the
highest bid is chosen to mine the next block and if he tries
to trick the system with bogus transactions he risks losing his
committed stake (balance). The process is deterministic since
a validator is chosen prior to each bidding process. Therefore,
blocks are published on their expected time without time
deviations or delays. Moreover, to launch a majority attack on
a PoS-based cryptocurrency, the attacker is required to acquire
more than 50% of the cryptocurrency tokens [102]. While it is
relatively easier to acquire 50% hash rate in PoW, it is difficult
to obtain 50% coin. Therefore, compared to PoW, the cost for
launching a majority attack in PoS application is relatively
high, which makes the attack less feasible.
Although PoS serves as a “green” mining alternative of PoW
and raises the attack cost for the majority attacks, it has some
major caveats that have prevented its widespread adoption by
the Blockchain community. In PoS, a rich validator may keep
on winning the bid for the next block to be validated, and
accumulate the block reward. As such, the rich validators in
the system gets richer for block confirmation, which makes
PoS applications centralized around those validators. This
challenges the fundamental premise of Blockchain technology
as a decentralized system [103]. Moreover, unlike PoW, in
which miners with limited resources may still have a chance
of winning the lottery, small bidders in PoS are certain to lose
the bid for each coming block.
3) PBFT: As pointed out in section III-B, in PBFT-based
private Blockchains, the system is grouped into a set of
replicas that process transactions and contribute towards the
block formation [71], [104]. The primary replica is responsible
for ordering transactions and obtaining approvals from other
replicas. Once sufficient approvals are received, the primary
computes a block and broadcasts it to the network. PBFT
is considered to be energy efficient with high transaction
throughput. However, it works under the assumption that the
primary replica faithfully executes the protocol and does not
tamper with the ordering of transactions and blocks. This
assumption may lead to a vulnerabilities in the permissioned
Blockchains. 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/01/16
09/01/16
11/01/16
01/01/17
03/01/17
05/01/17
Normalized Value
Dates (mm/dd/yy)
Hash Rate
Difficulty
(a) Change in difficulty and hash rate of Bitcoin
network during 2016-17
0
0.2
0.4
0.6
0.8
1
07/01/16
09/01/16
11/01/16
01/01/17
03/01/17
05/01/17
Normalized Value
Dates (mm/dd/yy)
Actual Time
Expected 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/01/16
09/01/16
11/01/16
01/01/17
03/01/17
05/01/17
07/01/17
09/01/17
11/01/17
01/01/18
03/01/18
05/01/18
Normalized Value
Dates (mm/dd/yy)
Bitcoin
Ethereum
(c) Orphaned Blocks per day plotted against the
expected block time.
0
0.2
0.4
0.6
0.8
1
10/01/15
01/01/16
04/01/16
07/01/16
10/01/16
01/01/17
04/01/17
07/01/17
10/01/17
01/01/18
Normalized Value
Dates (mm/dd/yy)
Difficulty
Hash Rate
(d) Change in difficulty and hash rate of
Ethereum network during 2015-18.
0
0.2
0.4
0.6
0.8
1
10/01/15
01/01/16
04/01/16
07/01/16
10/01/16
01/01/17
04/01/17
07/01/17
10/01/17
01/01/18
Normalized Value
Dates (mm/dd/yy)
Actual Time
Expected 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/01/15
01/01/16
04/01/16
07/01/16
10/01/16
01/01/17
04/01/17
07/01/17
10/01/17
01/01/18
Normalized Value
Dates (mm/dd/yy)
Block Time
Uncle Blocks
(f) Uncle Blocks per day plotted against the
expected 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 difficulty
sharply decreases with constant hash rate around October 2017, the expected and the actual time of block computation decreases sharply. As a result, the
number of Uncle blocks increases. The sharp decrease in the difficulty is associated to a byzantium fork that reduced block rewards per block.
Fig. 8. Energy Profile of Bitcoin and other countries. C-Republic refers to
Czech 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/or
4) invalidate transactions even after obtaining approvals.
As such, private Blockchains always are subjected to the risk
of a malicious primary who may compromise the system.
However, since the identity of the primary is usually known
to everyone, malicious activities of a primary can be tracked
back, eventually.
Another key challenge in PBFT-based private Blockchains is
their limited scalability and low tolerance to Byzantine nodes.
Low scalability results from the O(n2)message complexity
associated with the processing of a single transaction, as shown
in Figure 2. In PBFT, transaction execution is carried out in
four phases, namely pre-prepare, prepare, commit, and reply.
In the prepare and commit phase, each peer is required to send
message to every other peer in the network. In aggregate, this
leads to enormous communication overhead which cannot be
expected to work efficiently at a large scale. Therefore, when
the network size grows, the performance of PBFT is degraded
significantly. This is the key reason why PBFT-based private
Blockchains suffer from low scalability.
Finally, another limitation of PBFT-based private
Blockchains is their low fault tolerance. Each transaction
requires approval from 3f+1 replicas, where fis the number
of faulty replicas or Byzantine nodes. In comparison with
PoW and PoS, where the network can withstand up to 50%
malicious entities, PBFT can only tolerate 33% malicious
replicas. Provided that PBFT already suffers from low
scalability, a lower fault tolerance increases the opportunity
for 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. The
cost of compromising 5,000 nodes is high, and the attack
is therefore infeasible. However, in a PBFT-based private
Blockchain that consists of a 100 nodes, an attacker can
succeed only by controlling 33 nodes. Low fault tolerance is
a 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 recent
progress made in this direction [106]–[108].
D. Countering Blockchain Structure Attacks
Resolving soft forks in a Blockchain network is a relatively
easy process. All peers in the network can come to a consensus
about the true state of the Blockchain and resume activities
from there. Resolving hard forks can be challenging because
conflicting chains can be lengthy with transaction activities
dating back to the time of the conflict. Although the stakes of
rolling back from a hard fork are high, they can be resolved
by the same principle of consensus as discussed earlier. As
was the case with Ethereum, a hard fork was used to retrieve
money for the investors after “The DAO” was attacked [48].
Ultimately, the process of solving a fork depends upon the
agreement of peers in the network and their stake in the fork.
In Ethereum, uncle blocks are also rewarded and made
part of the Blockchain. Recently, the number of orphaned
blocks in Bitcoin has decreased due to the shift towards
highly centralized mining networks and thus reducing the
probability of orphaned blocks prevalent in decentralized min-
ing networks. However centralized mining has other issues
such as unfairness in the network and the 51% attack. The
other solution to avoid stale or orphaned blocks involves
dynamic adjustment of network’s difficulty [109]. In Bitcoin,
the difficulty is adjusted every two weeks (2016 blocks). In
the meantime, if there is a sharp increase in the hash rate
of the network or more miners join in, then the expected
time of finding new block decreases (2). As a result, there
is a higher likelihood of producing stale blocks. Therefore, a
dynamic difficulty adjustment helps in reducing the number of
stale and orphaned blocks. While there are effective techniques
to counter forks and orphaned blocks, the area of consensus
remains open. Research efforts need to be dedicated to make
PoW more energy efficient, and PoS, more decentralized.
In PBFT-based private blockchains, the key issue is limited
scalability due to high message complexity. Moreover, PBFT
has low fault tolerance which makes it vulnerable to attacks.
In section V-H, we provide more details about making PBFT
more scalable and secure.
V. BLOCKCHAIN’SPE ER -TO -PEE R SYSTEM
The underlying peer-to-peer architecture is the primary
reason why certain guarantees are provided by a Blockchain,
including security and accessibility. Counter intuitively, this
peer-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-service
attacks, eclipse attacks, fork after withholding attacks, and
consensus delay. In this section, we explore how these attacks
can compromise the Blockchain applications.
A. Selfish Mining
The selfish mining attack [110] is a strategy opted by certain
miners who attempt to increase their rewards by deliberately
keeping their blocks private [32], [111], [112]. Rather than
b1b2bn
bn+1
bn+1 bn+2 bn+3
Mh
Ms
Fig. 9. Illustration of Selfish Mining. Selfish behavior of Msforks the chain
at bn+1 and discards Mh’s block. Mh’s block becomes a stale block.
releasing them to the public upon discovery, these selfish
miners continue to mine their own private blocks to obtain a
longer chain than the public Blockchain. These activities lead
to a block race between the public chain of honest miners and
the private chain of selfish miners. Once the public Blockchain
starts approaching the length of their private chain, selfish
miners release their blocks to claim block rewards. Having
exceptional mining power may further help selfish miners win
the block race. In Figure 9, we demonstrate how a selfish
mining attack is carried out.
Consider a Blockchain with blocks (b1,b2, . . . , bn). Suppose
an honest miner Mhhas successfully mined the next block
bn+1 and he publishes it. All the peers in the network validate
and accept his block. At the same time, a selfish miner Ms
also computes the block bn+1. Instead of publishing his block,
Mschooses to withhold it and successfully mines two more
blocks bn+2 and bn+3. Despite Mh’s block being added to
the Blockchain, we show that Mhcan still be cheated while
having a majority of network’s confidence in his block. Let the
hash value of Mh’s block bn+1 be lower than both the target
threshold and Ms’s block bn+1. If only these two blocks were
presented to the network, Mh’s block would be chosen (due
to its greater computational complexity) over Ms’s block and
appended to the public Blockchain.
However, after some time, Msreleases all of his blocks
bn+1 ,bn+2, and bn+3 and forks the Blockchain at bn+1
. Due to the design protocols of Blockchain, the network
will invariably shift to the longer chain belonging to Msand
discard the block bn+1 of Mh. The effort put forth by Mh
in computing his block will be wasted due to selfish behavior
of Ms. The incentive in adopting this selfish mining strategy
is maximizing block rewards by publishing a longer chain.
It should be noted that excluding the Mh’s block bn+1 from
the Blockchain does not destroy the block, rather it leads to
another significant problem in the network known as “stale
blocks” as shown in section IV-B.
Selfish mining attacks can produce undesirable results for
the rest of the network by invalidating the blocks of honest
miners who contribute to the Blockchain. Furthermore, all the
transactions in the honest miner’s block also get rejected. In
a situation where two selfish miners compete to add their
chains to the network, the chances of a “Blockchain fork”
arise section IV-A. These forks can cause a delay of consensus
in the network, which can further lead to other potential attacks
such as “double-spending” and “fork after withholding”, as
discussed in section VI-B. One selfish activity in the network
has the potential to disrupt the overall network, and therefore
it is imperative to study their relationship with one another.
11
B. The Majority Attack
The majority attack also known as the 51% attack is well
known vulnerability in Blockchain-based applications that can
be exploited when a single attacker, a group of Sybil nodes,
or a mining pool in the network attains the majority of
the network’s hash rate to manipulate the Blockchain. With
majority of network’s hash rate, the attackers are able to
1) prevent transactions or blocks from being verified (thus
making them invalid), 2) reverse transactions during the time
they are in control to allow double-spending, 4) fork the
main Blockchain and split the network, and 3) prevent other
miners (verifiers) from finding any blocks for a short period
of time. Under race conditions, the attackers with over 50%
hash rate are guaranteed to over take other miners and append
their 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 a
transaction in exchange for any product with Alice, it can
replicate the same transaction with Bob and put it on the
block. Transactions on Blockchains are not reversible, and
only one transaction can be considered valid. In the following,
we elaborate the prospects of double-spending with majority
attacks along with the mathematical primitives.
1) Caveats and realities: Mining pools do not always need
51% of the network’s hashing power to carry out the fraudulent
activities. As such, even with less hashing power, similar
objectives can be achieved with a significant probability of
success. To understand this issue, consider the scenario in
which a malicious mining pool with significant hash rate
carries out a transaction T x with a receiver. At the same
time, it generates a fraudulent double-spent transaction T y
from the same parent transaction to trick the receiver. The
receiver, on the other hand, waits for kconfirmations before
releasing the product to the miner. The kconfirmations mean
that ksubsequent blocks have been mined by the network after
mining the transaction T x. During this process, the malicious
miner keeps mining blocks on his end with the double-spent
transaction T y and hopes to fork the Blockchain after he
receives the product from the recipient. By forking the chain,
the malicious miner will be able to invalidate the chain with
transaction T x, and will replace it with his own chain with
double-spent transaction T y.
To launch a successful attack, the malicious miner needs
to publish a longer chain with valid PoW so that the network
switches to his forked version. Miner’s success depends on his
hash rate xas a fraction of the network’s hash rate and the
number of confirmations k. To find the probability of success
P(s)for the attacker, let xbe the fraction of miner’s hashing
power and ybe the fraction of remaining hashing power, where
x+y= 1 [110]. The success probability is:
P(s) = (1, if x>y
(x
y)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 acquires
half of the network’s hash rate, he can trick the recipient with
100% success rate. Moreover, an attacker with hash rate less
than 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
Success Probability P(s)
Number of blocks (k)
x = 0.49
x = 0.45
x = 0.40
x = 0.35
Fig. 10. Change in the success probability P(s)of majority attack with
varying hashing power xand number of confirmations k. Notice that with
0 confirmations, an attacker can always double-spend with any magnitude of
hash power. In that case we describe the user to be optimistic.
TABLE V
ATTACK CO ST R EQU IR ED TO L AUNC H TH E 51% ATTACK ON T HE T OP SI X
BLOCKCHAIN-BASED CRYPTOCURRENCIES. HE RE CAP D EN OTE S THE
MARKET CAP IN USD, ALG O DEN OTE S THE A LG ORI TH M USE D FO R
BLOCK CONSENSUS,AN D COS T DEN OTE S TH E ATTACK CO ST I N USD FOR
LAU NCH IN G THE 51% ATTAC K FO R ONE H OU R.
SYS TEM CAP ALGO HA SH RATE COST
BITCOIN 112.7B SHA-256 35,604 PH/s 486K
ETHEREUM 49.5B Ethash 222 TH/s 347K
B.CAS H 14.9B SHA-256 5,023 PH/s 68K
LITECOIN 5.7B Scrypt 327 TH/s 60K
DAS H 2.1B X11 2 PH/s 15K
MON ERO 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 the
hash power. Bahack et al. [114] show that the majority attacks
are highly feasible with one quarter of the network’s hashing
power. There are online services such as Nicehash, that rent
hashing power to miners on hourly basis [115].
A malicious mining pool can rent the computation power
for a few hours and launch the majority attack on the targeted
cryptocurrency. Since major blockchain systems have a high
aggregate hash rate, the renting cost to launch the 51% attack
on them is (naturally) high. In Table V, we outline the top
six Blockchain-based cryptocurrencies, and the cost required
to successfully launch the 51% attack, based on data obtained
from “51crypto” [116]. We notice that Dash with a market
cap of 2.3 Billion USD can be compromised for one hour by
spending only 17,000 USD (8×10−4% of the market cap).
4) Case studies: A 51% attack is not beyond the realm of
possibilities. In July 2014, a Bitcoin mining pool “GHash.IO”
acquired over 51% of the hash rate for one day [31], which
raised many concerns in the press and media about Bitcoin
and its vulnerabilities, and shed light on the general problem
in Bitcoin-based systems. Although no malicious activity was
carried out, “GHash.IO” later shrunk in size when miners left
12
TABLE VI
LOCATION OF FULL NODES IN THREE MAJOR CRYPTOCURRENCIES. – I N BITC OI N REF ER S TO TH E NOD ES T HAT USE T OR S ERVI CES A ND T HEI R
LO CATIO N CA NNO T BE ID ENT IFI ED.
Bitcoin Ethereum Litecoin
Rank 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 August
2016, a group of attackers, known as “51 crew”, hijacked
two Ethereum Blockchains, namely Krypton and Shift, and
managed to hijack 21,465 Kryptons worth of digital currency
by double-spending. In May 2018, a group of malicious miners
acquired 51% hash rate in Bitcoin Gold and stole $18 million
USD worth of cryptocurrency [117]. In June 2018, four other
notable Blockchain-based cryptocurrencies were also attacked;
namely Monacoin, Zencash, Verge, and Litecoin Cash.
C. Network Attacks
Blockchain applications are decentralized and use peer-to-
peer network architecture as the medium of communication
between the network entities. In this section, we will look into
the attacks associated with the peer-to-peer network and we
will use Bitcoin network as our example to provide details of
these attacks. The attacks associated to the Blockchain network
include among others, the DNS attacks, spatial partitioning,
and Eclipse attacks. For each of these attacks, the goal of the
attacker is to isolate users and miners from the real network,
limit their access to the network resources, or create partition
in the network and enforce conflicting rules among the peers.
1) DNS Attacks: When a node joins the Bitcoin network for
the 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. The
Domain Name System (DNS) can be used as a bootstrapping
mechanism, and DNS seeds are queried by nodes upon joining
the network to obtain further information about other active
peers. The initial DNS query returns one or more DNS A
records along with their corresponding IP addresses of peers
that are accepting incoming connections. Once the new node
establishes connections to the peers, it can send addr command
with port numbers to establish connections with other peers.
It has been mentioned in the developer’s guide of Bitcoin
systems [28] that the DNS opens a wide attack surface to
the Bitcoin networks in general. Namely, the DNS resolution
is vulnerable to man-in-the-middle attacks (at the resolver
side), cache poisoning, and stale records, among many others.
For this attack, an adversary can either inject an invalid list
of seeder nodes in the open source Blockchain software, or
poison DNS cache at the resolver. By default, the Blockchain
Bitcoin
Network
33.33.33.3
Attacker's
Network
22.22.22.2
1.
2.
3.
Attacker User
Attacker poisons
DNS cache
dig seed.bitcoin
.sipa.be.
22.22.22.2
4.
User routed
to Attacker's
Network
Fig. 11. DNS resolution attack on Bitcoin. The attacker poisons DNS cache
and modifies the data. When a user queries the server to obtain IP addresses
of 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 network
discovery. If the attacker injects a fake list of seeders, the user
will be compromised. As a result, the adversary can poten-
tially isolate Blockchain peers and lead them to a counterfeit
network. In Figure 11, we illustrate how a DNS attack can be
carried out by poisoning DNS cache. A node in Bitcoin net-
work has an IP address of 33.33.33.3 (for illustration purpose
only) while the attacker’s node in a counterfeit network has an
IP address 22.22.22.2. The attacker poisons the DNS cache to
lure the user into the counterfeit network. The user makes the
DNS query dig seed.bitcoin.sipa.be. and instead of responding
with 33.33.33.3, the DNS resolver returns 22.22.22.2. As a
result, the user connects to malicious nodes in the counterfeit
network 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 two
types of nodes in most Blockchain applications, namely full
nodes 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
CDF of Full Nodes
ASes and Organizations (x100)
Organizations
ASes
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% of
nodes 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 Blockchain
from the full nodes, when a full node is compromised all of
its associated lightweight nodes are also compromised. Full
nodes in a Blockchain network are spatially distributed across
the Internet. In Table VI, we show the spatial spread of full
nodes in three major Bitcoin systems (cryptocurrency). In each
system, a majority of the nodes is located in United States,
Germany, China, and Russia. The flow of traffic on the Internet
is controlled by Internet Service Providers (ISPs), which own
one or more Autonomous Systems (ASes), responsible for
handling traffic routing. [119], [120].
Spatial concentration of nodes within an AS or an ISP
makes them vulnerable to routing attacks such as BGP hi-
jacking. An adversarial AS can hijack the traffic for a target
AS that hosts a majority of the Blockchain application nodes.
This can disrupt the flow of valuable information, including
transactions and blocks, to the nodes being hosted by the
target AS. When the victim nodes are miners or mining pools,
the attacker can substantially reduce the hash rate of the
Blockchain application, thereby affecting the system activities.
In a mining pool, the miners communicate using stratum
overlay protocol. The stratum servers act as a dropzone where
miners submit their PoW. Stratum servers have a public IP
address that makes them vulnerable to routing attacks and
flood attacks. Apostolaki et al. [29] studied that by hijacking
fewer than 100 border gateway protocol (BGP) prefixes in
Bitcoin, an attacker can isolate up to 50% of the network’s
hash rate. They further explored that 60% of all Bitcoin
traffic traverses only three internet service providers (ISPs).
Every month, over a 100 Bitcoin nodes suffer from routing
attacks and BGP hijacks. Furthermore, they estimated that
the routing attacks can delay block propagation by up to 20
minutes. As mentioned in section IV-B, the average block
computation time in Bitcoin is 10 minutes. Therefore, the
routing attacks can delay the propagation of two or more
blocks to a group of nodes. Such delays increase the likelihood
of other attacks including Blockchain fork, consensus delay,
and double-spending.
TABLE VII
TOP 5M INI NG P OOL S PER H AS H RATE , ASE S,AND ORGANIZATIONS.
65.7% OF M INI NG DATA GO ES TH ROU GH ON LY THR EE O RGA NI ZATIO NS .
ALI BABA A LON E HA S A VIE W OF AT LE AS T 60% OF TH E MIN IN G DATA.
WE EXCLUDE THE REMAINING 12 M INI NG PO OL S FRO M THE S TU DY AS
THEIR TOTAL CONTRIBUTION TO HASH RATE IS MINIMAL.
Mining Pool H. Rate % ASes ISP
BTC.com 25% AS37963 Alibaba
AS45102 AliBaba
Antpool 12.4% AS45102 AliBaba
ViaBTC 11.7% AS45102 AliBaba
BTC.TOP 10.3% AS45102 AliBaba
F2Pool 6.3% AS45102 AliBaba
AS58563 Chinanet
12 others 34.3% — —
To verify their results and further analyze the spatial
vulnerability of Bitcoin network, we replicated their study
and noticed that Bitcoin network has further centralized with
respect to ASes and ISPs. We crawled data from “Bitnodes”,
an online service that maintains information related to full
nodes in Bitcoin [105]. In Figure 12, we plot the CDF of
the spatial distribution of full nodes across ASes and ISPs in
the world. In Table VII, we show the distribution of mining
pools across ASes and ISPs in Bitcoin. Notice that 60% of the
hash rate is solely intercepted by AliBaba. Our results show
that compared to the prior work by Apostolaki et al. [29],
the Bitcoin network has further centralized and become more
vulnerable to routing attacks.
Case studies. Over the last few years, a number of BGP
attacks have been launched against ASes that host mining
pools or cryptocurrency exchanges. In 2014, a malicious
ISP in Canada announced BGP prefixes belonging to major
ISPs including Amazon, OVH, Digital Ocean, LeaseWeb, and
Alibaba, and intercepted the traffic routed to mining pools. As
a result, the attacker made a fortune of 83,000 USD. In April
2018, BGP attacks were launched against MyEtherWallet.com,
an open source web application used for exchanging Ethereum
tokens online. Attackers managed to steal 152,000 USD from
the web application [121].
3) Eclipse Attacks: Blockchain’s peer-to-peer system is
also vulnerable to a form of attack known as the eclipse attack
[30], [112], [122], in which a group of malicious nodes isolates
its neighboring nodes using IP addresses, thereby compro-
mising their incoming and outgoing traffic. For example in
Bitcoin, a node can actively connect to all the other nodes
in the network, forming a node cluster. In the node cluster,
every peer is aware of the IP address of all other peers. With
sufficient compromised nodes in a cluster, the attacker can
isolate honest nodes and change their Blockchain view. He
can control their incoming and outgoing traffic and feed them
with fake information regarding Blockchain and transactions.
In Figure 13, we illustrate this attack procedure. As long
as the honest node maintains a connection with one other
honest node, it is likely to receive the correct information
to maintain the true state of the Blockchain. However, when
the 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 nodes
represent the malicious nodes that form a cluster around the blue nodes. If the connection between the honest nodes is compromised, the malicious nodes may
feed 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 fed
with fake transactions and blocks, they eventually develop the
wrong view of the state of Blockchain and become part of the
malicious node cluster. Furthermore, if another honest node
establishes a connection with the malicious node cluster, it
is also exposed to the same vulnerability which leads to the
cascade effect of propagation of fake transactions and blocks.
D. Distributed Denial of Service Attacks
One of the most common attacks on online services is the
distributed denial-of-service (DDoS) attack [123]. Blockchain
technology, and despite being a peer-to-peer system, is still
prone to DDoS attacks. Blockchain-based applications, such
as Bitcoin and Ethereum, have repeatedly suffered from these
attacks [124]–[128]. DDoS attacks manifest themselves in
a number of ways, depending upon the application nature,
network architecture, and peers behavior. For example, in the
Bitcoin network, the 51% attack can lead to denial-of-service.
Specifically, if a group of miners acquire a significant hashing
power, they can prevent other miners from adding their mined
blocks to the Blockchain, invalidate ongoing transactions, and
cause service failure in the network. Intentional forks; forks
that are the result of malicious behavior; can turn into hard
forks, resulting in similar outcomes of denial-of-service.
1) Stress testing: Another possibility for the attack is due
to the limited number of transactions per block a Blockchain
application can process in a given time. For example, on
average, it takes the Bitcoin network 10 minutes to mine a
block, which has a maximum size of 1MB. Although the
size of transactions in Bitcoin varies, the average size of a
transaction in Bitcoin is approximately 500 bytes, allowing
approximately 2,000 transactions per block on average—the
maximum number of transactions added to a block in Bitcoin
is reported to be 2,210 [93]. Furthermore, the average time
needed to mine a block, based on the predefined difficulty, is
approximately 10 minutes. As such, for all current transactions
in 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 transaction
requires a minimum of two peers (identified by two different
public identifiers) to be involved in a transaction, the total
active peers served by the network per minute (i.e. where
a block containing their transaction will be mined) will not
exceed 200 peers. Given these constraints, the throughput of
0
0.2
0.4
0.6
0.8
1
07/01/16
09/01/16
11/01/16
01/01/17
03/01/17
05/01/17
07/01/17
09/01/17
11/01/17
01/01/18
03/01/18
05/01/18
Normalized Value
Dates (mm/dd/yy)
Mempool Size
Fee
Fig. 14. Bitcoin mempool size and average fee paid to the miner. It can be
observed from the figure that as the mempool size is increases, the fee paid
to the miners also increases.
Bitcoin is 3-7 transactions per second. Throughput of Bitcoin
is low compared to mainstream payment processors such as
Visa Credit that can verify up to 2,000 transactions per second.
An adversary may exploit the aforementioned operational
reality 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 several
dust transactions (e.g., 0.001 BTC per transaction) between
the various Sybil identities under his control. By introducing a
large number of transactions of small value over a short period
of time, the network will be congested by creating blocks
containing those transactions, and service to legitimate users
in the network will be denied. As a result of this congestion
the 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 transactions
to include in a block. However, this is discouraged by design
in Bitcoin, as outlined by Satoshi. Blocks today even include
transactions of value as low as 0.0001 BTC, which makes
flooding the network with low-value transactions possible.
2) Mempool flooding: Another form of DDoS attack is
carried 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, the
mempool size has no size limit. However, users estimate the
size of mempools to prioritize their transactions. If there are
more transactions in the mempool, then the competition for
mining becomes high. To prioritize their transactions, users
start paying more mining fees as an incentive for miners. Saad
et al. [33], identified a low cost DDoS attack on Blockchain
applications in which the adversary along with Sybil nodes
may flood the mempools with unconfirmed transactions. Such
an attack creates panic among the legitimate users who are
tempted to pay higher mining fee to prioritize their transactions
while 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 been
flooding 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,500
unconfirmed spam transactions which increased the mempool
size by 45MB. The increased size led to a spike in the mining
fee and legitimate users were propelled to pay higher fee to
get their transactions mined [129]. In Figure 14, we plot the
mempool size and the mining fee of Bitcoin over the last two
years. We use min-max normalization to scale the data points.
4) DDoS Attacks in Private Blockchains: In PBFT-based
private Blockchains, a DDoS attack can be launched if
the adversary controls ≈33% replicas [130]. In the private
Blockchains, the size of the network is known to the par-
ticipating nodes, which allows the adversary to calculate the
number of sybil nodes he needs to introduce in the network
for an attack. Assuming that the adversary controls fsybil
nodes such that the total network size is n < 3f+ 1, then
the attacker will be able to launch a DDoS attack to stop the
verification process. For each transaction sent by the primary,
the sybil replicas will not reply with their approvals. Since the
primary will need approvals from at least 3f+ 1 replicas, it
will not be able to process any transaction, and the system
activities will be halted leading to a DDoS attack.
In public Blockchains, launching such an attack can be
costly. The adversary needs to have either the majority of the
total hash rate, the majority of stake, or control over 50% net-
work peers. Considering that public Blockchain applications
such 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 size
does not grow beyond a few hundred nodes, whereby the
adversary needs to control only 33% replicas or just the
primary replica, making the attack on private Blockchains
more 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 withhold
important information that needs to be relayed across the
network. Some of the known attacks of this nature are “The
Finney Attack” and “Block Withholding Attack” [131].
1) The Finney attack: The Finney attack is a variant of
the double-spending attack in which a miner delays block
propagation to double-spend his transaction [132], [133]. The
miner generates a transaction, computes a block, and chooses
not to relay the block. In the meantime, he generates a
duplicate of his previous transaction and sends it to a recipient.
After the recipient accepts the transaction and delivers the
product, the miner publishes his previous block with the orig-
inal transaction in it. Therefore, the previous transaction sent
to the recipient becomes invalid and the miner successfully
double-spends transaction.
The Finney attack has low success probability due to short
block intervals and time sensitive attack procedure. The block
time in Bitcoin and Ethereum are 10 minutes and 15 seconds.
If an attacker attempts to launch this attack on Ethereum, it
is unlikely that he will be able to 1) generate a double spent
transaction, 2) trick an optimistic receiver, 3) receive product
before confirmation, and 4) publish a block before any other
miner, within 15 seconds. Since the attack procedure is more
time consuming than the block interval time, Finney attack is
highly infeasible and as such, no case of Finney attack has yet
been reported on any cryptocurrency.
2) Classical block withholding attack: The block withhold-
ing attack is launched against decentralized mining pools with
intent to harm the pool operator by withholding a valid PoW.
[134], [135]. In decentralized mining pools, all participants
consume electricity and CPU power to find a nonce whose
value of a hash with the block is less than the target threshold.
Once the valid solution is found, all participants are rewarded
based on their aggregate effort put towards the computation
of the solution. Since nonce finding is a lottery-based system,
therefore, miners with less hash power may come up with a
valid solution before other miners with a higher hash rate. In
the block withholding attack, a compromised miner in the pool
finds the proof-of-work and chooses not to disclose it to the
pool operator. Unaware of the compromised miner, the rest of
the miners in the pool waste their resources to find the nonce
and eventually lose the race. The malicious miner then can
collude with other mining pools and share the PoW with them
for a higher reward, or even publish the block independently
with a different identity. Due to this unfair behavior of one
miner in the pool, the entire pool is deprived of block rewards.
Another form of withholding attack is possible when two
mining pools intentionally try to fork the Blockchain to create
a network partition [89]. For instance let there be two mining
pools in a cryptocurrency, namely MpAand MpB, and M pA
computes a valid block but decides not to publish it. MpA
waits for MpBto compute and publish the block. As soon
as MpBreleases its block, M pAalso releases its block and
resulting in two valid blocks in the network. This will fork the
Blockchain and nodes in the network will have a consensus
disagreement upon receiving two valid blocks. Although this
attack may partition the network, it may also cause loss to both
mining pools. Therefore, no such attack has been reported in
any 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 more
rewarding than block withholding attacks. In the following,
16
Node A Node B Node C
Verification
Time v1(t)
Verification
Time v2(t)
block
getdata
inv
block
inv
Fig. 15. Block propagation between nodes A, B, and C. Notice that the
maximum time is consumed in block verification, v1(t)and v2(t). Consensus
delay 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 MpAand
MpBrespectively. 2) The miner computes a valid PoW in
mining pool MpA. 3) He withholds the solution and only
publishes the block once MpBalso publishes the block. 4) The
network selects one block among the two. 5) The malicious
miner gets rewarded either way.
Kwon et al. [89] also show that if the FAW attack is
launched by two or more mining pools against each other, then
the bigger mining pool will always win in the race condition.
Therefore, the FAW attack is always more profitable than
selfish mining and block withholding.
4) Block Withholding in Private Blockchains: In private
Blockchains, the primary replica can launch a block with-
holding attack after receiving a confirmations from other
replicas. Private Blockchains work under the assumption that
the primary will faithfully execute the protocol. Moreover, the
adversarial model assumes that the attacker controls a subset
of faulty replicas among all the other replicas. However, if the
adversary also controls the primary replica, he can withhold
blocks and transactions from all other replicas. As shown in
Figure 2, the primary receives a transaction request from the
client and sends the transaction to other replicas to obtain their
signatures. Finally, it computes the block when a sufficient
number of transactions are processed. However, if the primary
gets compromised, he may: 1) withhold a transaction issued by
the 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 block
and withhold it from the rest of the network. In each case, the
primary can launch a withholding attack to compromise the
system and delay the transaction processing.
F. Consensus Delay
Another 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 latency
or prevent peers from reaching consensus about the state of
the Blockchain. In Figure 15, we illustrate the delays incurred
during block propagation in Bitcoin. When node A receives a
block, it authenticates the block and sends an inv message to
its neighbors including node B. If node B does not have the
block, it sends getdata message back to A. Upon receiving
the getdada message from B, A sends the block to B. Once B
has the block, it also authenticates the block and sends an inv
message to its neighbors. As Figure 15 shows, the maximum
delay is incurred during authenticity check (v1(t)and v2(t)).
The other delays include transmission delays and propagation
delays of messages and block. Transmission delays are subject
to the size of block and messages while the propagation delays
depend upon the bandwidth of the link between the nodes.
In such conditions, intentional delays can be introduced
in the network by propagating stale blocks or double-spent
transactions. The nodes which are not aware of stale blocks
will respond with getdata messages and upon receiving the
block, they will waste time in its verification. If an attacker
controls a set of sybil nodes in the node cluster section V-C,
it can add significant delays among legitimate nodes in that
cluster. The problem is further exacerbated for time-critical
applications 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 also
cause consensus delay by using sybil nodes. As shown in
Figure 2, a major component of transaction processing is
the exchange of messages and signatures among participating
replicas. Especially, in the prepare and commit phase, each
replica sends its signatures to every other replica. As outlined
in section V-D, if the adversary controls more than 33% of
replicas, he can launch a DoS attack. On the other hand, if
the adversary controls fewer replicas, he may still be able to
cause consensus delay in transaction processing [137], [138].
The sybil nodes can also send bogus signatures to the other
replicas during the prepare phase and the commit phase. Since
each 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 stall
the completion of the commit phase and eventually cause a
delay in the reply phase. As a result, the primary will not
receive the required number of approvals for the transaction
verification. This will cause consensus delay and reduce the
throughput of the application.
G. Timejacking Attacks
In Bitcoin systems, such as Bitcoin, full nodes maintain an
internal counter that denotes the network time. The network
time is obtained by receiving a version message ver from
neighboring peers and calculating its median during the boot-
straping phase. If the median time of all the neighboring peers
exceeds 70 minutes, the network time counter is automatically
reverted to the system time of the node. This creates an attack
opportunity for malicious nodes which may connect to the
target node as shown in Figure 13. In such case, the attacker
can feed varying timestamps with median value exceeding 70
minutes. Furthermore, in Bitcoin, for example, a node rejects
a block if its timestamp exceeds the network time by 120
minutes. An attacker can compute a new block and set its
timestamp ahead of network’s timestamp by 50 minutes. The
attacker then, along with Sybil nodes, can slow the network
time of a target node by launching a timejacking attack against
it. As a result, the difference between the block time and the
target node’s counter will exceed 120 minutes. As a result, if
17
the target node is presented with the block, it will reject it
and all the subsequent blocks. The target node eventually gets
isolated from the activities of the main network.
H. Countering Peer-to-Peer Attacks
Prior research has been conducted to address the problem of
selfish mining, and researchers have suggested several possible
solutions [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 block
expires (calculated by the honest miners), it is rejected by the
network. Heilman [140] impedes the profitability of selfish
miners by introducing a defense scheme called “Freshness
Preferred.” Heilman [140] builds on top of the previous work
by Eyal and Sirer [110] by adding unforgeable timestamps
to blocks and prefers blocks with more recent timestamps
compared to older ones. His work reduces the incentive for
selfish miners to withhold their blocks for long periods of time.
Eyal [26] modeled a game between two mining pools carrying
out block withholding and discovered miner’s dilemma, where
both mining pools suffer a loss in equilibrium.
Majority attacks have also been widely discussed with coun-
termeasures proposed to overcome a monopoly in Blockchain
networks. Miller et al. [143] proposed changes to the PoW
puzzle in Bitcoin in order to restrict coalitions of mining
pools for majority attacks. Their proposed design incorpo-
rates nonoutsourceable puzzles in PoW, in which mining
pools that outsource their mining work risk losing mining
rewards. Saad et al. [144] leveraged the expected transaction
confirmation height and the block publishing height to detect
selfish mining behavior in PoW-based Blockchains. Using the
relationship between the two features, they created a “truth
state” for each published block in order to distinguish between
a legitimate block and a selfishly mined block. Also addressing
the 51% attack, Bastiaan [31] introduced the concept of “two
phase proof-of-work” (2P-PoW). 2P-PoW is a continuous-time
Markov chain (CTMC) model that incorporates two challenges
for miners to solve instead of one. The states of the CTMCs
prevent the pool from increasing beyond an alarming size by
shrinking incentive for miners in the pool. 2P-PoW prevents
large pools from creating a hegemony by either outsourcing a
major chunk of their hash rate or exposing the private keys of
the pool operator.
Johnson et al. [145] proposed a game-theoretic approach
to address DDoS attacks against mining pools. Other counter-
measures include putting a cap on the minimum amount in the
transaction that a sender can have or increasing the block size
to accommodate more transactions. Yet another approach is to
reduce the difficulty in mining blocks so that more blocks can
be mined with no transactions going to waste. Each of these
propositions have their own caveats.
Increasing the block size might not be sufficient, since a
powerful adversary can still stress the network by generat-
ing dust transactions. On the other hand, reducing difficulty
will reduce the block time but it will increase the number
of orphaned blocks in the system and the overall size of
the Blockchain. At the time of writing this paper, Bitcoin
and Ethereum Blockchain size was recorded to be 162 GB
and 450 GB, respectively [146]. Saad et al. [33] proposed
fee-based and age-based countermeasures to prevent DDoS
attack on Blockchain mempools. In their work, they shifted
the transaction filtering process from the mining pools to
the mempools. Their proposed countermeasures optimize the
mempool size and raise the attack cost for the attacker while
favoring legitimate users in the system.
To prevent DNS-based attacks, extensive research has been
carried out to equip the Blockchain systems with DNS attack
defenses [147]–[149]. Apostolaki et al. [29] proposed long-
and short-term solutions for routing attacks. They propose
routing-aware peer selections to maximize diversity of internet
paths and limit the vantage points for attacks. They also pro-
posed peer behavior monitoring to check abrupt disconnections
and unusual latency in block delivery.
Other solutions to prevent delay attacks include end-to-
end encryption for message propagation. Another possible
approach to prevent spatial partitioning is the decentralized
hosting of mining pools and full nodes over the Internet. As
shown in Table VI. 50% of Ethereum nodes are located within
two countries, which makes them vulnerable to a nation-state
adversary. In order to prevent that, new nodes must be hosted
on cloud services that have a higher geographical spread and
network diversity. The dimensions we explored in this paper
encourage additional research on Blockchain technology in the
areas regarding DNS and DDoS attacks.
To counter block withholding attacks [131], [141], [150],
[151], Schrijve et al. [152] introduced an incentive-compatible
reward scheme that discourages a malicious miner from carry-
ing out withholding attacks against the targeted mining pool.
Rosenfeld [153] introduced a Honeypot technique to lure
rogue miners into a “trap”, thereby catching the miner who
withholds valid solutions. Bag and Sakurai [151] proposed
additional incentives for finding a valid solution for a block
in order to prevent mining collusion. Concurrent to their prior
work, Bag et al. [150] introduced a new scheme that blinds
the miners in the pool from the current target to obfuscate
their ability to distinguish between a partial and full PoW.
Their proposed solution also binds the pool operator to fairly
distribute the reward to the winning miner.
The FAW attack can be countered by introducing times-
tampped beacons in the assignment given to the miners by
the pool operators [89]. As a response to each assignment,
the miners calculate the partial proof-of-work and send the
response to the pool operator embedded with the beacon value.
The beacon value is updated after a few seconds to catch a
malicious miner if he withhold the valid solution and later
propagates it in the network. However, the authors also noticed
that this solution may not be practical in some situations
and conclude that FAW attacks remain an open problem for
the research community to address. To address the security
issues in private Blockchains, several variants of PBFT protcol
have been proposed. Those protocols try to increase the
fault tolerance beyond 33% [154], [155] and use hardware
assistance to detect the behavior of faulty replicas [156]. The
key challenge in private Blockchains is the high message
complexity that restricts the scalability. As a result, in a small
network, the adversary can easily compromise 33% replicas.
To address this issue, Liu et al. [156] proposed a scalable
Byzantine 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 Blockchain
networks that can withstand various forms of attacks.
VI. AP PL IC ATIO N ORIENTED ATTACK S
The Blockchain and associated peer-to-peer system are
separate from the application services using them. Based on
the nature of the Blockchain applications, they have their
own vulnerabilities and attack surface. Therefore, we expect a
significant number of attacks related to various applications,
which we address in this section. Our analysis is primarily on
applications such as cryptocurrencies and smart contracts.
A. Blockchain Ingestion and Anonymity
Public Blockchains have a weak notion of anonymity, and
they provide open data accessibility to the public. As such, the
analysis of the public Blockchain can reveal useful information
to an adversary. This process is known as Blockchain ingestion
and it might not be desirable to the Blockchain application or
its users. For example, a credit card company in the open mar-
ket can use data analytics to delve into public information on
the Blockchain and optimize its own schemes to compete with
the digital currency. To demonstrate the potential exploitation
of the public data, Fleder et al. [37] used graph analysis to
create directed links between Blockchain data of Bitcoin and
associated identities of the wallet users.
Mt. Gox incident. In 2013, two attackers exploited the
public nature of Bitcoin Blockchain to carry out fraudulent
transactions and create a fake demand of bitcoins at multiple
exchanges. The main target of attack was Mt. Gox; the biggest
Bitcoin exchange in Japan in 2013. The attackers frequently
carried out a sequence of fraudulent transactions at Mt. Gox.
Since the Blockchain is public, the rate of transactions was
noted by other exchanges too and it was assumed as if the
overall demand of the coins had increased. As a result, the
price of Bitcoin increased from $150 USD to $1,000 USD
towards the end of 2013. The trade carried out at Mt. Gox
by the attackers was not backed by the real coins, which
eventually led to the bankruptcy of the exchange.
Illegal Activities. Anonymity in Blockchain-based cryptocur-
rencies provides lucrative opportunities for miscreants to carry
out fraudulent activities. As such, cryptocurrencies have be-
come a popular source of funds transfer for illicit activities
associated with the Deep Web [157], [158]. Since the use of fiat
currency leaves traces on Blockchains that can be tracked by
law enforcement, cryptocurrencies on the other hand, preserve
the anonymity of the user. This is a key reason why various
countries 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 Bitcoin
ATMs. Furthermore, the absence of a central authority makes
it harder to claim fraud and expect reimbursement. Therefore,
design constructs of Blockchain applications can be exploited
to facilitate cyber crimes and online frauds.
B. Double-Spending
In cryptocurrencies, double-spending refers to the use of
a one-time transaction twice or multiple times. To illustrate
double-spending with an example, consider the following
scenario. In cryptocurrency operations, a transaction transfers
the ownership of asset from a sender’s address to the receiver’s
public address, and the value of the transaction is signed by
the signer with a private key. Once the transaction is signed, it
is broadcast to the network upon which the receiver validates
the transaction. The validation at the recipient’s end happens
when the receiver looks up the unspent transaction output of
the sender, verifies the sender’s signature, and waits for the
transaction to be mined into a valid block. The process takes
a few minutes depending upon the size of the mempool, the
throughput of the network, priority factor of the transaction,
and the block computation time of the cryptocurrency. In
Bitcoin, the average time of block mining is 10 minutes.
In an environment of fast transactions [54], [160] or if a
receiver is optimistic, he may release the product to the sender
before the transaction gets mined into the Blockchain. As
such, this gives the sender an opportunity to sign the same
transaction and send it to another recipient. This behavior of
signing the same transaction with a private key and sending
it to two different receivers is known as double-spending. In
double-spending there are two transactions derived from the
same unspent transaction output of the sender, and only one of
them gets incorporated into the Blockchain. In Figure 16, we
illustrate how a double-spending attack can be carried out in a
cryptocurrency. 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 verification
and propagation process, which increase the chances of an
adversary to perform double-spending. In March 2013, due
to 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 launched
on web and cloud-based services to illegally perform PoW
for Blockchain-based cryptocurrencies without consent [161],
[162]. The most recent as well as the most prevalent form
of cryptojacking is the in-browser cryptojacking, which turns
websites into mining pools [163]. PoW requires processor
intensive mathematical calculations which usually involves
finding a target hash value. As the aggregate hash rate of
the cryptocurrency network increases, the associated difficulty
to compute a block also increases. To meet the difficulty
requirements, sophisticated hardware such as GPUs and ASIC
chips [91] are used by miners. Mining pools expand their
hashing capability by inviting more miners to join their pool
and purchasing expensive hardware with better computation
capabilities. As a result, the mining process in major Bitcoin
systems becomes an expensive and competitive game that
prevents small miners from mining blocks independently.
1) Cloud-based Cryptojacking: To compensate for that,
malicious miners have found a way of to expand their hash
power 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 Transactions
Computes Block. (Transaction 3 Rejected)
Miner
Block Hash
Previous Block Hash
Merkel Root
Number of Transactions
Coinbase Reward
Transaction 2
Transaction 4
Transaction 5
3.
B1 B2 B3 B4 B5
Blockchain
Memory Pool
Transaction 2
Transaction 3
Transaction 4
Transaction 5 Block Added
4.
Block 5 (B5)
User A
Balance
Transaction 1
Transaction 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 sends
it 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 2
or Transaction 3. If Transaction 3 gets rejected, user C suffers the loss.
0
20
40
60
80
100
06/01/17
07/01/17
08/01/17
09/01/17
10/01/17
11/01/17
12/01/17
01/01/18
02/01/18
03/01/18
04/01/18
05/01/18
06/01/18
07/01/18
Popularity Index
Dates (yy/mm/dd)
Cryptojacking
Coinhive
Monero
(a) Google popularity index
0
20
40
60
80
100
0 5 10 15 20 25 30
% CPU Usage
Time (Seconds)
browar.bz
seriesfree.to
megapastes.com
legendaoficial.net
(b) Percentage CPU usage by four cryptojacking
websites when JavaScript is enabled
0
20
40
60
80
100
0 5 10 15 20 25 30
% CPU Usage
Time (Seconds)
browar.bz
seriesfree.to
megapastes.com
legendaoficial.net
(c) Percentage CPU usage by four cryptojacking
websites 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 been
a 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 four
cryptojacking 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 perform
PoW calculations for the attacker. Initially, these attacks were
launched against cloud service providers, where malicious
users performed covert mining operations on virtual machines
and exhausted cloud resources. This behavior was first noticed
by Tahir et al. [40], where they also proposed countermeasures
in 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 the
web in 2017, and has been soaring in popularity as shown
in Figure 17(a). Web-based cryptojacking is used by attack-
ers who inject malicious JavaScript code into websites that
secretly mine tokens without the consent of their visitors. In
browser-based cryptojacking, the web browser on the client
device executes JavaScript code that establishes a WebSocket
connection with a remote dropzone server. The server then
sends the target to the client, which computes hashes for PoW
and transmits them back to the server. During this process, the
device owner remains unknown of this background activity
and seamlessly continues to browse the website. In-browser
cryptojacking not only poses a major privacy threat, it also
harms the performance of the visiting device, since PoW-
based hash computations are processor-intensive and may lead
to excessive CPU usage and battery drainage. To further
facilitate these attacks, online platforms such as coinhive and
crypto-loot [164], [165] emerged in 2017, to provide simple
code snippets for the attackers and website owners. Those
services 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 cryptocurrency
called Monero [166]. In Figure 19, we provide the JavaScript
cryptojacking code used by attackers to bind victim website to
their account at Coinhive. The code listing shows that when a
browser loads coinhive.min.js file, it establishes a WebSocket
connection with coinhive server and passes the attacker’s key
to bind with the dropzone server. It then receives a target and
submits the corresponding hashes to the server over the same
socket connection [167]. The throttling parameter controls
the hash rate of the victim device and is adjustable to the
requirement of the attacker.
In Figure 17(b) and Figure 17(c), we plot the processor
usage of four cryptojacking websites with JavaScript enabled
and disabled. It can be noticed that each website uses different
CPU power when JavaScript is enabled, indicating varying
thresholds of throttling parameters. Figure 17 also shows that
when the JavaScript is disabled, the browser cannot execute
the malicious script and is unable to perform cryptojacking.
In-browser cryptojacking is a relatively new attack related
to the PoW-based Blockchain applications, therefore no prior
research is available that looks into the operations and effects
of this attack. However, owing to the incidents reported in the
news, it can be inferred that cryptojacking is becoming popular
over time. In 17(a), we show the popularity index of the terms
“Cryptojacking”, “Coinhive”, and “Monero”, as recorded by
Google 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. Moreover
there is more similarity in the search for Coinhive and Monero.
<script
src="./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 in
the search for each term, indicating the interest shown by the
users in cryptojacking. Additionally, in Figure 18, we show
the global distribution of these searches.
3) Case studies: Cryptojacking is considered as an emerg-
ing threat to the security and privacy of Bitcoin systems, by
the research community. Symantec’s latest Internet Security
Threat Report (ISTR) reveals that cryptojacking attacks on
websites have increased by 8500% during 2017 [169]. In
February 2018, a large scale cryptojacking attack was launched
that compromised more than 4000 websites worldwide includ-
ing the websites of UK National Health Service (NHS) and US
Federal Judiciary [167]. UK’s National Cyber Security Centre
(NCSC) has declared cryptojacking a “significant threat” in its
yearly cyber security report [170].
D. Wallet Theft
Where credentials, such as keys, associated with peers in
the 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-encrypted
by default, allowing an adversary to learn the credentials
associated with it and the nature of transactions issued by it.
Even when a wallet is safely guarded on the host, launching
a malware attack on the host will allow the adversary to steal
the wallet. Finally, with many third-party services enabling
storage of wallets, those services can also be compromised
and the wallets can be leaked to an adversary [48].
Case studies. In December 2017, $63 million USD worth
bitcoins were stolen from the wallet of a cryptocurrency
company, NiceHash [171]. During the hack, the entire contents
in NiceHash’s Bitcoin wallet were stolen. In November 2017,
Tether Treasury wallet was hacked and $31 million USD
worth bitcoins were stolen from it. Also in November 2017,
$280 million USD worth of ether was locked up after a user
deleted the code in the digital wallet hosted by a company
named Parity Technologies. In July 2016, the social media
Blockchain “Steemit” was attacked and $85,000 USD worth
TABLE VIII
TOP 5S OFT WARE V ERS IO NS US ED BY BITCOIN FULL NODES ALONG WITH
TH EIR R EL EAS E DATE,L AG FRO M TH E DATE OF C OLL EC TIO N IN DAYS ,
AN D PER CE NTAGE O F USE RS . THE RECENT VERSION 0.16.0 HA S 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 January
2015, Bitstamp’s Bitcoin wallet was hacked, resulting in a
loss of $5.1 million USD worth bitcoins [172].
Key Exposure and Theft. A well-known problem in
Blockchain-based cryptocurrencies is private key exposure and
theft. If the attacker acquires the private key belonging to a
user, he can sign and generate a new transaction on behalf
of the user, and possibly spend his balance to unauthorized
recipients. Brengel et al. [173] studied the key leakage in
Bitcoin by studying the Bitcoin Blockchain for ECDSA nonce
reuse. Their results show that ECDSA nonce reuse is misused
in Bitcoin to generate transactions on behalf of users. Sim-
ilarly, Breitner et al. [174] performed cryptanalytics attacks
on Bitcoin, Ethereum, and Ripple to expose their private
keys. They used a lattice-based algorithm to compute private
ECDSA keys that were used in biased signatures.
Software Client Vulnerabilities. Public Blockchain applica-
tions such as Bitcoin and Ethereum have open-source software
clients that enable users to connect with the network. Over
time, new software versions are released, implementing new
rules and upgrades. An upgrade is also released to patch
vulnerability in an old version. In Bitcoin, the Bitcoin Core
v0.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 exposed
to its vulnerabilities. In Table VIII, we show the diversity in
adoption of a Bitcoin software client. Notice that only 36.28%
of the nodes are using the most updated software version that
is immune to the denial-of-service attack.
Moreover, the open-source code can be exploited by an
adversary to release a new update with a malicious code and
bugs. If a user installs the software, it can provide access to
the 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 Contracts
As new applications are built on top of Blockchain, their
own limitations along with Blockchain vulnerabilities, create a
new attack surface. Smart contracts belong to the generation of
Blockchain 2.0 and in this section, we will explore the attack
possibilities in smart contracts. The most well known smart
contract application in digital world is Ethereum, which uses
Solidity 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 series
of attacks. In Figure 20, we demonstrate a vulnerable smart
contract code that steals a sender’s balance. “The DAO” had a
similar vulnerability in their smart contract which resulted in
a loss of $50 million USD. Some of the well known attacks
on Ethereum smart contracts include reentrancy attack, over
and under flow attacks, replay attacks, short address attacks
and reordering attacks [42], [176].
1) Reentrancy attacks: In reentrancy attack, if the user does
not update the balance before sending ether, an attacker can
steal all the ether stored in the contract by recursively making
calls to the call.value() method in a ERC20 token. As such, a
careless user may lose his entire balance in the contract if he
forgets to update his balance.
2) DoS attacks: DoS attack in smart contract enables
a malicious actor to keep funds and authority to himself.
Consider an example of a smart contract auction in which
a malicious bidder tries to become the leader of an auction
illustrated in Figure 22. The vulnerable contract prevents
refunds to the old leader of the contract and makes the attacker
the new leader. Moreover, it cancels all the bid() requests
sent by other bidders and keeps the attacker as the leader
of the auction. Another form of DoS attack in Ethereum
smart contract involves exploiting the gas limit set by the
contract Figure 21. In Ethereum, if the overall gas consumed
by the smart contract upon execution exceeds the gas limit,
the contract transaction fails. An attacker can exploit this by
adding multiple addresses with refund needs. Upon execution,
the gas required to refund those addresses may exceed the total
gas 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 someone
sends large amount of ether, exceeding (2256), the value of the
bet would be set to 0. Although exchange of an ether value
greater than (2256) is unrealistic, but it remains a programming
vulnerability in smart contracts written in Solidity.
4) Short address attacks: The short address attack exploits
a bug in Ethereum’s virtual machine to make extra tokens
on limited purchases. The short address attack is mostly
applicable on ERC20 tokens. For this attack, the attacker
creates an Ethereum wallet ending with 0digit. Then he makes
a purchase on the address by removing the last 0. If the
contract has a sufficient balance, then the buy function does
not check the sender’s address and Ethereum’s virtual machine
appends missing 0to complete the address. As a result, for
each 1000 tokens bought, the machine returns 256000 tokens.
// Vulnerable Smart Contract
mapping (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 can
make recursive call to withdraw() again.
userBalance[msg.sender] = 0;
}
Fig. 20. Reentrancy attack on smart contract code [41]. A major problem
with calling external contracts is that they alter the control flow of the code
that the running contract does not anticipate. In this contract, an external call
is made before the user’s balance is set to 0.
// DoS attack
contract Malicious_Auction {
address presentLeader;
uint maxBid;
function bid() payable {
require(msg.value > maxBid);
require(presentLeader.send(maxBid)); //
Refund the old leader, if it fails then
revert
presentLeader = msg.sender;
maxBid = msg.value;}}
Fig. 21. DoS attack on a vulnerable smart contract in which the malicious
bidder may revert funds to the old leader and prevent other bidders from
calling the bid() function. As such the malicious bidder remains the leader of
the auction for as long as he wants.
5) Forcible balance transfer: In vulnerable smart contract
codes, forcible balance transfer to the contract can occur
without a fallback function. This can be used to exhaust the
gas limit and disallow the final transaction.
F. Replay attacks
The replay attack involves making one transactions on two
different Blockchains. For instance, when a cryptocurrency
forks into two separate currencies, users hold equal assets on
both ledgers. A user has an option of carrying out a transaction
on any one of the two chains. In replay attacks, the attacker
sniffs the transaction data on one ledger and replays it on the
other ledger. As such, the user loses assets on both chains. A
simple case can be drawn from Ethereum.
In Ethereum, a transaction signed on one Blockchain is valid
on all Blockchains. Therefore, a transactions made on a test
network can be replicated on the public network to steal funds.
Although Ethereum has taken countermeasures to prevent
replay attacks by incorporating chainID in transactions, users
who do not enable this wallet feature remain vulnerable.
G. Countering Application Oriented Attacks
Attacks on Blockchain applications have various possible
countermeasures. For example, to secure blocks, it is advised
to keep backups of the wallet and secure the keys used for
signing transactions. Passwords are easy to compromise, and
using a strong password is required as a defence against brute-
force attack. However, changing passwords does not change
the keys secured by them, making those keys vulnerable due
to a previous compromised password. Wallet encryption, a
standard practice in the original Bitcoin design, is highly rec-
ommended to cope with vulnerable keys. Other mechanisms to
22
// DoS attack on Gas Limit
struct 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 the
refund. Once all the addresses are refunded, the overall gas used by the smart
contract exceeds its gas limit.
mapping (address => uint256) public userBalance;
// Vulnerable code
function transfer(address _to, uint256 _value) {
// Check if the sender has sufficient balance
require 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, the
contract code does not take into the account if the balance exceeds the value
2256. In such a case, the balance will be set to 0 by default and overflow
attack can be launched.
cope with wallet security include insurance, which technically
does not address the problem by remedying its consequences.
A backup of the keys and wallet is essential because if the
keys are lost, then access to wallet is not possible, and if
some attacker deletes the wallet, all the coins are lost.
New models of cryptocurrency, such as “Zcash”, provide
chain anonymity to the transactions, the users, and the amount
exchanged. As such, the shielded architecture of “Zcash”
Blockchain prevents block ingestion attacks. The double-
spending attack is easily addressed in fast networks, but not
when the network is characterized by high latency and longer
block mining times. One possible approach to deal with the
problem is utilizing one-time (or a few time) signatures, such
as XMSS [177], which reveal the private key of the user if he
tries to double-spend. However, this requires the change in the
current signature algorithms that Blockchain applications have
used. Other proposals include reducing the difficulty parameter
of a Blockchain to enable swift block mining, which is a
reasonable approach, except that it would further facilitate
selfish mining and the rate of stale blocks.
All major attacks on smart contracts in Ethereum are either
related to the vulnerabilities in programming platforms or care-
less programming practices. These attacks can be prevented by
patching 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, reputable
web browsers, including Chrome and Firefox have, launched
web extensions that actively detect WebSocket connections
that trasnmit PoW [178]–[180]. However, as of now, the
extensions use a blacklisting approach to spot the WebSocket
traffic 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 the
contract without a fallback function.
access to the blacklist can easily circumvent detection by using
a relay server between the host and the dropzone server. As of
now, cryptojacking and its defences are open challenges and
require more attention from the community.
VII. REL ATED WORK
The work surveyed for paper includes the prior research
efforts towards the study of Blockchain applications and
their security vulnerabilities. In doing so, we also con-
sulted the Comprehensive Academic Bitcoin Research Archive
(CABRA) [181], a comprehensive list of over 900 research
papers that keep track of ongoing research in Blockchain
systems. CABRA is influenced by a chronological list of
Blockchain papers maintained by Brett Scott [182]. From these
useful repositories, we curated a list of relevant papers for this
study, as starting pointers.
There have been several attempts at understanding the attack
surface of Blockchains by various surveys, which we contrast
to our work in the following. Towards analyzing the attack
surface of Blockchains, Li et al. [183] surveyed various se-
curity aspects of Blockchains by studying popular Blockchain
applications including Bitcoin, Ethereum, and Monero. They
evaluated the robustness of Blockchain applications against
popular 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 Bitcoin
is a motivating example to analyze the attack surface of
Blockchains in general, however, Blockchains have evolved
beyond Bitcoin and their attack surface has increased accord-
ingly. Furthermore, their work does not cover new attacks
related to Blockchain applications such as cryptojacking,
among others. Tara et al. [184], explored the utilization of
the Blockchain technology in providing distributed security
services. They mainly focused on the use of Blockchains
to provide services including authentication, confidentiality,
provenance, and integrity assurance. In contrast, our work is
dedicated 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 as
Namecoin and Peercoin. They also surveyed various security
features of these applications with an emphasis on smart
contracts. In a similar context, Atzei et al. [61] also explored
various attacks limited to Ethereum smart contracts. Compared
to the existing literature, our work goes beyond the state-
of-the-art in outlining new attacks, their implications, their
defenses, and relevant case studies.
Kiran and Stanett [187] perform risk analysis on Bit-
coin, spanning its vulnerabilities and attack surface. They
also explore the risk factors associated with the economics
23
TABLE IX
COU NTE RM EAS URE S AN D THE IR E FFEC TI VEN ES S REL ATED T O THE ATTAC KS S URFAC E OF BLOCKCHAINS. HERE ,#, ,H#DE NOT E OPE N PRO BL EM,
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, including
deflation, volatility, and complicity. Becker et al. [96], out-
lined challenges and security risks associated with PoW-based
Blockchain applications. Moubarak et al. [188] explored the
security challanges of three major Blockchain applications,
namely Bitcoin, Ethereum, and Hyperledger. However, their
work was more directed towards the application attacks and
did not consider the attacks related to the Blockchain’s cryp-
tographic constructs and P2P fabric.
Carlsten et al. [189], analyzed the security features of
Bitcoin in the absence of Block rewards. Since the number
of coins in Bitcoin are deterministic and the coinbase rewards
will eventually end when all the coins are mined, the stake of
miners in the system will take a paradigm shift which might
influence the security properties of Bitcoin. As such, there is an
implicit belief that this might not change the attack surface of
Bitcoin. However, in [189], the authors outline the limitations
of this belief and present new attack avenues and their effects.
As Blockchain applications are evolving, they are being
targeted with new and more sophisticated attacks every day.
In this paper, we look into the prior work and also cover the
emerging vulnerabilities and attacks on Blockchain applica-
tions. We also report the major incidents and case studies
related to each attack and provide future directions for research
and analysis. In Table IX, we outline the possible counter-
measures and their effectiveness for each attack discussed in
our work. The criterion of determining the effectiveness of
a countermeasure is how fully or partially it addresses the
problem. For instance, one way to reduce orphaned blocks is
to 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, in
Figure 25, we provide an illustration of various attacks and
their countermeasures. Note that some countermeasures may
address more than one attack, thereby indicating a common
cure. This can be used to motivate future research directions
in prioritizing defenses.
A. Blockchain Structure Attacks
Analyzing the problems associated to Blockchain’s math-
ematical constructs, Eyal et al. [34], proposed a Byzantine
fault tolerant Blockchain protocol that addresses the problems
of Blockchain fork. Decker and Wattenhofer [171] observed
information propagation in Bitcoin network and introduced a
model that explains the formation of Blockchain forks. From
their results, they concluded that delays in block propagation
are the primary cause of Blockchain forks. Kiffer et al.
[190] analyzed the design space of Ethereum and studied a
large-scale fork that partitioned Ethereum into two separate
networks (Ethereum and Ethereum Classic). They further
analyzed the impact of the fork on users, mining pools, and
the two networks, by exploring the possible gains and security
vulnerabilities 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 than
100 border gateway protocol (BGP) prefixes in Bitcoin, an
attacker 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 with
their countermeasures. Some attacks have common countermeasures which
provides future directions towards a common cure.
They further analyzed that Bitcoin hosting is highly centralized
and 13 ISP’s have a view of more than 30% total mining
traffic. High centralization makes Bitcoin vulnerable to routing
attacks, delay attacks, and DNS attacks. They also show that
over a 100 Bitcoin nodes become victims to BGP hijacks,
every month. In this paper (section V-C), we verify the findings
of Apostolaki et al. [29] and show that over time, Bitcoin
network has further centralized with respect to ASes and ISPs
offering greater vulnerability to partitioning attacks.
Bradbury [191] reviewed various attacks on Bitcoin, namely,
the 51% attack, code-based attacks, double-spending, and dust
transactions. Inspired from the Block Withholding (BWH)
attack, Kwon et al. [89] presented the Fork After Withholding
(FAW) attack which guarantees more rewards to the mining
pools. In nash equilibrium, when two mining pools carry
out BWH attack against each other, they both suffer a loss.
However in current Bitcoin system, the rewards for FAW
attacks are at least 56% more than BWH attacks.
Eyal and Sirer [110] modeled the mining process of
Blockchains and concluded that Bitcoin mining protocol is not
incentive compatible. They also postulated that higher rewards
can lead to new miners joining the selfish mining pool and as
such, can lead to the possibility of a majority attack. Optimal
selfish mining strategies have been studied by Sapirshtein et
al. [139]. In their work, they analyzed the fraction of resources
required to carry out a successful selfish mining attack. They
also provide bounds under which a Blockchain system can be
considered secure against such an attack. Heilman [140] and
Solat 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 carry
out selfish mining. Bastiaan [31] proposed a defense against
the 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 growing
beyond a limit. It does so by forcing the pool owners to either
reduce their hash power or give up their private keys.
The domain of DDoS attacks on Blockchains and mempools
remain an open problem and as such, countermeasures are
being proposed which include: increasing throughput, increas-
ing block size, and limiting the size of the transactions. Since
DDoS attacks manifest themselves in a different way in a peer-
to-peer architecture, as opposed to a centralized system, their
prevention 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, as
new applications are emerging, and Blockchains are evolving
into Blockchain 3.0, their attack surface is broadening and
posing new challenges for security and privacy. Rosenfeld
[193] performed quantitative analysis on successful double-
spending scheme under varying hash rate and number of
confirmations. Solà et al. [53] use a modified signature scheme
that exposes the private key of the double-spender in fast
transactions. Their proposed method protects an optimistic
user in Bitcoin who might be willing to deliever the product
before the confirmation of the received transaction. Atzei et
al. [46] analyzed possible attacks on Ethereum smart contracts
with emphasis on the DAO attacks. They categorize the
attacks based on the vulnerabilities associated with Ethereum
programming language “Solidity”, Ethereum Virtual Machine
(EVM), and the Ethereum Blockchain. Chen et al. [194]
introduced an adaptive gas cost mechanism for Ethereum to
defend against under-priced denial-of-service attacks. Luu et
al. [195], investigated various possibilities through which an
adversary can compromise smart contracts in Ethereum. They
also developed a symbolic execution tool OYENTE, which
actively finds and patches bugs in Ethereum smart contracts.
To observe Blockchain ingestion attacks and privacy leakage
on Bitcoin, Fanti and Viswanath [196] studied the anonymity
properties of Bitcoin’s peer-to-peer and concluded that the
network has weak security properties. To enhance privacy and
anonymization in Bitcoin, Ziegeldorf et al. [197] proposed
decentralized mixing services and shuffle protocols that reduce
the chances of transaction tractability. Although conventional
attacks on Blockchains have been addressed by the commu-
nity, new attacks such as cryptojacking and mempool flooding
have not been explored in depth. By drawing attention to them
in this paper, we hope that active research will be carried our
to build countermeasures for these attacks.
VIII. DISCUSSION AND OPE N DIRECTIONS
Blockchains have become popular in recent years owing to
the increasing use of decentralized systems and the growing
need 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 legacy
systems with Blockchains, it is pertinent to fully understand
their security properties and the attack surface. It might be
possible that a conventional application, hoping to improve its
security model, may further be exposed to a higher risk by
using Blockchains. For example, delay-sensitive applications
in supply chains cannot afford unusual latency in transaction
propagation and data-sensitive applications such as electronic
voting cannot afford a double-spent transaction. While these
attacks 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 stall
information 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 fraudulent
activity is part of the Blockchain, the system will require a
major hard fork to reverse the transaction. Therefore, the use
of Blockchains may bring new attack avenues on an otherwise
secure application. In the light of these changes, we believe
it is important and timely to perform a systematic treatment
of Blockchain attack surface to expose its vulnerabilities and
outline new threat models for emerging applications. As an
outcome of our research, in the following, we discuss the key
lessons learned as well as the open directions that can navigate
the 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 the
Blockchain attack surface. In public Blockchains particularly,
the topological asymmetry of the network can be easily
exploited to compromise the system. Moreover, and since the
public Blockchains are permissionless, the network remains
impartial towards legitimate users as well as the adversary.
This property further weakens the security model since the
adversary has an open access to all the resources.
Moreover, the network layer allows external entities to
influence the internal operations of the Blockchain application.
For example, an ISP, external to the Blockchain network, can
hijack BGP prefixes to isolate peers. If such an attack is
launched against a mining pool, the hash rate of the network
will be affected leading to transaction stall. Other external
adversaries include competing Blockchain applications, nation
states, cloud service providers, and DNS servers, that can
disrupt the flow of traffic to affect the activities of the target
Blockchain application. While the effect of external entities
can be reduced by using private Blockchains, however, this
may only partially solve the problem. Private Blockchains can
strengthen the network conditions by limiting the exposure of
system information, however, they also limit the scope of the
application by allowing selective peers to participate.
Another takeaway from our work is the need to develop
energy efficient and secure consensus protocols that may
substitute PoW and PoS. Through Bitcoin, we have learned
that PoW is highly energy inefficiency. Moreover, PoW also
leads 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 energy
inefficiency and avoid race conditions, PoS has been proposed
that uses an auction process for block mining. However, we
have shown that PoS can create network centralization and
unfairness in system. Although PBFT has served well as an
alternative to PoS and PoW in private Blockchains, however, it
suffers from high message complexity and low scalability. This
stands 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 Blockchain
applications more vulnerable. In Ethereum, for example, the
reentrancy attack and the overflow attack can be launched to
steal the user’s balance. Such attacks cannot be launched on
Bitcoin, Ripple, and Zcash which do not offer programming
flexibility to users. Additionally, we have reported that the
use of a Blockchains at the application layer also creates
new attack avenues. For example, by exploiting the open-
source client software, an attacker can get access to his private
keys and balance. Therefore, the application-oriented use of
Blockchains 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 distributed
environment, 2) development of fair and efficient consensus
algorithms, and 3) careful interaction of Blockchain layer with
the application layer to avoid vulnerabilities and attacks.
B. Open Challenges
Some of the open challenges in the Blockchains attack
surface are shown in Table IX. It can be observed that routing
attacks do not have effective countermeasures and current
Blockchain applications have not taken initiatives to address
them. For example, as shown in Table VII, if a malicious
ISP hijacks ASes owned by Alibaba, it can hijack more than
50% of the Bitcoin hash rate. As a result, block generation in
Bitcoin will stall, leading to delays in transaction confirmation.
If we analyze the spatial behavior of Bitcoin [105], we
observe an increase in the centralization of nodes over time,
indicating that the network is not responding to the threats of a
hijack. Also shown in Table IX, certain policies of Blockchain
applications have created attack avenues that remain an open
problem. In Bitcoin and Ethereum, the block size limit and
the block generation time have led to flooding attacks and
delays [33]. These applications should revise their policies to
prevent such attacks. Furthermore, a developing problem that
most Blockchain applications are likely to encounter in future
is their high storage footprint. Due to the append-only model,
Blockchains linearly grow in size leading to a high storage
cost. While this problem appears trivial in cryptocurrencies, it
will become significant when Blockchains will be introduced
in data intensive applications such as supply chains. A naïve
solution is the use of payment channel networks to offload the
transaction activity from the main Blockchain [207], [208].
However, the use of payment channels obscures the data
transparency on the main Blockchain and may also suffer from
privacy issues. Therefore, more research is required to come
up with effective solutions.
26
IX. CONCLUSION
In this paper, we explore the attack surface of Blockchain
technology. We attribute attacks to the cryptographic con-
structs of the blockchain, the underlying communication ar-
chitecture, and the context in which they are applied. In
doing so, we highlight major threats and ongoing defense
research activities. We believe that various attacks against
Blockchain can be still launched, not withstanding the current
and existing defenses, and that some of those attacks can be
used to facilitate several others. By outlining these attacks and
surveying their countermeasures, we highlight new research
directions that need to be pursued towards more secure and
effective use of Blockchains.
Acknowledgement. This work is supported by Air Force
Material Command award FA8750-16-0301.
REFERENCES
[1] L. Mauri, S. Cimato, and E. Damiani, “A comparative analysis
of current cryptocurrencies,” Proceedings of the 4th International
Conference 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 System
Security 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, and
E. W. Felten, “Research perspectives and challenges for bitcoin and
cryptocurrencies,” 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 smart
contracts,” in Proceedings of the 37th IEEE Symposium on Security
and 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 verification
of smart contracts: Short paper,” in Proceedings of the 23rd
ACM 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 communication
for a scalable smart city network,” IEEE Consumer Electronics
Magazine, 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-based
efficient privacy preserving and data sharing scheme of content-centric
network 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-based
signature scheme with multiple authorities for blockchain in electronic
health records systems,” IEEE Access, vol. 6, pp. 11676–11 686, 2018.
[Online]. Available: https://doi.org/10.1109/ACCESS.2018.2801266
[9] D. Rakic, “Blockchain technology in healthcare,” in Proceedings of
the 4th International Conference on Information and Communication
Technologies 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 of
things 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 iot
networks,” 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 approach
towards 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 blockchain
technology on business models in the payments industry,” in Towards
Thought Leadership in Digital Transformation: 13. Internationale
Tagung 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 signed
contracts: Anonymous on-blockchain and off-blockchain bitcoin
transactions,” in Financial Cryptography and Data Security -
International Workshops, BITCOIN, VOTING, and WAHC, Christ
Church, 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 Information
Systems 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-voting
with blockchain: An e-voting protocol with decentralisation and
voter 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, “Merging
supply chain and blockchain technologies,” Computing Research
Repository (CoRR), vol. abs/1804.04149, 2018. [Online]. Available:
https://goo.gl/5wMVJS
[18] G. Baruffaldi and H. Sternberg, “Chains in chains - logic and
challenges of blockchains in supply chains,” in 51st Hawaii
International Conference on System Sciences (HICSS), Hilton
Waikoloa 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 security
for content distribution using blockchains,” in IEEE Conference on
Computer 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 data
perspective,” 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 starts
here,” 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 Symposium
on Security and Privacy Workshops, SPW, San Jose, CA, USA, May
2015, 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 blockchain
innovations 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 and
unlinkable bitcoin transactions,” in Proceedings of the 2017
Annual 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 36th
IEEE 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 bitcoin
network,” in 13th IEEE International Conference on Peer-to-Peer
Computing, 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 38th
IEEE 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 eclipse
attacks on ethereum’s peer-to-peer network,” IACR Cryptology
ePrint Archive, vol. 2018, p. 236, 2018. [Online]. Available:
http://eprint.iacr.org/2018/236