First published February 2014, in O’Reilly Radar
If a crook gets access to the credit card or wire transfer networks, it’s a disaster. That’s because, as I explained in my recent article about security models, these traditional financial networks achieve trust by excluding bad actors through access control. Effective access control requires exclusivity and strict vetting, only a small carefully vetted group of “trusted actors” are granted control.
Bitcoin and other crypto-currencies based on the blockchain invention are different. Trust is based on computation, not access control. On the bitcoin network you trust math so everyone can have access. That also means that there will be bad actors, arguably just as there are on access control networks, and nuisance attacks. Fortunately, these types of attacks cannot affect the distributed asset ledger, the blockchain, because to achieve the level of trust to write into the ledger you must apply enormous distributed computation. The root of trust is in the majority of computing power, not individual actors or any central authority.
As on the Internet, Denial-of-Service (DoS) attacks can be launched against services connected to the bitcoin network. While these DoS attacks can temporarily disrupt service, they do not affect the trust model. Bitcoin’s routing nodes, most often implemented using the reference client “bitcoind”, contain numerous defenses to DoS attacks, imposing limits on connections and traffic, detecting malformed requests and blocking repeat offenders automatically. This makes the network adaptive to threats and as new attacks are discovered and thwarted the network becomes more and more robust and resilient. The early Internet was also much more sensitive to DoS attacks. At times, large providers like Yahoo and Microsoft were taken offline by large DoS attacks. Nowadays, it is exceedingly rare for a DoS attack to affect major sites for very long. As the Internet matured, it has become harder and harder to disrupt — it became less fragile by repeated exposure to stress. This is the idea of an anti-fragile system: it not only resists attack, it gets stronger through exposure to attack.
Bitcoin was stress-tested quite a bit in the last week, by attackers exploiting “Transaction Malleability”, a known issue that if coupled with a weak implementation of the protocol could lead to service disruption. In simple terms, the variable-length and complex scripting language used to encode transactions means that a single transaction (sender, signature, recipient, value) can be encoded in a variety of ways, all of which are valid. An attacker cannot modify the fundamental details of the transaction but can create a cloned transaction which is mutated in a subtle way, so as to present a different fingerprint. For example, a value of 2 bitcoin can be encoded as 02 bitcoin or 002 bitcoin. Any transaction modified in that way will still spend 2 bitcoin (with the same sender and recipient) and will be verified by the network the same way but the resulting fingerprint will be different. This becomes a problem only if the transaction fingerprint (“hash” or “transaction ID”) is considered authoritative before it has been confirmed into the authoritative ledger. Once a transaction has been included in a block in the blockchain (backed by the proof-of-work, a process called “mining”) it is entirely immutable and authoritative. In the short time when a transaction is submitted and propagated on the network but before it is confirmed in the blockchain, the transaction hash is not considered authoritative. Any implementation that tries to reconcile transactions with its internal accounting using the transaction’s hash before it is confirmed, runs the risk of being intentionally confused by conflicting transaction hashes.
For example, let’s say an exchange issues a withdrawal transaction to a bitcoin address for a customer. If the exchange presents the withdrawal transaction hash as a receipt, the customer could create a conflicting transaction with a modified hash and try to propagate it on the bitcoin network alongside the original withdrawal transaction. One of the two transactions will succeed and be included in the ledger, the other will be ignored. There’s no risk the customer can modify the value, recipient or any of the critical details — all they can do is have the transaction processed in an identical way, but under a different transaction hash. This is where a faulty implementation can lead to a vulnerability. If the exchange uses unconfirmed transaction hashes to track withdrawal success, they may be fooled into re-issuing the withdrawal because they do not see the transaction hash in the blockchain ledger.
This is similar to a department store issuing a refund against a photocopied receipt, without checking to see if their system contains a previous such refund. Many retailers have had to adjust their refund policies and operations training to defend against such fraud. For an exchange, the correct implementation is to use the list of transaction inputs and see if they have been spent or not, regardless of the transaction hash that spent them. If the inputs are spent, then the withdrawal occurred, even if the transaction hash they issued as a receipt does not appear in the blockchain.
During a single week, the issue of “Transaction Malleability” went from a known-issue first identified in 2011, to a workable exploit against a single exchange, and finally to bot-based attack against thousands of transactions that clogged up the systems of many of the exchanges. The exchanges, faced a situation similar to a flood of customers with shoeboxes full of photocopied receipts, all hoping to exploit a trick they heard about on the news. Even if their attempt to defraud retailers fails, as they are now wizened to such a trick, it will still clog the lines to the customer service desk and delay legitimate customers. A few days after the initial attack, after several exchanges suspended withdrawals while they strengthened their systems, most returned to normal operations.
Here’s the interesting thing, though: the attack didn’t stop. While the exchanges resumed operations, they did so with systems strengthened against this and variants of this type of attack. The attack continued but the systems were no longer vulnerable to fraud or even delays from the confusing traffic. In essence, the entire ecosystem of bitcoin exchanges just got a bit more resilient, a bit more robust and a bit more resistant to attacks. Bitcoin demonstrated anti-fragility.
There will be more nuisance attacks. During each attack, the media will confuse access for trust and write hyperbolic headlines proclaiming the end of the currency. Soon after, the bitcoin network and ancillary services will learn, adapt, thwart and become more resilient. Like the Internet, over time, crypto-currency networks such as bitcoin will get stronger and stronger, as each attack increases resilience by training the distributed immune system of an anti-fragile network.