Tampering with the Delivery of Blocks and Transactions
in Bitcoin
Arthur Gervais

Hubert Ritzdorf

Institute of Information Security
Department of Computer Science
ETH Zurich, Switzerland
arthur.gervais@inf.ethz.ch

Institute of Information Security
Department of Computer Science
ETH Zurich, Switzerland
hubert.ritzdorf@inf.ethz.ch

Ghassan O. Karame

Srdjan Čapkun

NEC Europe Ltd.
NEC Laboratories Europe
Heidelberg, Germany
ghassan.karame@neclab.eu

Institute of Information Security
Department of Computer Science
ETH Zurich, Switzerland
srdjan.capkun@inf.ethz.ch

ABSTRACT
Given the increasing adoption of Bitcoin, the number oftransactions and the block sizes within the system are only
expected to increase. To sustain its correct operation inspite of its ever-increasing use, Bitcoin implements a numberof necessary optimizations and scalability measures. These
measures limit the amount of information broadcast in thesystem to the minimum necessary.
In this paper, we show that current scalability measures
adopted by Bitcoin come at odds with the security of thesystem. More specifically, we show that an adversary can
exploit these measures in order to effectively delay the propagation of transactions and blocks to specific nodes for a considerable amount of time—without causing a network partitioning in the system. Notice that this attack alters theinformation received by Bitcoin nodes, and modifies theirviews of the ledger state. Namely, we show that this allows
the adversary to considerably increase its mining advantage
in the network, and to double-spend transactions in spite of
the current countermeasures adopted by Bitcoin. Based on
our results, we propose a number of countermeasures in order to enhance the security of Bitcoin without deteriorating
its scalability.

1.

INTRODUCTION

Bitcoin has received more adoption and popularity thanany other digital currency proposed to date. Currently, Bitcoin holds the largest market share amongst all existing digital currencies, with a market cap exceeding 3 billion USD [4].
There are also numerous businesses [11], exchange platforms,
and banks [15] that are currently built around the Bitcoin
ecosystem.
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from Permissions@acm.org.
CCS’15, October 12–16, 2015, Denver, Colorado, USA.
c 2015 ACM. ISBN 978-1-4503-3832-5/15/10 ...$15.00.
DOI: http://dx.doi.org/10.1145/XXX.XXXXXXX.

Transaction security is ensured in Bitcoin by means ofblocks which instantiate a hash-based Proof of Work (PoW)
mechanism; Bitcoin’s PoW requires 10 minutes on average
to be solved and 6 consecutive blocks are recommended toconfirm any single transaction in the system. This suggeststhat transactions will be confirmed in the system after almost one hour—provided that the majority (>50%) of thecomputing power in the network is honest.
Given the growing investments in Bitcoin, and the increasing adoption by users, the security, scalability, and reliabilityof Bitcoin has received considerable attention in the literature. Recently, several studies have challenged the security
assumptions adopted by Bitcoin [14, 20, 21]. For instance,
Eyal and Sirer [16] showed that selfish miners that command more than 33% of the total computing power of the
network can acquire a considerable mining advantage in the
network. Additionally, Karame et al. [21] showed that themeasures adopted in Bitcoin to handle fast payments are
not enough to deter double-spending attacks, and proposeda countermeasure which is currently integrated in Bitcoin.
Recently, Heilman et al. showed how to attack the Bitcoin
mining protocol by monopolizing the connections of nodes
in the system.
Given that the Bitcoin overlay network is densely connected, most of these studies assume that all transactions
and blocks (and their order of execution) advertised in thesystem will be almost immediately available to the majority
of Bitcoin nodes soon after their release into the network.
Recently, a number studies briefly hinted on the possibility of delaying blocks [2] and transactions [1, 23] for a shortamount of time (e.g., for 2 minutes).
In this paper, we extend these observations and we show
analytically and experimentally that an adversary can deny
the delivery of blocks and transactions to victim Bitcoin
nodes for a considerable amount of time. By doing so, this
attack enables the adversary to alter the information received by Bitcoin nodes, and to modify their views of theledger state. This is achieved by exploiting Bitcoin bandwidth optimization techniques and the measures that are inplace to tolerate network delays and congestion. The minimal requirement for this attack to succeed in practice is simply that the attacker can establish at least one connection
to the victim. An even more powerful attack resulting in al-most indefinite delays at the victim node only requires thatthe attacker can fill the victim’s remaining open connection
slots—without necessarily causing any network partitioning
in the Bitcoin network.
Our results therefore motivate the need for a careful design of the scalability mechanisms adopted in Bitcoin. While
existing mechanisms limit the amount of propagated information in the system to the minimum necessary, we showthat these techniques come at odds with security and reduce
the ability of the network to e.g., detect double-spending
attacks, resolve, or prevent blockchain forks. For instance,
our findings suggest that the 33% bound outlined by Eyaland Sirer [16] might be even further reduced. Namely, if aconsiderable fraction of miners does not rely on alternative
relay networks to receive network updates [3], then malicious
miners can temporarily prevent the propagation of recently
mined blocks in the network, in order to further increase
their advantage—while commanding less than 33% of thetotal computing power in the network. In this respect, we
propose a modification of the block request process in Bitcoin to deter this misbehavior.
Our findings additionally uncover new vulnerabilities in
the Bitcoin network’s ability to handle fast payments. Fast
payments refer to payments where the time between the exchange of currency and goods is short (in the order of aminute). In light of the vulnerabilities discovered in [21],Bitcoin incorporated a new countermeasure which consistsof relaying the first double-spent transaction in order to enhance the security of fast payments [7]. In this respect, weshow analytically and experimentally that an adversary canleverage our findings to circumvent this countermeasure anddouble-spend fast payments without bearing any risk of losing her money. We also show that payments which were only
confirmed by few blocks might be reverted by the adversary.
Based on our findings, we explore a number of solutions todeter this misbehavior and we estimate a lower-bound on
the waiting time required to ensure the security of fast payments.
More specifically, our contributions in this paper can besummarized as follows:• We analytically and experimentally confirm that a resource-constrained adversary can abuse existing scalability measures adopted in Bitcoin clients in order to deny
information about newly generated blocks and transactions to Bitcoin nodes for at least 20 minutes. We
then extend this basic attack and show how an adversary can continuously deny the delivery of such information.
• We validate our analysis by means of implementation
using a handful of hosts located around the globe. Our
results demonstrate the feasibility and easy realizationof our attacks in current Bitcoin client implementations.
• We show that our results allow the adversary to considerably increase its mining advantage in the network, double-spend transactions in spite of the current
countermeasures adopted by Bitcoin, and easily mount
Denial-of-Service attacks.
• We propose a number of mitigations for hardening thesecurity of the network against such a misbehavior
without deteriorating the scalability of Bitcoin. Namely,
we propose a modification of the block request management system in Bitcoin in order to detect any mis-

behavior in the delivery of blocks. Additionally, weleverage our findings to estimate the minimum amountof waiting time required to ensure, with considerable
probability, the security of fast payments in Bitcoin.
The remainder of the paper is organized as follows. In Section 2, we overview Bitcoin and summarize the measures deployed in the system to minimize the amount of propagatedinformation. In Section 3, we show how an adversary caneffectively delay information propagation in the network. In
Section 4, we extend our analysis and discuss possible techniques to continuously prevent the delivery of Bitcoin blocks.
In Section 5, we discuss the impact of our findings on the
security of Bitcoin, and we outline possible countermeasuresin Section 6. In Section 7, we overview related work in thearea, and we conclude the paper in Section 8.

2.

SCALABILITY MEASURES IN BITCOIN

In this section, we overview Bitcoin, and summarize themain scalability measures integrated in the system.

Background.
Bitcoin is a loosely-connected P2P network, where nodes
can join and leave the network at any moment. Bitcoin
nodes are connected to the overlay network over TCP/IP.
Initially, peers bootstrap to the network by requesting peer
address information from Domain Name System (DNS) seeds
which provide a list of current Bitcoin node IP addresses.
Newly connected nodes advertise peer IP addresses via Bitcoin addr messages. Notice that a default full Bitcoin clientestablishes a maximum of 125 TCP connections, of which
up to 8 are outgoing TCP connections.
Bitcoin transactions transfer coins (BTCs) among peers;these peers are referenced in each transaction by means ofvirtual pseudonyms—referred to as Bitcoin addresses. Each
address maps to a unique public/private key pair; these keys
are used to transfer the ownership of BTCs among addresses.
A Bitcoin transaction is formed by digitally signing a hash of
the previous transaction where this coin was last spent alongwith the public key of the future owner and incorporating
this signature in the coin. Transactions take as input thereference to an output of another transaction which spends
the same coins, and outputs the list of addresses which cancollect the transferred coins. A transaction output can only
be redeemed once, after which the output is no longer available to other transactions. Once ready, the transaction issigned by the user and broadcast in the P2P network. Any
peer can verify the authenticity of a BTC by checking thechain of signatures.
The difference between the input and output amounts ofa transaction is collected in the form of fees by Bitcoin miners. Miners are peers, which participate in the generationof Bitcoin blocks. These blocks are generated by solving ahash-based proof-of-work (PoW) scheme; miners must finda nonce value that, when hashed with additional fields (e.g.,
the Merkle hash of all valid transactions, the hash of the previous block), the result is below a given target value. If sucha nonce is found, miners then include it in a new block thus
allowing any entity to verify the PoW. Since each block links
to the previously generated block, the Bitcoin blockchain
grows upon the generation of a new block in the network.
A Bitcoin block is mined on average every 10 minutes andcurrently awards 25 BTCs to the generating miner. It was
shown in [21] that Bitcoin block generation follows a shiftedgeometric distribution with parameter 0.19. This also suggests that there is considerable variability in the generation
times; for example, one of the longest block generation time
so far lasted almost 99 minutes (this corresponds to block
152,218).
During normal operations, miners typically work on extending the longest blockchain in the network. Due to theunderlying PoW scheme, however, different miners can potentially find different blocks nearly at the same time—in
which case a fork in the blockchain occurs. Forks are inherently resolved by the Bitcoin system; the longest blockchain
which is backed by the majority of the computing power in
the network will eventually prevail.

Node A

Node Vnew block arrival

Node A

Node Vnew transaction arrival

inv

inv

aders
gethe
ta
getda
head
ers
block

getda

Block transmission

ta

trans

actio
n

Transaction transmission

Figure 1: Summary of the request management system in Bitcoin.

Scalability Measures.
Currently, almost 1 transaction per second (tps) [6] is executed in Bitcoin; this results in an average block size of almost 400 KB1 . In an experiment that we conducted, we measured the amount of traffic observed by a full Bitcoin node2 ;our results show that Bitcoin nodes in- and outbound trafficheavily depends on the number of connections of the node.
For instance, a node with about 70 connections witnesses
on average 8.5 GB daily traffic3 , while a node with about
25 connections witnesses on average 3 GB traffic within 24
hours4 . Given the increasing adoption of Bitcoin, the number of transactions, and the block sizes are only expected toincrease. For example, if Bitcoin were to handle 1% of thetransactional volume of Visa5 , then Bitcoin needs to scale toaccommodate almost 500 tps—requiring considerably larger
blocks to be broadcasted in the network.
Motivated by these factors, the current Bitcoin protocol
implements various bandwidth optimizations, and measuresin order to sustain its scalability and correct operation inspite of ever-increasing use. In what follows, we detail theexisting measures taken by Bitcoin developers.
Measure 1. Bitcoin combats the broadcasting of ill-formed
blocks and transactions by maintaining an internal reputation management system.
Whenever a node receives objects (e.g., blocks, transactions), it checks their correctness before forwarding themto other peers in the network. First, objects are validated
based on their respective syntax and sizes, e.g., oversized objects are discarded. If this verification passes, the contentsof the objects are subsequently validated. For transactions,this includes verifying the signature, the input and output
coins used in the transaction; similarly, the PoW included inblock headers is verified with respect to the current network
difficulty.
To prevent any abuse of the Bitcoin overlay network (e.g.
Denial of Service attacks), a receiving node locally assigns
a penalty to peers who broadcast ill-formed objects. Oncea node has reached 100 penalty points, the receiving node
disconnects from the misbehaving node for 24 hours. For
1
The maximum block size is currently limited to 1 MB whichcorresponds to less than 7 transactions per second.
2
Our measurements were conducted over a period of 18 days,
during which our node had on average 70 active connections.
3
Measured over 20 days.
4
Measured over 2 days.
5
Currently, the Visa network is designed to handle peakvolumes of 47,000 tps [9].

example, if a node broadcasts invalid alerts, then it will begiven 10 penalty points. Nodes which attempt more serious
misbehavior, such as inserting invalid transaction signatures,are immediately assigned 100 points, and therefore directly
banned. Penalties also apply to ill-formed control messages
such as inv (inventory) or addr commands. Notice that
locally assigned penalties are not transmitted to other peers.
Measure 2. Bitcoin uses an advertisement-based request
management system to minimize the information spread in
the network.
To minimize information spread in the network, messages
are propagated in the Bitcoin network with the help of an
advertisement-based request management system. Namely,
if node A receives information about a new Bitcoin object(e.g., a transaction or a block) from another node, A will
advertise this object to its other connections (e.g. node V)
by sending them an inv message; these messages are muchsmaller in size than the actual objects, because they only
contain the hash and the type of object which is advertised.
Only if node V has not previously received the object advertised by the inv message, V will request the object from A
with a getdata request. Following the Bitcoin protocol, node
A will subsequently respond with a Bitcoin object, e.g., thecontents of a transaction or a block.
By doing so, inventory messages limit the amount of databroadcast in the network. Notice that in case the object
advertised corresponds to a block, neighbor V first requests
the block header before the actual block data. Here, whena block header is advertised via a headers message, the receiving node internally stores the highest block known by thesending peer. The receiving node also validates any received
header, by verifying its corresponding PoW. Transactions,on the other hand, are requested directly using a transaction inv message. This process is summarized in Figure 1.
To minimize bandwidth consumption, Bitcoin nodes request a given object only from a single peer, typically the
first peer which first advertises the object. In an experiment that we conducted, we measured the traffic (cf. Figure 2) witnessed by a default Bitcoin client over a periodof 24 hours6 . We observe that, indeed, the transmission ofblocks consumes a significant part of the bandwidth of ourclient. Requesting the same object from multiple peers entails downloading the same data several times, and therefore
can only increase the bandwidth consumption of the system.
6
During our measurements, the client was connected to approximately 30 neighbors.

Time for block retrieval (s)Megabytes per hour

140
inv
tx
block

120
100
80
60
40
20
0

1

3

5

7

9

160

1400

140

1200

120

800

80

600

60
40

400

20

200

0

11 13 15 17 19 21 23

Hours of traffic capture

1000

100

500 Mbit/s
downstream

0

256 Kbit/s
downstream

Figure 2: Hourly traffic distribution of a Bitcoinnode, up and downstream, over 24 hours, w.r.t. todifferent Bitcoin messages. Here, ‘tx’ denotes transactions.

Figure 3: Block transmission times with respect tothe connection speed. Here, we evaluate the time
to download 400 consecutive Bitcoin blocks on a
500 Mbps and 256 Kbps connection.

Measure 3. Bitcoin relies on static timeouts in order toprevent blocking while tolerating network outages, congestion, and slow connections.

given transaction is not delivered, the next peer in the list isqueried.

Given that Bitcoin runs atop an overlay network, communication latency and reliability pose a major challenge tothe correct operation of the system. Currently, Bitcoin relies on timeouts in order to tolerate network delays—while
preventing blocking. Blocking can occur e.g., when a nodestops responding during communication.
For example, in Bitcoin version 0.10, the Bitcoin developers introduced a block timeout download of 20 minutes7 .
Similarly, for transactions, the Bitcoin developers introduced a 2-minute timeout. Notice that the choice of thetimeout is a non-trivial task and depends on a number ofparameters such as bandwidth, object size, latency, processing power, and the Bitcoin version of each node. On the one
hand, overly long timeouts might deteriorate the quality ofservice of the whole network and can be abused to conducte.g., double-spending attacks [8]. On the other hand, shorttimeouts might hinder effective communication under varying network conditions, or when communicating with slow
peers.
In an experiment that we conducted, we measured theblock transmission times in Bitcoin with respect to the nodes’
bandwidths. Our results (cf. Figure 3) show that block retrieval times significantly vary depending on the connectionof the node. For instance, fast nodes with 500 Mbps downstream take an average of 1.55 seconds to download a block,while slow nodes equipped with a 256 Kbps connection takean average of 71.70 seconds to download blocks. It is interesting to note that, during our measurements on the slow
node, 0.5% of the generated blocks exceeded the 20 minutetimeout adopted by current clients. This shows that thecurrent timeouts adopted in Bitcoin when sending/receiving
blocks are indeed necessary for the correct delivery of blocks
in the network.
Measure 4. Bitcoin clients keep track of the order ofthe received transaction advertisements. If a request for a
7
Available from https://github.com/bitcoin/bitcoin/pull/5608

When a transaction T is advertised via an inv message
to a given node, the latter keeps track of the order of announcements with a first-in first-out (FIFO) buffer. Eachtime a peer advertises T , the peer is inserted in the buffer.
Transaction T is only requested from one peer at a time. For
each entry in the buffer, Bitcoin clients maintain a 2-minutetimeout, after which, the next entry in the buffer is queried
for T .

3.

DELAYING INFORMATION DELIVERY

In this section, we show how an adversary can exploit
the scalability measures of Bitcoin’s request management inorder to delay the delivery of message advertisements.
For the purpose of our analysis, we assume that the adversary A is a full Bitcoin node, and has access to the entire
blockchain. Here, the objective of A is to deny the deliveryof an object O for a short period of time from a specific nodedenoted by V. In Section 4, we extend this analysis and show
how an adversary can arbitrarily prolong the prevention of
message delivery.

3.1

Necessary Requirements

We start by outlining the necessary conditions which need
to be satisfied for A to successfully prevent the delivery ofobject information from a given Bitcoin node V.
Requirement 1: A must be the first peer to send a message advertisement of object O to V. If V requests
an object O from a node which is not under the control of A, then little can be done by A to preventthe node from sending O to V. However, if A is able
to first advertise O via an inv message to V, then V
will temporarily abstain from requesting O from anyother node in the network. As explained earlier, Bitcoin nodes only request the same data element from asingle peer in order to minimize bandwidth consumption (cf. Measure 2). In order to be the first to advertise an object O to V, A needs to be an immediateneighbor of V in the Bitcoin overlay network (i.e., there
is a direct TCP connection between A and V).
Requirement 2: V should wait sufficiently long after a getdata message before requesting the data from anotherpeer [23]. The longer V waits for A to send O, themore damaging is the misbehavior of A (cf. Section 5).
As mentioned earlier, current Bitcoin implementations
inflict a timeout of 20 minutes on V for blocks, and 2
minutes for transactions; after the timeout, V can request O from another node (cf. Measure 3).
In what follows, we show how these requirements can besatisfied.

Satisfying Requirement 1.
As mentioned earlier, Bitcoin nodes verify the correctness of every received object before they re-broadcast it in
the network. Notice that this process requires considerable
time; for example, when receiving transactions, nodes verify
the transactions’ signatures, and check that the input coins
have not been spent previously. Similarly, for blocks, nodes
check the correctness of the PoW in relation with the current difficulty in the network, and verify the correctness ofevery transaction that is confirmed in the block.
This offers a clear advantage for an adversary in orderto satisfy Requirement 1. Indeed, an adversary can simply forward a given object of choice O immediately after it
receives it—without verifying its correctness. Since all remaining nodes in the system will have to perform a series ofverification steps to verify O, the adversary is likely to be
the first node to advertise O to its neighbors. As explainedin Measure 2, this ensures that A’s neighbors will not request the object from any other node in the network until
the timeout expires. Notice, that if A is interested in denying the delivery of O to a specific node V, then the adversary
can advertise O solely to V. Here, in the case where O iscreated by A (e.g., O is a transaction), A can satisfy Requirement 1 by first advertising O to V, before broadcasting
it in the network.
We stress here that A should be directly connected toV. This is a reasonable assumption, since most full Bitcoin
nodes do not exhaust their maximum 125 connections; intypical cases, nodes are therefore likely to accept connection
request originating from A. Notice that if V does not accept
incoming connections (e.g., is located behind a NAT or firewall), Requirement 1 can also be satisfied if V connects to A
(i.e., by requesting an outbound connection). Alternatively,
A can try to compromise a neighbor of V.

Satisfying Requirement 2.
To optimize bandwidth, recall that objects are only requested from one peer at a time (cf. Measure 2). Thismeans that if A is the first node to advertise O to V, V will
simply wait for A to send O and will not request the same
object from any other peer. During this period, A simply
has to respond to the active ping messages of V. Notice that
if A does not actively respond to ping messages from V inthis period, then V disconnects eventually before the object
transmission timeout.
For blocks, the default timeout for V is set to 20 minutes;
transactions, however, have a waiting timeout of 2 minutes.
Given Measure 4, it is easy for A to increase the timeout

Adversary

inv
inv

Proxy

inv
inv

Victiminv

inv

VictimBitcoin network

Figure 4: Satisfying Requirement 1. The adversary
can use a simple relay proxy to forward inv messages without validating the correctness of the corresponding object.

for transactions simply by sending x back to back inv messages for the same transaction. By doing so, A effectively
increases the timeout specific to the advertised transaction
by 2x minutes. We validate this analysis experimentally in
Section 3.2.

3.2

Experimental Validation

In what follows, we empirically assess the probability that
A succeeds in relaying first an inv message of an object O
to a given node V (cf. Requirement 1). For this purpose,
we implement a proxy which relays specific inv messages
directly before passing them to the Bitcoin software. Basedon this proxy, we evaluate how likely A can be the first node
to advertise an inv message to V.
Our experimental setup is sketched in Figure 4. Here, we
assume that A is located in Europe and operates an Inteli7 CPU (3.40GHz) with 32 GB RAM and a 500/400 Mbps
Internet connection. In our setup, A connects to V througha direct TCP connection.
To remove any bias that might occur from a given network topology, we consider 10 different nodes emulating V
geographically dispersed around the globe. We also vary
the connectivity of A and V during our measurements (i.e.,
between 40 and 800 TCP connections to different full Bitcoin nodes for A and between 40 and 200 for V). Because
only full Bitcoin nodes forward blocks and transactions, only
connections to full Bitcoin nodes are relevant for this experiment. We, therefore, modify the Bitcoin client, such that
only connections to full Bitcoin clients are established andsuch that the maximum connection limit is kept constantly.
We measure the probability Pr = Nr , that A satisfies
Requirement 1 as follows. We relay N advertisements forobjects to V, and we compute the number of getdata andgetheaders replies r originating from V received within thesubsequent 30 seconds; recall that these messages provide
sufficient evidence that A is the first relayer of an object toV, and as such V will not request this object from elsewhere.

Denying the Delivery of Blocks.
We start by investigating the success probability of A in
denying the delivery of blocks. Here, for different combinations of the number of connections of A and V (cf. Table 1),
we forward N = 100 blocks generated after block height
350,000 and compute Pr .
Recall that to prevent the delivery of a block object O, A
needs to directly relay the inv corresponding to O, without
validating it. By doing so, A is faster in relaying the inv mes-

sage than any other node in the system. To better assess theadvantage of A in this case, we measured the time required
to validate 100 blocks (from block height 353,000 onwards).
Our results show that a single block requires on average 174
milliseconds to validate on an Amazon EC2 dual-core instance; notice that most of the overhead is spent in verifying
the correctness of the transactions. In addition to the network latency for retrieving a Bitcoin block (cf. Measure 3),
this gives 174 milliseconds advantage on average for A tosucceed in denying the delivery of a block object.
In Table 1, we measure Pr with respect to (i) the locationof V, (ii) A’s number of connections and (iii) V’s numberof connections (cf. Requirement 1). By gradually increasing
the number of connections of A from 40 to 800, we observe,that A’s success increases with more connections. Namely,
our results show that Pr ≈ 0.89 when A has 800 connections. The more connections A maintains, the bigger is A’s
likelihood to receive a new block inv message before V. Similarly, by gradually increasing the number of connections ofV from 40 to 200, we observe, that the adversary’s successdecreases when V maintains more connections. We do not
observe a strong correlation between the physical location,and the resulting network latency from A to V. This implies,that it is crucial for A to be connected to nodes advertising
blocks first.
In summary, our results clearly indicate that an adversary
can successfully prevent the delivery of blocks to a particular
node with considerable probability.
In another experiment, we measured the amount of timethat a particular Bitcoin block can be denied to V (cf. Requirement 2). Here, when A forwards a block B successfully
as a first node to V, A actively responds to V’s ping requests,
but refrains from answering with a block message. We repeated this experiment for a number of times and observedthat in all cases, V actively disconnects from A after exactly
20 minutes.
Notice that the costs borne by A to deny V a given block
are modest. Namely, A needs to maintain an active TCP
connection with V and to frequently reply to V’s ping requests. Moreover, A needs to simply transmit 101 bytes
comprising the inv message (i.e., 40 bytes for IP and TCP
header, and 61 bytes for an inv message advertising one
block object).

Denying the Delivery of Transactions.
In the following, we investigate the probability of A in
successfully denying the delivery of a transaction. In our experiments, we assume that the transaction T is created by A(for the reasoning why, refer to Section 5.2), and therefore, A
is guaranteed to be the first node to relay the corresponding
inv message.
Our evaluation is conducted as follows. We connect only
two nodes to V; one node corresponds to a machine controller by A, while the other node C emulates an honest
machine in the Bitcoin network. In our experiments, A creates an inv message for transaction T and forwards the inv
to V and C. Upon reception of the inv message, C also forwards the message to V. This captures a realistic transaction
announcement in the Bitcoin network. We repeated this experiment 100 times during which A was able to successfully
deny the delivery of T each time for 2 minutes. Namely,
for all 100 experiments, V was always requesting T with agetdata message from A, which was not responding to therequest. After 120 seconds, V issued a getdata request for T
to the other node C.
We then extended this attack such that A sends T ’s inv
message 10 times to V, even before C issues T ’s inv message.
We repeated this experiment 100 times during which V did
not request T from any other peer for a period of 20 minutes. This is consistent with our observations in Section 2.
Namely, every node which advertises a transaction object T
is inserted in a FIFO buffer and allocated a 2-minute timeout to deliver T . After 2 minutes, T is requested from thenext node in the FIFO buffer. By advertising T x-times,
the adversary can therefore deny the delivery of T for 2x
minutes and arbitrarily extend the denial time.
We point out that the communication overhead of this
attack basically consists of 101 bytes for each 2 minutes ofdelay8 .

4.

EXTENDING THE BLOCK DELIVERY
TIME

We explained in Section 3.2 how A can deny the delivery
of a block object to V for at least 20 minutes. In this section, we build on our findings and study the possibility ofextending the time a block is denied from V. The necessary
requirements are that (i) V accepts at least one connection
from A, and (ii) A is capable of filling V’s remaining open
connection slots. For example, if V maintains 50 connections, A initiates one connection for advertising block inv
messages, and fills the remaining 125 − 51 = 74 open connection slots with default Bitcoin connections. Note thatV’s existing 50 connections do not prevent the attack.
In Bitcoin, blocks are transmitted by performing a headerfirst synchronization. Given the header of a block, any nodecan find the longest chain and verify the proof of work. Oncethe headers have been synchronized, Bitcoin nodes can selectively request the corresponding blocks from their peers.
Headers are typically synchronized on two different occasions:
1. If V receives a new, previously unknown block inv advertisement from a peer A, V actively requests theblock headers from A with a getheaders message.
2. Once a node A connects to V, both nodes exchange a
Bitcoin version message. Each version message contains a counter for the most recent block height therespective node is aware of. If A has a higher blockheight than V, V actively requests the block headersfrom A with a getheaders message.
The header-first synchronization is especially important
for the purpose of our analysis, since it allows V to actively
request a block from its peers as soon as it learns about newheaders. More specifically, if A prevents the delivery of block
B to V and V receives B’s header from another peer, then A
can prevent the delivery of B for at most 20 minutes. Thatis, because after 20 minutes, V actively disconnects from A
and requests the block B from another peer. Clearly, if thelatter peer is not under A’s control, then V is likely to synchronize with the current main blockchain in the network. If
V, however, does not receive the header for block B, V does
not actively request block B from another peer after the 20minute timeout, even if V received the block inv message
from additional peers during the 20-minute timeout.
8
Note that multiple inv messages could be embedded into
one inv message in order to lower the TCP overhead.

Connections of A
Connections of V

40
40

80
40

200
40

800
40

80
80

80
200

Victim node
ZurichFrankfurt
IrelandN.Virginia
OregonN.California
Tokyo
Singapore
SydneySão Paulo

Pr
0.63
0.29
0.67
0.55
0.38
0.36
0.55
0.40
0.31
0.29

Pr
0.40
0.46
0.47
0.92
0.80
0.46
0.86
0.51
0.37
0.45

Pr
0.97
0.61
0.94
0.88
0.82
0.83
0.96
0.76
0.60
0.63

Pr
0.90
0.83
0.85
0.96
0.90
0.96
0.98
0.92
0.77
0.83

Pr
0.35
0.29
0.24
0.34
0.36
0.68
0.22
0.63
0.35
0.20

Pr
0.29
0.34
0.18
0.18
0.12
0.25
0.16
0.19
0.21
0.20

avg. latency A, V (ms)0.95 ± 0.3
43.1 ± 0.3
28.6 ± 0.5
91.0 ± 0.0
171.0 ± 3.0
180.0 ± 0.0
246.0 ± 4.9
303.0 ± 4.6
303.0 ± 4.6
400.0 ± 6.3

Average Pr

0.44 ± 0.14

0.57 ± 0.20

0.80 ± 0.14

0.89 ± 0.07

0.37 ± 0.16

0.21 ± 0.06

176.67 ± 128.3

Table 1: Pr with respect to the number of connections of A and V. Each experiment is measured over 100
consecutive blocks and across 10 different geographical locations. Each data point of Pr corresponds to theaverage of 100 measurements; where appropriate, we report the standard deviation (labelled as ‘±X’). Notethat we exclusively report the number of connections to full Bitcoin nodes.
In order to continuously deny the delivery of block information from V, A therefore needs to make sure that V does
not receive block headers from the network. This can beachieved when the following two conditions are met.

Connection depletion: In the mean time, V must not receive a new version message from another peer. Thiscan be ensured if A can keep all remaining open connection slots of V occupied, such that V does not receive any version message from other peers. Noticethat existing connections do not exchange version messages and, do not impact this condition.
We exemplify the process of denying the delivery of 2 consecutive blocks in Figure 5. Here, we assume that V successfully receives B’s header and appends block B to its local
chain. Once block B + 1 is found, A prevents it from being
delivered to V . Here, a 20-minute timeout for A starts forblock B + 1. Once block B + 2 is found, A also prevents
the delivery of this block to V. Here again, a 20-minutetimeout for A starts for block B + 2. When the timeout
for block B + 1 expires, V does not actively request a block,because it has not learned about any new headers. V would
only receive the headers if V establishes a new connection
to a peer with an up-to-date blockchain, or receives B + 1’s
inv message from another peer after the timeout. A now,
however, can re-advertise block B + 1 and thus re-activate
another 20-minute timeout for block B + 1.
Now, assume that when block B + 3 is found, A is not
the first node to relay B + 3’s inv message. V consequently
requests getheaders and getdata from the advertising peer.
Because blocks B +1 and B +2, however, are currently being

Prx
Expected success based on Pr =0.83

0.8

Probability

First relayer for all blocks: A must be the first node to
forward all block inv messages to V. For example,
when A starts to deny the delivery of block B from V,
and wants to deny the delivery of all blocks up to andincluding block B + 5, A needs to be the first node
relaying all block inv messages between and including
B and B + 5. Note that after a 20-minute timeout,
A is required to resend the corresponding block inv
message before other peers. Other nodes are unlikely
to advertise older blocks, and therefore A can reliably
extend the time a block is denied.

1.0

0.6
0.4
0.2
0.0

0

5

10

15

20

25

30

Number of consecutively denied blocks
Figure 6: Prx w.r.t. the number x of consecutively
denied blocks. Here, A maintains 80 and V between
11 and 25 connections to full Bitcoin nodes.
awaited from A, V only receives block B + 3. In order tovalidate block B + 3 in the main blockchain, V requires theintermediate blocks B + 1 and B + 2. When the timeout
for B + 2 expires, V disconnects from A and requests block
B + 2 immediately from another peer. Still, V is not able toconnect B + 2 and B + 3 to the blockchain, because B + 1
is missing. Finally, when the timeout for B + 1 expires,
V requests block B + 1 from another peer and is able tosynchronize with the main blockchain.
Let Prx denote the probability that A can successfully
prevent the delivery of x consecutive blocks. Clearly, thedelivery of different blocks is an independent process, thenPrx = (Pr )x , where Pr denotes the average probability ofdenying the delivery of a single Bitcoin block. We confirm
this analysis by means of experiments in the following paragraphs.

Experimental Validation
In what follows, we assess the probability Prx that an adversary A can prevent the delivery of at least x blocks fromV.
Our experimental setup is designed as follows. The adversary—in addition to trying to be the first to advertise consecutive

Minerblock Bfound

block B+1
found

block B+2
foundblock B+3
found

Node A

headers: B
mainchain: B

headers: B+1
mainchain: B+1

headers: B+2
mainchain: B+2

headers: B+3
mainchain: B+3

Action:does not attack

deniesblock B+1 from V

deniesblock B+2 from V

fails at denying
block B+3 from V

Node V

headers: B
mainchain: B

headers: B
mainchain: B

headers: B
mainchain: B

headers: B+3
mainchain: B

headers: B+3
mainchain: B+3

Action:synchronizes correctly

does not learn about
B+1 header or block

does not learn about
B+2 header or blocklearns about block B+1,
header B+3, B+2 and B+1

learns about
block B+1

Timeouts of V
for block B+1

20-minute timeout for B+1 V does not
20-minute timeout for B+1
request a
advertising inv
advertising inv
block

Timeouts of V
for block B+2

20-minute timeout for B+2 V requests block B+2
from another peer
advertising inv

time

V requests block B+1
from another peer

Figure 5: Example process of denying the delivery of multiple blocks. Here, A succeeds to deny the deliveryof 2 consecutive blocks.

9
These nodes were synchronized to the blockchain for almost
72 hours and had 11 to 25 connections to full Bitcoin nodes.
10
Recall that lightweight Bitcoin clients do not forward
blocks or transactions and are therefore not relevant for ourstudy.

26
Regression line

Full node connections of V

blocks—makes sure that V does not establish new connections by filling all remaining connection slots of V. In our
setup, we attempt to continuously prevent the delivery ofblocks to 5 different nodes (emulating 5 different V) runningthe default Bitcoin clients9 . During our study, the nodes’
connections to full Bitcoin nodes10 varied over time (cf. Figure 7). On the other hand, the adversary maintained at all
times a fixed number of 80 connections to full Bitcoin clients.
Here, all of the machines emulating V were located in Europe, with a latency below 200ms to A.
In our experiments, the adversary performed a total of2849 block denying attempts on all 5 nodes; A was successful
in denying the delivery of a total of 2364 blocks—resulting
in Pr = 0.83. In Figure 6, we measure Prx , the probability toprevent the delivery of at least x blocks, as follows. We countthe number of consecutive blocks, x, that are only requested(i.e., using a getheaders and getdata) from the adversary.
Here, if we do not receive a getheaders and getdata message
within 30 seconds for a given advertised block or any intermediate re-advertised block, we assume that the victim hasrequested that block from elsewhere, compute the resulting
x, and restart the process. Our results (cf. Figure 6) confirm the analysis in Section 4, indeed show that Prx ≈ (Pr )xand indicate that the adversary can succeed in preventing
the delivery of consecutive blocks with considerable probability. For instance, the probability to prevent the deliveryof 5 consecutive blocks is approximately 0.4.
In Figure 7, we evaluate the number of consecutively denied blocks with respect to the number of connections of V.
Our results confirm our previous observation (cf. Table 1)that the fewer connections V maintains, the more blocks canbe denied. Recall that the more connections a node has (tofull nodes), the earlier the node can receive information fromthe network.

24
22
20
18
16
14
12
10

0

5

10

15

20

25

30

Consecutively denied blocks
Figure 7: Number of consecutively denied blocks
w.r.t. the connections of V. Here, A maintains 80
full Bitcoin node connections.

5.

IMPLICATIONSIn the previous sections, we thoroughly investigated how
Bitcoin’s request management system can be abused by amalicious adversary in order to delay information delivery
in the Bitcoin network. In what follows, we evaluate theimpact of our findings on the security of the Bitcoin system.

5.1

Increasing Mining Advantage

In [16], Eyal and Sirer show that a mining pool which controls more than 33% of the computing power in the network
can considerably increase its mining advantage (by morethan 10%) by withholding its mined blocks until new blocks
are found in the network. We show in what follows that the
33% bound of Eyal and Sirer can be even further reducedby leveraging our findings.

Eyal and Sirer’s Selfish Mining.
In the selfish mining game (adapted from [16]), a selfish
miner does not directly announce its newly mined blocks inthe network and instead keeps them secret, until the remain-

...
0'
1-

(1- )
(1- )(1- )
0
1-

0
11
1-

2

3
1-

...

4
1-

1-

...

1(1-P)(1- )21
P: 0
1-P: 1'

Beyond Selfish Mining.
To deter this misbehavior, Eyal and Sirer [16] propose thefollowing countermeasure. When a miner is aware of twocompeting blocks, the miner should propagate both blocks
and select a random block to mine on. This solution does nottake into account the case where an adversary can selectively
deny miners from receiving a particular block—as confirmed
by our results.
Even worse, by preventing the delivery of blocks to a fraction of the network, an adversary can create multiple virtual
partitions in the network—each mining on different blocks.
As we show below, this grants the adversary with an additional advantage in the selfish mining scenario. Notice thatminers can make use of additional relay networks in order toreceive blocks and transactions faster than the official P2P
network can provide [5]11 . For instance, Matt Corallo’s relay
11

Note that some of the largest mining pools do not makeuse of the relay network [3].

[P(1-P)+(1-P)](1- )

1-

131
P: 0
1-P: 1'22
P²: 0
P(1-P): 1''
1-P: 1'P²(1- )

...

...

3

(1-P)(1- )...
P(1- )

Figure 8: Selfish mining state machine adapted from
Eyal and Sirer [16].

ing network finds new blocks. This strategy is captured in
the state machine shown in Figure 8.
The state machine depicts the adversary’s view on thecurrent state of the selfish mining attack. In state 0, A
and the network have the same view of the currently longest
blockchain. A controls a fraction α of the computing powerin the network, and is therefore likely to mine a block withprobability α. With probability 1−α, the network finds andpublishes a block, leading to state 0. Once A, however, finds
a block, she keeps it secret from the network and state 1 isreached. Moving on, different cases can arise.
First, the network can find a competing block BN withprobability 1 − α, moving the state to 00 . In this case, A
has an incentive to spread his single secret block BA in the
network as fast as possible, such that a fraction γ of the
network continues mining on BA . Namely, γ is the fractionof the network that received BA before BN . Subsequently,
three cases arise: (i) A finds a block with probability α, (ii)the network finds a block by building upon BA with probability (1 − α)γ, or (iii) the network finds a block building on
BN , with probability (1−α)(1−γ). For A, these three cases
generate two, one and zero block rewards, respectively.
Second, A can find a second block and also keep it secret,moving to state 2. Reaching state 2 guarantees A at least
two block rewards. If the network finds a block (transition
from 2 → 0 with probability 1 − α), A can publish the twosecret blocks, generate the longest chain and earn two block
rewards. A keeps additional blocks secret moving to statesfurther right and publishes these blocks individually whilemoving left in the state machine whenever the network finds
a block.

2

P(1- )
32
P²: 0
P(1-P): 1''
1-P: 1'

...
...

...

...

P²(1- )...

Figure 9: Extending Eyal and Sirer’s state machine
to capture the case where a selfish miner can deny
the delivery of recently mined blocks to a fraction Pof the network.

network [5] is optimized to transmit blocks and transactions
as fast as possible, and is designed as a fallback mechanism
for the official P2P network. Namely, Corallo’s relay network does not follow the inv and getdata protocol of theofficial P2P network, but instead directly relays blocks andtransactions. Clearly, miners which rely on an additional
relay network will immediately receive information about
blocks and transactions. In what follows, we show that theadvantage of an attacker is considerable in selfish mining assuming that a fraction 1 − P of the miners is connected tothe additional relay network.
To this end, we extend the state machine from Eyal andSirer by modeling the fact that A can deny the deliveryof blocks to a fraction of the mining power. The modifiedstate machine is depicted in Figure 9. Let’s assume that theadversary currently reached state 3, representing 3 secretblocks. With probability 1 − α the honest network finds a
block B10 , resulting in state change to state 21 . A manages
to deny the delivery of this block to a fraction P of the
network, and consequently, only a fraction 1 − P has learned
about the new block B10 . Three states arise: (i) the fraction
1 − P finds a block (with probability (1 − P )(1 − α)) andA publishes his remaining 2 secret blocks, resulting in state0; (ii) A finds a block with probability α (resulting in state31 ), or (iii) the fraction P which has not yet seen block B10
finds with probability P (1 − α) a block resulting in state
22 . All other cases follow the same principle; A virtuallypartitions the miners by denying the delivery of new blocks
to other honest miners. This strengthens the selfish mining
game as it leads to even more wasted computations by thehonest miners.
Based on the state machine of Figure 9, we measure therevenue of the adversary in comparison with findings of [16].
For this purpose, we simulate both state machines; in eachstate, our simulator chooses the next state by generating theprobability distribution of the possible transitions according
to the given parameters. We performed up to 1,000,000
iterations for both state machines and per data point of
Figure 10. Here, we assume that A is able to deny theRelative pool revenue

1.0

0.8

0.6

4. Send Tl

P = 0.250, consec. denied blocks = 2
P = 0.500, consec. denied blocks = 2
P = 0.500, consec. denied blocks = 5
Honest mining
Network control
γ = 0.00 [Eyal]
γ = 1.00 [Eyal]

0.4

Figure 11: Circumventing the double-spend relay
protection of Bitcoin XT.

0.2

0.0
0.0

0.1

0.2

0.3

Pool size

0.4

0.5

Figure 10: Relative revenue gain of selfish miners
with and without the delaying of block information.
For our simulations, we assume γ = 0 and always
perform better than [16].

delivery of 2 and 5 consecutive blocks with probabilities 0.5
and 0.25, respectively. This assumption conforms with ourfindings in Section 4. To compute the revenue, we adapt thescheme from [16]; we refer the readers to Appendix A for
more details on the adopted revenue estimation.
Our results (cf. Figure 10) show that the 33% bound advertised by Eyal and Sirer can be considerably lowered. For
instance, an adversary which succeeds in denying the delivery of 2 consecutive blocks from 50% of the network willprofit from selfish mining if he controls 26.5% of the computing power in the network. This adversary effectively controls
the Bitcoin mining network given only 35% of the actual
computing power—even if 50% of the miners leverage an additional relay network to receive transactions/blocks. Even
worse, our results show that an adversary (with P = 0.5
and 5 consecutively denied blocks) which commands less than
34% of the computing power in the network can effectively
sustain the longest block chain and therefore control the entire network.

5.2

Vendor

Double-Spending

In what follows, we show how an adversary can leverage our findings to double-spend (i) fast payments in which
the corresponding transactions have not yet been included
in any block of the main blockchain (also referred to as
zero-confirmation transactions) [8], and (ii) 1-confirmationtransactions, i.e., transactions which have been already confirmed in one Bitcoin block in the main blockchain. Notice that zero-confirmation and one-confirmation transactions are common to handle payments in which the time
between exchange of the currency and goods is short.
Here, we assume that the adversary A creates two transactions Td and Tl sharing the same input coins. Td is atransaction whose output addresses are owned by A, while
the outputs of Tl are owned by a vendor V. Similar to [8],the goal of A is to convince V to accept Tl , acquire service
from V, while ensuring that Td is confirmed by miners andincluded in the main blockchain.

Double-Spending of Zero-Confirmation Transactions.
Zero-confirmation transactions are essential for the operation of several businesses. Recall that Bitcoin blocks are
generated within 10 minutes on average which prevents thedaily operation of businesses where the exchange between
the currency and the service is short (e.g. in the order of few
minutes). In light of the double-spending analysis in [21], anenhanced version of Bitcoin, referred to as Bitcoin XT [7],currently broadcasts the first double-spend transaction in
the network. This allows a vendor to observe any doublespending attempt for an upcoming payment, and to consequently deny the processing of a fast payment. By February 2015, almost 16 full nodes in the Bitcoin network had
adopted the double-spend relay protection of Bitcoin XT.
Motivated by our findings, we show in what follows thatthe protection of Bitcoin XT is not effective in preventing
double-spending attacks of fast payments. We also showthat an adversary can perform double-spending attacks—without
the risk of loosing money.
To do so, the adversary first sends an inv message advertising Td to V; this prevents V from receiving Td from the
network—in spite of the protection embedded in Bitcoin XT.
A subsequently broadcasts Td in the network, and sends Tl
to V shortly after (cf. Figure 11). From the viewpoint of V,
Tl does not conflict with any other transaction, and therefore the trade can be concluded. Although other nodes in
the network can observe the two conflicting transactions, Td
and Tl , and issue the corresponding warnings, V cannot receive Td from its neighbors, and is therefore unable to detect
this attack. Shortly after, the first observed transaction in
the network (i.e. Td ) is typically included in the blockchain.
A can further prevent nodes in the network from detecting
the attack, as follows. Similar to before, A issues Td in the
network, while denying its delivery to V (e.g. for a 20 minuteperiod). As soon as Td is confirmed in a block Bd , A directly
prevents the delivery of Bd to V by sending the latter an inv
advertising Bd (cf. Section 3.2). This ensures that V does
not receive Bd from the network for at least 20 minutes.
In the meantime, A sends Tl to V which will broadcast it
in the network. Because Bitcoin XT, however, only relays
conflicting transactions from the memory pool, a pool of
not yet confirmed transactions, Tl is not considered doublespent. Tl , nonetheless, is considered a conflicting transaction
w.r.t. the already confirmed Td , and therefore is not relayedin the network. In this way, A does not bear any risk ofloosing her money since Td was already included in a block
and will likely be accepted by most nodes in the network.
We empirically confirm our analysis using a testbed comprising of three Bitcoin nodes emulating a vendor V, theadversary A and a Bitcoin XT node12 . All three nodes maintain a direct TCP connection in order to exchange Bitcointransactions. We performed the aforementioned double-spending
attack a number of times; our results confirm that although
the Bitcoin XT node attempts to broadcast Td , V does notreceive Td . This clearly shows that the protection of Bitcoin
XT cannot deter double-spending.

11. Send Bl

Vendor

Double-Spending of 1-Confirmation Transactions.
Notice that if A is connected directly to a (honest) minerM, then A can also attempt to double-spend a transaction Tl which has already been confirmed by one block Bl
in the blockchain. In this case, the only means for A todouble-spend Tl would be to include the double-spendingtransaction Td in a fork of the blockchain. Recall that forks
frequently occur in the Bitcoin network [14], and are resolved automatically by choosing the longest fork chain. If
the blockchain fork, which contains Td , eventually emerges
as the longest fork, Td will be accepted by the majority ofthe peers in the network and double-spending is successful,since V can no longer redeem Tl .
To double-spend Tl , A connects directly to both V and
M in order to prevent the delivery of Td to both prior tobroadcasting it in the network. As mentioned earlier, thisensures that V and M do not receive Td , but the rest of the
network receives and mine for blocks which confirm Td . A
then sends Tl to M, with the aim that M confirms Tl in a
block.
With some probability, the Bitcoin network eventually includes Td in block Bd . Because Bd contains the doublespend transaction Td , A has to again prevent Bd from being
received by V and M. Later on, if M finds and broadcasts
a block Bl , then Bl will be accepted by V since the latterdoes not receive any conflicting transaction Td nor conflicting block Bd . This process is summarized in Figure 12.
Here, we assume that M does not control a large fraction of
the computing power—otherwise Bl will be likely includedin the main blockchain. Notice that A can collude with M(or can mine for blocks by herself) to further increase thesuccess probability of the attack.

5.3

Denial of Service

Delaying information propagation in a P2P-based cryptocurrency network such as Bitcoin can be very damaging as
it results in the delay of processing payments. Our findings
clearly suggest that e.g., Denial of Service (DoS) attacks
on Bitcoin can be made more easily realizable by exploiting the object request management of Bitcoin. That is, anadversary that controls a number of nodes in the network(and establishes connections with many Bitcoin nodes) caneffectively prevent the dissemination of information, such as
blocks and transactions, in the entire network.
Notice that there are approximately 6000 reachable Bitcoin nodes in the network13 . A resource-constrained adversary can simply connect to all these nodes and deny themthe delivery of transactions and blocks.
Given an average block generation time g, and a timeoutof 20 minutes per block (cf. Section 3.2), we estimate thenumber n of required inv messages to prevent the delivery
12

We employ the same setup as visualized in Figure 11, but
replace the Bitcoin network with the Bitcoin XT node.
13
Available from: https://getaddr.bitnodes.io/

Figure 12: The adversary A performs doublespending of a 1-confirmation transaction against a
vendor, by leveraging the computing power of a
weak miner. Td corresponds to the double-spending,and Tl to the legitimate transaction.
of consecutive blocks during time t:
l

m

t −1


g
X
t−g·i
n(t) =
20i=1(1)

In addition, A needs to fill and maintain the open connection slots of V. To prevent the delivery of blocks to all
6000 reachable full Bitcoin nodes, A needs to maintain approximately 450,000 active Bitcoin TCP connections14 andtransmit about 101 · 6000 ≈ 600KB of inv messages per
block. During time t, every node requires moreover n(t) inv
messages. Assuming that A can operate 10000 connections
per node15 , A requires approximately 45 nodes for attempting to constantly prevent block information propagation in
the Bitcoin network.
Notice that by denying the delivery of blocks from fullBitcoin nodes, A implicitly prevents the reception of theseblocks by the various lightweight Bitcoin clients16 .
This analysis complements the work of [20] and shows that
A can deny the delivery of blocks from the entire network
using almost 45 nodes, and by transmitting only 600 KB per
denied block for every 20 minute delay.

6.

COUNTERMEASURES

Based on our findings, we discuss and explore possible
avenues for enhancing the security of Bitcoin without deteriorating its scalability.
14

Assuming all 6000 Bitcoin nodes accept no more than
125 connections and maintain on average 50 connections.
Clearly, some Bitcoin nodes accept significantly more than
125 connections (1500 or more).
15
To limit the amount of information received from these
10,000 nodes, A can outsource a Bloom filter (similar to existing lightweight clients [19]) which match a small fractionof transactions in the system. By doing so, A reserves his
bandwidth to perform his DoS attack.
16
Lightweight Bitcoin clients (e.g. SPV nodes) do not validate nor maintain the full blockchain, and therefore get theirinformation from a subset of the reachable Bitcoin nodes.
Users typically prefer operating SPV clients, because theyrequire significantly less processing power and disk storage.

Alternative Relay Networks.
As outlined in Section 5.1, miners (and users) can rely on
additional relay networks to receive up-to-date informationfrom the network. These networks allow miners to directly
exchange information, which would effectively prevent anadversary from denying/delaying object delivery.
Matt Corallo’s relay network is one of the most prominent instantiations of an alternative relay network, currently
operating 5 relay nodes—each serving between 20 and 40
clients. Corallo’s network performs partial object validation and does not follow the request management system of
Bitcoin to ensure a faster spread of information in those networks. This allows any entity to flood the network with illformed objects—which might explain the reason why Corallo’s
network is still not widely used [3].
Notice, however, that alternative relay networks can bebuilt with different trust models, and can incorporate arbitrary policies to counter DoS; for instance, one can constructa small and trusted relay network only comprising one representative node from each centralized mining pool.

Dynamic Timeouts.
As described in Measure 3, Bitcoin relies on static timeouts in order to tolerate network delays. This implicitly
assumes that all nodes and resources in the network arehomogeneous—which is clearly not the case. As we show in
Figure 3, slow nodes require considerable time to download
blocks, while fast nodes can secure the download of blocks
in few seconds.
We believe that dynamic timeouts would suit better theheterogeneity of resources in the Bitcoin network. For thispurpose, we suggest the inclusion of the size of the message at advertisement time, which would allow each node
to dynamically estimate the timeout value according to its
resources, and the object size. For instance, when sending
block advertisements, we suggest that the miner includes
the block size into the block header17 —which would allow
receiving nodes to know the total block size and to appropriately estimate a dynamic timeout for any given block.
By doing so, we argue that the advantage of an adversary
in abusing timeouts to delay block delivery can be considerably reduced.
We observe that the current timeouts employed by Bitcoin
only capture the time starting from the getdata advertisement until the full data reception. Here, a timeout between
the data request and the beginning of the data transfer could
additionally be considered. We argue that such an approach
would increase the costs of the adversary in delaying the delivery of information.

Updating Block Advertisements.
Based on our observations, we recommend updating thecurrent block request system as follows:

new blocks in the network even if the adversary fills
all of its remaining connections to deny the delivery ofsuch information. Notice that each block header is 80
bytes, while a block’s inv message occupies 36 bytes.
Therefore, we do not expect a considerable increase in
the communication overhead due to this modification.
Keep track of block advertisers: Similar to transaction
advertisements, we suggest that Bitcoin nodes keep
track of the block headers’ advertisers. This recommendation goes hand in hand with the advertisement
based on block headers since it allows the node to request the blocks from the peers announcing the longest
chain. Additionally, this allows the node to request
the block from (a randomly chosen) advertising peerin case the chosen relay delays the delivery of the block.

Handling Transaction Advertisements.
As mentioned in Measure 4, a transaction is currently requested from the peers that advertised it first. If a given
peer does not respond within an appropriate timeout, thetransaction will be requested from the next peer stored in
the FIFO queue. As mentioned in Section 3.2, this gives considerable advantage for the adversary to prolong the timeout
before the receiver requests the transaction from any otherpeer. To remedy this, we suggest the following hardening
measures:
Filtering by IP address: One way to deter against suchan adversary would be to accept only one inv of thesame transaction per IP address. Notice that this cannot entirely prevent the adversary from advertising thesame transaction using different IP addresses.
Randomly choosing sender: Another complementary approach would be to randomly choose an incrementing
number of peers to contact from the list of advertising
peers if the first peer did not answer to the getdata
request. Here, a transaction is first queried from thefirst advertising peer. If this peer however does nottransmit the transaction within the specified timeout,
the transaction is requested from two randomly chosen peers simultaneously, then from three peers, until
the transaction is finally received. This will limit theadvantage of an adversary which tries to advertise firstthe same transaction several times.
Given these suggestions, the probability to receive a transaction after the n’s timeout, when the first advertising peer
is controlled by A, given ia inv messages sent by A and a
total of it inv messages is computed as follows:j(j+1) (i+1)(i+2) 
ia −
ia −
n Y
i
2
2
X
j+1
i+2
)
·
(1
−
)] (2)
Pt (n) =[ (j(j+1) (i+1)(i+2) 
it −
it −
i=0 j=1

No inv messages: We suggest to drop the advertisementof inv messages for blocks, and solely advertise theblock headers before transmitting the blocks. By doing
so, every receiver can immediately verify the correctness of the PoW, and learn about any new discovered
blocks in the network. As mentioned in Section 4, thiswill ensure that an honest node will always learn about
17

Block headers contain an unused field which was intended
for the number of transactions confirmed in the block.

2

j+1

2

i+2

Equation 2 allows one to compute the probability Pt (n)that a fast payment in Bitcoin is secure after a waiting timeof nt, where t is the timeout set by the node when handlingtransactions. Figure 13 depicts Pt (n) with respect to thewaiting time. Here, we assume that it = 125,18 t = 30
seconds and that the adversary controls a fraction iiat of18

Recall that the default maximum of neighbors per node is
125.

1.0

Pt(n)

0.8
0.6
ia
it = 0.50

0.4ia
it = 0.75

0.2
0.0

ia
it = 0.9530

60

90 120 150 180 210 240 270 300

Waiting time

Figure 13: Waiting time vs iiat . Here, t = 30 seconds
and it = 125.

the advertised inv messages. Our results show, that after
5 minutes waiting time, the node would be almost certain
to receive a transaction, even if the adversary controls 95%of the advertised inv messages (in return about 6 out of
125 inv messages originate from honest peers). Notice thatthe receiving peer can be alerted if a sudden increase in inv
advertisements occurs.
We conclude, that fast payments should only be accepted
after a waiting time nt to ensure with probability Pt (n) thatthe transaction cannot be double-spent—even if the doublespend first-relay protection is implemented in the network.
For a transaction request timeout of t = 30 seconds, thiswaiting time amounts to almost 5 minutes— which is half
the duration of the block generation time.

Operating Several Bitcoin Nodes.
Another effective alternative to harden the realization of
our attack consists of the installation of several Bitcoin nodes(operated by the same entity) in the official Bitcoin network.
By doing so, an adversary would have to prevent the deliveryof objects to all these nodes in order to deny the entity fromreceiving an object of interest. As shown in Section 3.2, themore connections a Bitcoin entity exhibits, the less likely an
adversary can delay the propagation of blocks and transactions. As shown in [21], this countermeasure can also effectively harden double-spending attacks on zero-confirmation
payments in Bitcoin.

Penalizing Non-responding Nodes.
We also suggest extending the penalty system employed
by Bitcoin (cf. Measure 1) to penalize non-responding peers.
Namely, nodes which constantly delay information delivery
after a getdata message should be penalized, and when appropriate disconnected from. Here, a careful design of theappropriate penalty is needed in order not to penalize slow
nodes in the network.

7.

RELATED WORKThe security and privacy of Bitcoin has received considerable attention from the research community. Bonneau
et al. [12] provide a comprehensive exposition of the second generation crypto-currencies, including Bitcoin and themany alternatives that have been implemented as alternate
protocols.
In [14], Decker and Wattenhofer investigate transaction
and block propagation time in Bitcoin. Gervais et al. analyze in [18] the limits of decentralization in Bitcoin, andshow that the vital operations and decisions that Bitcoin isundertaking are not decentralized.
Finney [17] describe a double-spending attack in Bitcoin
where the attacker includes in her generated blocks transactions that transfer some coins between her own addresses;
these blocks are only released in the network after the attacker double-spends the same coins using fast payments andacquires a given service. Barber et al. [10] analyze possible
ways to enhance the resilience of Bitcoin against a numberof security threats. Eyal and Sirer [16] show that Bitcoin
is not safe against attacks by selfish miners that command
more than 33% of the total computing power of the network.
Similarly, Courtois and Bahack [13] study subversive mining strategies where miners withhold their recently minedblocks in order to increase their advantage in the network.
Karame et al. [21, 22] investigate double-spending attacks
in Bitcoin and show that double-spending fast payments in
Bitcoin can be performed in spite of the measures recommended by Bitcoin developers. The authors also proposeda countermeasure which is currently integrated in Bitcoin.
All these studies, however, assume that the information
disseminated in the Bitcoin network is directly received bynodes. Recently, the Bitcoin developers discussed the possibility that a transaction transmission can be delayed [1], andhinted at the possibility to delay the delivery of blocks [2].
Miller et al. [23] exploited this observation and made useof the 2-minute transaction timeout in order to try to discover Bitcoin’s topology. In this paper, we extend thesestudies and show that an adversary can effectively preventthe delivery of transaction and block information from the
network peers for a considerable amount of time. Our work
share similarities with Heilman’s et al. eclipse attacks on
Bitcoin [20]. Here, the authors showed that by monopolizing the connections of nodes in the system, an adversary can
perform selfish mining, and abuse Bitcoin’s consensus protocol. Unlike [20], our work however shows that a resourceconstrained attacker can achieve considerable damage in the
network using only a handful of connections. By doing so,
our results suggest that the attacks outlined in [13,16,20,21]
can be even more aggravated (cf. Section 5).

8.

CONCLUDING REMARKSIn this paper, we showed that the current scalability measures adopted by Bitcoin come at odds with the security ofthe system. More specifically, we showed that an adversary
can exploit these measures in order to effectively delay the
propagation of transactions and blocks to specific nodes—
without causing a network partitioning in the system.
We analyzed the implication of our findings and showedthat these threats enable an adversary to easily mount Denialof-Service attacks on the entire network by preventing thedelivery of blocks in the system. Moreover, mining pools
can exploit this vulnerability to claim a higher mining advantage in the network. When combined with the results ofEyer and Sirer [16], our findings therefore suggest that selfish
mining pools which command less than 33% of the computing power can considerably increase their mining advantage.
Finally, our findings show that the countermeasure adopted

in Bitcoin XT to prevent the double-spending of fast payments can be easily circumvented by a resource-constrained
adversary.
Based on our findings, we explored a number of countermeasures in order to enhance the security of Bitcoin without
deteriorating its scalability. Notice that our findings are notparticular to Bitcoin and also apply to P2P networks andcrypto-currencies which use a similar request management
system such as Litecoin, and Dogecoin. We therefore hopethat our findings solicit more research towards the re-designof the request management system of Bitcoin.

Acknowledgements
The authors would like to thank the anonymous reviewers
for their valuable feedback and comments.

9.

REFERENCES[1] Bitcoin dev commit 4547: prevent peer flooding
request queue for an inv, 2015. Available from:https://github.com/bitcoin/bitcoin/pull/4547.
[2] Bitcoin dev commit 4831: net: Better askfor request
management, 2015. Available from:https://github.com/bitcoin/bitcoin/pull/4831.
[3] Bitcoin Mailing List - Peter Todd about how many
pools use an additional relay network, 2015. Available
from: http://sourceforge.net/p/bitcoin/mailman/
message/34152876/.
[4] Bitcoin market cap, 2015. Available from:https://blockchain.info/charts/market-cap.
[5] Bitcoin Relay Network, 2015. Available from:http://bitcoinrelaynetwork.org/.
[6] Bitcoin Scalability, 2015. Available from:https://en.bitcoin.it/wiki/Scalability.
[7] Bitcoin XT, 2015. Available from:https://github.com/bitcoinxt/bitcoinxt.
[8] Double spending in Bitcoin, 2015. Available from:https://medium.com/@octskyward/
double-spending-in-bitcoin-be0f1d1e8008.
[9] Stress Test Prepares VisaNet for the Most WonderfulTime of the Year, 2015. Available from:http://goo.gl/hba0oh.
[10] S. Barber, X. Boyen, E. Shi, and E. Uzun. Bitter toBetter - How to Make Bitcoin a Better Currency. In
Proceedings of Financial Cryptography and Data
Security, 2012.
[11] Trade - Bitcoin, 2013. Available from:https://en.bitcoin.it/wiki/Trade.
[12] Joseph Bonneau, Andrew Miller, Jeremy Clark,
Arvind Narayanan, Joshua A. Kroll, and Edward W.
Felten. Research Perspectives and Challenges for
Bitcoin and Cryptocurrencies. In 2015 IEEE
Symposium on Security and Privacy, May 2015.
[13] Nicolas T. Courtois and Lear Bahack. On subversiveminer strategies and block withholding attack in
bitcoin digital currency. CoRR, abs/1402.1718, 2014.
[14] C. Decker and R. Wattenhofer. Information
Propagation in the Bitcoin Network. In 13-th IEEE
International Conference on Peer-to-Peer Computing,
2013.
[15] Bitcoin exchanges, 2013. Available from:https://en.bitcoin.it/wiki/Exchanges.

[16] Ittay Eyal and Emin Gün Sirer. Majority is notenough: Bitcoin mining is vulnerable. In Financial
Cryptography and Data Security, pages 436–454.
Springer, 2014.
[17] The Finney Attack, 2013. Available from:https://en.bitcoin.it/wiki/Weaknesses#The_.22Finney.22_attack.
[18] Arthur Gervais, Ghassan Karame, Srdjan Capkun,
and Vedran Capkun. Is bitcoin a decentralized
currency? In IEEE Security and Privacy, 2014.
[19] Arthur Gervais, Ghassan O. Karame, Damian Gruber,and Srdjan Capkun. On the privacy provisions ofbloom filters in lightweight bitcoin clients. In
Proceedings of the 30th Annual Computer Security
Applications Conference, ACSAC 2014, New Orleans,
LA, USA, December 8-12, 2014, 2014.
[20] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg.
Eclipse attacks on bitcoin’s peer-to-peer network.
2015.
[21] Ghassan O. Karame, Elli Androulaki, and Srdjan
Capkun. Double-spending fast payments in bitcoin. In
Proceedings of the 2012 ACM conference on Computerand communications security, CCS ’12, New York,NY, USA, 2012. ACM.
[22] Ghassan O. Karame, Elli Androulaki, Marc Roeschlin,
Arthur Gervais, and Srdjan Čapkun. Misbehavior in
bitcoin: A study of double-spending andaccountability. ACM Trans. Inf. Syst. Secur.,18(1):2:1–2:32, May 2015.
[23] Andrew Miller, James Litton, Andrew Pachulski, Neal
Gupta, Dave Levin, Neil Spring, and Bobby
Bhattacharjee. Discovering bitcoin’s public topology
and influential nodes, 2015.

APPENDIXA.

REVENUE FOR SELFISH MINING

In what follows, we detail Eyal and Sirer’s revenue scheme.
1. Current state: Any state, except 2 branches of length 1.
Event: The pool finds a block, adds it to its secret chain.
Reward: Block reward is determined later.
2. Current state: Two branches of length 1.
Event: Pool finds a block.
Reward: Pool publishes two blocks, revenue of two blocks.
3. Current state: Two branches of length 1.
Event: Other find block on previous pool block.
Reward: Pool and other obtain revenue of one block each.
4. Current state: Two branches of length 1.
Event: Other find block on previous other block.
Reward: Other obtain revenue of two blocks.
5. Current state: No secret block.
Event: Other find block.
Reward: Other obtain revenue of one block.
6. Current state: One secret block.
Event: Other find block. Pool publishes secret block.
Reward: Block reward is determined later, depends on γ.
7. Current state: Leading two secret blocks.
Event: Other find block, only 1 secret left.
Reward: Pool publishes secret blocks, two blocks revenue.
8. Current state: Leading more than two secret blocks.
Event: Other find block, only 1 secret left.
Reward: Pool publishes one block, revenue of one block.