However, while confirmed transactions are practically irreversible, it can be possible to intercept and modify information related to unconfirmed transactions in some cases.

The ability to modify input data before it has been confirmed is known as ‘transaction malleability.’ The most common way this occurs is through alteration of the transaction signature, which is responsible for generating the transaction ID. If this signature is altered, the transaction ID will also change, making the previous transaction ID invalid.

TxIDs Can Be Modified, So What?

Transaction malleability can cause serious problems if abused, for example, an attacker could change the unique hash of a Bitcoin (BTC) transaction before it is confirmed. This can be done by changing the digital signature that was used when creating it, without actually invalidating the signature.

By modifying the transaction hash of unconfirmed transactions, an attacker could make any associated child transaction invalid, which, under the right conditions, could allow the attacker to claim that the transaction itself is invalid. That being said, while malleability attacks cannot change the amount sent, the recipient or any other critical parameter, it does open up a number of scenarios where it could be possible to defraud.

For example, the now-defunct Mt. Gox cryptocurrency exchange was subject to a long-standing malleability attack which saw a number of attackers almost completely drain its accounts by claiming that their withdrawal transactions never occurred at all, leading to Mt. Gox resending the funds, and the attacker getting twice the amount they were due.

Malleability Problem Still Relevant?

Although the Bitcoin blockchain has technically fixed the malleability issue through its earlier SegWit upgrade, there are several other blockchains that remain vulnerable to a malleability attack.

Perhaps the most prominent of these is the Bitcoin Cash (BCH) blockchain, which diverged from the original Bitcoin protocol after disagreements surrounding the implementation of SegWit as a means to help Bitcoin scale. As part of the solution, SegWit also corrected the transaction malleability issue, by removing the signature from the equation when generating the transaction ID.

Instead of going with SegWit (and the included malleability fix), Bitcoin Cash instead opted to support larger block sizes, bumping it from 1Mb, up to its current 32Mb value, and allowing a much larger number of transactions to be handled simultaneously.

As it stands, Bitcoin Cash has already fixed third-party malleability, which means external agents cannot alter the transaction hash of a transaction they didn’t create. However, the person who crafted the transaction still has the potential to modify the signature and the transaction hash.

Part of the reason this hasn’t been ‘fixed’ is that many believe it doesn’t need fixing. They argue that transaction malleability has a number of benefits, for example, allowing malformed transaction hashes to be corrected, avoiding stuck transactions.

By forgoing a malleability fix, Bitcoin Cash has left itself vulnerable to these types of attacks, which means another Mt. Gox style hack is not out of the question. This is very unlikely, however, since the risks associated with transaction malleability are now well known.

What is your opinion on transaction malleability? Do you think the risks outweigh the benefits? Let us know your thoughts in the comments below! 

Disclaimer

All the information contained on our website is published in good faith and for general information purposes only. Any action the reader takes upon the information found on our website is strictly at their own risk.