Content uploaded by Ghassan Karame
Author content
All content in this area was uploaded by Ghassan Karame on Dec 22, 2016
Content may be subject to copyright.
Misbehavior in Bitcoin: A Study of
Double-Spending and Accountability
Ghassan O. Karame
NEC Laboratories Europe
ghassan.karame@neclab.eu
Elli Androulaki
IBM Research Zurich
lli@zurich.ibm.com
Marc Roeschlin
ETH Zurich
romarc@student.ethz.ch
Arthur Gervais
ETH Zurich
arthur.gervais@inf.ethz.ch
Srdjan ˇ
Capkun
ETH Zurich
capkuns@inf.ethz.ch
Abstract
Bitcoin is a decentralized payment system that relies on Proof-of-Work
(PoW) to resist double-spending through a distributed time-stamping ser-
vice. To ensure the operation and security of Bitcoin, it is essential that
all transactions and their order of execution are available to all Bitcoin
users.
Unavoidably, in such a setting, the security of transactions comes at
odds with transaction privacy. Motivated by the fact that transaction
confirmation in Bitcoin requires tens of minutes, we analyze the conditions
for performing successful double-spending attacks against fast payments
in Bitcoin, where the time between the exchange of currency and goods
is short (in the order of a minute). We show that, unless new detection
techniques are integrated in the Bitcoin implementation, double-spending
attacks on fast payments succeed with considerable probability and can be
mounted at low cost. We propose a new and lightweight countermeasure
that enables the detection of double-spending attacks in fast transactions.
In light of such misbehavior, accountability becomes crucial. We show
that in the specific case of Bitcoin, accountability complements privacy.
To illustrate this tension, we provide accountability and privacy definition
for Bitcoin and we investigate analytically and empirically the privacy and
accountability provisions in Bitcoin.
1 Introduction
First introduced in 2008, Bitcoin [50] is an emerging digital currency that is
currently integrated across a number of businesses [15] and exchange markets
1
(e.g., [8]).
Bitcoin is a Proof-of-Work (PoW) based currency that allows users to gener-
ate digital coins by performing computations. Users execute payments by dig-
itally signing their transactions and are prevented from double-spending their
coins (i.e., signing-over the same coin to two different users) through a dis-
tributed time-stamping service [50]. This service operates on top of the Bitcoin
Peer-to-Peer (P2P) network that ensures that all transactions and their order
of execution are visible to all Bitcoin users.
Nowadays, Bitcoin is increasingly used in a number of“fast payment” scenar-
ios, where the exchange time between the currency and goods is short. Examples
include vending machine payments and fast-food payments (recently featured
in media reports on Bitcoin [23]), where the payment is followed by fast (in
the order of a minute) delivery of goods. While the Bitcoin PoW-based time-
stamping mechanism is essential for the detection of double-spending attacks
(i.e, in which an adversary attempts to use some of her coins for two or more
payments), it requires tens of minutes to verify a transaction and is therefore
inappropriate for fast payments. Since Bitcoin users are encouraged to hold
many accounts, there is only limited value in verifying the payment after the
user has obtained the goods (and e.g., left the store) or services (e.g., access to
on-line content). The developers of Bitcoin implicitly acknowledge the problem
of verifying fast payments and inform users that they do not need to wait for
the payment to be verified as long as the transaction has been released in the
network [11]. ; this, however, as we show, does not prevent double-spending.
In this work, we start by analyzing double-spending attacks on fast Bitcoin
payments and we show that, unless appropriate detection techniques are inte-
grated in current Bitcoin clients, double-spending attacks on fast payments suc-
ceed with overwhelming probability and can be mounted against current Bitcoin
clients at low cost. We further show that the detection measures recommended
by Bitcoin developers are not always effective in detecting double-spending; we
argue that even if those recommendations are followed, double-spending attacks
on Bitcoin are still possible. Leveraging our findings, we propose and imple-
ment a modification to the current Bitcoin implementation that ensures the
detection of double-spending attacks against fast payments. A variant based on
our proposed technique is integrated in Bitcoin XT [17].
Given the increasing use of Bitcoin, misbehavior in Bitcoin is only expected
to increase. Motivated by our double-spending investigation, we then proceed to
analytically and empirically investigate the degree of privacy and accountability
currently offered by Bitcoin. Our investigation aims at determining (i) the
extent of which misbehaving users/profiles can be identified, and (ii) the privacy
and accountability that Bitcoin offers to its users.
This paper extends and improves our prior work in [3,37] with significant new
material. More specifically, our contributions in this paper can be summarized
as follows:
- We measure and analyze the time required to confirm transactions in Bitcoin.
Our analysis shows that transaction confirmation in Bitcoin can be modeled
with a shifted geometric distribution with an average transaction confirmation
2
time of 10 minutes and a standard deviation of approximately 20 minutes. We
argue that this hinders the reliance on transaction confirmation when dealing
with fast payment scenarios.
- We thoroughly analyze the conditions for performing successful double-spending
attacks against fast payments in Bitcoin. We then present the first realiza-
tion of double-spending attacks on fast payments in Bitcoin using a handful of
hosts located around the globe1. Here, we extend our work in [37] and show
how an adversary can exploit block forks and version changes in Bitcoin in
order to perform such double-spending attacks.
- We explore the privacy and accountability provisions of Bitcoin. More specifi-
cally, we adapt existing privacy notions to the Bitcoin context and we investi-
gate analytically and experimentally the privacy and accountability provisions
of Bitcoin. In this respect, we extend our analysis in [3] and we collect statis-
tics acquired from the first 239,200 Bitcoin blocks using two of our proposed
heuristics. We also extend our simulation results to categorize the privacy
leakage in Bitcoin with respect to the user activity in Bitcoin (i.e., number of
transactions performed by users). Finally, we show that, in the case of Bitcoin,
accountability can be seen as the complement of privacy.
The remainder of the paper is organized as follows. In Section 2, we briefly
describe Bitcoin. In Section 3, we analyze and evaluate the security of fast
payments with existing Bitcoin clients. In Section 4, we evaluate the privacy
and accountability provisions of the Bitcoin system. In Section 5, we overview
related work and we conclude the paper in Section 6.
2 Background on Bitcoin
Bitcoin is a decentralized P2P payment system [50] that was introduced in 2008.
Electronic payments are performed by generating transactions that transfer Bit-
coin coins (BTCs) among Bitcoin peers. These peers are referenced in each
transaction by means of virtual pseudonyms—referred to as Bitcoin addresses.
Each address is mapped through a transformation function to a unique pub-
lic/private key pair. These keys are used to transfer the ownership of BTCs
among addresses.
Peers transfer coins to each other by issuing a transaction. A transaction is
formed by digitally signing a hash of the previous transaction where this coin
was last spent along with the public key of the future owner and incorporating
this signature in the coin [50]. Transactions take as input the references to an
output of another transaction which spends the same coins, and outputs the list
of addresses which can collect the transferred coins. Any peer can verify the
authenticity of a BTC by checking the chain of signatures.
Transactions are included in Bitcoin blocks that are broadcasted in the entire
network. To prevent double-spending of the same BTC, Bitcoin relies on the
1In our experiments, we solely used Bitcoin wallets and accounts that we own; other Bitcoin
users were not affected by our experiments.
3
synchronous communication assumption along with a hash-based PoW concept.
More specifically, to generate a block, Bitcoin peers, or miners, must find a nonce
value that, when hashed with additional fields (i.e., the Merkle hash of all valid
and received transactions, the hash of the previous block, and a timestamp),
the result is below a given target value. If such a nonce is found, miners then
include it (as well as the additional fields) in a new block thus allowing any entity
to verify the PoW. Upon successfully generating a block, a miner is granted a
number of BTCs (25 new BTCs since block 210,000). This provides an incentive
for miners to continuously support Bitcoin. The resulting block is forwarded to
all peers in the network, who can then check its correctness by verifying the
hash computation. If the block is deemed to be “valid”
2, then the peers append
it to their previously accepted blocks. Since each block links to the previously
generated block, the Bitcoin block chain grows upon the generation of a new
block in the network. Note that when miners do not share the same view in the
network (e.g., due to network partitioning), they might work on different block
chains, thus resulting in “forks” in the block chain. Block forks are inherently
resolved by the Bitcoin system; the longest block chain will eventually prevail.
In rare occasions, the Bitcoin developers can force one chain to be adopted on
the expense of others [35]. Transactions which do not appear in blocks that are
part of the main block chain (i.e., the longest) will be re-added to the pool of
transactions in the system and re-confirmed in subsequent blocks.
The main intuition behind Bitcoin is that for peers to double-spend a given
BTC, they would have to replace the transaction where the BTC was spent and
the corresponding block where it appeared in, otherwise their misbehavior would
be detected immediately. This means that for malicious peers to double-spend
a BTC without being detected, they would not only have to redo all the work
required to compute the block where that BTC was spent, but also recompute
all the subsequent blocks in the chain. The older a Bitcoin transaction is, and
thus the deeper it is included in the block chain, the harder it becomes to
modify/double-spend the transaction.
Further details on Bitcoin can be found in [13,14,50]. In what follows,
we provide a summary (adapted from [50]) of the steps that peers undergo in
Bitcoin when a payment occurs.
•New transactions are broadcasted by peers in the network.
•When a new transaction is received by a peer, it checks whether the trans-
action is correctly formed, and whether the BTCs have been previously
spent in a block in the block chain. If the transaction is correct, it is stored
locally in the memory pool of peers until it is included in a valid block. In
the paper, we refer to a transaction that appears in the memory pools of
peers as a zero-confirmation transaction.
•Miners work on constructing a new block. If they find a PoW, they in-
clude all the transactions that appear in their memory pool within the
newly-formed block. Miners then broadcast the block in the network.
2That is, the block contains correctly formed transactions that have not been previously
spent, and has a correct PoW.
4
Transaction that are included in well-formed blocks are called “confirmed
transactions”
3.
•When peers receive a new block, they verify that the block hash is valid
and that every transaction included within the block has not been previ-
ously spent. If the block verification is successful, miners continue working
towards constructing a new block using the hash of the last accepted block
in the “previous block” field.
3 Security Analysis of Fast Bitcoin Payments
In what follows, we analyze and evaluate the effectiveness of double-spending
attacks on fast Bitcoin payments (i.e., where the exchange between currencies
and services happens simultaneously). Leveraging our findings, we propose and
implement a modification to the current Bitcoin implementation to accelerate
the detection of double-spending attacks against fast payments.
3.1 Model
Our system consists of a malicious client A, and a vendor V, connected through
a Bitcoin network. We assume that Awishes to acquire a service from Vwithout
having to spend its BTCs. More specifically, Acould try to double-spend the
coin she already transferred to V. By double-spending, we refer to the case
where Acan redeem and use the same coins with which she paid Vso as to
acquire a different service elsewhere.
We assume that Acan only control few peers in the network (that she can
deploy since Bitcoin does not restrict membership) and does not have access to
V’s keys or machine. The remaining peers in the network are assumed to be
honest and to correctly follow the Bitcoin protocol. In this paper, we assume
that Adoes not participate in the block generation process. This also suggests
that when a transaction is confirmed in a block, this transaction cannot be
modified by A. In order to hide her profile, we assume that Agenerates a new
Bitcoin address whenever it communicates with V.
3.2 Transaction Confirmation Time
As described in Section 2, the most conventional way for a vendor Vto accept
a payment made by a customer Cis to wait until the transaction issued from
Cto Vis confirmed in at least one block before offering service to C. In what
follows, we analyze the block generation times in Bitcoin.
To generate a block, miners work on constructing a PoW. In particular,
given the set of transactions that have been announced since the last block’s
generation, and the hash of the last block, Bitcoin miners need to find a nonce
3In current Bitcoin clients, a transaction has to receive 6 confirmations before it is added
to the user’s wallet.
5
Figure 1: Distribution of the an-
nouncement times of transactions.
We assume that transactions are an-
nounced uniformly at random within
two successive blocks.
0 10 20 30 40 50
0.00 0.05 0.10 0.15 0.20
Block Generation Time (minutes)
Fraction of Blocks / Probability
Fraction of Blocks
Shifted Geometric Dist. p=0.19
Figure 2: Block generation times in
Bitcoin. Assuming a (time) bin size of
2 minutes, the block generation func-
tion can be fitted to a shifted geomet-
ric distribution with p= 0.19.
such that:
SHAd256{Bll|| MR(TR1,..., TRn)|| No} ≤ target ,(1)
where SHAd256 is the SHA-256 algorithm applied twice, Blldenotes the last
generated block, MR(x) denotes the root of the Merkle tree with elements x,
TR1|| ... || TRnis a set of transactions that have been chosen by the miners to
be included in the block4, No is the 32-bit nonce, and target is a 256-bit number.
To generate the PoW, each miner chooses a particular subset of the candidate
solutions’ space and performs brute-force search. It is apparent that the bigger
target is, the easier it is to find a nonce that satisfies the PoW.
In the following, we show that (i) the success of each miner in generating
a block within sufficiently small time intervals can be simulated as a Bernoulli
trial, and (ii) that the success probability of block generation within a sequence
of small time intervals corresponds to successive Bernoulli trials with substitu-
tion (which is also known as shifted geometric distribution [45]). For the purpose
of our analysis, we note the following:
1. The probability of success in a single nonce-trial is negligible. Taking
in consideration that SHA-256 is a pseudo-random permutation function,
each of the 232 nonces has target
2256−1probability of satisfying the PoW.
2. Miners compute their PoW independently; as such, the probability that
one of them succeeds does not depend on the progress of PoW of the
others.
3. Miners frequently restart the generation of their PoW, whenever a new
transaction is added to the memory pool of a miner, the Merkle root
(included in the block) changes.
4. For the sake of our analysis, we approximate the time interval between
the announcement of successive transactions as follows. We extract the
4These transactions are chosen from the transactions which have been announced (and not
yet confirmed) since Bll’s generation.
6
various block generation times from the Bitcoin block explorer and we
assume that transactions are announced uniformly at random between two
successive block generations. Our findings (Figure 1) show that the time
interval between the announcement of most pairs of successive transactions
is below 15 seconds. Therefore, we assume in the sequel that the PoW for
block generation is restarted approximately every dt ≈15 seconds.
Given the first two observations, the probability of a miner in succeeding
in an individual block generation attempt can be modeled as an independent
Bernoulli process with success probability ε=target
2256−1. Based on the last obser-
vation, we claim that consecutive block generation attempts can be modeled as
sequential Bernoulli trials with replacement. Our claim for replacement is jus-
tified by the fact that maximum possible PoW progress performed by a miner
(expressed as a number of hash calculations) before its PoW resets, is negligible
in comparison to 2256 −1. This is the case since the PoW progress approximates
235 ≪2256 −1 given the computing power of most Bitcoin miners [42,43].
Let nirefer to the number of attempts that a miner miperforms within a time
period δ. Typically, δis in the order of few minutes. The probability piof mi
finding at least one correct PoW within these trials is given by pi= 1−(1 −ε)ni.
Since εand niare small, pican be approximated to pi= 1 −(1 −ε)ni≈niε.
Therefore, the set of trials of miwithin δcan be unified to constitute a single
Bernoulli process with success probability niε.
Assuming that there are ℓminers, mi, i = 1 . . . ℓ with success probability
pi, i = 1 . . . ℓ respectively, the overall probability of success in block generation
can be approximated to:
pr ≈1−
ℓ
Y
i=1
(1 −pi),or pr = 1 −(1 −p)ℓ≈ℓ·p.
This is true when pℓ ≪1 and when the miners have equal computing power,
i.e., pi=p, i = 1 . . . ℓ.
We divide time into equal sized intervals of size δ; let t0= 0 denotes the time
when the last block was generated. Here, each miner can make up to nitrials
for block generation within each interval. Let the random variable Xkdenote
the event of success in the time interval between tkand tk+1. That is,
Xk=1 if a block is created between tk−1,and tk,
0 otherwise.
It is evident that: Prob(Xk= 1) = pr. Conceivably, after a success in block
generation, miners stop mining for that particular block. We denote the number
of attempts until a success is achieved by another random variable Y.
Prob(Y=k) = Prob(Xk= 1)
k−1
Y
i=1
Prob(Xi= 0) = pr(1 −pr)k−1.
7
Assuming a constant rate of trials per time window δ, the number of failures
until a success is observed in block generation is proportional to the time it
takes for a block to be generated. Let Tdenotes the time period till a block is
generated.
Prob(T=k·δ) = Prob(Y=k) = pr(1 −pr)k−1.
Given this, we conclude that the distribution of block generation times can
be modeled with a shifted geometric distribution with parameter pr [45].
In Figure 2, we confirm this analysis and we show that (experimental) block
generation times in Bitcoin, can be fitted to a shifted geometric distribution with
p= 0.19.5For the purpose of our experiments, we considered δto be 2 minutes.
To measure the generation time of existing Bitcoin blocks, we created a Python
script that parses the block chain of Bitcoin (up to June 2013) and extracts the
time intervals between the generation of consecutive blocks. Our findings show
that while the average block generation time is approximately 10 minutes (10
minutes and 2.66 seconds), the standard deviation of the measurements is about
1241.3855 seconds which corresponds to almost 20 minutes.
This also shows that the time required to confirm transactions impedes the
operation of many businesses that are characterized by a fast-service time. As
such, it is clear that vendors, such as vending machines and take-away stores [12],
cannot rely on transaction confirmation when accepting Bitcoin payments. To
address that, Bitcoin encourages vendors to accept fast Bitcoin payments with
zero-confirmations as soon as the vendor receives a transaction from the network
transferring the correct amount of BTCs to one of its addresses [11,12].
3.3 Necessary Conditions for Successful Double-Spending
To perform a successful double-spending attack, the attacker Aneeds to trick
the vendor Vinto accepting a transaction TRVthat Vwill not be able to redeem
subsequently.
In this case, Acreates another transaction TRAthat has the same inputs as
TRV(i.e., TRAand TRVuse the same BTCs) but replaces the recipient address
of TRV—the address of V— with a recipient address that is under the control
of A. If both transactions are sent at the same time, they are likely to have
similar chances of getting confirmed in an upcoming block. This is the case since
Bitcoin peers will not accept multiple transactions that share common inputs;
they will only accept the version of the transaction that reaches them first which
they will consider for inclusion in their generated blocks and they will ignore all
subsequent transactions. Given this, a double-spending attack can succeed if V
receives TRV, and the majority of the peers in the network receive TRAso that
TRAis more likely to be included in a subsequent block.
Let tV
iand tA
idenote the times at which node ireceives TRVand TRA,
respectively. As such, tV
Vand tA
Vdenote the respective times at which Vreceives
5We acquired p= 0.19 by fitting the average and variance of block generation times that
we acquired experimentally from the block chain (up to June 2013) in a shifted geometric
distribution [45].
8
0123456
x 104
0
0.2
0.4
0.6
0.8
1
Number of Bitcoin Nodes that received
the double−spent transaction
Success Probability
p=10−6
p=10−5
Figure 3: PS(2) with respect to various values of ηk
Aand ηk
V. Here, p= 10−6,
δ= 10 seconds, t0= 0, ts=δand the number of peers in the network is 60000.
TRVand TRA. Given this, we outline the necessary conditions for A’s success
in performing a double-spending attack.
Requirement 1 — TRVis added to the wallet of VIf TRVis not added
to the memory pool of V, then Vcannot check that TRVwas indeed broadcasted
in the network. Note that for TRVto be included in V’s wallet, then tV
V< tA
V;
otherwise, Vwill first add TRAto its memory pool and will reject TRVas it
arrives later.
Requirement 2 — TRAis confirmed in the block chain If TRVis
confirmed first in the block chain, TRAcan never appear in subsequent blocks.
That is, Vwill not have its BTCs back. Recall that the goal of Ais to acquire
a service offered by Vwithout having to spend her BTCs.
Requirement 3 — V’s service time is smaller than the time it takes
Vto detect misbehavior Since Bitcoin users are anonymous and users hold
many accounts, there is only limited value in Vdetecting misbehavior after
the user has obtained the service (and e.g., left the store). As such, for Vto
successfully detect any misbehavior by A, the detection time must be smaller
than the service time. In Section 4, we investigate in details the linkability of
Bitcoin addresses.
3.4 Performing Double-Spending Attacks in Bitcoin
In this section, we discuss how Acan satisfy Requirements (1),(2), and (3).
Table 1summarizes the notations used in Section 3.
9
Table 1: Summary of notations used in Section 3.
Notation Explanation
AAttacker machine
VMerchant machine
HHelper nodes colluding with A
TRxTransaction x
niNumber of attempts that a miner miperforms to find a PoW
piProbability that mifinds a PoW after nitrials
pr Probability of success of all miners in finding a PoW
ηk
VThe number of Bitcoin peers that received (and mine for) TRV
ηk
AThe number of Bitcoin peers that received (and mine for) TRA
pV(k) Probability that a block containing TRVis generated within the time interval ]tk, tk+1]
pA(k) Probability that a block containing TRAis generated within the time interval ]tk, tk+1]
δA
HV Propagation delay of TRAto reach the merchant
δV
AV Propagation delay of TRVto reach the merchant
tgATime required by miners to generate a block containing TRA
tgVTime required by miners to generate a block containing TRV
TRATransaction double-spending coins to A’s addresses
TRVOriginal transaction destined to merchant
tV
iTime at which node ireceives TRV
tA
iTime at which node ireceives TRV
∆ Delay between the transmission of TRAand TRV
PSProbability that the double-spending attack succeeds
PDProbability that the merchant receives both TRAand TRVafter waiting for 15 seconds
Satisfying Requirement 1 — TRVis added to the wallet of V
In the sequel, we assume that Ahas access to a set of helper nodes, denoted
by H.Aand Hdo not necessarily have to be on physically disjoint machines
(e.g., Hcould run as a thread/process on the same machine as A). We further
assume that Hnever connects directly to Vin the Bitcoin P2P network.
As shown in Figure 4,Asends TRVto Vat time τVand TRAto Hat time
τA, such that τA=τV+ ∆. Vand Hrelay the transactions that they received
from Ain the network. Let δA
HV refer to the time it takes TRAto propagate in
the Bitcoin P2P network from Hto Vand δV
AV denote the time it takes TRV
to reach V. In this case, tA
V−tV
Vcan be estimated as follows:
tA
V−tV
V≈τA+δA
HV −(τV+δV
AV )≈∆ + δA
VH −δV
AV .(2)
Note that since His never a neighbor of V, there is at least one hop on the
path between Hand V. For simplicity, we assume that Aconnects directly to
V. We acknowledge that some vendors may not accept direct incoming connec-
tions [16], or may be located behind Network Address Translators (NATs). In
Section 3.5, we show that our analysis can also apply in the case where Ais not
directly connected to V.
Since Ais an immediate neighbor of Vand assuming no congestion at net-
work paths, then δA
VH > δV
AV . In this case, tV
V< tA
Vfor reasonably chosen ∆
(e.g., ∆ ≥0), thus satisfying Requirement (1).
Satisfying Requirement 2 — TRAis confirmed in the block chain
Since Hand Vare highly likely to have different neighbors, the broadcasted
transactions are likely to spread in the network till the point where either (i)
10
Vendor
Attacker
Helper node
Time
Figure 4: Sketch of a double-spending attack on fast payments in Bitcoin. Here,
the attacker Adispatches two transactions that use the same BTCs in the
Bitcoin network. The double-spending attack is successful if the BTCs that
Aused to pay for Vcannot be redeemed (i.e., when the second transaction is
included in the upcoming Bitcoin block).
all Bitcoin peers accept in their memory pools TRVor TRAor (ii) either TRV
or TRAgets confirmed in a block.
In what follows, we estimate the probability that TRAis confirmed in a block
first. In our analysis, we denote by t0the time at which both transactions TRA
and TRVfirst coexist in the network6, and we assume that no block containing
either one of them has been generated till that time. We argue that this is a
realistic assumption given that TRAand TRVneed to be typically broadcasted
back to back given a small delay (in the order of few seconds); it is therefore
unlikely that one of them is confirmed within the first few seconds in a new block.
In the experiments in Section 3.5, we relax this assumption and we evaluate the
general case where either TRAand TRVcan be confirmed immediately when
they are broadcasted in the network.
We divide time into equal intervals of size δ, such that, the probability of
successful block generation in each δcan be modeled as a Bernoulli trial with
success probability η·p, where ηis the number of peers that work towards block
generation and pthe success probability of a peer in generating a block within
δ.7
Let tk=k·δ+t0and ηk
Vand ηk
Adenote the number of Bitcoin peers that
received (and mine for) TRVand TRArespectively until time tk. Each Bitcoin
node will only add to its memory pool the transaction it receives first among
TRVand TRA. Since only the transactions that appear in the memory pool
of peers are eligible to be confirmed in subsequent blocks, the probability that
6This does not necessarily mean that TRAand TRVare broadcasted at the same time.
7The probability that at least a miner succeeds in block generation within δis the comple-
ment of the probability that none of the peers who are working towards the block generation
succeed, and equals to 1 −(1 −p)η≈1−(1 −η·p) = η·p, where η·p≪1.
11
TRVis included in a block within time interval ]tk, tk+1] is: Prk
V=ηk
V·p.8
Similarly, for TRA, the corresponding probability is Prk
A=ηk
A·p.9Thus, the
probability pV(k) that a block containing TRVis generated within the time
interval ]tk, tk+1] is:
pV(k) = Prk
V·
k−1
Y
i=0
(1 −Pri
V) = ηk
Vp·
k−1
Y
i=0
(1 −ηi
Vp).
Similarly, the probability that a block containing TRAis generated at the
same time interval is given by:
pA(k) = Prk
A·
k−1
Y
i=0
(1 −Pri
A) = ηk
Ap·
k−1
Y
i=0
(1 −ηi
Ap).
If at time ts=s·δ+t0every node in the network has received at least one
of the transactions TRVor TRA, the following holds:
ηk
A≤ηk+1
Aand ηk
V≤ηk+1
V,if k < s
ηk
A=ηk+1
A=ηs
Aand ηk
V=ηk+1
V=ηs
V,otherwise.
This suggests that ∀i≥s,ηi
V+ηi
A=ηs
V+ηs
A. To compute the probability
of success of the double-spending attack, we make the assumption that, ∀k,ηk
V
and ηk
Ado not exchange their newly constructed blocks; in this way, the time
tgVrequired by peers that are mining in favor of TRVto generate a new block
is independent of that required by the peers that are mining in favor of TRA,
tgA. Given this, the probability that Requirement (2) is satisfied, PS(2) , is:
PS(2) = Prob(tgA< tgV) + 1
2Prob(tgA=tgV).
That is, PS(2) is composed of two components; one corresponds to the event
that the block containing TRAis first generated and the second to the event
where the blocks containing TRAand TRVare generated at the same time, i.e.,
tgA=tgV. In the latter case, the probability that the block containing TRA
is eventually adopted by the Bitcoin peers is 0.5. Here, Prob(tgA< tgV) and
Prob(tgA=tgV) are computed as follows.
Prob(tgA< tgV) =
∞
X
gA=0
pA(gA)·pV(gV> gA|gA) (3)
=η0
Ap(1 −η0
Vp) +
∞
X
gA=0
ηgA
Ap·(1 −ηgA
Vp)·
gA−1
Y
j=0
(1 −ηj
Vp)(1 −ηj
Ap).
(4)
8This stems from the fact that the probability that at least one out of the ηk
Vnodes
succeeding in block generation in the time interval between tkand tk+1 (each with success
probability pin this time interval) is given by Prk
V= 1 −(1 −p)ηk
V). Since ηk
V·p≪1, the
previous equation can be written as Prk
V=ηk
V·p.
9Note that in this case both ηk
V·p≪1, and ηk
A·p≪1; here, we assume that the time
interval between tkand tk+1 is short enough to satisfy these constraints.
12
Prob(tgA=tgV) =
∞
X
gA=1
p2ηgA
VηgA
A·
gA−1
Y
j=0
(1 −ηj
Vp)(1 −ηj
Ap).
For the purpose of this analysis, we assume that ts=δand that δ= 10
seconds. We can therefore rewrite PS(2) as follows:
PS(2) = Prob(tgA< tgV) + 1
2P rob(tgA=tgV).
Prob(tgA< tgV) = η0
Ap(1 −η0
Vp) + η1
Ap(1 −η0
Ap)(1 −η0
Vp)(1 −
η1
Vp)P∞
gA=2 η1
Ap(1 −η0
Ap)(1 −η1
Ap)(gA−2) ·(1 −η0
Vp)(1 −η1
Vp)(gA−1)
Prob(tgA=tgV) = η0
Vη0
Ap2+
∞
X
gA=1
η1
Vη1
Ap2(1−η0
Vp)·(1−η0
Ap)[(1−η1
Vp)·(1−η1
Ap](gA−1).
(5)
In Figure 3, we depict PS(2) for various values of ηk
V,ηk
Aand pwhen δ= 10
seconds, ts=δand the number of peers in the network is 60000. Our analysis
therefore shows that Acan maximize PS(2) by increasing the number of peers
that receive TRA,ηk
A,∀tk.Acan achieve this: (i) by sending TRAbefore
TRVand therefore giving TRAa better advantage in spreading in the network
and/or (ii) by relying on multiple helpers to spread TRAfaster in the network.
In the former case, Acan delay the transmission of TRVby a maximum of
∆ = δA
VH −δV
AV (cf. Equation 2) after sending TRAwhile ensuring that Vfirst
receives TRV. In this way, both Requirements (1) and (2) can be satisfied.
Satisfying Requirement 3 — V’s service time is smaller than the time
it takes Vto detect misbehavior
As advocated in [12], one possible way for Vto detect double-spending at-
tempts is to adopt a “listening period”, of few seconds, before delivering its
service to A; during this period, Vmonitors all the transactions it receives,
and checks if any of them attempts to double-spend the coins that Vpreviously
received from A. Note that Vcan also rely on additional nodes that it controls
within the Bitcoin network—“observers”—that would directly relay to Vall the
transactions that they receive.
These techniques are based on the intuition that since it takes every trans-
action few seconds10 to propagate to every node in the Bitcoin network, then it
is highly likely that Vor its observers would receive both TRVand TRAwithin
the listening period (and before granting service to A).
This detection technique can be circumvented by Aas follows. Acan at-
tempt to delay the transmission of TRAsuch that t=(tA
V−tV
V) exceeds the
listening period (Requirement (3)) while TRAstill has a significant chance of
10Our experiments in Section 3.5 show that the average time for a peer to receive both TRA
and TRVis approximately 3.354 seconds if both transactions were sent concurrently.
13
Figure 5: PSversus ∆ when Vhas
40 connections. Here, the vendors
are located at 4 different network
locations (Locations 1 and 2 are
in North America, and Locations 3
and 4 are in Asia Pacific).
Figure 6: PSversus ∆ when Vhas
125 connections. Here, the ven-
dors are located at 4 different net-
work locations (Locations 1 and 2
are in North America, and Loca-
tions 3 and 4 are in Asia Pacific).
Location # Helpers ∆ (sec) PS
Asia Pacific 1, 125 connections 2 0 100%
Asia Pacific 2, 125 connections 2 0 100%
North America 1, 8 connections 1 0 100%
North America 2, 40 connections 1 0 90%
Asia Pacific 1, 8 connections 2 1 100%
Asia Pacific 2, 125 connections 2 1 100%
North America 1, 40 connections 1 -1 100%
Figure 7: Summary of Results. Here, “Location” denotes the location of V,
“connections” denote the number of V’s connections.
being spread in the network. On one hand, as tincreases, the probability that
all the immediate neighbors of Vin the Bitcoin P2P network receive TRVfirst
also increases; when they receive TRAlater on, TRAwill not be added to the
memory pool of V’s neighbors and as such TRAwill not be forwarded to V. On
the other hand, Ashould make sure that TRAwas received by enough peers so
that Requirement (2) can be satisfied. To that end, Acan increase the number
of helpers it controls.
It is interesting to note that a Bitcoin node located at http://blockchain.
info/ keeps track of all transactions exchanged in the system, and attempts
to identify double-spending transactions [18]). However, this information is not
propagated to peers in the network.
3.5 Experimental Evaluation
We now present the experimental results of double-spending experiments in the
Bitcoin network. Our experiments aim at investigating the satisfiability of the
aforementioned Requirements (1),(2) and (3).
14
Experimental Setup: We adopt the setup described in Section 3.4 in which
the attacker Ais equipped with one or more helper nodes Hthat help her relay
the double-spent transaction. In our experiments, we made use of 10 Bitcoin
nodes located around the globe; this serves to better assess the different views
seen from multiple points in the Bitcoin overlay network and to remove any bias
that might originate from specific network topologies.
To perform the attack, we modified the C++ implementation of Bitcoin
client version 0.5.2. Conforming with our analysis in Section 3.4, our new client
does the following:
•The attacker connects to the vendor’s machine. Here, we assume that V
accepts direct connections if it has fewer than 125 connections11. If the
connection is refused, Acan wait until a neighbor of Vdisconnects before
attempting to connect again.
•The attacker creates transactions TRVand TRAspending the same coins.
She sends TRVusing the Bitcoin network to the neighboring vendor and
TRAto one or more helper nodes with an initial delay ∆ of -1, 0, 1, and
2 seconds. Here, ∆ refers to the time delay between the transmission of
TRVand TRAby A.
•Upon reception of TRA, each helper node broadcasts it in the Bitcoin
network.
With this setup, we performed double-spending attempts when the vendors
are located at 4 different network locations (2 vendors were in North America
and the remaining 2 were in Asia Pacific). In our experiments, Awas located
in Europe. However, since Adoes not contribute in spreading any transaction
herself, her location does not affect the outcome of the attack. That is, the sole
role of Ais to send TRVto Vusing a direct connection in the Bitcoin network.
We conducted our experiments with a varying number of connections of the
vendor (8, 40 and 125 connections) and by varying the number of helper nodes (1
and 2). The helper nodes were connected to 125 other Bitcoin peers. Each data
point in our measurements corresponds to 10 different measurements, totaling
approximately 500 double-spending attempts. We also created a Python script
that, for each conducted measurement, parses the generated logs along with the
Bitcoin block explorer [10] to check whether Requirement (2) is satisfied.
Satisfying Requirements 1 and 2: To assess the feasibility of double-
spending in fast Bitcoin payments, we evaluate empirically the success prob-
ability with respect to the number of helper nodes, the number of connections
of the vendor and ∆.
Our experimental results, depicted in Figures 5,6, and 7show that, irrespec-
tive of a specific network topology, the probability that Asucceeds in performing
double-spending attacks is significant. Confirming our previous analysis, PSde-
creases as ∆ increases. As explained in Section 3.4, this is due to the fact that
the higher is ∆, the larger is the number of peers that receive TRV; in turn,
11Note that the maximum number of connections can be modified using the “-
maxconnections” command [25].
15
the probability that TRAis confirmed before TRVdecreases. As shown in Fig-
ures 5, and 6, this can be remedied if the number of helper nodes that spread
TRAincreases. Our results show that even for a large ∆ of 2 seconds, relying
on 2 helper nodes still guarantees that double-spending succeeds with a consid-
erable probability; when ∆ = 1 seconds, the attack is guaranteed to succeed
(PSis close to 1) using 2 helpers. This is summarized in Figure 7. Generalizing
these results, it is clear that Asucceeds, with high probability, in spending the
same coin to n≥1 different recipients as long as the number of helpers that
assist Ain spreading TRAis greater or equal to n. As we show in the previous
section, the larger is n, the higher is the probability that A’s misbehavior is
detected.
The number of V’s connections considerably affects PSespecially when A
controls only one helper; in the case where Vhas a similar number of connections
when compared to the number of connections of the helper, PSapproaches 0.5.
This corresponds to the case where TRAand TRVare spread equally in the
network (Figure 6). On the other hand, as the connectivity of Vdecreases,
TRAspreads faster in the network (cf. Figure 5).
Satisfying Requirement 3: In our experiments, we were looking for triplets
(∆, NH,C), where NHis the number of helper nodes, and Cis the number of
V’ connections, that minimize the probability PDthat Vreceives TRA.
In Table 2, we include a number of triplets (∆, NH,C) for which PS>0 and
PD= 0 (i.e., t=tA
V−tV
V=∞). These are instances of the case where all the
neighbors of Vreceive TRVfirst and do not forward TRA. We point out that
in this case, although PSis modest, Ahas considerable incentives in performing
double-spending attacks since the probability that Vdetects her misbehavior is
zero. In Table 3, we show other instances of (∆, NH,C) for which PS≥PD.
Here, although PD>0, Astill has an advantage in performing double-spending
attacks, since these attacks are more likely to succeed.
Our findings therefore show that, even if Vadopts a listening period of few
tens of seconds, double-spending is still possible. Our experiments also show that
the triplets (∆, NH,C) resulting in PS≥PDdo not depend on the location of
Hnor Vnor on the time of the measurements; as shown in Table 3, the same
triplets can be used repeatedly by Ato perform attacks at various times and in
different network topologies.
In addition, we evaluated this technique using up to 5 observers. Our findings
in Tables 2and 3show that this method can help detecting double-spending as
all double-spent transactions were received by at least one observer within few
seconds. However, given that Adelays the transmission of TRA, our results
show that only a subset of the observers receive TRA. As mentioned previously,
this corresponds to the case where all the neighbors of these observers have
received TRVfirst and as such they will not forward TRAback to the observers.
Therefore, Vneeds to employ a considerable number of observers (≈3) (that
connect to a large number of Bitcoin peers) to ensure that at least one observer
detects any double-spending attempt; this, however, comes at the expense of
additional costs for Vto maintain the observers in the network.
16
Table 2: Example of triplets (∆, NH,C) where PS>0, PD= 0 and tA
V−tV
V=∞.
In these cases, Vnever receives TRAand as such can not detect double-spending
attacks, even if it adopts a very large listening period.
PSPDtA
V−tV
V(sec) % Observed
South America, 8 Connections, 3 Helpers, ∆ = 2.5 7.7% 0% ∞53%
South America, 8 Connections, 4 Helpers, ∆ = 3.0 13.33% 0% ∞57%
Asia Pacific, 8 Connections, 3 Helpers, ∆ = 2.75 10% 0% ∞57%
Asia Pacific, 8 Connections, 3 Helpers, ∆ = 2.75 5% 0%∗∞66%
North America, 20 Connections, 3 Helpers, ∆ = 2.75 5% 0% ∞47%
Asia Pacific, 60 Connections, 1 Helper, ∆ = 3.00 10% 0%∗∞20%
Clearly, in the general case where Aattempts to n-times spend the same
coins, the larger is n, the bigger is the probability that this misbehavior is
detected by fewer observers in the network. Our results show that double-
spending attacks can be successfully mounted even when ∆ >1 second. This
also suggests that Adoes not have to be directly connected to Vand may release
TRVin the Bitcoin network ∆ seconds before Hreleases TRA. That is, when
∆ is not small (e.g., ∆ >1), this also means that (i) the merchant’s transaction
will exhibit a comparable spread in the network irrespective of whether Ais
directly connected to Vor not12, and (ii) the probability that the merchant
receives TRVbefore receiving TRAis high. As shown in our experiments, A
can maximize its probability of success by relying on multiple helpers when ∆
is large.
3.6 Abusing Forks in Bitcoin
Our analysis in Sections 3.4 and 3.5 shows that double-spending fast transactions
is feasible during the normal operation of the Bitcoin system. In what follows,
we discuss double-spending attacks in the special case where Bitcoin is subject
to block chain forks [26].
Block Forks: During the normal Bitcoin operation, miners work on extending
the longest block chain in the network. If miners do not share the same view
in the network (e.g., due to network partitioning), they might work on different
block chains, thus resulting in “forks” in the block chain. As an example, in
March 2013, due to a difference in how Bitcoin versions 0.7 and 0.8 handled the
block chain database, a serious block chain fork occurred (cf. Figure 8). The
fork started at block-height 225,430 and at block-height 225,451 the 0.8 fork
exceeded the 0.7 fork by 13 blocks. The Bitcoin developers however, decided to
support the smaller chain supported by the Bitcoin version 0.7. During block
forks, the adversary bears little risk in performing double-spending attacks.
Indeed, under such settings, the adversary can try to include TRVin one chain,
and TRAin another [31].
12Indeed, since Bitcoin users will immediately broadcast transactions where they appear
as senders or recipients in the network, the merchant’s transaction will be almost directly
broadcasted in the network after it is received.
17
Table 3: Example of triplets (∆, NH,C) where PS≥PD. In these cases, Vcan
detect double-spending attempts with some probability by adopting a listening
period, but since PS≥PD, then a number of A’s double-spending attempts
will not be detected, which gives her incentives to perform double-spending
attempts.
PSPDtA
V−tV
V(sec) % Observed
Europe, 8 Connections, 3 Helpers, ∆ = 2.00 10% 10% 8.664 53%
Europe, 8 Connections, 3 Helpers, ∆ = 2.25 10% 10%∗5.65 47%
South America, 8 Connections, 2 Helpers, ∆ = 2.5 20% 6.66%∗3.749 62%
Asia Pacific, 8 Connections, 2 Helpers, ∆ = 1.75 55% 20%∗5.5 91%
North America, 20 Connections, 5 Helpers, ∆ = 3.00 11% 11% 3.208 46%
North America, 20 Connections, 1 Helper, ∆ = 1.25 30% 30%∗3.34 78%
North America, 20 Connections, 4 Helpers, ∆ = 2.00 82% 63% 2.85 78%
North America, 20 Connections, 2 Helpers, ∆ = 2.00 20% 20%∗4.79 60%
North America, 20 Connections, 1 Helper, ∆ = 1.50 40% 30%∗3.51 60%
Europe, 20 Connections, 3 Helpers, ∆ = 1.0 45% 45%∗3.844 87%
Europe, 30 Connections, 1 Helper, ∆ = 1.5 15% 10%∗3.412 42%
Asia Pacific, 40 Connections, 1 Helper, ∆ = 2.9 10% 10%∗4.946 42%
Europe, 40 Connections, 1 Helper, ∆ = 1.25 10% 10% 1.841 36%
Europe, 40 Connections, 2 Helpers, ∆ = 1.5 20% 20%∗3.075 36%
South America, 40 Connections, 1 Helper, ∆ = 2.0 30% 40% 3.217 57%
Asia Pacific, 80 Connections, 1 Helper, ∆ = 3.7 10% 20% 5.04 18%
Europe, 80 Connections, 1 Helper, ∆ = 2.75 13.33% 26.67% 5.093 28%
Asia Pacific, 100 Connections, 1 Helper, ∆ = 1.5 80% 80% 2.807 88%
Double-spending using forks: In what follows, we present an exemplary
double-spending attack—that we tested in Bitcoin—which takes advantage of
block forks. Our attack leverages an exploit in Bitcoin that arises from the
simultaneous adoption of client versions 0.8.1 and 0.8.2 (or beyond) in the net-
work. Starting from version 0.8.2, Bitcoin clients no longer accept transactions
which do not follow a given signature encoding. As we show, this incompatibil-
ity with prior client versions can potentially lead to a double-spending attack in
a fast payment setting in Bitcoin. The attack can only work when Voperates
on any client version prior to 0.8.2.
Up to version 0.8.1, a transaction signature could contain zero-padded bytes
and the signature check would still be valid. However, starting from version
0.8.2, transactions with padding will no longer be accepted to the memory pool
of nodes nor will they be relayed to other nodes13 . This gives a considerable
advantage for Ato mount a double-spending attack as follows:
1. Asends a transaction TRVwith a zero-padded signature to V.
2. TRVwill be relayed to the miners. Miners that use any Bitcoin version
newer than 0.8.1 will not accept the transaction in their memory pool,
and thus not include it into a block. Miners with an older Bitcoin version
will accept it.
3. Awaits for a small time t(e.g. 1-5 minutes), until she acquired service
from the merchant.
4. Then, provided that TRVwas still not included in a Bitcoin block, A
13This applies to all Bitcoin versions starting from version 0.8.2 until the time of writing
(i.e., version 0.8.5).
18
225429
225430
225461
Block height
225462
version 0.7 and
0.8 compliant
version 0.8
compliant version 0.7 and
0.8 compliant
version 0.7 and
0.8 compliant
version 0.7 and
0.8 compliant
version 0.7 and
0.8 compliant
version 0.7 and
0.8 compliant
Figure 8: Bitcoin chain fork in March 2013 due to concurrent adoption of client
versions 0.7 and 0.8.
sends another transaction TRAthat double-spends the inputs of TRVto
the benefit of a new Bitcoin address that is controlled by A. TRAis not
padded with additional zeros.
5. If most peers in the network use newer client versions than version 0.8.1,
they will accept TRA(and will reject TRV). The higher is the fraction of
peers that use version 0.8.2 (or beyond), the larger is the likelihood that
TRAis included in a block, and that the attack succeeds.
We implemented this double-spending attack in a private “test” Bitcoin net-
work comprising of two Bitcoin miners, a merchant, and the adversary’s ma-
chine. In our setup, the merchant was running client version 0.8.1, while the
miners were running version 0.8.2. Our results show that such a double-spending
attack succeeds with 100% probability in the investigated setting.
We therefore hope that our findings increase the awareness within the Bitcoin
community on the delicacy of version releases. Indeed, while block forks might
“naturally”occur from time to time in the network, such forks are unlikely to last
for more than few blocks, as the network views tend to naturally converge on
the longest block chain within few blocks. We argue that new version releases,
on the other hand, can cause more serious damages, since they might result in
long-lasting block forks that can only be stopped by manual intervention. Ver-
sion releases should therefore be carefully designed for backward-compatibility;
otherwise, the Bitcoin system might witness severe misbehavior.
19
3.7 Countermeasure: Forwarding Double-Spending Attempts
in the Network
In order to efficiently detect double-spending on fast Bitcoin payments, we pro-
pose that Bitcoin peers forward transactions that attempt to double-spend the
same coins in the Bitcoin network. Namely, our technique unfolds as follows.
Whenever a peer receives a new transaction, it checks whether the transaction
uses coins that have not been spent in any other transaction that resides in
the block chain and in their memory pool. If so, then peers follow the current
protocol of Bitcoin; peers add the transaction to their memory pool and for-
ward it in the network. If, on the other hand, peers detect that there is another
transaction in their memory pool that spends the same coins to different recipi-
ents, then peers forward the transaction to their neighbors (without adding the
transaction to their memory pools).
The main intuition behind this technique is that while Amight be able to
prevent Vand a subset of V’s observers from receiving TRA, a considerable
number of Bitcoin peers receive both TRAand TRV. If the majority of these
peers are honest14, both transactions would eventually reach Vwithin few sec-
onds. The double-spending of Acan be therefore detected before Aactually
receives the service from V. We emphasize that our proposed technique does
not change the spread of each transaction within the memory pools of Bitcoin
peers (as such, it does not affect the success probability of the attack). Instead,
this technique ensures that both transactions are received within few seconds
by Vand that any possible double-spending attempt is detected almost imme-
diately. This intuition is based on our previous measurements: our experiments
in Section 3.4 show that the average time for a transaction to be received by the
vendor is approximately 3.354 seconds after the transaction has been released
in the Bitcoin network.
We implemented this technique and integrated it with the official Bitcoin
client. Our modified Bitcoin client also keeps track of the number of established
connections to warn the user when this number drops below a threshold value
(80 in our case) and uses our proposed detection technique to (visually) alert the
user when a double-spending attempt was detected on any of its transactions.
We have evaluated the performance of our modified client by integrating it in
the Bitcoin network for a period of 7 consecutive days. During the evaluation
period, our modified client was able to forward all double-spent attempts (that
we manually injected in the network) with a detection rate of 100%.
We acknowledge that this detection technique can result in the increase of
the number of transactions circulating in the Bitcoin network and could be
(ab)-used to affect the performance of the network (e.g., to conduct Denial of
Service attacks [9]). We argue however that peers can only forward the first
double-spending transaction attempt in the network, and drop all subsequent
double-spending of the same coin. This variant ensures that all peers in the
network can identify, and verify the misbehaving address, and refuse to receive
14This is the underlying assumption that ensures the correct operation of Bitcoin.
20
any subsequent payment/transaction from this address. This variant detection
technique is integrated in Bitcoin XT [17]; a number of Bitcoin nodes already
use this technique to report double-spending attempts [29].
4 Evaluating User Privacy and Accountability
in Bitcoin
Our findings in Section 3suggest that misbehavior in Bitcoin is inevitable, and
is only expected to increase as the utility of the system increases. Currently,
Bitcoin nodes locally ban the IP address of the misbehaving user for 24 hours.
Clearly, such an approach is not sufficient to deter misbehavior, since malicious
peers can, e.g., modify/spoof their IPs or even try to connect to and attack
other peers, who still haven’t blacklisted their IP address.
We argue that if Bitcoin is to sustain another decade of service, then it must
incorporate accountability measures in order to ensure that a misbehaving user is
indeed “punished”. In this respect, one possible solution would be to enforce Bit-
coin address blacklisting. Here, the idea would be that those Bitcoin addresses
which have been found to misbehave (e.g., double-spend), are added to a public
blacklist. Ideally, the BTCs of the blacklisted addresses will not be accepted by
Bitcoin peers, and will therefore lose their value. Besides the concerns/issues
related to the management and maintenance of such lists, this approach is not
sufficient, when used alone, to deter misbehavior since misbehaving users can
be equipped with many addresses each containing low balances.
Therefore, one natural question that emerges is whether it is possible to link
different Bitcoin addresses of the same (misbehaving) user (address linkability).
If such linking were possible, misbehaving users could receive some degree of
punishment for their misbehavior by not being able to spend (a large fraction
of) their funds. Clearly, this comes at odds with user privacy, which is strongly
coupled with the notion of address unlinkability. More specifically, while privacy
in Bitcoin reduces to activity unlinkability, accountability is strongly coupled
with the traceability of a user’s transactions. In this section, we analyze the
tension between privacy and accountability in Bitcoin. Our analysis aims to
answer the following question: to which extent can one infer information about
users in Bitcoin?
4.1 Methodology
We frame the above question by defining the information leakage using novel
privacy and accountability definitions of Bitcoin. More specifically, we observe
the public log of Bitcoin, denoted by pubLog, within a period of time ∆. During
this period, nUusers, U = {u1, u2,...,unU}, participate in pubLog through a
set of nAaddresses: A={a1, a2,...,anA}.We assume that within ∆, nTtrans-
actions have taken place as follows: T = {τ1(S1→R1),...,τnT(SnT→RnT)},
where τi(Si→Ri) denotes a transaction with (unique) ID number iand Siand
Ridenote the sets of senders’ addresses and recipients’ addresses, respectively.
21
Given pubLog, we quantify and evaluate the privacy and accountability provi-
sions of Bitcoin. In the sequel, we assume a security parameter κ; the security
parameter can be seen as a measure of the running time of our adversary.
4.2 Quantifying Privacy and Accountability in Bitcoin
Activity linkability refers to the ability of an adversary Ato link two different
addresses (address linkability) or transactions (transaction linkability) that per-
tain to the same user of the system, and in this sense, activity unlinkability is
strongly associated to accountability. That is, the more a third party, e.g., law
enforcement, is able to reconstruct the set of addresses or transactions of an
individual, the easier it is to make Bitcoin users accountable for any misbehav-
ior. More specifically, fee-based punishments for double-spending acts could be
more effective, e.g., by blacklisting or invalidating the BTCs of the addresses
that are linked to the double-spender address.
However, activity linkability seems to contradict the privacy requirements
of a payment system with public transaction logs as Bitcoin, where it is crucial
to maintain the confidentiality of each individual’s balance and transactions.
Therefore, we see activity unlinkability as the privacy-preserving complement of
linkability.
We note that since two Bitcoin transactions are not more linkable than
the addresses that participate in those transactions, we focus our analysis on
unlinkability of addresses. In particular, we define address unlinkability through
the following AddUnl game, and we quantify it by assessing the advantage of
an adversary Ain winning this game over an adversary who responds to all
game challenges with random guesses, AR. We assume that Ahas access to
pubLog and that both Aand ARhave gathered (the same) a-priori knowledge
KAwith respect to correlations of a subset of addresses. KAcan include any
information related to address ownership, e.g., the identity of the owner of the
address, the transactional habits of the latter, whether two specific addresses are
owned by the same individual, etc. For simplicity, we assume in the following
that KAconsists of a list of probabilities of correlating every pair of addresses
in pubLog; clearly, the correlation probability between addresses for which the
adversary has no prior knowledge about, equals the default probability that the
two addresses are owned by the same individual (depending on the assumed
game). The adversary can gather this a-priori knowledge, e.g., by interacting
with users in the system [40].
We construct the following address unlinkability game in Bitcoin, AddUnl,
which consists of an adversary Aand of a challenger Cwho knows the correct
assignment of addresses to Bitcoin entities. The adversary Achooses an address
a0chosen among the addresses that appear in pubLog, but for which the adver-
sary has no prior knowledge (expressed in KA), and sends it to the challenger C.
The challenger Cchooses a bit buniformly at random. If b= 1, then Cchooses
another address a1randomly from pubLog such that a0, a1belong to the same
user; otherwise, Crandomly chooses a1such that the two addresses are owned
by different users. The challenger sends ha0, a1ito A, who responds with her
22
estimate b′on whether the two addresses belong to the same user. Awins the
game if she answers correctly, i.e., b=b′. We say that Bitcoin satisfies address
unlinkability if for all probabilistic polynomial time (p.p.t.) adversaries A, and
∀ha0i,Ahas only at most a negligible advantage over ARin winning, i.e., if:
Prob[b′← A(pubLog,KA, a0, a1) : b=b′]−Prob[b′← AR(KA, a0, a1) : b=b′]≤ε,
where εis negligible with respect to the security parameter κ.
Quantifying Address (Un-)linkability: In what follows, we quantify the unlink-
ability offered by Bitcoin by measuring the degree to which Bitcoin addresses
can be linked to the same user. To do so, we express the estimate of Athrough
an nA×nAmatrix, Elink, where Elink [i, j ] = {pi,j}i,j∈[1,nA]. That is, for every
address ai,Aassesses the probability pi,j with which aiis owned by the same
user as every other address ajin pubLog. Note that Elink incorporates KA, and
any additional information that Acould extract from pubLog (e.g., by means
of clustering, statistical analysis, etc.). Similar to [44], we quantify the success
of Ain the AddUnl game as follows. Let GTlink denote the genuine address
association matrix, i.e., GTlink [i, j] = 1, if aiand ajare of the same user and
GTlink[i, j ] = 0 otherwise for all i, j ∈[1,nA]. For each address ai, we compute
the error in A’s estimate, i.e., the distance of Elink[i, ∗] from the genuine associ-
ation of aiwith the rest of the addresses in pubLog,||Elink[i, ∗]−GTlink[i, ∗]||,
where || · || denotes the L1 norm of the corresponding row-matrix. Thus, the
success of Ain AddUnl, SuccA, can then be assessed through A’s maximum
error: max
∀ai/∈KA
(||Elink[i, ∗]−GTlink [i, ∗]||).
Similarly, we represent the estimate of ARin the AddUnl game for all possi-
ble pairs of addresses by the nA×nAmatrix ER
link which is constructed as follows.
ER[i, j] = πi,j if hai, aji ∈ KA, and ER
link[i, j ] = ρ+ (1 −ρ)1
2otherwise. Here,
πi,j represents the probability that addresses aiajcorrespond to the same user
according to KA, and ρis the fraction of addresses that cannot be associated
to other addresses (i.e., when their owners have only one address). For pairs
of addresses that are not included in KA, this probability equals to 1
2(1 + ρ),
i.e., to the probability that at least one of the two happens: (i) a0is the only
address of its owner, or (ii) ARdid not succeed in guessing bcorrectly.
Given this, we measure the degree of address linkability in Bitcoin by eval-
uating the additional success that Acan achieve from pubLog, when compared
to AR. We call this advantage Linkabs
A= SuccA−SuccAR, and its normalized
version: LinkA=SuccA−SuccAR
SuccAR.
Address unlinkability can then be measured by the normalized complement
of Linkabs
A, UnLinkA= 1 −SuccA−SuccAR
SuccAR.
4.3 Exploiting Existing Bitcoin Client Implementations
Current Bitcoin client implementations enable Ato link a fraction of Bitcoin
addresses that belong to the same user.
23
0
500000
1e+06
1.5e+06
2e+06
2.5e+06
3e+06
2009 2010 2011 2012 2013 2014
Number of GAs
Time
(a) Evolution of GA dynamics.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
40+ 0 5 10 15 20 25 30 35
Fraction of GAs
Number of Addresses per GA
(b) Number of addresses per GA.
Figure 9: Number of addresses until June 2013 and the number of addresses per
GA.
Heuristic I—Multi-input Transactions: As mentioned earlier, multi-
input transactions occur when uwishes to perform a payment, and the pay-
ment amount exceeds the value of each of the available BTCs in u’s wallet. In
fact, existing Bitcoin clients choose a set of BTCs from u’s wallet (such that
their aggregate value matches the payment) and perform the payment through
multi-input transactions. It is therefore straightforward to conclude that if these
BTCs are owned by different addresses, then the input addresses belong to the
same user [3,48].
Heuristic II—“Shadow” Addresses: As mentioned earlier, the standard
Bitcoin client generates a new address, the “shadow” address [7], on which each
sender can collect back the “change” [3].
This mechanism suggests a distinguisher for shadow addresses. Namely, in
the case when a Bitcoin transaction has noutput addresses, {aR1,·, aRn}, such
that only one address is a new address (i.e., an address that has never appeared
in pubLog before), and all other addresses correspond to an old address (an ad-
dress that has appeared previously in pubLog), we can safely assume that the
newly appearing address constitutes a shadow address for ai. Note that the
official Bitcoin client started to support transactions with multiple recipients
since December 16, 2010.
Evaluating Heuristics I and II: In what follows, we evaluate the implica-
tions of these heuristics on user privacy and accountability in Bitcoin. For that
purpose, we modified the blockchain parser in [55] in order to parse the first
239,200 blocks (June 2013).
Our modified C++ parser extracts all the addresses in each block and catego-
rizes them in clusters of General Addresses, GAs, given the two aforementioned
heuristics. The parser then outputs a list of addresses organized in different
GAs. Our results are depicted in Figures 9,10, and 11.
As shown in Figure 9(a), our results show that the number of GAs consider-
ably increased over time since the genesis of Bitcoin. Our parser distinguishes
almost 3,000,000 GAs, each comprising on average 4.5 addresses. Figure 9(b)
24
(a) Evolution of the num. of addresses
per GA.
0 10 20 30 40 50 60
0
0.2
0.4
0.6
0.8
1
Number of Bitcoins
Fraction of GA
Block 26250 (2009−11−02)
Block 52500 (2010−04−22)
Block 78750 (2010−09−08)
Block 105000 (2011−01−28)
Block 131250 (2011−06−16)
Block 157500 (2011−12−14)
Block 183750 (2012−06−09)
Block 239200 (2013−06−02)
(b) Evolution of the balance of GA.
Figure 10: Evolution of GA dynamics with time.
depicts the distribution of addresses per GA. More than 70% of GAs comprise
of a single address; we believe that these are addresses of “inactive” users in the
system who only “mine” and collect BTCs but rarely perform transactions in
the system. Nevertheless, our heuristics enable the linking of addresses of up to
30% of the GAs. Note that our parser identified a number of very large GAs
(i.e., comprising of more than 50 addresses). We believe that these are addresses
of big players in the Bitcoin ecosystem, such as GAs of electronic wallets, mar-
ket places or mining pools. For example, we were able to distinguish 4,238,361
addresses belonging to one GA corresponding to the mining pool deepbit [27].
In Figure 10(a), we show the evolution of the average number of addresses
per GA with respect to time. Here, it is interesting to note that the number
of addresses per GA only started increasing one year after the genesis block.
This supports our observation that at the start most Bitcoin users were inactive
and simply were involved in the mining process. Recall that our heuristics can
only link addresses of active entities that participate in Bitcoin transactions. In
Figure 10(b), we depict the accumulated balance per GA over time. Till the
end of 2009, we can see that nearly no GA had less than 50 BTCs. This is
consistent with the fact that within the first six months of Bitcoin’s existence,
few transactions have been conducted and block generation was awarded with 50
BTCs. On the other hand, our measurements in June 2013 show that 98% of the
GAs have less than 2 BTCs. This is reminiscent to the fact that Bitcoin users
have become increasingly active and are spreading their coins across several of
their addresses, collecting transaction fees, etc.
In Figure 11, we capture the information leakage due to our heuristics from
the public Bitcoin log. Figure 11(a) depicts the relationship among various
GAs; more specifically, we show the number of different GA entities that send
transactions to other GAs. We refer to GAs which interact with each other
as friends. Similarly, Figure 11(b) shows the number of transactions captured
within each GA; our results show that almost 35% of the GAs did not participate
in any transaction and as such were only mining and collecting BTCs. On the
other hand, most GAs that were captured by our heuristics participated in less
25
than 5 transactions. This is the case since our best-effort heuristics could only
track the transactions performed by GAs within the period of few weeks; as
shown in Figure 11(c), these heuristics were ineffective in tracking the activity
of GAs for longer periods. Finally, in Figure 11(d), we depict the average
transaction amount (in BTCs) per GA.
Clearly, our results in Figure 9,10, and 11 hint that an adversary might
be able to win the AddUnl game with high probability. Indeed, simply by
observing the public Bitcoin log, the adversary can link some of the addresses
and transactions of entities. However, our heuristics can only cluster a small
number of addresses, and link addresses that perform transactions close in time.
In Section 4.4, we show that the advantage of the adversary in linking Bitcoin
addresses can be significantly boosted when combining the use of Heuristics I
and II with standard clustering algorithms.
As an application of our analysis, we identified two Bitcoin addresses be-
longing to Torservers.net (using information available from blockchain.info).
Given the knowledge of these two addresses, we were able to identify a total of
47 addresses, belonging to the operator of Torservers, with a total balance of
498.20 BTC.
Note that it is not easy for the adversary to evade both Heuristics I and II.
That is, to evade Heuristic I, the adversary should not combine its coins/ad-
dresses in a single transaction; since it is unlikely that all payments made by
the adversary will exactly match the coins in her possession, a large number of
shadow addresses that are pertaining to the adversary will be created to collect
the change. These addresses can be subsequently captured by Heuristic II [3].
One way to evade Heuristics I and II would be for the adversary to rely
on mixers, such as Bitcoin banks, web-wallets, or CoinJoin [24]. These mixers
shuffle the coins of all their customers, thus preventing an external entity to link
between the inputs and outputs of a transaction. Clearly, this strategy however
does not protect against an honest but curious mixer, and only provides a degree
of anonymity for the adversary against an external entity e.g., which is not
participating in the CoinJoin protocol. Furthermore, it is not clear whether such
mixing techniques (e.g., [19,24,49]) can completely hide the profiles of Bitcoin
users. As we show in the following paragraphs, the amounts in each payment
and the transaction times constitute a strong distinguisher for an adversary to
cluster the transactions/addresses of Bitcoin users.
4.4 Clustering Bitcoin Addresses
Besides exploiting current Bitcoin implementations, clustering techniques can
also be used in order to link different addresses. In what follows, we proceed
to measure the effectiveness of linking different addresses in Bitcoin using clus-
tering algorithms such as K-Means (KMC), and the Hierarchical Agglomerative
Clustering (HAC) algorithms. We also measure the degree of address unlinka-
bility.
To evaluate the success of Ain the AddUnl game, we simulate a realistic
case of using Bitcoin in the Department of Computer Science in ETH Zurich.
26
0.1
0.2
0.3
20+ 0 5 10 15
Fraction of GAs
Number of friends per GA
(a) Connectivity per GA. Here, “Friends” re-
fer to distinct GA entities that each GA in-
teracts with.
0.0001
0.001
0.01
0.1
1
40+ 0 5 10 15 20 25 30 35
Fraction of GAs
Number of transactions per GA (as sender)
(b) Distribution of the number of transactions
performed by each GA.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
20+ 0 5 10 15
Fraction of GA
Timespan per GA in days
(c) Lifetime of GAs.
0.001
0.01
0.1
1
100+ 0 10 20 30 40 50 60 70 80 90
Fraction of GAs
Average amount spent per transaction
(d) Average amount per transaction within
GAs
Figure 11: Characterization of GAs obtained using Heuristics I and II.
Here, we assume that the shops located around the university also accept BTCs
as a currency. Given the lack of details and statistics about the current use of
Bitcoin, this was one of the few “workable” uses of Bitcoin that we could try to
accurately model and through which we could evaluate the advantage of Ain
the system.
Experimental Setup: To evaluate the privacy implications of using Bitcoin
in a university environment, we constructed a Bitcoin simulator and devised the
setup shown in Figure 12. Our Bitcoin simulator takes an XML configurations
file as input and outputs: (i) a log that details the events that were simulated,
the “ground truth”, as well as (ii) the resulting simulated public Bitcoin log,
pubLog. The XML configurations file contains all the necessary parameters to
run the simulator. These include the number of users, the number of miners, the
simulation time, the difficulty in block generation, as well as usage configurations
for creating user profiles and Bitcoin sellers/buyers.
Our s imulator is round-based; in each simulation round (defined as a “weekly
timestepping” interval), events are added to a priority queue with a probabil-
ity dictated by the configuration file. These events correspond to one of the
following operations:
•Issue a new transaction: Users might issue new Bitcoin transactions whose
27
Figure 12: Experimental setup used throughout our simulations. The outputs of
our Bitcoin simulator are pre-filtered according to Heuristics I and II and then
fed as input to our clustering algorithm. The clustering result is then compared
with the “ground truth” that is emulated by our simulator.
time, value, beneficiary and purpose stem from the XML configurations
file. The process of transaction issuance in our simulator fully mimics its
counterpart in the genuine Bitcoin system.
•Generate a new Bitcoin address: Here, “privacy-aware” users might decide
to manually generate a number of new addresses to further obfuscate their
usage of Bitcoin [48]. This captures the behavior of an adversary who tries
to prevent linking of its addresses by constantly creating new addresses.
Our Bitcoin simulator abstracts away network delays, congestion, jitter, etc.
We also assume that all transactions in the system are well-formed and we do not
model transaction fees that are incurred in the network. Moreover, our simulator
relies on a variant coin selection algorithm that approximates the algorithm used
in Bitcoin for coin selection; our greedy algorithm chooses the coins which will
result in the smallest number of inputs for any given transaction. Throughout
our experiments, we assume that new blocks are generated every 20 minutes
on average; by doing so, we ensure that the number of transactions confirmed
within blocks generated by our simulator is comparable to that of Bitcoin.
As shown in Figure 12, the outputs of our simulator are used to evaluate
A’s success. In fact, once the simulations terminate, a Perl-based parser uses
the simulated Bitcoin block as input and pre-classifies the simulated addresses
into GAs according to Heuristics I and II. The resulting “pre-filtered output”
is then fed into our clustering algorithms, the HAC and the KMC algorithms
(both implemented in C). The output of these algorithms is then compared
using another Perl-based script with the ground truth in order to evaluate the
success of A.
We tuned our simulator to match a real-world scenario that reflects the
actual behavior of the staff and student members of a Computer Science De-
28
partment of a university in the Fall 2012 semester. In our setting, we consider
a variable number of users, 5.2% of which are “Professors”, 42.0% are “Staff”
and the remaining 52.8% are “Students”. We consider a total of 6 events, each
having several options: lunching/dining (12 options), buying groceries (2 op-
tions), buying from vending machines (4 options), online shopping (5 options),
purchasing books (2 options), and performing barters with other users, totalling
25 different Bitcoin vendors present in our system. For each user, we assign a
probability that the user undergoes each of the possible options of each event.
These probabilities are assigned according to the “category” of the user; that is,
if the user is a “Professor”, then it is more likely that he/she would eat lunches
at more expensive restaurants, when compared to the case where the user falls
in the “Student” category. For each event, we specify in the XML configura-
tion the following parameters: the frequency of the event, and the price range
per option of the event. Note that each option is assigned a rating that would
reflect its popularity. The probability of performing an option is interpolated
from the frequency of occurrence of the event per week, and from the rating
of the option. To ensure a large variety of profiles in our user base, we specify
in the XML configuration a minimum and maximum value for the frequency,
rating and price fields. These bounds depend on the category of the user, the
event and option in question. At the start of our experiments, users originally
have few (<10) Bitcoin addresses; as they issue new transactions, new (shadow)
addresses are created in their wallets. In the XML file, we also model the be-
havior of “privacy-aware” users. We assume that these users create new Bitcoin
addresses in their wallets and send some of their BTCs from their old to their
new addresses.
Clustering Addresses: We cluster addresses in our setting using the KMC,
and the HAC algorithms. The HAC algorithm assumes that initially each GA
represents a separate cluster ({zi=i}nGA
i=1 ) and computes similarity values for
each pair of clusters. Clusters with higher similarity value are combined into
a single cluster and cluster-to-cluster similarity values are re-computed. The
process continues until the number of created clusters equals the number of
users nU. KMC is then initialized using the output of HAC and assumes that
each user is represented by the center of each cluster. The algorithm iterates
assignments of GAs to clusters and aims at minimizing the overall distance of
GAs to the center of the cluster they have been assigned to. The centers of the
clusters and the GA-to-cluster distances are re-computed in each round.
Let Ube the set of users populating Bitcoin and (GA1,...,GAnGA ) denote
the GAs that Ahas obtained by applying the two aforementioned heuristics on
pubLog, respectively. Given this, the goal of Ais to output a group of clusters of
addresses Eprof ={g1,...,gnU}such that Eprof best approximates U. Since each
GA is owned by exactly one user, the estimate on the assignment of each GAi
can be modeled by a variable zisuch that zi=k, if and only if, GAibelongs to
gk. In our implementation, we represent each transaction that appears within
aGA using: (i) the time at which the transaction took place, (ii) the indexes of
the different GAs that appear within the transaction (as senders or recipients),
29
and (iii) the values of the BTCs spent by the transaction. Let τxdenote the
set of transactions of GAx. The degree of similarity between GAiand GAj,
denoted by Simhac(GAi,GAj), is then represented by the cosine similarity of lists
τiand τj, i.e., Simhac(GAi,GAj) = P∀τ∈τi∩τj(f(τ ,i)·f(τ,j))
kτik·kτjk,where f(τ,i),f(τ,j)are
the occurrences of item τin lists τiand τjrespectively, and kXkdenotes the
L2 norm of vector X. Given this, the resulting distance metric in KMC is
Distkmc(GAi,gk) = 2
1+Simhac(GAi,gk)−1.
Our implementation also accounts for constraints that are posed in realistic
deployments. Namely, since users cannot be physically located in two different
places at the same time, they cannot participate in two different (physical)
exchanges of goods at the same time. To account for this case, we apply different
weighting for similarity of GAs who participate in transactions concurrently.
We quantify the success of Ain clustering addresses in Bitcoin by measuring
the similarity of A’s estimate Eprof from the genuine grouping of profiles GTprof ,
Sim(Eprof ,GTprof ), where the similarity function Sim ranges in [0,1]. Similar to
quantifying address unlinkability, we assess the advantage of Ain approximating
GTprof over ARby ProfA= Sim(Eprof ,GTprof )−Sim(ER
prof ,GTprof ).
We evaluate Sim(Eprof,GTprof ) and Prof Aby relying on two commonly used
entropy based distance metrics, namely: the Normalized Mutual Information
(NMI) and the Adjusted Mutual Information, (AMI). NMI assesses the simi-
larity of two groupings of the same items (in our case, Eprof and GTprof ), and
takes higher values (1) the more identical the groupings are [53,54]. On the
other hand, given the two groupings Eprof and GTprof AMI approaches 0 when
Eprof is close to random assignment of addresses/transactions to groups, i.e.,
ER
prof , and is 1 when Eprof matches GTprof [53,54]. Assuming address-based
profiles, NMI and AMI are computed as follows:
NMI = I(Eprof ,GTprof )
max(H(Eprof ),H(GTprof )) ,AMI = I(Eprof ,GTprof )− E
max(H(Eprof ),H(GTprof )) − E ,
where:
I(Eprof ,GTprof ) =
nU
P
i=1
nU
P
j=1
n(i,j)
nAlog( n(i,j)·nA
n(i,∗)n(∗,j)),
H(Eprof ) = −
nU
P
i=1
n(i,∗)
nAlog( n(i,∗)
nA),H(GTprof ) = −
nU
P
j=1
n(∗,j)
nAlog( n(∗,j )
nA),
E=
nU
P
i=1
nU
P
j=1 P
n∈M
n
nAlog( nAn
n(i,∗)n(∗,j))n(i,∗)!n(∗,j)!(nA−n(i,∗))!(nA−n(∗,j ))!
nA!(n(i,∗)−n)!(n(∗,j)−n)!(nA−n(i,∗)−n(∗,j)−n)! . Here,
nAis the number of Bitcoin addresses, n(i,j)is the number of ui’s addresses,
which are assigned to group gj,n(i,∗)and n(∗,j)are the number of addresses of ui
and gjrespectively. Ereflects the expected mutual information between GTprof
and a random grouping of addresses (ER
prof ). Also, M= [max(n(i,∗)+n(∗,j)−nA,0),
min(n(i,∗), n∗,j )]. Similar calculations can be derived to compute NMI and AMI
for transaction-based profiles.
Experimental Results: Throughout our experiments, we emulated two differ-
ent scenarios for each simulation round. In the first scenario denoted by “Partial
30
100 150 200 250 300 350
0.6 0.7 0.8 0.9 1.0
Estimate of the Number of Users
ProfA
NMI (Addresses)
AMI (Addresses)
NMI (Transactions)
AMI (Transactions)
Figure 13: The case where Acannot accurately estimate nU. We assume the
‘Partial Knowledge” case where nU= 200.
Knowledge”, we assume that Ais aware of the location/service of all Bitcoin
vendors and as such can distinguish whether a transaction was performed in
exchange of a physical good. In this case, we include the vendors’s addresses in
the prior knowledge of Awhen computing LinkA; we also assume that Acan
tune the clustering algorithm to take into account that the same user perform-
ing this transaction cannot appear in other transactions that takes place at the
same time. This case emulates the realistic setting where Acan extract a subset
of the addresses owned by geographically co-located Bitcoin users/vendors from
the overall public Bitcoin log; for example, Acan extract from the Bitcoin log all
the addresses that interact with a known address of a vendor located within the
university environment. In the second scenario denoted by “No Knowledge”, we
consider the case where Adoes not know the location or service of the vendors,
and as such does not have any prior knowledge, but assumes that up to 10% of
the transactions are performed in exchange of goods delivered over the Internet.
Given this setup, we evaluate the metrics LinkA, Profa
A(for address-based
profiles), and Profτ
A(for transaction-based profiles) with respect to (i) the frac-
tion of “privacy-aware” users and (ii) the number of users nU. By privacy-aware
users, we refer to users that manually generate new Bitcoin addresses (following
a configuration in the XML file) to enhance their privacy in the system. Table 7
depicts our findings. Our results show that both the “Partial Knowledge” and
the “No Knowledge” configurations exhibited comparable results.
In the first round of experiments, we evaluate the success of Awith respect
to the fraction of “privacy-aware” users. More sp ecifically, we run our clustering
and accountability (privacy) evaluation algorithm in a setting featuring 200
users, among which 0%,50%, and 100% of the users are privacy-aware. Table 7
shows LinkA, Profa
A, and Profτ
Awith respect to the fractions of privacy-aware
31
Table 4: Clustering results in the “Partial Knowledge” and “No Knowledge”
scenarios. A column entitled X (Y%) denotes an experiment featuring X users
among which Y% are privacy-aware. Each data point in our plots is averaged
over five rounds of experiments; we also present the corresponding 95% confi-
dence intervals (shown after the “±” sign).
Partial Knowledge 100 (50%) 200 (0%) 200 (50%) 200 (100%) 400 (50%)
LinkA0.91 ±0.01 0.90 ±0.01 0.91 ±0.01 0.92 ±0.01 0.93 ±0.01
Profa
A
NMI 0.76 ±0.01 0.87 ±0.01 0.79 ±0.01 0.70 ±0.01 0.80 ±0.01
AMI 0.75 ±0.01 0.86 ±0.01 0.77 ±0.01 0.68 ±0.01 0.77 ±0.01
Profτ
A
NMI 0.68 ±0.01 0.73 ±0.02 0.70 ±0.01 0.65 ±0.01 0.72 ±0.01
AMI 0.67 ±0.01 0.72 ±0.01 0.69 ±0.01 0.63 ±0.01 0.70 ±0.01
No Knowledge 100 (50%) 200 (0%) 200 (50%) 200 (100%) 400 (50%)
LinkA0.90 ±0.01 0.90 ±0.01 0.91 ±0.01 0.92 ±0.01 0.93 ±0.01
Profa
A
NMI 0.79 ±0.01 0.89 ±0.01 0.79 ±0.01 0.71 ±0.02 0.80 ±0.01
AMI 0.78 ±0.02 0.88 ±0.01 0.78 ±0.02 0.69 ±0.02 0.78 ±0.01
Profτ
A
NMI 0.69 ±0.01 0.73 ±0.03 0.69 ±0.03 0.65 ±0.01 0.72 ±0.01
AMI 0.68 ±0.01 0.72 ±0.01 0.68 ±0.03 0.63 ±0.01 0.70 ±0.01
users. Here, we use a normalized version on LinkA.
The advantage of Ais only negligibly affected by the fraction of the privacy
aware users in the system. More specifically, we can see that our adversary
outperforms ARby almost 90%. On the contrary, Profa
Aand Profτ
Ashow a
better dependency on the fraction of privacy aware users. When none of users
in the system are privacy-aware, the performance of our clustering algorithms is
high. In particular, in both configurations ProfAa(NMI and AMI for addresses)
range within 0.87 −0.89, while Profτ
A(NMI and AMI for transactions) are 0.73.
However, as the fraction of the privacy aware users increases, the performance
of Adrops and results in Profτ
Aand Profa
Aof 0.70 and 0.63 respectively. This
mischief can be explained by the fact that privacy aware users add noise to the
Bitcoin log. However, the fact that AMI values remain consistently far from 0
and close to 1 indicates that Aperforms much better than ARand that the
estimate chosen by Ais close to the genuine assignment of users to clusters. We
therefore conclude that the privacy of users in Bitcoin can still be compromised,
even if users manually create new addresses in order to prevent the linking of
their addresses [48]. Furthermore, our results show that A’s advantage over
ARis not significantly affected by the number of participant users in the case
of address unlinkability. Profa
Aand Profτ
Aincrease from 0.76 and 0.68 to 0.80
and 0.72 respectively as the number of users increases from 100 to 400. This is
mostly because when the number of users increases, the assignments of addresses
(or transactions) into groups of users (AR) performs worst. In Figure 13, we
evaluate the case where Adoes not have an accurate estimate of the number
of users in the university setting. Our findings show that even if A’s estimate
of the number of users is not accurate, the privacy of a considerable fraction of
users is still compromised.
In our simulation environment, the number of transactions performed by
users largely depends on their budget and “hobbies”, which results in a consid-
erable variety of frequency of transactions per user. In Figure 14, we assess the
32
advantage of Awith respect to different classes of users and different privacy-
awareness levels. Here, we throttle the average number of transaction per user
to 30%, 50%, 90% and 100% of the total possible transactions that all users
would commit to (as defined in their profile within the simulator); by doing
so, we simulate cases where the network features various levels of transactional
traffic. In each investigated setting, we classify the profiles of Bitcoin users into
three groups based on the number of transactions they were involved in (i.e.,
groups were divided according to their 3-quantiles), and measure the overall
fraction of user profiles (measured by means of the similarity of transactions
appearing in a user’s wallet and the corresponding cluster) that are captured by
Ain each case. Our results in Figure 14 show that in the case when nU= 200
users with 0% privacy awareness and 100% transactional traffic, almost 42% of
the users have their profiles captured with 80% accuracy. In the case featuring
100% privacy-aware users, this fraction drops to 35% of the users whose pro-
file was correctly clustered with an accuracy of at least 80%. In summary, our
results suggest the following:
•The profile leakage is larger when users participate in a large number of
transactions, and decreases as the number of transactions performed by the
user decreases. This is mainly due to the fact that users who participate
in more transactions can be more easily profiled when compared to those
users who only participate in few transactions.
•The overall number of transactions exchanged in Bitcoin has little impact
on the profile leakage of users in the system. Our results show that even
when the network features 70% less transactions, then the fraction of cap-
tured transactions per user does not decrease significantly—irrespective of
the activity level of each user.
It is straightforward to see that accountability provisions in Bitcoin become
stronger, the weaker are the privacy provisions of Bitcoin. Notably, the less un-
traceable the user activity is within Bitcoin log, and therefore the more account-
able the system is, the more individual privacy such as activity unlinkability is
compromised. This tension is also depicted in our metrics; the higher is LinkA,
the smaller is UnLinkA.
Our results suggest that the privacy provisions of Bitcoin are not strong,
which opens the door to the integration of accountability measures in the system.
As mentioned earlier, the manual creation of new addresses can only partly
conceal the profiles of users who participate in a small amount of transactions.
Such a countermeasure, however, does not increase the privacy of users who
are active in the network and participate in a large number of transactions.
Moreover, as mentioned earlier, protocols which mix the inputs and outputs
of transactions cannot fully prevent clustering analysis since they do not hide
the amounts and times of payments. Transaction amounts and times can be
hidden, e.g., by using the protocols in [2,6], and by randomizing the time of
sending transactions in the network. However, such protocols incur considerable
computational overhead, and require modifications to the Bitcoin protocol.
33
30% Transaction Traffic
50% Transaction Traffic
90% Transaction Traffic
100% Transaction Traffic
●●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●●● ●
●●
●
●
●
●●
●
●
●
●
●
●●
●
●
●
● ● ● ●
●
●
●
●
●
●●
●
●
●
●
●● ●
●
●
● ● ● ● ●
●
●
●●
●● ●
●
●
●
●
● ● ●
●
●● ● ● ● ●
0
25
50
75
100
0
25
50
75
100
0
25
50
75
100
0% Privacy Awareness
50% Privacy Awareness
100% Privacy Awareness
20 40 60 80 20 40 60 80 20 40 60 80 20 40 60 80
Fraction of Transactions Captured [%]
Fraction of Users [%]
●Low Num. Transactions Medium Num. Transactions High Num. Transactions
Figure 14: Fraction of transactions captured by our clustering algorithms in the
“No Knowledge” case and 200 users in the system.
5 Related Work
In what follows, we overview related work in the area. In [30], Elias investigates
the legal aspects of privacy in Bitcoin. In [46], Reid and Harrigan explore user
anonymity limits in Bitcoin. In [4], Babaioff et al. address the lack of incentives
for Bitcoin peers to include recently announced transactions in a block. In [48],
Ron and Shamir analyze the behavior of users (i.e., how they acquire and how
they spend their BTCs) and investigate how users move BTCs between their
various accounts in order to better protect their privacy. As far as we are aware,
their analysis was only based on Heuristic I (cf. Section 4.3) and did not take
into account classifying addresses using our second heuristic. In [40], Meiklejohn
et al. try to identify big players in the Bitcoin system by leveraging our Heuris-
tics I and II presented in Section 4.3; notably, the authors perform transactions
with big vendors such as Mt. Gox. and use our heuristics to identify a bigger
cluster of addresses particular to such vendors. Our analysis in Section 4.3 ex-
plores the information leakage due to the public Bitcoin block chain, and reveals
the first comprehensive clustering results of all Bitcoin addresses using our two
heuristics. In [26], Decker and Wattenhofer investigate transaction and block
propagation time in Bitcoin. In [38], the authors investigated the possibility of
linking addresses of the same user together by utilizing the Bitcoin peers net-
work address information (IPs). The authors identified (in terms of IP) certain
addresses whose behavior deviated from the average address behavior in the
Bitcoin network, but did not perform any generic analysis covering all Bitcoin
addresses. In [34], Gervais et al. showed that the reliance on Bloom filters
34
within existing SPV clients leaks considerable information about the addresses
of Bitcoin users.
To enhance user privacy in Bitcoin, mixing transactions emerges as an ef-
fective technique to hide the linkability between inputs and outputs of Bitcoin
transactions. Existing solutions such as [19,24] rely on a mixing server to harden
the tracing of coin expenditure in the network; here, the mixing server still needs
to be trusted to ensure anonymity, since it learns the mapping of coins to ad-
dresses. In [49], Ruffing et al. propose a mixing protocol that does not require
any centralized mixing server. Miers et al. introduced in [41] ZeroCoin, a cryp-
tographic extension to Bitcoin that augments the protocol to prevent the tracing
of coin expenditure. In this work, we have shown that standard clustering algo-
rithms can be used to acquire considerable information about the user profiles
in Bitcoin. These algorithms mainly leverage user spending patterns, such as
transaction amounts, transaction times, etc., in order to profile users. Clearly,
ZeroCoin and existing mixing protocols can impede to some extent the linkabil-
ity of transactions belonging to the same address. In these schemes, the advan-
tage of our adversary in linking addresses is likely to be reduced; nevertheless, it
is not clear whether clustering analysis can be completely deterred in ZeroCoin
and in mixing protocols, since the transaction times, transaction amounts, and
address balances can still be derived from the block chain. Garman et al. briefly
describe a ZKPoK based technique that enables the construction of transactions
between anonymous coins in ZeroCoin [33]. ZeroCoin was later extended in [2,6]
to hide the transaction values and address balances in the system.
In [52], Syed and Syed propose a user-friendly technique for managing Bitcoin
wallets. In [35], Gervais et al. analyze the limits of decentralization in Bitcoin,
and show that the vital operations and decisions that Bitcoin is currently un-
dertaking are not decentralized. Finney [31] describes 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 pay-
ments and acquires a given service. Barber et al. [5] analyze possible ways to
enhance the resilience of Bitcoin against a number of security threats; they do
not, however, analyze the security of fast Bitcoin payments.
Anonymity and unlinkability have been explored in different contexts by the
research community. More specifically, in [44], Pfitzmann and Hansen define
unlinkability and privacy for pseudonymous systems in high level. In [28,51],
the authors model and measure anonymity and unlinkability in communication
systems. In [39] the authors provide a model the unlinkability of distributed
data, while in [32], the authors investigate how important the context is for the
unlinkability provisions of a system and provide metrics for that.
Micropayments [1,36,47] is an efficient payment scheme aiming primarily at
enabling low-cost transactions. Here, the payer provides signed endorsements
of monetary transfers on the vendor’s name. Digital signatures in these systems
constitute the main double-spending resistance mechanism. ECash [20–22] and
anonymous credit cards were the first attempts to define privacy-preserving
transactions. Privacy in ECash consists of user anonymity and transaction
35
unlinkability; by relying on a set of cryptographic primitives ECash ensures
that payments pertaining to the same user cannot be linked to each other or to
the payer, provided that the latter does not misbehave.
6 Conclusion
Bitcoin has already witnessed a wider adoption and attention than any other
digital currency proposed to date. One of the main reasons for such a broad
adoption of Bitcoin has been a promise of a low-cost, anonymous, and decen-
tralized currency that is inherently independent of governments and of any cen-
tralized authority
In this paper, we analyzed and evaluated the double-spending resilience
of Bitcoin in fast payments. We showed that not only these attacks succeed
with overwhelming probability, but also that—contrary to common beliefs—
they do not incur any significant overhead on the attacker. We also proposed
a lightweight countermeasure that enables the detection of double-spending at-
tacks in fast transactions.
Motivated by our analysis, we then investigated analytically and empirically
the privacy and accountability provisions in Bitcoin. Our findings show that
the public transaction log of Bitcoin leaks considerable information about the
user profiles in Bitcoin. This information can be used to link different Bit-
coin addresses pertaining to Bitcoin users in order to implement accountability
measures within the system (e.g., “black-list” linked addresses from th e network)
within the Bitcoin system. We therefore hope that our findings motivate further
research in this area.
Acknowledgements
The authors would like to thank Matthias Herrmann and Hubert Ritzdorf for
collecting various measurements in the Bitcoin network, and Tobias Scherer for
the help in implementing the HAC and KMC algorithms. The authors also
thank the anonymous reviewers for their valuable feedback and comments.
References
[1] E. Androulaki, M. Raykova, A. Stavrou, and S. M. Bellovin. PAR: Payment
for Anonymous Routing. In Proceedings of PETS, 2008.
[2] Elli Androulaki and Ghassan Karame. Hiding transaction amounts and
balances in bitcoin. In Proceedings of International Conference on Trust &
Trustworthy Computing (TRUST), 2014.
[3] Elli Androulaki, Ghassan Karame, and Srdjan Capkun. Evaluating user
privacy in bitcoin. In Financial Crypto 2013, 2013. http://eprint.iacr.
org/2012/596.pdf.
36
[4] M. Babaioff, S. Dobzinski, S. Oren, and A. Zohar. On Bitcoin and Red
Balloons. 2011.
[5] S. Barber, X. Boyen, E. Shi, and E. Uzun. Bitter to Better - How to Make
Bitcoin a Better Currency. In Proceedings of Financial Cryptography and
Data Security, 2012.
[6] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green,
Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Practical decen-
tralized anonymous e-cash from bitcoin. In Proceedings of the 2014 IEEE
Symposium on Security and Privacy. IEEE, May 2014.
[7] Bitcoin – Wikipedia, 2013. Available from: https://en.bitcoin.it/
wiki/Introduction.
[8] Bitcoin Charts, 2013. Available from: http://bitcoincharts.com/.
[9] Weaknesses - Bitcoin, 2013. Available from: https://en.bitcoin.it/
wiki/Weaknesses.
[10] Bitcoin Block Explorer, 2013. Available from: http://blockexplorer.
com/.
[11] FAQ - Bitcoin, 2013. Available from: https://en.bitcoin.it/wiki/FAQ.
[12] Myths - Bitcoin, 2013. Available from: https://en.bitcoin.it/wiki/
Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_
of_the_10_minute_wait_for_confirmation.
[13] Protocol Specifications – Bitcoin, 2013. Available from: https://en.
bitcoin.it/wiki/Protocol_specification.
[14] Protocol Rules – Bitcoin, 2012. Available from: https://en.bitcoin.it/
wiki/Protocol_rules.
[15] Trade - Bitcoin, 2013. Available from: https://en.bitcoin.it/wiki/
Trade.
[16] 2014. Bitcoin, Double-Spending, Available from https://en.bitcoin.it/
wiki/Double-spending.
[17] Bitcoin XT, 2014. Available from: https://github.com/bitcoinxt/
bitcoinxt.
[18] Bitcoin Double Spends, 2013. Available from: http://blockchain.info/
double-spends.
[19] Joseph Bonneau, Arvind Narayanan, Andrew Miller, Jeremy Clark,
Joshua A. Kroll, and Edward W. Felten. Mixcoin: Anonymity for Bit-
coin with accountable mixes. In Financial Cryptography, 2014.
37
[20] S. Brands. Electronic Cash on the Internet. In Proceedings of the Sympo-
sium on the Network and Distributed System Security, 1995.
[21] J. Camenisch, S. Hohenberger, and A. Lysyanskaya. Compact E-Cash. In
Proceedings of Advances in Cryptology - EUROCRYPT, 2005.
[22] D. Chaum, A. Fiat, and M. Naor. Untraceable e