Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Two Bitcoins at the Price of One? Double-Spending Attacks on
Fast Payments in Bitcoin
Ghassan O. Karame Elli Androulaki
NEC Laboratories Europe ETH Zurich
69115 Heidelberg, Germany 8092 Zürich, Switzerland
ghassan.karame@neclab.eu elli.androulaki@inf.ethz.ch
Srdjan Capkun
ETH Zurich
8092 Zürich, Switzerland
srdjan.capkun@inf.ethz.ch
Abstract digitally signing their transactions and are prevented
from double-spending their coins (i.e., signing-over
Bitcoin is a decentralized payment system that is the same coin to two different users) through a dis-
based on Proof-of-Work. Bitcoin is currently gaining tributed time-stamping service [21]. This service
popularity as a digital currency; several businesses operates on top of the Bitcoin Peer-to-Peer (P2P)
are starting to accept Bitcoin transactions. An ex- network that ensures that all transactions and their
ample case of the growing use of Bitcoin was recently order of execution are available to all Bitcoin users.
reported in the media; here, Bitcoins were used as a
Nowadays, Bitcoin is increasingly used in a num-
form of fast payment in a local fast-food restaurant.
ber of “fast payment” scenarios, where the exchange
In this paper, we analyze the security of using
time between the currency and goods is short. Ex-
Bitcoin for fast payments, where the time between
amples include online services, ATM withdrawals,
the exchange of currency and goods is short (i.e.,
vending machine payments and fast-food payments
in the order of few seconds). We focus on double-
(recently featured in media reports on Bitcoin [5]),
spending attacks on fast payments and demonstrate
where the payment is followed by fast (< 30 seconds)
that these attacks can be mounted at low cost on
delivery of goods. While Bitcoin PoW-based time-
currently deployed versions of Bitcoin. We further
stamping mechanism is appropriate for slow pay-
show that the measures recommended by Bitcoin de-
ments (e.g., on-line orders with delivery of physical
velopers for the use of Bitcoin in fast transactions are
goods), it requires tens of minutes to confirm a trans-
not always effective in resisting double-spending; we
action and is therefore inappropriate for fast pay-
show that if those recommendations are integrated
ments. This mechanism is, however, essential for the
in future Bitcoin implementations, double-spending
detection of double-spending attacks—in which an
attacks on Bitcoin will still be possible. Finally, we
adversary attempts to use some of her coins for two
leverage on our findings and propose a lightweight
or more payments. Since Bitcoin users are anony-
countermeasure that enables the detection of double-
mous and users (are encouraged to) hold many ac-
spending attacks in fast transactions.
counts, there is only limited value in verifying the
payment after the user obtained the goods (and e.g.,
1 Introduction left the store) or services (e.g., access to on-line con-
tent). The developers of Bitcoin implicitly acknowl-
First introduced in 2009, Bitcoin [21] is an emerging edge this problem and inform users that they do not
digital currency that has, as of September 2011, ap- need to wait for the payment to be verified as long
proximately 60,000 users [1]. Bitcoin is currently in- as the payment is not of high value [6]; this, how-
tegrated across several businesses [2] and has several ever, does not solve this problem but merely limits
exchange markets (e.g., [3]). It is also foreseen that the damage as the system still remains vulnerable to
Bitcoin ATMs will be deployed in locations around double-spending attacks.
the globe [4] in order to bridge the gap between dig- Until now, double-spending attacks on fast pay-
ital currency and cash. ments in Bitcoin or mechanisms for their prevention
Bitcoin is a Proof-of-Work (PoW) based currency have not been studied. In this work, we analyze
that allows users to “mine” for digital coins by per- double spending attacks in detail and we demon-
forming computations. Users execute payments by strate that double-spending attacks can be mounted
1on currently deployed version of Bitcoin, when used 2 Background on Bitcoin
in fast payments. We further show that the measures
recommended by Bitcoin developers for fast trans- Bitcoin is a decentralized P2P payment system [21]
actions are not always effective in resisting double- that relies on PoW. Electronic payments are per-
spending; we argue that if those recommendations formed by generating transactions that transfer Bit-
are followed1 , double-spending attacks on Bitcoin coin coins (BTCs) between Bitcoin peers. These
are still possible. Finally, we propose a lightweight peers are referenced in each transaction by means
countermeasure to detect double-spending attacks in of virtual pseudonyms—referred to as Bitcoin ad-
fast transactions. dresses. Generally, each peer has hundreds of differ-
More specifically, our contributions in this paper ent Bitcoin addresses that are all stored and man-
can be summarized as follows: aged by its (digital) wallet. Each address is mapped
through a transformation function to a unique pub-
- We measure and analyze the time required to con-
lic/private key pair. These keys are used to transfer
firm transactions in Bitcoin. Our analysis shows
the ownership of BTCs among addresses.
that transaction confirmation in Bitcoin can be
modeled with a shifted geometric distribution and Peers transfer coins to each other by issuing a
that, although the average time to confirm transac- transaction. A transaction is formed by digitally
tions is almost 10 minutes, its standard deviation is signing a hash of the previous transaction where this
approximately 15 minutes. We argue that this hin- coin was last spent along with the public key of the
ders the reliance of transaction confirmation when future owner and incorporating this signature in the
dealing with fast payment scenarios. coin [21]. Any peer can verify the authenticity of a
BTC by checking the chain of signatures.
- We thoroughly analyze the conditions for perform-
ing successful double-spending attacks against fast Transactions are included in Bitcoin blocks that
payments in Bitcoin. We then present the first are broadcasted in the entire network. To prevent
comprehensive double-spending measurements in double-spending of the same BTC, Bitcoin relies on
Bitcoin. Our experiments were conducted us- a hash-based PoW scheme. More specifically, to gen-
ing modified Bitcoin clients running on a hand- erate a block, Bitcoin peers must find a nonce value
ful of hosts located around the globe. Our results that, when hashed with additional fields (i.e., the
demonstrate the feasibility and easy realization of Merkle hash of all valid and received transactions,
double-spending attacks in current Bitcoin client the hash of the previous block, and a timestamp),
implementations2 . the result is below a given target value. If such a
nonce is found, peers then include it (as well as the
- We explore and evaluate empirically a number of additional fields) in a block thus allowing any entity
solutions for preventing double-spending attacks to publicly verify the PoW. Upon successfully gen-
against fast payments in Bitcoin. We show that the erating a block, a peer is typically granted 50 new
recommendations of Bitcoin developers on how to BTCs. This provides an incentive for peers to con-
counter double-spending are not always effective. tinuously support Bitcoin. Table 1 depicts the infor-
Leveraging on our results, we propose a lightweight mation included in Bitcoin block number 80,000 as
countermeasure that enables the secure verification reported in the Bitcoin block explorer [7]. The re-
of fast payments. sulting block is forwarded to all peers in the network,
who can then check its correctness by verifying the
The remainder of the paper is organized as follows.
hash computation. If the block is “valid”, then the
In Section 2, we briefly present Bitcoin. In Section 3,
peers append it to their previously accepted blocks,
we review how Bitcoin payments can be processed.
thus growing the Bitcoin block chain.
In Section 4, we analyze and evaluate the security
of fast payments with existing Bitcoin clients. We The main intuition behind Bitcoin is that for peers
then evaluate the security of possible measures to to double-spend a given BTC, they would have to
alleviate double-spending against fast payments in replace the transaction where the BTC was spent
Bitcoin. In Section 6, we overview related work and and the corresponding block where it appeared in,
we conclude the paper in Section 7. otherwise their misbehavior would be detected im-
mediately. This means that for malicious peers to
1 These recommendations are still not integrated in the Bit-
double-spend a BTC without being detected, they
coin implementation.
2 In our experiments, we solely used Bitcoin wallets and would not only have to redo all the work required
accounts that we own; other Bitcoin users were not affected to compute the block where that BTC was spent,
by our experiments. but also recompute all the subsequent blocks in the
2Hash: 000000000043a8c0fd1d6f726790caa2a406010d19efd2780db27bdbbd93baf6
Previous block: 00000000001937917bd2caba204bb1aa530ec1de9d0f6736e5d85d96da9c8bba
Next block: 00000000000036312a44ab7711afa46f475913fbd9727cf508ed4af3bc933d16
Time: 2010-09-16 05:03:47
Difficulty: 712.884864
Transactions: 2
Total BTC: 100
Size: 373 bytes
Merkle root: 8fb300e3fdb6f30a4c67233b997f99fdd518b968b9a3fd65857bfe78b2600719
Nonce: 1462756097
Input/Previous Output Source & Amount Recipient & Amount
N/A Generation: 50 + 0 total fees Generation: 50 + 0 total fees
f5d8ee39a430...:0 1JBSCVF6VM6QjFZyTnbpLjoCJ...: 50 16ro3Jptwo4asSevZnsRX6vf..: 50
Table 1: Example Block of Bitcoin. The block contains 2 transactions, one of which awards the generator peer with
50 BTCs.
chain3 . This ensures that the Bitcoin network can Further details on Bitcoin can be found in [8,9,21].
counter such misbehavior as long as the fraction of Throughout the rest of the paper, we will adopt the
honest peers in the network exceeds that of malicious following notations.
colluding peers [21].
In what follows, we provide a summary (adapted Confirmed transactions: These refer to Bitcoin
from [21]) of the steps that peers undergo in Bitcoin transactions that appear in a valid block. As men-
when a payment occurs. tioned earlier, these transactions are checked before
being included in a block to prevent double-spending
• New transactions are broadcasted by peers in attacks; since they already appear in a block in the
the network. Bitcoin block chain, they cannot be modified easily.
In the paper, we refer to a transaction that has ac-
• When a new transaction is received by a peer, quired X confirmations (i.e., X − 1 blocks appear in
it checks whether the transaction is correctly the chain after the block that confirms the transac-
formed, and whether the BTCs have been pre- tion) by an X-confirmation transaction.
viously spent in a block in the block chain. If
the transaction is correct, it is stored locally in
the memory pool of peers. Memory Pool: This is a local structure at each
peer that contains all transactions that have been re-
• Peers work on constructing a block. If they find ceived and not yet confirmed. If a transaction that
a nonce that solves the PoW, they include all appears in the memory pool of a given peer is con-
the transactions that appear in their memory firmed elsewhere, the transaction is removed from
pool within the newly-formed block. Peers then the memory pool. Note that a peer does not need
broadcast the block in the network. to be involved in any of the transactions appearing
in its memory pool.
• When peers receive a new block, they verify that
the block hash is valid and that every trans-
3 Payments in Bitcoin
action included within the block has not been
previously spent. If the block verification is In transactions where the exchange between curren-
successful, peers continue working towards con- cies and services happens simultaneously, the pay-
structing a new block using the hash of the last ment verification is typically required to be immedi-
accepted block in the “previous block” field (cf. ate, e.g., fast credit-card authorization. Otherwise,
Table 1). the delivery of the services will only occur after the
3 Bitcoin claims that it is computationally infeasible for an payment is processed, e.g., slow delivery by post.
attacker to redo the PoW required to compute 6 consecutive Bitcoin is currently being used in both slow and
blocks. fast payment scenarios. In this section, we review
3and analyze how Bitcoin transactions are processed generation times. In Figure 1, we depict the distribu-
in these two scenarios. For that purpose, we consider tion of the generation times of the extracted Bitcoin
a system that consists of a Bitcoin P2P network, a blocks. As shown in Appendix A, this distribution
vendor V and a set of its customers. can be fitted to a shifted geometric distribution with
success probability 0.19. Our results also show that
only 64% of the blocks are generated in less than 10
3.1 “Slow Payments”—Transaction
minutes. The remaining 36% of the blocks require
Confirmation between 10 and 40 minutes to be generated.
As described in Section 2, the most conventional and
secure way for V to accept a payment made by a cus-
tomer C is to wait until the transaction issued from C 3.2 “Fast Payments”—Transaction
to V is confirmed in at least one block before offering Reception
service to C. Note that the Bitcoin client can inform
V whether its transactions have been confirmed or Our analysis shows that the time required to confirm
not. Since confirmed transactions are likely to be ac- transactions impedes the operation of many busi-
cepted by honest peers in the Bitcoin network, a ma- nesses that are characterized by a fast-service time
licious client A has negligible advantage in tricking (i.e., when the exchange of currency and goods is
V to accept incorrect or double-spent transactions. shorter than a minute). As such, it is clear that
vendors, such as supermarkets, vending machines,
take-away stores [13], etc., cannot rely on transac-
Transaction Confirmation Time: In what fol-
tion confirmation when accepting Bitcoin payments.
lows, we briefly analyze the time it takes for a given
transaction to be confirmed. To enable fast payments, Bitcoin encourages ven-
dors to give away service without waiting for the
Bitcoin is designed so that blocks are generated
transaction verification, as long as the transaction is
every 10 minutes, on average. For that purpose, the
not of high value [6, 13].
difficulty of the work required to construct a block
is adjusted dynamically depending on the time it As such, for low-cost transactions, Bitcoin pay-
took to solve the previous blocks. More specifically, ments with zero-confirmations can be accepted as
Bitcoin requires that the hash of the block to be con- soon as the vendor receives a transaction from the
structed is below a given target value. This target network transferring the correct amount of BTCs
is interpolated from the overall time it took to solve from the client to one of its addresses. This verifica-
the previous 2016 blocks [10]. If it took more than tion can be done using current Bitcoin clients since
two weeks4 to generate the last 2016 blocks, the tar- the vendor can search in his wallet for the client’s
get is increased, otherwise the target is decreased. transaction. The main intuition here is that this
Since the fields required to construct the hash of a constitutes sufficient proof that the transaction was
block also change with time (e.g., timestamp, previ- indeed broadcasted in the network. We emphasize
ous block hash), the probability to successfully con- that it typically takes few seconds (< 3 seconds)
struct a valid block in Bitcoin is almost constant for a transaction to propagate between two Bitcoin
with respect to the number of trials [11]. peers—which explains the use of the terms “zero-
To measure the generation time of existing Bitcoin confirmation transactions” and fast payments inter-
blocks, we created a Python script that parses the changeably in the rest of this paper.
block chain of Bitcoin starting from the genesis block
(Block # 0) until Block # 1532605 and extracts the
time intervals between the generation of consecutive 4 Security of Fast Payments with
blocks. Current Bitcoin Clients
Our findings show that while the average block
generation time is approximately 10 minutes (9 min- Fast payments cannot rely on the timestamp server
utes and 54 seconds), the standard deviation of the of Bitcoin to prevent double-spending. Furthermore,
measurements was about 881.24 seconds which cor- current and past Bitcoin clients (up to version 0.5.2)
responds to almost 15 minutes. This shows that do not employ any countermeasure against double-
there is a considerable variability among the block spending fast payments. In what follows, we analyze
4 This corresponds exactly to a generation time of 10 min-
the necessary requirements for mounting a successful
utes per block.
double-spending in existing Bitcoin implementations
5 This block was generated on the 14th of November 2011, and we describe how to meet these requirements in
as reported on the Bitcoin Block Explorer [12] practical settings.
4(a) Block generation times in Bitcoin. Assuming a (time) bin (b) Cumulative Distribution Function (CDF) of block gener-
size of 2 minutes, the block generation function can be fitted ation times. 36% of Bitcoin blocks take between 10 and 40
to a shifted geometric distribution with p = 0.19. Refer to minutes to be generated.
Appendix A for further details.
Figure 1: Block generation times in Bitcoin. Transactions are confirmed when they appear in valid blocks. The
histogram of block generation times was created assuming a bin size δt = 2 minutes. Our measurements show that
the average time to generate a Bitcoin block is almost 9 minutes and 54 seconds with a standard deviation of 14
minutes and 41 seconds.
Input A
4.1 Attacker Model Input B Output H
Output P
A malicious client A constitutes the core of our at-
tacker model. We assume that A is equipped with
a device that runs Bitcoin. We further assume that
A is motivated to acquire a service from V without Input A
Output O
having to spend its BTCs. For instance, A could try Input B
Output F
to double-spend the coin she already transferred to
V. By double-spending, we refer to the case where
Figure 2: Example construction of TRA and TRV .
A can redeem and use the same coins with which she Here, we show two different transactions with the same
payed V so as to acquire a different service elsewhere. inputs and different outputs. TRA and TRV can share
We assume that A can only control few peers in the a subset of their inputs—in which case A only tries to
network (that she can deploy since Bitcoin does not double-spend a subset of the BTCs that she pays with.
restrict membership) and does not have access to V’s
Bitcoin keys or machine. We assume, however, that
A knows the Bitcoin and IP addresses of V 6 . The re- true identity is unlikely to be revealed.
maining peers in the network are assumed to be hon-
est and to correctly follow the Bitcoin protocol. We
4.2 Necessary Conditions for Suc-
point out here that the computing power harnessed
by A and its helpers does not exceed the aggregated cessful Double-Spending
computer power of all the honest peers in the net- To perform a successful double-spending attack, the
work. This prevents A from inserting/confirming in- attacker A needs to trick the vendor V into accepting
correct blocks in the Bitcoin block chain. In this pa- a transaction TRV that V will not be able to redeem
per, we consider the scenario where A does not mine subsequently. While this might be computationally
for blocks (i.e., it does not participate in the block challenging for A to achieve if TRV was confirmed
generation process). This also suggests that when a in a Bitcoin block7 , this task might be easier if the
transaction is confirmed in a block, this transaction vendor accepts fast payments.
cannot be modified by A. In this case, A creates another transaction TRA
Conforming with the operation of Bitcoin, we as- that has the same inputs as TRV (i.e., TRA and
sume that the set of addresses used by A are insuffi- TRV use the same BTCs) but replaces the recipient
cient to identify A. This also suggests that although address of TRV —the address of V— with a recipient
the misbehavior of A may be detected at some later address that is under the control of A. Note that our
point in time (after it has acquired a service), its 7 As mentioned earlier, A will then have to do all the work
6 When issuing a transaction, a Bitcoin client could either required to re-generate the block where the transaction ap-
specify a recipient Bitcoin address or an IP address. pears in (and all subsequent blocks).
5140
120
Number of connections
Transaction to
Vendor 100
80
Vendor
60
Transaction to
Vendor 40
Bitcoin Network
Attacker 20
North America
Europe
Transaction to 0
colluding Transaction to Day 01 Day 02 Day 03 Day 04 Day 05 Day 06
address colluding Time
address
Figure 4: Number of connections that two Bitcoin
nodes (in North America and in Europe, respectively)
witnessed over the period of 6 consecutive days. Since
the connectivity of peers in Bitcoin varies with time, A
Bitcoin Mining Pools
has considerable opportunities to establish at least one
Figure 3: Sketch of a double-spending attack against direct connection with V.
fast payments in Bitcoin. In typical cases, the attacker
A dispatches two transactions that use the same BTCs
in the Bitcoin network. The double-spending attack is and will reject TRV as it arrives later. After waiting
deemed successful if the BTCs that A used to pay for V for few seconds without having received TRV , V can
cannot be redeemed (i.e., when the second transaction is ask A to re-issue a new payment.
included in the upcoming Bitcoin block).
Requirement 2 — TRA is confirmed in the
block chain: As mentioned previously, if TRV is
analysis is not restricted to the case where the recip-
confirmed first in the block chain, TRA can never
ient address is controlled by A and applies to other
appear in subsequent blocks. In this case, V has
scenarios, where the recipient is another merchant.
received its BTCs, and can redeem them at its con-
An example construction of TRA and TRV is de-
venience. The attack of A therefore fails unless TRA
picted in Figure 2. If both transactions are sent adja-
is confirmed first in the block chain.
cently in time, they are likely to have similar chances
of getting confirmed in an upcoming block. This We point out that Requirements (1) and (2) are
is the case since Bitcoin peers will not accept mul- sufficient for the case where the vendor only checks
tiple transactions that share common inputs; they for the reception of the transaction as a proof of pay-
will only accept the version of the transaction that ment and does not employ other double-spending
reaches them first which they will consider for inclu- prevention/detection techniques. This accurately
sion in their generated blocks and they will ignore all mimics the functionality provided by existing Bit-
remaining versions. Given this, a double-spending coin client implementations. In Section 5, we ex-
attack can succeed if V receives TRV , and the major- tend our analysis and we evaluate the effectiveness
ity of the peers in the network receive TRA so that of possible measures to alleviate double-spending.
TRA is more likely to be included in a subsequent
block. This is sketched in Figure 3.
In this respect, let tV A
i and ti denote the times at
4.3 Mounting Double-Spending At-
which node i receives TRV and TRA , respectively. tacks in Bitcoin
As such, tV A
V and tV denote the respective times at In this section, we discuss how A can satisfy Re-
which V receives TRV and TRA .
quirements (1) and (2).
The necessary conditions for A’s success in mount-
ing a double-spending attack are the following:
Satisfying Requirement 1: A connects as a
direct neighbor to V in the P2P network8 . Given the
Requirement 1 — tV A
V < tV : This requirement
Bitcoin protocol specification, V will always accept
is essential for the attack to succeed. In fact, if tV
V >
tA
V , then V will first add TRA to its memory pool
8 Recall that the IP address of V is public.
6the connection requests by other peers as long as the that time. We argue that this is a realistic assump-
maximum number of its current inbound connections tion given that TRA and TRV need to be typically
has not been reached. By default, this number is set broadcasted back to back given a small delay (in the
to 125.9 As shown in Figure 4, the connectivity of order of few seconds); it is therefore unlikely that
Bitcoin peers is heavily dependent on the churn of one of them is confirmed within the first few sec-
the Bitcoin network (i.e., peers departing/joining); onds in a new block. In Section 4.4, we relax this
this gives a considerable number of opportunities for assumption and we evaluate the general case where
A to establish a direct connection with V (e.g., A either TRA and TRV can be confirmed immediately
could try to connect with V over the weekend or in when they are broadcasted in the network.
the evening, when the number of connections of V We divide time into equal intervals of size δt, such
drops below the maximum). that, the probability of successful block generation
In the sequel, we assume that A has access to one in each δt can be modeled as a Bernoulli trial with
or more helpers, denoted by H. A and H do not nec- success probability η · p, where η is the number of
essarily have to be on physically disjoint machines peers and p the success probability of a peer in gener-
(e.g., H could run as a thread/process on the same ating a block within δt (for the reasoning why, refer
machine as A). We further assume that A and H to Appendix A).
communicate using a low-latency confidential chan- Let tk = k · δt + t0 and ηVk and ηA k
denote the
nel (e.g., by exchanging encrypted messages using a number of Bitcoin peers that have received TRV and
direct TCP connection) and that H never connects TRA respectively until time tk . Recall that each
to V. Bitcoin node will only add the first transaction it
A sends TRV to V at time τV and TRA to H at receives (among TRV and TRA ) to its memory pool
time τA , such that τA = τV + ∆t. V and H relay and that only the transactions that appear in the
the transactions that they received from A in the memory pool of peers are eligible to be confirmed in
network. Let δtA HV refer to the time it takes TRA to subsequent blocks. Given this, the probability that
propagate in the Bitcoin P2P network from H to V TRV is included in a block that is generated within
and δtVAV denote the time it takes TRV to reach V. time interval (tk , tk+1 ] is given by PrkV = ηVk · p.
In this case, tA V
V − tV can be estimated as follows: Similarly, for TRA , the corresponding probability is
PrkA = ηA k
· p. The probability pV (k) that a block
containing TRV is generated within the time interval
tA V A V
V − tV ≈ τA + δtVH − (τV + δtAV ) (1) (tk , tk+1 ], is:
≈ ∆t + δtA
VH − δtV
AV . (2)
k−1
Y k−1
Y
Note that since H is never an immediate neighbor pV (k) = PrkV · (1 − PriV ) = ηVk p · (1 − ηVi p).
of V, there is at least one hop on the path between i=0 i=0
H and V. Since A is an immediate neighbor of V
and assuming no congestion at network paths, then Similarly, the probability that a block containing
δtA V TRA is generated at the same time interval is given
VH ≥ δtAV , . This suggests that, in this case,
V A
tV < tV for reasonably chosen ∆t (e.g., ∆t ≥ 0). by:
k−1
Y k−1
Y
Satisfying Requirement 2: Since H and V are pA (k) = PrkA · (1 − PriA ) = ηA
k
p· i
(1 − ηA p).
highly likely to have different neighbors, the broad- i=0 i=0
casted transactions are likely to spread in the net-
work till the point where either (i) all Bitcoin peers If at time ts = s · δt + t0 every node in the network
accept in their memory pools TRV or TRA or (ii) has received at least one of the transactions TRV or
either TRV or TRA get confirmed in a block. TRA , the following holds:
In what follows, we estimate the probability that k+1
and ηVk ≤ ηVk+1 ,
k
ηA ≤ ηA
TRA is confirmed in a block first. In our analysis, we
if k < s
assume that at time t0 both transactions TRA and
TRV coexist in the network10 , and that no block con- k+1
η k = ηA s
= ηA and ηVk = ηVk+1 = ηVs ,
taining at least one of them has been generated till A
otherwise.
9 The default maximum number of connections is 125. Note
that the maximum number of connections can be modified
This suggests that ∀i ≥ s, ηVi + ηA
i
= ηVs + ηA
s
.
using the “-maxconnections” command [14].
10 This does not necessarily mean that TR
A and TRV are
To compute the probability of success of the
broadcasted at the same time. double-spending attack, we make the assumption
7Success Probability 1 Location Number of Hosts
0.8 Europe 4
North America 3
0.6 Asia Pacific 2
0.4 South America 1
p=10−6
0.2 Table 2: Geographic location of the Bitcoin nodes that
p=10−5
we used in our measurements. We made use of 10 Bit-
0
0 1 2 3 4 5 6 coin nodes located around the globe. All the hosts were
Number of Bitcoin Nodes that received x 10
4
running Ubuntu 11.10 with at least 613 MB of RAM.
the double−spent transaction
k
Figure 5: PS for various values of ηA and ηVk , with
p = 10−6 , δt = 10 seconds, t0 = 0, ts = δt and the of space, we include in Appendix B the approxima-
number of peers in the network is 60000. Further details tions/formulas that were used to generate the plots
can be found in Appendix B. in Figure 5.
Our analysis therefore shows that A can maximize
PS (2) by increasing the number of peers that receive
that, ∀k, ηVk and ηA k
do not exchange their newly TRA , ηA k
, ∀tk . A can achieve this: (i) by sending
constructed blocks; in this way, the time tgV required TRA before TRV and therefore giving TRA a better
by peers that are mining in favor of TRV to generate advantage in spreading in the network and/or (ii)
a new block is independent of that required by the by relying on multiple helpers to spread TRA faster
peers that are mining in favor of TRA , tgA . Given in the network. In the former case, A can delay
this, the probability that Requirement (2) is satis- the transmission of TRV by a maximum of ∆t =
fied, PS (2) , is computed as follows: δtA V
VH − δtAV (cf. Equation 1) after sending TRA
while ensuring that V first receives TRV . In this way,
1 both Requirements (1) and (2) can be satisfied.
PS (2) = Prob(tgA < tgV ) + Prob(tgA = tgV ). (3) We denote by PS = PS (1) · PS (2) , the probability
2
that the attack succeeds (in satisfying Requirements
That is, PS is composed of two components; one (1) and (2)). Here, PS (1) refers to the probability
corresponds to the event that the block containing that Requirement (1) is satisfied.
TRA is first generated and the second to the event
where the blocks containing TRA and TRV are gen-
erated at the same time, i.e., tgA = tgV . In the latter 4.4 Experimental Evaluation
case, the probability that the block containing TRA
is eventually adopted by the Bitcoin peers is 0.5. We now present the experimental results of double-
spending experiments in the Bitcoin network. Our
experiments aim at investigating the satisfiability of
∞
X aforementioned Requirements (1) and (2).
Prob(tgA < tgV ) = pA (gA ) · pV (gV > gA |gA )
gA =0
0
Experimental Setup: We adopt the setup de-
= ηA p(1 − ηV0 p)+ scribed in Section 4.3 in which the attacker A is
P∞ gA gA QgA −1 j j
equipped with one or more helper nodes H that help
gA =0 ηA p · (1 − ηV p) · j=0 (1 − ηV p)(1 − ηA p). her relay the double-spent transaction. In our ex-
periments, we made use of 10 Bitcoin nodes located
Similarly, around the globe (Table 2); this serves to better as-
sess the different views seen from multiple points in
Prob(tgA = tgV ) = the Bitcoin overlay network and to abstract away
∞ gA −1 the peculiarities that might originate from specific
X gA gA Y network topologies. Appendix C includes the Bit-
2
p ηV ηA · (1 − ηVj p)(1 − ηA
j
p).
gA =1 j=0
coin addresses that we used while performing our
experiments.
In Figure 5, we depict PS (2) for various values of Conforming with our analysis in Section 4.3, we
ηVk , ηA
k
and p when δt = 10 seconds, ts = δt and the modified the C++ implementation of Bitcoin client
number of peers in the network is 60000. Due to lack version 0.5.2 as follows:
8Figure 6: PS versus ∆t when the vendor has 8 con- Figure 7: PS versus ∆t when the vendor has 40 con-
nections. nections.
Location # Helpers ∆t (sec) PS
Asia Pacific 1, 125 conn. 2 0 100%
Asia Pacific 2, 125 conn. 2 0 100%
North America 1, 8 conn. 1 0 100%
North America 2, 40 conn. 1 0 90%
Asia Pacific 1, 8 conn. 2 1 100%
Asia Pacific 2, 125 conn. 2 1 100%
North America 1, 40 conn. 1 -1 100%
Figure 9: Summary of Results. Here, “Location” de-
notes the location of V, “conn” is the number of V’s
connections.
Figure 8: PS versus ∆t when the vendor has 125 con-
nections.
• The attacker only connects to the vendor’s ma- We conduct our experiments with a varying num-
chine. ber of connections of the vendor (8, 40 and 125 con-
nections) and by varying the number of helper nodes
• The attacker creates transactions TRV and
(1 and 2) chosen randomly from the nodes in Ta-
TRA constructed using the same coins. She
ble 2.The helper nodes were connected to at least
sends TRV using the Bitcoin network to the
125 other Bitcoin peers. Each data point in our
neighboring vendor and TRA via a direct TCP
measurements corresponds to 10 different measure-
connection to one or more helper nodes with
ments, totaling approximately 500 double-spending
an initial delay ∆t of -1, 0, 1, and 2 seconds.
attempts with a total of 20 BTCs11 . We point out
Here, ∆t refers to the time delay between the
that since all the hosts in our measurements were
transmission of TRV and TRA by A.
using wallets that were under our control, other Bit-
• Upon reception of TRA , each helper node coin users were not affected by our measurements.
broadcasts it in the Bitcoin network. We also created a Python script that, for each
conducted measurement, parses the generated logs
• V accepts the payment if it receives TRA .
along with the Bitcoin block explorer [12] to check
With this setup, we performed double-spending whether the Requirements (1) and (2) described in
attempts when the vendors are located in 4 different Section 4.2 are satisfied.
network locations (2 vendors were in North America
and the remaining 2 were in Asia Pacific). In our ex- Results: To assess the feasibility of double-
periments, A was located in Europe. However, since spending in fast Bitcoin payments, we evaluate em-
A does not contribute in spreading in the Bitcoin pirically the success probability, PS , with respect to
network any transaction herself, her location does the number of helper nodes, the number of connec-
not affect the outcome of the attack. That is, the tions of the vendor and ∆t.
sole role of A is to send TRV to V using a direct 11 We point out that since all the hosts in our measurements
connection in the Bitcoin network and TRA to the were using wallets that were under our control, other Bitcoin
helper nodes using a direct TCP connection. users were not affected by our measurements.
9Our results, depicted in Figures 6, 7, 8, and 9 tening period, of few seconds, before delivering its
show that, irrespective of a specific network topol- service to A; during this period, V monitors all the
ogy, the probability that A succeeds in mounting transactions it receives, and checks if any of them at-
double-spending attacks is significant. tempts to double-spend the coins that V previously
Confirming our analysis, PS decreases as ∆t in- received from A. This countermeasure is based on
creases. As explained in Section 4.3, this is due to the intuition that since it takes every transaction few
the fact that the higher is ∆t, the larger is the num- seconds12 to propagate to every node in the Bitcoin
ber of peers that receive TRV ; in turn, the proba- network, then it is highly likely that V would receive
bility that TRA is confirmed before TRV decreases. both TRV and TRA within the listening period (and
As shown in Figures 6, 7, and 8, this can be reme- before granting service to A).
died if the number of helper nodes that spread TRA We show that this detection technique can be,
increases. Our results show that even for a large ∆t however, circumvented by A as follows. A can at-
of 2 seconds, relying on 2 helper nodes still guaran- tempt to delay the transmission of TRA such that
tees that double-spending succeeds with a consider- t =(tA V
V − tV ) exceeds the listening period while TRA
able probability; when ∆t = 1 seconds, the attack still has a significant chance of being spread in the
is guaranteed to succeed (PS approaches 1) using 2 network. On one hand, as t increases, the probability
helpers. This is summarized in Figure 9. that all the immediate neighbors of V in the Bitcoin
The number of V’s connections considerably af- P2P network receive TRV first also increases; when
fects PS especially when A controls only one helper; they receive TRA later on, TRA will not be added to
in the case where V has a similar number of con- the memory pool of V’s neighbors and as such TRA
nections when compared to the number of connec- will not be forwarded to V. On the other hand, A
tions of the helper, PS approaches 0.5. This corre- should make sure that TRA was received by enough
sponds to the case where both TRA and TRV are peers so that Requirement (2) can be satisfied. To
spread equally in the network (Figure 8). On the that end, A can increase the number of helpers it
other hand, as the connectivity of V decreases, TRA controls.
spreads faster in the network. This is depicted in
Figures 6 and 7. We thoroughly investigate the im- To validate this claim, we conducted experiments
pact of the connectivity of V in Section 5.1. using the setup described in Section 4.4. Our exper-
iments aimed at finding triplets (∆t, NH , C), where
NH is the number of helper nodes, and C is the num-
5 Countering Double-Spending in ber of V’ connections, such that the probability PD
Fast Bitcoin Payments that V receives TRA (after having received TRV ) is
minimized. We illustrate our results in Table 3.
In this section, we evaluate two strategies that the
Conforming with our analysis, our findings show
vendor can adopt, as recommended by Bitcoin de-
that, for C < 80, ∃∆t, such that PS ≥ PD . That is,
velopers, to resist double-spending: using a listen-
in the case where V utilizes a listening period of few
ing period and inserting observers. Moreover, we
seconds to detect double-spending, there are a num-
propose an effective countermeasure based on the
ber of cases in which A can circumvent this counter-
propagation of “alert” messages and we show that it
measure and perform a successful double-spending
does not require significant modifications on existing
attack without being detected. Note that if PD is
clients.
small, A has incentives to attempt to double-spend
even in the case when PS ≈ 0.1), since her attempts
5.1 Using a “Listening Period” will be detected with low probability. For a subset
The Bitcoin daemon locally generates an error if of our measurements, we also show that ∃(∆t, N, C),
it receives a transaction whose inputs have already such that tA V
V − tV = ∞. This case corresponds to the
been spent. However, this error is not displayed to event where all the neighbors of V receive TRV first
the Bitcoin user. Therefore, Requirements (1) and (and do not forward TRV to V). In this case, PD = 0
(2) can be satisfied (as shown in Section 4), but A and V cannot detect the misbehavior of A, irrespec-
can only trick a vendor who does not thoroughly tive of the number of double-spending attempts that
check the transactions that are processed by its Bit- A performs.
coin daemon. Such a functionality would require a
modification of existing Bitcoin clients. 12 Our experiments in Section 4.4 show that the average
As advocated in [13], one possible way for V to time for a peer to receive both TRA and TRV is approxi-
detect double-spending attempts is to adopt a lis- mately 3.354 seconds.
10PS PD tA V
V − tV (sec) % Observed
Europe, 8 Connections, 3 Helpers, ∆t = 2.00 10% 10% 8.664 53%
Europe, 8 Connections, 3 Helpers, ∆t = 2.25 10% 10%∗ 5.65 47%
South America, 8 Connections, 2 Helpers, ∆t = 2.5 20% 6.66%∗ 3.749 62%
South America, 8 Connections, 3 Helpers, ∆t = 2.5 7.7% 0% ∞ 53%
South America, 8 Connections, 4 Helpers, ∆t = 3.0 13.33% 0% ∞ 57%
Asia Pacific, 8 Connections, 3 Helpers, ∆t = 2.75 10% 0% ∞ 57%
Asia Pacific, 8 Connections, 2 Helpers, ∆t = 1.75 55% 20%∗ 5.5 91%
Asia Pacific, 8 Connections, 3 Helpers, ∆t = 2.75 5% 0%∗ ∞ 66%
North America, 20 Connections, 3 Helpers, ∆t = 2.75 5% 0% ∞ 47%
North America, 20 Connections, 5 Helpers, ∆t = 3.00 11% 11% 3.208 46%
North America, 20 Connections, 5 Helpers, ∆t = 1.75 10% 10% 5.76 74%
North America, 20 Connections, 1 Helper, ∆t = 1.25 30% 30%∗ 3.34 78%
North America, 20 Connections, 4 Helpers, ∆t = 2.00 82% 63% 2.85 78%
North America, 20 Connections, 2 Helpers, ∆t = 2.00 20% 20%∗ 4.79 60%
North America, 20 Connections, 1 Helper, ∆t = 1.50 40% 30%∗ 3.51 60%
Europe, 20 Connections, 3 Helpers, ∆t = 1.0 45% 45%∗ 3.844 87%
Europe, 30 Connections, 1 Helper, ∆t = 1.5 15% 10%∗ 3.412 42%
Asia Pacific, 40 Connections, 1 Helper, ∆t = 2.9 10% 10%∗ 4.946 42%
Europe, 40 Connections, 1 Helper, ∆t = 1.25 10% 10% 1.841 36%
Europe, 40 Connections, 2 Helpers, ∆t = 1.5 20% 20%∗ 3.075 36%
South America, 40 Connections, 1 Helper, ∆t = 2.0 30% 40% 3.217 57%
South America, 60 Connections, 1 Helper, ∆t = 2.5 6.67% 20%∗ 3.999 41%
South America, 60 Connections, 2 Helpers, ∆t = 2.75 6.67% 13.33% 4.157 28%
Asia Pacific, 60 Connections, 1 Helper, ∆t = 3.00 10% 0%∗ ∞ 20%
Asia Pacific, 60 Connections, 2 Helpers, ∆t = 2.75 30% 50% 3.992 50%
Asia Pacific, 80 Connections, 1 Helper, ∆t = 3.7 10% 20% 5.04 18%
Europe, 80 Connections, 1 Helper, ∆t = 2.25 33.33% 66.67% 3.648 61%
Europe, 80 Connections, 1 Helper, ∆t = 2.75 13.33% 26.67% 5.093 28%
North America, 100 Connections, 3 Helpers, ∆t = 1.0 60% 80%∗ 2.25 88%
Asia Pacific, 100 Connections, 1 Helper, ∆t = 1.75 44.4% 66.66% 2.871 82%
Asia Pacific, 100 Connections, 1 Helper, ∆t = 1.5 80% 80% 2.807 88%
Table 3: Monitoring received transactions at V (Section 5.1) and its observers (Section 5.2) to detect double-
spending. Each data point corresponds to 20 measurements. The helpers used in these experiments had between
125 and 400 connections. “PD ” denotes the probability that V receives TRA . “% Observed” refers to the fraction of
observers (among 5) that received TRA . tA V
V − tV refers to the average of the time it takes V to receive TRA after
having received TRV , for those cases where V receives TRA (PD ). ∗ refers to the case where TRA was received after
15 seconds (beyond the listening period); otherwise, the absence of ∗ shows that TRA was not received.
The Connectivity of V as a Security Param- a listening period can be indeed effective to detect
eter: As shown from our results in Table 3, the double-spending.
fewer connections of V, the more likely is that all However, since the connectivity of Bitcoin peers
the neighbors of V receive TRV before TRA and largely varies with the network churn13 (Figure 4),
thus that V does not receive TRA . Similarly, as V needs to constantly monitor its connection count
the number of connections of V increases, the effort to ensure that it does not drop below a threshold so
(i.e., the number of helpers, the amount of delay) that it can detect double-spending.
that A needs to invest to ensure that none of V’s In Section 5.3, we propose a countermeasure that
neighbors receive TRA becomes considerable. This effectively detects double-spending even in the case
is depicted in Figure 10; when V adopts a listening when the number of the connections of V is small.
period of at least 15 seconds, PD increases as the 13 For example, some of the nodes used in our experiments
number of V’s connections increases. When V has
could not acquire more than 40 connections over a period of
more than 100 connections, the probability that it few days, due to the fact that these nodes were often restarted.
does not receive TRA is negligible; in this case, using In such cases, other Bitcoin peers will assign a low priority to
connecting to these nodes.
110.7 5.3 Communicating Double-
0.6
Spending Alerts Among Peers
0.5
Given our findings, an efficient countermeasure to
combat double-spending on fast Bitcoin payments
0.4 would be for Bitcoin peers to propagate alerts when-
PD
0.3
ever they receive two or more transactions that share
common inputs and different outputs (cf. Figure 2).
0.2 This countermeasure extends the solutions outline
0.1
in the previous sections. However, unlike the afore-
mentioned solutions, double-spending alerts (i) can-
0 not be evaded by A and (ii) do not incur additional
0 50 100 150 200 250
costs on V.
Number of Connections
The main intuition behind this solution is that
Figure 10: The connectivity of V as a security param- while A might be able to prevent V and a subset
eter. We measure PD with respect to the number of of V’s observers from receiving TRA , a considerable
connections of V. Here, we consider a setting where V is number of Bitcoin peers receive both TRA and TRV .
located in Asia Pacific, ∆t = 3.0 seconds and A controls If the majority of these peers are honest14 , they can
4 helpers. As the number of connections of V increases, immediately alert the entire network by broadcast-
the probability that V receives both TRA and TRV also
ing an alert that includes both TRA and TRV as a
increases.
proof of double-spending to all network peers. Given
the fast broadcast medium in Bitcoin, alert broad-
casts would eventually reach V within few seconds;
the double-spending of A can be therefore detected
5.2 Inserting Observers in the Net- before A actually receives the service from V.
work We emphasize that similar alert mechanisms al-
ready exist in the current implementation of Bitcoin,
Another possible technique that naturally extends but were devised for other purposes and are cur-
the aforementioned proposal based on the adop- rently unused15 . As such, this technique does not
tion of listening period would be for V to insert a require any significant modification in the Bitcoin
node that it controls within the Bitcoin network— client. Furthermore, we argue that this solution can
an “observer”—that would directly relay to V all the easily combat false claims; honest Bitcoin peers will
transactions that it receives. In this case, V can be only forward alert messages if TRA and TRV are
aware within few seconds of a double-spending at- indeed correctly formed, share common inputs and
tempt if either it or its observer receive TRA . different outputs and are equipped with legitimate
signatures.
We evaluated this technique using up to 5 ob-
servers. These observers were chosen from the hosts
listed in Table 2. Our findings in Table 3 show 6 Related Work
that this method can indeed help detecting double-
spending as all double-spent transactions were re- First introduced in 2009, Bitcoin has recently at-
ceived by at least one observer within few seconds. tracted the attention of the research community.
However, given that A delays the transmission of In [20], Elias investigates the legal aspects of pri-
TRA , our results show that only a subset of the ob- vacy in Bitcoin. Reid and Harrigan [35] explore user
servers receive TRA . As mentioned previously, this anonymity limits in Bitcoin. In [24], Babaioff et al.
corresponds to the case where all the neighbors of address the lack of incentives for Bitcoin peers to
these observers have received TRV first and as such include recently announced transactions in a block.
they will not forward TRA back to the observers. In [19], Syed et al. propose a user-friendly technique
for managing Bitcoin wallets.
Therefore, V needs to employ a considerable num- Finney [15] describes a double-spending attack in
ber of observers (≈ 3) (that connect to a large num- Bitcoin where the attacker includes in her generated
ber of Bitcoin peers) to ensure that at least one ob- 14 This is the underlying assumption that ensures the cor-
server detects any double-spending attempt; this, rect operation of Bitcoin.
however, comes at the expense of additional costs 15 Bitcoin plans to use “alert” messages to broadcast infor-
for V to maintain the observers in the network. mation signed by the private key of Bitcoin’s founder.
12blocks transactions that transfer some coins between 7 Concluding Remarks
her own addresses; these blocks are only released
to the network after the attacker double-spends the Given its design, Bitcoin can only ensure the secu-
same coins using fast payments and acquires a given rity of payments when a payment verification time
service. In its official documentation [6, 13], Bit- of few tens of minutes can be tolerated. Moreover,
coin acknowledged that double-spending might oc- our results show that the verification time of pay-
cur when dealing with fast payments but still en- ments exhibits a large variance as it depends on
couraged its users to “sell things without waiting for the confirmation of transactions in blocks—which
a confirmation as long as the transaction is not of follows a shifted geometric distribution. This slow
high value” [6]. Bitcoin developers claim in [6] that payment verification is clearly inappropriate for fast
the cost of mounting double-spending attacks for payments; it is, however, essential for the detection
low-cost transactions is comparatively high and that of double-spending attacks.
vendors could adopt a listening period for few sec- In this paper, we addressed the double-spending
onds before delivering a product to counter double- resilience of Bitcoin in fast payments, in which the
spending attacks. In this work, we thoroughly inves- time to acquire a service is in the order of few sec-
tigate double-spending attacks in Bitcoin. Namely, onds. More specifically, we showed that not only
we show that (i) double-spending fast payments in these attacks succeed with overwhelming probabil-
Bitcoin can be performed without incurring costs ity, but also that, contrary to common beliefs, they
on the attacker and (ii) the countermeasures rec- do not incur any significant overhead on the at-
ommended by Bitcoin to alleviate double-spending tacker. For that purpose, we analyzed the condi-
can be circumvented. tions for performing successful double-spending at-
tacks against fast payments in Bitcoin and we exper-
Double-spending in online payments has received imentally confirmed our analysis. As far as we are
considerable attention in the literature [23, 31]. In aware, our experiments constitute the first compre-
Credit-Card based payments, fairness is achieved hensive double-spending measurements in Bitcoin.
through the existence of a bank (e.g., [26,33]) or an- It is noteworthy that we have performed thousands
other trusted intermediary (e.g., PayPal [30], Mon- of double-spending attempts using fixed Bitcoin ad-
eyBookers [16]). Here, the intermediaries are trusted dresses without having to bear any type of penalty.
(i) to verify that the client has not already spent Finally, we explored the solution space for secur-
the funds he/she is paying the vendor with, and ing Bitcoin against double-spending attacks. Our
(ii) to reverse a charge, if the vendor has misbe- findings show that the measures recommended by
haved. Micropayments [22, 32, 34, 36] is an efficient Bitcoin developers for fast transactions are not al-
payment scheme aiming primarily at enabling low- ways effective in resisting double-spending. By lever-
cost transactions. Here, the payer provides signed aging on our results, we propose a lightweight mea-
endorsements of monetary transfers on the vendor’s sure that would enable the secure and albeit verifi-
name. Digital signatures in these systems consti- cation of Bitcoin transactions.
tute the main double-spending resistance mecha- Given that the vulnerability of existing clients
nism. ECash [27–29] is another form of digital to double-spending might severely harm the growth
cash which supports payer anonymity. ECash of- of Bitcoin, and impact its financial and economic
fers strong accountability guarantees by relying on standing, we argue that the integration of double-
a set of cryptographic primitives that ensure that spending countermeasures in the current implemen-
when a user double-spends a coin, his/her identity tation of Bitcoin emerges as a necessity. As we show
is revealed. in this work, the propagation of double-spending
alerts in the network would constitute a first im-
Similar to Bitcoin, a number of decentralized pay- portant step towards efficiently detecting double-
ment systems [25,37] were designed to resist double- spending.
spending attacks. In [37], Yang and Garcia-Molina
introduce a P2P payment system, in which the first References
owner of an electronic coin authorizes that coin’s
transfer among other peers in the network. Thus, [1] Bitcoin – Wikipedia, Available from https://
the generator of the coin is responsible for preventing en.bitcoin.it/wiki/Introduction.
double-spending. In [25], Belenkiy et al., introduce
an ECash-based P2P payment scheme that provides [2] Trade - Bitcoin, Available from https://en.
accountability at the cost of privacy. bitcoin.it/wiki/Trade.
13[3] Bitcoin Charts, Available from http: [19] Bitcoin Gateway, A Peer-to-peer Bitcoin Vault
//bitcoincharts.com/. and Payment Network, 2011. Available from
http://arimaa.com/bitcoin/.
[4] Bitcoin ATM, Available from http:
//bitcoinatm.com/. [20] Bitcoin: Tempering the Digital Ring of
Gyges or Implausible Pecuniary Privacy, 2011.
[5] CNN: Bitcoin’s uncertain future as cur- Available from http://ssrn.com/abstract=
rency, Available from http://www.youtube. 1937769ordoi:10.2139/ssrn.1937769.
com/watch?v=75VaRGdzMM0. [21] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer
[6] FAQ - Bitcoin, Available from https://en. Electronic Cash System.
bitcoin.it/wiki/FAQ. [22] Androulaki, E., Raykova, M., Stavrou,
A., and Bellovin, S. M. PAR: Payment
[7] Bitcoin Block 80000, Available from http:// for Anonymous Routing. In Proceedings of
blockexplorer.com/b/80000. the 8th Privacy Enhancing Technologies Sym-
posium (2008).
[8] Protocol Rules – Bitcoin, Available from
https://en.bitcoin.it/wiki/Protocol_ [23] Asokan, N., Janson, P., Steiner, M., and
rules. Waidner, M. State of the Art in Electronic
Payment Systems. IEEE Computer (1999).
[9] Protocol Specifications – Bitcoin, Avail-
able from https://en.bitcoin.it/wiki/ [24] Babaioff, M., Dobzinski, S., Oren, S.,
Protocol_specification. and Zohar, A. On Bitcoin and Red Balloons.
CoRR (2011).
[10] Difficulty – Bitcoin, Available from https:// [25] Belenkiy, M., Chase, M., Erway, C., Jan-
en.bitcoin.it/wiki/Difficulty. notti, J., Küpçü, A., Lysyanskaya, A.,
[11] Block hashing algorithm – Bitcoin, Availabe and Rachlin, E. Making P2P Account-
from https://en.bitcoin.it/wiki/Block_ able without Losing Privacy. In Proceedings of
hashing_algorithm. WPES (2007).
[26] Bellare, M., Garay, J., Hauser, R.,
[12] Bitcoin Block Explorer, Available from http: Krawczyk, H., Steiner, M., Herzberg,
//blockexplorer.com/. A., Tsudik, G., van Herreweghen, E.,
and Waidner, M. Design, Implementation
[13] Myths - Bitcoin, Available from https://
and Deployment of the iKP Secure Electronic
en.bitcoin.it/wiki/Myths#Point_of_sale_
Payment System. IEEE Journal on Selected Ar-
with_bitcoins_isn.27t_possible_because_
eas in Communications (2000).
of_the_10_minute_wait_for_confirmation.
[27] Brands, S. Electronic Cash on the Internet. In
[14] Satoshi Client Node Connectivity, Avail- Proceedings of the Symposium on the Network
able from https://en.bitcoin.it/wiki/ and Distributed System Security (1995).
Satoshi_Client_Node_Connectivity.
[28] Camenisch, J., Hohenberger, S., and
[15] The Finney Attack, Available from Lysyanskaya, A. Compact E-Cash. In Pro-
https://en.bitcoin.it/wiki/Weaknesses# ceedings of Advances in Cryptology - EURO-
The_.22Finney.22_attack. CRYPT (2005).
[16] MoneyBookers, Available from https://www. [29] Chaum, D., Fiat, A., and Naor, M. Un-
moneybookers.com/app/. traceable electronic cash. In Proceedings on Ad-
vances in Cryptology - CRYPTO (1990).
[17] Comparison of Mining Pools, Available from [30] Company, P. Paypal, Available from http:
https://en.bitcoin.it/wiki/Comparison_ //www.paypal.com.
of_mining_pools.
[31] Everaere, P., Simplot-Ryl, I., and
[18] Comparison of Mining Hardware, Available Traore, I. Double Spending Protection for E-
from https://en.bitcoin.it/wiki/Mining_ Cash Based on Risk Management. In Proceed-
hardware_comparison. ings of Information Security Conference (2010).
14You can also read
