Bitcoin transaction malleability and how to fix it (or not)

Image credit: Hyperactive Studios /

As MtGox’s CEO brings his “transaction malleability” defense to trial, the fight over Bitcoin’s capacity roadmap escalates and raises the issue of how to fix the transaction malleability bug – or whether it needs fixing at all.

It is poetic that just as Mark Karpeles heads for trial over 850,000 missing Bitcoins when MtGox – then the world’s largest Bitcoin exchange – collapsed in 2014, the issue of transaction malleability is once again in the headlines via the clash over Bitcoin’s capacity problems and how to fix them.

Background: in 2014, MtGox CEO Karpeles blamed the transaction malleability bug for the huge loss. The transaction malleability bug allows the transaction ID to be changed but not the input and outputs. It is akin to changing the number of a cheque but not the account or payee, which by and large should not be a big problem. MtGox was sucked dry when attackers made withdrawals, subjected them to a transaction malleability attack, then claiming the withdrawal failed. MtGox allegedly simply checked the transaction and ID and, seeing it did not go through, re-issued the withdrawal.

Just how they were stupid enough to reissue 850,000 BTC worth of withdrawals before figuring out something was wrong beggars belief.

Whether that was the whole truth, or if Karpeles sucked the company dry with his lavish lifestyle, will become clearer as the trial progresses. Karpeles is due in court in Tokyo on Tuesday.

Today, transaction malleability is back in the headlines – albeit indirectly – thanks to the ongoing battle over how to fix Bitcoin’s capacity problem.

The SegWit bug fix

One group of people (Chinese miners, corporates and Craig Wright, who claims to be Bitcoin inventor Satoshi Nakamoto) want big blocks and huge $20,000 Xeon Phi-based nodes to perform the block validation. This group controls a new version of Bitcoin software called Bitcoin1, which they want to make the standard reference client.

The Bitcoin-Core developers (who have been the custodians of the Bitcoin reference client since “Nakamoto” disappeared) want SegWit, and then Lightning and Schnorr, and small blocks that can run on a Raspberry Pi.

Here’s what this has to do with transaction malleability:

SegWit (or Segregated Witness) fixes the transaction malleability bug and also makes versioning of new features possible. Lightning, a planned Bitcoin upgrade that will allow for instant almost unlimited transactions, cannot work until the transaction malleability bug is fixed, as a lightning channel depends on the transaction ID being known in advance. Schnorr compact signatures will also increase capacity by making the signatures smaller. Strictly speaking, Schnorr does not require SegWit, but rolling out Schnorr via the versioning that SegWit brings is much, much easier than rolling out Schnorr through a soft-fork where the majority of users and miners have to upgrade first.

Some people (who shall not be named) claim that Bitcoin-Core’s vision of “SegWit now and no plan later” is simply a blatant lie. The plan is there, and it all hinges on SegWit.

Last week, Wright claimed that transaction malleability could be used as a feature and does not need to be fixed. But that was probably more a case of belittling the Bitcoin-Core developers.

Bitcoin1’s development is not in the spirit of open source. While the source code was eventually put out on GitHub as open source, the development is very closed, with invite-only slack. And until they changed their minds on Sunday, Bitcoin1 was running a real-name policy for anyone wanting to join the mailing list and contribute to the software. Which is ironic, as Satoshi Nakamoto would not have been able to contribute under such a policy, were he still around.

Capacity increase or power grab?

Bitcoin1’s solution is called Segwit2x, which means bundling SegWit with a promised block size increase at a later date. Which begs the question: why? If SegWit works and Lightning and Schnorr happen, then Bitcoin’s network capacity will be huge anyway, and a capacity increase might not even be needed for years.

Their last attempt at an alternative Bitcoin codebase, called Bitcoin Unlimited, was a joke – it had so many bugs that it would not even stay online long without crashing, let alone serve as the backbone of a multi-billion dollar cryptocurrency.

Segwit2x is a power grab disguised as a capacity increase. SegWit is a bug fix that comes with some capacity increase and a clear roadmap for more.

Charlie Lee, the creator of LItecoin – which has now successfully activated SegWit on its own blockchain – summarized SegWit2x vs SegWit in a series of tweets:

Lee also questioned if Bitcoin’s capacity issue was real, or if it was just spam transactions from one side trying to artificially exacerbate the issue. As of Sunday, the Bitcoin mempool of uncleared transactions was almost empty.

With less than three weeks until UASF Day on August 1, the recriminations and accusations from both sides will only get faster and more intense.

Be the first to comment

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.