This article is an excerpt from my book, A brief introduction to Bitcoin.
Bitcoin’s proof-of-work scheme prevents double-spending for slow payments where the payee waits for the transaction to be acknowledged in at least one block. Each new transaction goes through two stages of verification, once after creation and once after it has been included in a block, as described earlier. As a result, a double-spending of the same Bitcoins would require a very high computing effort for the generation of fake blocks. This type of double spending is discussed in the next chapter, as part of the larger issue of centralizing computational capacity. In the current chapter, we discuss the risk of double-spending in fast-paced scenarios.
Unlike conventional banking systems, Bitcoin preserves the entire history of the transactions, which can cause information asymmetries. This means not everyone will know the latest status of the blockchain at the exact same moment. Propagating a payment to the network typically has a delay of fewer than three seconds. The confirmation of a transaction lasts on average 9 minutes and 54 seconds with a standard deviation of approx. 15 minutes. (Please note that these numbers might be outdated, as they stem from pre-2017, but the effects described remain unchanged).
Such short-lived asymmetries may suffice in practice to issue the same Bitcoin amounts multiple times by triggering transactions at different addresses simultaneously. This problem is described in the literature as the double-spending problem.
Bitcoin is used in a number of fast-paced scenarios, for example, over-the-counter purchases. And while this is slowly being taken over by second-layer solutions — like the Lightning Network— sellers right now can’t always wait for the complete confirmation of a Bitcoin transaction — or for that matter, not even for a partial confirmation. If you buy a coffee, you expect the process to last seconds, not minutes, and certainly not an hour. In the literature, this is called prevention of activity for enterprises which are characterized by fast service times. Providers are therefore prompted to conduct and accept low-value transactions without confirmation.
Such so-called “zero-confirmation transactions” allow double-spending attacks in which the exchange of goods is completed before the transaction verification has been conducted. Here’s what that would look like:
To perform a successful double-spending attack, attacker A must make the vendor V accept an unconfirmed transaction TRV. At the same time, A generates another transaction TRA. This has the same inputs as TRV, i.e. both transactions use the same Bitcoins, but they reference a different output address. For example, instead of the address of vendor V, attacker A could reference an address under his own ownership.
The attack could be successful if the vendor V receives transaction TRV, which was meant for him, but the network instead confirms transaction TRA and the trade is settled before the first block acknowledgment, i.e. before the Bitcoin amount is taken out of the wallet.
If both transactions are broadcasted at the same time, both have a similar probability of being included in the next block, since the network nodes always accept only one transaction with the same inputs. To help his cause, attacker A could modify the output of TRA to influence the size of the transaction fee. That way he can get a better confirmation probability for TRA.
This type of attack is considered feasible in practice if no countermeasures are taken. Therefore, extensions exist which are considered ways to protect against double-spending. For example, such extensions are “listening periods” in which the network checks all incoming transactions for equal inputs, or “observers” which point out fraud attempts.
Other solutions once in use were so-called “green addresses”. With these, a vendor who considered the owner of the address trustworthy could accept zero-confirmation payments. However, this method was highly criticized for requiring third party trust, a necessity which Bitcoin is meant to circumvent. A better way in which the double-spending problem can be mitigated is by introducing a second-layer mechanism for fast payments. We will discuss an example of an existing second-layer solution, the „Lightning Network”, in Subchapter 5.6.
[1] (Bitcoin Stats, the numbers are just exemplary, and change frequently.)
