Transaction malleability has been a long-standing issue for Bitcoin-derived cryptocurrencies and it’s an issue which the Zcash team have been keen to address. Let’s explore what the problem is and why it’s important to solve in the long run.
In a nutshell, transaction malleability is where a valid transaction can be modified in-flight as it propagates across the network. The details can be found here. While the modifier doesn’t have access to the private keys of the sender and is unable to steal funds for personal gain, the modified transaction does pose a problem because it can be considered valid by the network. That is, there could be two transactions attempting to spend the same coins but with different transaction IDs.
Although such modifications are often thought to be just a nuisance, transaction malleability does have real-world impact. First, wallet software cannot rely on a transaction ID to track a movement of funds. Second, businesses relying on chained transactions, where the change from one transaction is spent immediately in a new transaction, will find that the chain can be broken. Thirdly, off-chain solutions designed to improve transaction throughput, such as Lightning and BOLT, are more practical if transaction malleability is first solved.
So how to fix malleability? One solution proposed to us has been to back-port Segregated Witness (segwit) which addresses a range of issues including malleability. However, it was decided a few months ago that it was not possible to do so within the Zcash project’s timeline, especially as segwit was a work-in-progress at the time. Today, development of segwit is mostly complete, but it has yet to be deployed and activated across the Bitcoin network.
Our own attempt at a smaller and more focused solution was released a few weeks ago as part of the z8 alpha release and deployed to the test network. Although no issues cropped up in daily use, we had always been conscious that there might be edge cases and security concerns we had not yet detected. In fact, there is a bug where a newly mined block could be modified posing a risk of denial-of-service, which fortunately was found by our auditors as part of the security audit of Zcash. Although the fix itself is fairly simple, the ensuing discussion raised a number of issues for the team to evaluate in order to provide a comprehensive and robust solution.
After consideration, given the available resources and the project schedule, the team have decided to roll back the changes made. We feel it would be prudent to launch with known knowns rather than introduce new unknowns. Our exploration of transaction malleability highlights the importance of independent third-party review to the development process, especially around the consensus protocol where even the smallest of changes can ripple out with hard-to-predict Kafkaesque side effects. We are grateful to our auditors Coinspect for helping us to catch some butterflies!
Please help us by running the latest z9 alpha release of Zcash and letting us know of any bugs, issues and usability problems you come across. You can reach the team by filing a GitHub issue or visiting the Zcash Community Slack channel. Thank you.
