For the past several years, the Bitcoin network has been bedeviled by transaction malleability attacks. These attacks shot to fame during the notorious Mt. Gox theft where it was referred as the sole reason for interrupting withdrawals. Since then, the attack has distressed many digital currency companies, including high-volumed exchanges BitStamp and BTC-e.
What is the Transaction Malleability?
While transaction malleability is still a little difficult to explain in plain English, we can consider it as an attack that tampers the unique Bitcoin transaction ID before it is confirmed by miners on the network. To understand it further, let’s first see how a Bitcoin transaction works.
Unlike traditional wire transfers, a Bitcoin transaction is created and confirmed right on the blockchain. The blockchain is Bitcoin’s public ledger which stores records of each and every transaction made on the network. This piece of information includes the addresses of both senders and receivers, alongside the number of Bitcoins that are exchanged between the participators.
Each of theses pieces of information is jumbled together with a mathematical “hash function” to create a unique transaction id (or TX ID). This hashed TX ID also includes digital signature of the sender, proving that the transaction was initiated from a legitimate Bitcoin address. In the end, a unique transaction hash is created to conceal original information, and due to the “mathematics” involved, any change in the input would tweak the entire transaction hash in an unpredictable manner.
And that’s where a malleability attack tries to spoil the day for Bitcoin users.
Despite being termed as “impossible to spoof”, a transaction id can still be tweaked simply by taking advantage of an intrinsic Bitcoin flaw — the digital signature format. The users’ digital signatures used to hash a transaction is not always properly formatted, and there is absence of proper mechanisms to check its formats. The attackers somewhat target this loophole and use it to twitch the entire transaction hash.
For example: “0100” and “100” normally represents the same number “100”, but in terms of hashing, these are treated as two different digits that produce two different ids.
Thus, a transaction malleability attack ends up creating two separate transaction hashes for a single transaction. And since miners on the network can confirm only one transaction ID, the other one gets ignored. There is also a chance that the fake transaction id is confirmed on the block before the original, despite the fact that latter is the one that has been processed in reality.
No Solutions in Sight
The solutions for tackling the transaction malleability have been proposed in decent numbers, but they are still far from being implemented. The most famous solution that was proposed recently was Bitcoin Improvement Proposal 62 (or BIP 62). It offered to change the Bitcoin validity rules and introduce some new ones to overall disable malleability from occurring. However, it was found later that even BIP62 had its own set of flaws that might conceive some more troubles for the Bitcoin network.
Back in 2013, some scholars from University of Warsaw also proposed a separate modification of Bitcoin, where modified transaction also produced the hash same as that of the original transaction. The scholars further updated their approach by eliminating the need to modify Bitcoin protocol while preserving the transaction hash. This approach was called “BitCoin-based timed commitment scheme.”
The said approach however had enough pre-conditions to prove itself effective.
Solutions proposed by other bigwigs meanwhile require core developers to fork the entire Bitcoin protocol, which is definitely not possible at this point of time. One can also find a whole seminar dedicated to solving the transaction malleability issue here, but each one of the solution routes towards twitching the original Bitcoin source code.
How to Avoid It?
Transaction Malleability is an irritation, but doesn’t put Bitcoin users under major risks. It cannot be resolved ideally but can be ignored if the concerned exchanges, wallet companies and developers ensure to double check their Bitcoin transactions. They are always recommended to wait for the transaction to get confirmed on blockchain. Furthermore, they should tweak their codes in order to handle mutant transactions sprucely.
Manual verifications can also help companies manage their transaction records at backend.
1- Bitcoin wiki; Transaction Malleability. https://en.bitcoin.it/wiki/Transaction_Malleability
2- Bitcoin wiki; Bitcoin transaction. https://en.bitcoin.it/wiki/Transaction
3- University of Warsaw. http://arxiv.org/pdf/1312.3230v1.pdf