(In-)Security of Zero-Confirmation Transactions

In what follows, we show that double-spending attacks are easily realizable on zero- confirmation transactions.

For that purpose, we assume a setting featuring a malicious client A and a vendor V connected through a Bitcoin network (see Figure 4.5). We assume that A wishes to acquire a service from V without having to spend its BTCs. More

Figure 4.4 Cumulative distribution function (CDF) of block generation times. Approximately 30% of Bitcoin blocks take between 10 and 40 minutes to be generated.

specifically, A could try to double-spend the coin that he or she already transferred to V. By double-spending, we refer to the case where A tricks the vendor V into accepting a transaction TRy that V will not be able to redeem subsequently. In this case, A creates another transaction TRa that has the same inputs as TRy (i.e., TRa and TRy use the same BTCs) but replaces the recipient address of TRy —the address of V — with a recipient address that is under the control of A. Figure 4.6 shows an example of transactions TRy and TRa.

We assume that A can only control few peers in the network (that he or she can deploy since Bitcoin does not restrict membership) and does not have access to V's keys or machine. The remaining peers in the network are assumed to be honest and to correctly follow the Bitcoin protocol. We further assume that A does not participate in the block generation process.

Given this, we outline the necessary conditions for A's success in performing a double-spending attack on zero-confirmation transactions.

Helper

Figure 4.5 Our system model.

Figure 4.6 Example of two transactions involving double-spending coins labeled Input 1 and Input 2.

Requirement 1: TRy is added to the wallet of V

If TRy is not added to the memory pool of V, then V cannot check that TRy was indeed broadcasted in the network.

Let t^y and t^} denote the times at which node i receives TRy and TR}, respectively. As such, ty and ty} denote the respective times at which V receives TRy and TR}. Note that for TRy to be included in V’s wallet, then ty < t}; otherwise, V will first add TR} to its memory pool and will reject TRy as it arrives later.

This requirement can be easily satisfied if A (or one of its helper nodes) connects directly to V and sends TRy to V first, before forwarding the doublespending transaction TR} to the rest of the network. In this way, V will immediately receive TRy and add it to its memory pool before receiving TR}.

If TRv is confirmed first in the blockchain, TRa cannot appear in subsequent blocks. That is, V will not have its BTCs back. Recall that the goal of A is to acquire a service offered by V without having to spend his or her BTCs.

As shown experimentally in [1], this requirement can be satisfied by broadcasting TRa quickly to as many nodes in the network. Note that if TRv and TRa are released by V and A at the same time in the network, they are likely to have similar chances of getting confirmed in an upcoming block. This is the case since Bitcoin peers will not accept multiple transactions that share common inputs; they will only accept the version of the transaction that reaches them first, which they will consider for inclusion in their generated blocks and will ignore all subsequent transactions. Given this, a double-spending attack can succeed if V receives TRv (see Requirement 1), and the majority of the peers in the network receive TRa so that TRa is more likely to be included in a subsequent block. This can be achieved if A can rely on the cooperation of one or more helper nodes that help him or her broadcast TRa to a large number of nodes. Note that A (and its helpers) can try to increase the number of their immediate neighbors in order to increase the success probability of their attack.

Requirement 3: V ’s service time is smaller than the time it takes V to detect misbehavior

Since Bitcoin users are anonymous and users hold many accounts, there is only limited value in V detecting misbehavior after the user has obtained the service (e.g., left the store). As such, for V to successfully detect any misbehavior by A, the detection time must be smaller than the service time.

We point out that requirements (1) and (2) are sufficient for the case where the vendor only checks for the reception of the transaction as a proof of payment and does not employ any other double-spending prevention/detection techniques. This is currently the case in most existing Bitcoin client implementations.

This analysis shows that requirements 1, 2, and 3 can be realizable in existing Bitcoin implementations.

This analysis is confirmed by means of experimental results adapted from [1] and summarized in Table 4.1. These results confirm that double-spending attacks succeed with a probability of almost 100% if A utilizes at least one additional helper node. This clearly shows that zero-confirmation transactions are not secure in Bitcoin and should not be accepted directly by vendors.

Table 4.1

Success Probability in Double-Spending Zero Confirmation Payments in Bitcoin³