Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin

 
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

                                                           1
on 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

                                                                  2
Hash: 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

                                                                   3
and 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).

                                                                  5
140

                                                                                            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.

                                                              6
the 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

                                                              7
Success 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:

                                                                                     8
Figure 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.

                                                        9
Our 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.

                                                         10
PS        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.

                                                          11
0.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.

                                                           12
blocks 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).

                                                     14
You can also read
NEXT SLIDES ... Cancel