For the past several days*, the Bitcoin network has been plagued by a so-called “transaction malleability attack.” Bitcoin users have experienced a number of annoyances, causing confusion and frustration. And while the transaction malleability issue is well-known and has plagued the Bitcoin network before, to many it is still unclear what it is, why it is a problem, who is causing the attack right now, and what can be done about it.
*According to the claimed attacker (see below), the attack is currently paused at the time of writing, but could and probably will be continued at any time.
What is transaction malleability?
In order to understand the transaction malleability attack, it helps to first understand the basics of how Bitcoin transactions work. In simplified form, each transaction over the Bitcoin network consists of different types of data. This includes transaction inputs (refering to the addresses bitcoin come from), transaction outputs (refering to the addresses bitcoin are sent to), the amount of bitcoin sent, and more. All of this data is cryptographically signed, combined, and scrambled (“hashed”) into a unique and smaller piece of data: a hash. This hash is essentially the transaction ID. If a miner confirms the transaction, the transaction ID is included in a block and stored in the blockchain.
The problem that enables transaction malleability, however, is that effectively identical signatures can result in completely different hashes. The specifics of this are deeply cryptographic, and are very hard – if not impossible – to explain in plain English. But as one extremely simplified example to get an idea of the problem, a comparison would be that the numbers “145” and “0145” are effectively the same number in many cases. But when hashed, “145” and “0145” might actually produce completely different results.
In the case of the ongoing transaction malleability attack, the attacker picks transactions from the Bitcoin network, and tweaks signature data. As a result, all sorts of transactions have two completely different transaction IDs circulating on the Bitcoin network. And since a specific transaction can confirm only once, just one of the transaction IDs will be included in a block, while the other will be ignored.
Are transaction malleability attacks a problem?
The essence of the transaction malleability problem arises when someone uses the transaction ID – and nothing but the transaction ID – to check whether a transaction has been included in a block. This is a problem, of course, because the transaction ID may have been changed by the attacker, and his new transaction ID could have been included in the block rather than the original transaction ID. It might then seem as if the transaction itself never went through – though it effectively did.
This can be problematic for several reasons.
For one, it complicates writing wallet software. This is a problem in particular for Bitcoin companies that use their own software, which several of the bigger businesses in the space do.
The best-known and most infamous example of such a company would be Mt. Gox, the world's first bitcoin exchange that spectacularly failed in 2014 as it claimed to have lost most of its customers’ funds. Mt. Gox claimed it lost this money because it fell victim to a long-lasting malleability attack, which messed up its bookkeeping. With it seeming as if transactions never confirmed, users are said to have been able to withdraw more bitcoin than they owned. Whether this is really why Mt. Gox lost so much of its customers bitcoin remains unclear, but it could – at least theoretically – be true.
This is an extreme example, as Mt. Gox asserts to have automatically re-sent bitcoin merely based on the transaction IDs – not a smart thing to do. But transaction malleability could complicate matters for Bitcoin companies with a more sensible payout policy, too. If they, like Mt. Gox, run software that keeps track of transaction IDs for bookkeeping, the transaction malleability attack could severely damage their records. Even if they do not automatically resend transactions, and, as such, don’t lose any, it’s still a nuisance.
A less urgent but potentially bigger problem is that transaction malleability impedes on chained transactions. Chained transactions are transactions that use an unconfirmed output as its own input, or in other words: They spend bitcoin balances that have not been confirmed yet. But if they spend transactions of which the transaction IDs are changed, they – and all subsequent chained transactions – become invalid all at once.
Chained transactions come in a lot of shapes and forms. The most common might be bitcoin spent from change addresses. But chain transactions also form the basis of more fancy bitcoin use cases, such as payment channels. Indeed, the transaction malleability issue is one of the reasons advanced scaling solutions such as the Lightning Network are not quite ready to be deployed yet.
It bears noting, however, that transaction malleability is no existential problem for Bitcoin. Only the transactions IDs can be changed, not the transactions themselves; no one can steal funds from anyone else, and no one can reverse or block transactions. Moreover, the current transaction malleability attack doesn’t really make the deeper problems with transaction malleability worse. These risks would have existed with or without the current attack.
Why is the Bitcoin network being attacked?
A short answer would be that it's hard to know for sure, as it is hard to determine who is carrying out the attack – let alone why.
Bitcointalk.org user “amaclin,” however, has claimed to be behind the attack. Amaclin, who is probably Russian (or at least speaks Russian), announced his involvement in the malleability attack shortly after it was first noticed on October 1.
Amaclin says he has carried out the attack, essentially, out of boredom. Additionally, amaclin argues that Bitcoin is fundamentally broken. He specifically points out that the incentive structures of Bitcoin’s development process do not align well, as users are not incentivized to reward developers for their work building and maintaining Bitcoin. By attacking the network, amaclin believes he is revealing that only a small number of developers can fix the issue, while most Bitcoin users expect them to do so for free. That is an unsustainable proposition, amaclin says.
Amaclin claims that he is not attacking the network in order to gain financially in any way. He also denies attacking any specific business in order to defraud them or otherwise. He has, however, posted two donation addresses in his forum signature: One is labeled a vote for the attack, while the other is labeled a vote against. At the time of writing, both addresses have had one transaction sent to them, adding up to 300 bits, worth less than 10 cents in total.
Whether amaclin is telling the truth is hard to verify. But the fact that he
could
be telling the truth, the fact that a networkwide attack on the Bitcoin network
could
be carried out by a bored individual with some coding skills, is probably quite telling in itself.
Can the problem be solved?
The good news is that the transaction malleability issue could likely be solved eventually. BIP 62 (Bitcoin Improvement Proposal 62) in particular is intended to prevent malleability attacks by narrowing down the types of data that can be included in Bitcoin transactions. BIP 62 could be implemented as a soft fork, which means that it would then be up to miners to adopt the changes.
The bad news is that the issue is still pretty far from actually being solved. The transaction malleability problem is quite complicated, and some solutions might create other – even bigger – problems for the Bitcoin network. BIP 62 currently is still in draft stage, and not ready to be implemented in Bitcoin Core yet. Moreover, it is far from clear that BIP 62 does or even can tackle all possible malleability issues. It is possible that additional exploits have not yet been found, and have, therefore, not yet been countered by proposals included in BIP 62.
While fixing the malleability issue is widely considered to be a problem that needs solving, it might take a while before a definite solution is ready – if one ever is. For the foreseeable future, wallet software will have to tackle the problem using workarounds.
Thanks to Bitcoin Core developer Peter Todd and Bitonic CEO Jouke Hofman for providing feedback.