Exploiting Forks to Double-Spend
In what follows, we describe an example of a double-spending attack—that was tested in Bitcoin in [22]—and takes advantage of block forks. This attack leverages an exploit in Bitcoin that arises from the simultaneous adoption of client versions
0.8.1 and 0.8.2 (or beyond) in the network. Starting from version 0.8.2, Bitcoin clients no longer accept transactions that do not follow a given signature encoding. As we show, this incompatibility with prior client versions can potentially lead to a double-spending attack on zero-confirmation payments in Bitcoin. Note that this attack can only work when V operates on any client version prior to 0.8.2.
Up to version 0.8.1, a transaction signature could contain zero-padded bytes and the signature check would still be valid. However, starting from version 0.8.2, transactions with padding will no longer be accepted to the memory pool of nodes nor will they be relayed to other nodes.[1] This gives a considerable advantage for A to mount a double-spending attack as follows:
- 1. A sends a transaction TRy with a zero-padded signature to V.
- 2. TRy will be relayed to the miners. Miners that use any Bitcoin version newer than 0.8.1 will not accept the transaction in their memory pool and thus not include it into a block. Miners with an older Bitcoin version will accept it.
- 3. A waits for a short time t (e.g. 1—5 minutes) until he or she acquires service from the merchant.
- 4. Then, provided that TRy was still not included in a Bitcoin block, A sends another transaction TRa that double-spends the inputs of TRy to the benefit of a new Bitcoin address that is controlled by A. TRa is not padded with additional zeros.
- 5. If most peers in the network use newer client versions than version 0.8.1, they will accept TRa (and will reject TRy). The higher the fraction of peers that use version 0.8.2 (or beyond), the larger is the likelihood that TRa is included in a block and that the attack succeeds.
While block forks might naturally occur from time to time in the network, such forks are unlikely to last for more than few blocks, as the network views tend to naturally converge on the longest blockchain within a few blocks. We argue that new version releases, on the other hand, can cause more serious damage since they might result in long-lasting block forks that can only be stopped by manual intervention. Version releases should therefore be carefully designed for backward-compatibility; otherwise, the Bitcoin system might witness severe misbehavior.
- [1] This applies to all Bitcoin versions starting from version 0.8.2 until the time of writing (i.e., version0.8.5).
