A few hours ago, a poster on the Bitcointalk forum announced that he was able to successfully reverse an unconfirmed transaction against the popular Bitcoin gambling site SatoshiDice. The attacker’s strategy was simple. First, he sent a 0.25 BTC bet against SatoshiDice with no transaction fees, which he lost. Immediately after receiving the notification of his loss from SatoshiDice, he sent another 0.25 BTC transaction to himself – this time with a transaction fee, encouraging miners to confirm the second over the first. However, this strategy as is turned out to be unsuccessful, and so the attacker was forced to introduce another tactic: make the transaction “spammy”. The standard Bitcoin client has a number of rules about accepting transactions that take up a large amount of disk space as one of its measures to prevent people from sabotaging Bitcoin by filling the blockchain with hundreds of gigabytes of transactions, and a general principle is that transactions which deviate from the model of having only a small number of standard inputs and outputs are much less likely to get accepted quickly, or in some limited cases even propagated, without fees. So the attacker deliberately made his second attempt a 0.20 BTC transaction which split up the funds into twenty inputs of 0.01 BTC each, and then attempted to overwrite the transaction with a 0.20 BTC transaction to himself with a generous 0.004 BTC fee. This time, the attempt worked. The mining pool BTC Guild confirmed the second transaction over the first, and the attacker’s original loss disappeared forever.
It is very important to note that this does not undermine the security of Bitcoin as a whole, outside of a very limited number of applications. There are two forms of “confirmation” in the Bitcoin system. The first, which takes about two to five seconds to complete, is simple network propagation; a valid transaction will find its way through the Bitcoin network and make its way to the node controlled by the merchant. The second, which takes about ten minutes, is a block confirmation; here, the miners that maintain the Bitcoin network place the transaction in a block and perform a proof of work computation on the block, which takes a massive amount of computing power to forge. Most Bitcoin-accepting businesses wait for one block confirmation before releasing the product, and this attack does nothing against transactions that have a block confirmation. In the case of vendors selling physical goods and online services, a fraudulent customer’s product can easily be cancelled even hours after the original notification of payment is made. In the case of consumable digital goods like gift codes and wireless refills, this is not the case, but even there the process of sending the code to the customer typically takes up to 30 minutes, so providers either already check for one confirmation or could easily be patched to do so without adding much inconvenience. For usability purposes, the current paradigm of instant confirmations can even still, from the customer’s point of view, appear to remain in place; the instant confirmation still performs its function of reassuring the customer that the transaction has successfully reached the merchant just fine. Waiting an extra ten minutes is a process that can simply happen behind the scenes.
Surprisingly, digital download stores that offer instant downloads for instant confirmations are also protected; Coindl does not need to change its business model. It is indeed possible to force a refund from such a business using this technique, but they are still protected from incurring any significant monetary loss from the act by economics. Digital goods like books, movies and songs have essentially zero marginal cost, meaning that, for example, Apple has to pay less than a penny in extra electricity and bandwidth costs when you download an album from them for $11.99. Using this technique to coax a digital download site into giving you a free song or book is thus essentially equivalent to downloading it through a torrent network; even if half the people in the world start doing it, the honest customers and artists can still continue to carry out their business in peace.
As for solutions, the simplest, and guaranteed to be sufficient, patch is to simply wait for one confirmation before doing anything irreversible. Of course, there are some business models for which this is simply not acceptable; the whole attraction of SatoshiDice was instantly getting one’s money back if one wins. SatoshiDice themselves have already solved the problem; they now require all incoming bets to include transaction fees. Even if sites do not want to introduce such a complication, however, there are still other options. About eight months ago, a now-defunct company called RingCoin released a product named ZipConf, with the intent of supporting merchants accepting instant confirmations by making it more difficult for transactions that have not had a block confirmation to be reversed. Zipconf’s software stack attempts to prevent such attacks in two ways. First of all, it broadcasts the first transaction to as much of the network as possible as soon as its gets it, so that nodes will ignore any transaction that follows it seeing that it conflicts with an existing transaction. Second, Zipconf was willing to compromise slightly on being instant, waiting a few extra seconds after receiving a transaction to listen for fraud attempts before finally accepting it. By then, the transaction will have spread to much of the network and, the theory went, it would be nearly impossible for a second transaction to gain a foothold.
Such an approach can be implemented by businesses like SatoshiDice, although it can be combined with other techniques. For example, SatoshiDice might consider immediately re-sending the output of any transaction that they receive to themselves with a fee, encouraging miners to quickly confirm both the new transaction and its parent over any conflicting transactions. Another layer of defense would be refusing and immediately returning overly large or non-standard transactions. A third strategy would be cooperating with the miners and the Bitcoin developers themselves, getting them to include a patch that does not accept conflicting transactions over older ones even if the new transaction is much smaller and has a higher fee. Individual “selfish” miners may take the fee, but the majority of mining is controlled by mining pools, which are large enough that the public good of the utility of the Bitcoin network itself outweighs any personal cost to them of not accepting such transactions. Thus, on the whole, although this is one of the larger speed bumps the Bitcoin protocol has had to deal with, especially as it is a zero-day vulnerability, it is still only a speed bump. The community will simply need to make an earnest effort to make sure that all businesses and miners are patched to address the issue, and even instant confirmations will still likely continue to exist.
