Malevolent Malleability

Transaction malleability is a longstanding well-known issue in the Bitcoin technical community. One of the earliest discussions about it occurred in 2011. Malleability comes up from time to time, such as when MtGox blamed their disabling of withdrawals upon this "bug in the bitcoin software" as their insolvency was approaching crisis levels in 2014.What is transaction malleability? You can read an in-depth explanation here, but essentially it is the result of using one of several different methods to slightly modify a Bitcoin transaction's data structure so that the inputs and outputs (sender and recipients) remain the same, but the hash of the transaction changes. This is not a critical attack vector in and of itself, but can become critical if Bitcoin services are reliant upon using the transaction hash as a unique ID under the assumption that it cannot change. Malleability has been used in targeted attacks against services such as exchanges in order to trick them into sending withdrawals multiple times, but more recently in 2015 we saw a programmer launch a system-wide untargeted malleability attack in an attempt to disrupt the entire Bitcoin economy. Why is a system-wide attack bad? It can result in a number of issues:

• A user sends a payment to a service, which sees the unconfirmed transaction, but then a malleated version ends up being confirmed, causing the service to think the payment never confirmed.
• A user checks a sent or received transaction on a block explorer and sees an alert for a "double spend" which results in confusion, anxiety, and opening a support ticket with their wallet provider for clarification.
• A user receives a transaction and then sends a transaction that spends an output from the first before it is confirmed, but a malleated version of the first transaction eventually gets confirmed, making it impossible for the second to ever be confirmed. This is because the "unspent transaction output" ID that the second transaction spent becomes invalid.
• Similarly, a user sends a transaction and then sends a second transaction that spends a change output from the first before it is confirmed, but a malleated version of the first transaction gets confirmed, making it impossible for the second to ever be confirmed.
• A user receives a transaction and the wallet software adds the received amount to the balance twice after also receiving a malleated version of it.
• Similarly, a user sends a transaction and the wallet software subtracts the sent amount from the balance a second time after also receiving a malleated version of it.
• In general, unconfirmed transactions become even less reliable than usual.
• Applications that use payment channels (such as Streamium or Lightning Network) rely upon "refund transactions" which become unreliable and thus break the "contracts" created in the payment channel.

What are we to do? This has been a problem for over 4 years now. It's clear that any developer who builds a service that uses the Bitcoin protocol needs to take into account the possibility of transaction malleability and guard against it disrupting their service. However, it's also clear that developers aren't going to take the time to do this unless it's a pain point for users. Since malleability attacks have been sporadic, we tend to forget that it's a problem during the time between high profile exploits.Thankfully, malleability vectors are slowly being addressed at the protocol level, such as in Bitcoin Core 0.9.0 and recently in 0.11.1. However there are nine known malleability vectors and only a handful have been addressed thus far. Malleability won't be completely fixed until the vast majority of nodes have been upgraded to run software that guards against every vector (thus preventing malleated transactions from propagating through the node network) and all miners have upgraded their nodes to malleability-proof software as well.The general consensus up to this point has been that malleability is an annoying but not critical system-wide problem. However, the problem may become critical from a scalability standpoint. As the debate around scaling Bitcoin and the maximum block size has raged for most of 2015, it has become clear that we will need off-chain solutions such as the Lightning Network in order to enable the Bitcoin network to continue to serve rising demand. Lightning Network in its current form assumes that malleability is solved, but BIP-062 has no time frame for completion. Lightning Network developers are currently pursuing other potential workarounds but so far they all appear to be inferior. If transaction malleability isn't fixed at the protocol level, the transaction volume capable of being processed within the Bitcoin ecosystem may remain stuck at current levels and users will choose other systems that can better meet their needs.