Written by Jonald Fyookball.
If you’re a Bitcoiner or crypto-enthusiast, you’ve probably heard this “malleability” issue being discussed and wondered what it’s all about.
Maybe you’ve probably heard a bunch of conflicting ideas and opinions about it too. Let’s break it all down.
What’s Malleability?
There’s different types of malleability, but to make a long story short, if you create a Bitcoin transaction, someone else (such as a miner or exchange) can modify the transaction ID (txid) before it gets put into a block.
What’s a transaction id? Well, think of it as like a “receipt number” for your transaction.
Keep in mind, with malleability, a third party cannot change the recipient of the funds, nor the amount, nor the fee… they can only change the txid.
So what’s the big deal? Hold on, we’re gonna get to that. I want to give you the complete picture here.
Feature or Bug?
The first thing to realize is that malleability is sort of “baked into” the design of Bitcoin.
Bitcoin uses a kind of cryptography called the Elliptic Curve Digital Signature Algorithm (ECDSA). And it is a well-known fact that these digital signatures are malleable.
In other words, a third party can change the signatures in certain ways, but they will still be valid. The same is also true for other types of digital signatures.
For example, an ECDSA signature which is an (r,s) pair can be malleated as (r, -s). All you do is take the negative of “s” and the signature is still valid… although different.
Now combine this with the fact that Bitcoin transactions (including the signatures) are hashed to create a chain of ownership. Because ECDSA signatures are inherently malleable, and those signatures are part of each transaction, that means that Bitcoin transactions are going to be malleable.
Because of all this, you could reasonably call malleability a ‘feature’ of Bitcoin. Yet, you could also call it a bug since there are some non-desirable consequences of this.
I think the best words to use are that this is an issue, and that a change to Bitcoin code to handle this would be an enhancement.
Malleability is Not a Huge Problem
Right off the bat, I can tell you that anyone claiming that malleability is a huge, urgent problem is either uninformed or lying. That’s because malleability has been around for 9 years since the beginning.
The infamous Mt Gox thefts have been blamed on malleability but those theories have been debunked.
As the properties of malleability are well known, no wallet or other software should be relying on transaction ids, and if they are, that software can and should be fixed.
Malleability in Bitcoin still exists today. Even in BTC, Segwit only prevents malleability in Segwit transactions, which currently make up about 5–10% of the total transactions.
Malleability as a Political Tool
One of the benefits of fixing malleability is that it makes other projects (such as the Lightning Network) easier to implement. Because certain groups desire those projects, they may greatly exaggerate the need to fix malleability.
Just be aware that this has been going on.
Does Malleability Help Wallet Development?
Another one of the claimed benefits of fixing malleability is that it will help developers of wallets — for example because its supposedly “easier to monitor transactions by txid”.
I think this is highly debatable.
Wallets and other software already have code to handle transactions. And many of the proposed changes for malleability actually add a great deal of complexity to Bitcoin, rather than simplify it.
0-Conf Transactions
Now that we have discussed what I consider the “non-issues”, we come to the actual issue, and it has to do with 0-conf transactions.
In Bitcoin, you know a transaction is confirmed once a miner includes it in a block and publishes the block to the blockchain. The more confirmations, the more secure the transaction.
Transactions not yet included in a block can be said to be unconfirmed, pending, “out there in the mempool”, zero confirmation, or “0-conf”.
Most everyone knows that a transaction that is unconfirmed is less secure than a transaction that has at least 1 confirmation.
But how much less secure? Well that depends…
Core Vs Cash Philosophies on 0-Conf
I’ll get back to how this relates to malleability in a moment, but let’s discuss “0-conf” a bit more. Perhaps you didn’t realize it, but 0-conf is actually a controversial topic that’s highly relevant to the Bitcoin scaling debate.
The ‘Bitcoin Core’ philosophy is that we should have a layered system with high fees on the base layer. So unless you use the proper high fee, your unconfirmed transaction might take a long time to confirm, or it may never confirm.
During this time, it could be double spent or replaced with “RBF” (replace by fee). In this system, 0-conf is fairly unsafe and unreliable… which makes sense if Bitcoin Core wants you to use second layer solutions.
The ‘Bitcoin Cash’ philosophy is that fees should not be inflated, and blocks should not be full. This makes 0-conf fairly safe and reliable…which makes sense if Bitcoin Cash wants you to be able to conduct your transactions on the blockchain.
It Only Affects “Unconfirmed Parent” Transactions
Let’s say you have an unconfirmed incoming transaction show up in your wallet, and you immediately try to spend those funds before that incoming transaction has a confirmation.
Your outbound transaction now has a status of “unconfirmed parent”, since the “parent” (the incoming transaction) hasn’t been confirmed yet.
Normally, not a problem. When the parent transaction gets confirmed, then the child transaction can also get confirmed, either in the same block or a subsequent block.
But, if a miner decides to malleate the parent transaction, then that child transaction won’t be valid, since the input is a hash of a transaction Id that no longer exists.
To explain this further:
Before it is malleated, the original parent transaction Id exists in the mempool of each node and miner.
(“Mempool” means memory pool, or a collection of transactions).
But once the miner malleates it and puts it into a block, the original transaction with the original Id will disappear from the other miners’ mempools since those outputs will now be spent.
This means that the child transaction (the one you sent out) is guaranteed to fail.
How Often Does This Actually Happen?
Normally, miners don’t malleate transactions. They have little or nothing to gain by doing so.
One reason is to prove a point. Recently, a mining pool called Bitclub decided to go on a malleation spree, for apparently political reasons.
But even when this kind of thing happens, in order to be affected you would need to have a transaction with an unconfirmed parent, and then your transaction would have to be malleated and mined by the attacking miner.
And even if that were to happen, your transaction would fail and the funds would go right back into your wallet since the transaction would be instantly invalidated.
Is There an Actual Problem with a Real Life Use Case?
If a transaction fails, its usually not a problem for the Internet user sitting at home. But in real life, a merchant may not want to accept a transaction with an unconfirmed parent if there is a (small) risk a miner may malleate it.
One source of these transactions is change addresses. For example, if you buy a $2 item with a $20 unspent output, you get back $18 in change. Now that $18 will be unconfirmed.
Even so, these kinds of issues can be avoided without any protocol changes. You could theoretically split a $20 bill into 20 singles at the push of a button before going out to shop. And it could later be sent back to “the vault” for storage.
Splitting and combining value can be done easily and cheaply when fees are low. The more commonplace this is, the more privacy increases because it makes blockchain analysis increasingly burdensome and complex.
Fixing Malleability for the Right Reason
0-conf transactions could theoretically be made stronger for the “unconfirmed parent” situation. This is at least a decent motivation for fixing malleability.
Bitcoin Core instead wants to fix malleability because it helps make second layer services easier to code. It is not even necessary for those services. It just makes some current implementations easier. But that is not a good reason to change the protocol.
Two Possible Approaches
There are two basic approaches when it comes to trying to fix malleability.
The first is adding consensus rules that dictate the precise details for how signatures are generated. This was attempted in Bip62, but the Bip was withdrawn, perhaps because consensus changes activating would actually be a hard fork.
If you read the Bip, you will see that “Bitcoin transactions are malleable in multiple ways”. Pieter Wuille identifies many of them, but there may be other ways that third party malleability is possible.
The second approach involves modifying the block and transaction structure so that the signatures are not a part of the transaction hash.
This is the approach taken by Segwit, Flex Trans, and MalFix.
If We’re No Longer Including the Signatures in the Hash, What Does That Imply?
The Bitcoin whitepaper, in section 2, says this:
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
All of these malleability fixes (Segwit, Flex Trans, and MalFix) change that. We are no longer signing a hash of the previous transaction. We’re signing only the transaction without it’s signature (which is the most important part) and then including that signature somewhere else in the block.
A purist might say that this is no longer Bitcoin.
SegWit
Sorry, SegWit fans. But out of all the malleability proposals, SegWit is the worst. It weakens the Bitcoin security model since signatures are optional for non-upgraded clients, and discardable by everyone.
Also, SegWit only fixes malleability for SegWit transactions, which currently account for only 5–10% of the total transactions.
FlexTrans
Flextrans is a better proposal. It is a hard fork that only changes a few lines of code. Transactions are not discardable as with SegWit, and the malleability is fixed for all transactions.
Still, the strict definition of Bitcoin as a chain of digital signatures (from one transaction to the next) is not preserved.
But does it matter?
Maybe not… But maybe.
Is FlexTrans Still a Chain of Signatures?
With schemes such as FlexTrans, you aren’t directly hashing the entire transaction before chaining it to the subsequent transaction, but the signatures are still in the block and they then become part of the entire block’s hash.
That hash is then used by the next block (unlike Segwit which puts the signatures into a second merkle tree which is NOT used by the next block).
On the surface, it appears that the Flextrans security model isn’t weaker than the original Bitcoin since a signature must always be present to transfer ownership.
And it could be further argued that we still have a chain of digital signatures. The difference is that the security has been moved from the transaction level to the block level.
FlexTrans and Ideas Like It Should be Studied Further
On the other hand, Flextrans IS a change from the whitepaper’s Bitcoin.
It is somewhat troubling to start heading down the road of separating signatures from transactions. That seems to make it easier in the future for miners to make further (undesirable) changes.
Bitcoin has worked well for 9 years. In general, we should extremely careful to change the formula, especially with something as sensitive at how we handle the signatures.
If a signature is separate from a transaction, does that make it easier to perform certain kinds of hashing collision attacks?
I do not know, but proposals like Flextrans should be deeply studied and peer reviewed before they are considered for deployment.
The cost/benefit should be evaluated carefully. What are the costs of deeply researching and analyzing the risks of changing Bitcoin, and what benefits do we actually get?
Maybe the Best Option is Simply Do Nothing
There was a great comment on reddit the other day. When asked if Bitcoin should ever include some “off chain” scaling, u/coincrazyy commented:
We will do this WHEN WE NEED TO. Let’s onboard 1 billion people first with gigablocks and $.01 transactions FIRST. Don’t solve problems that DO NOT EXIST
The same philosophy should be applied to malleability.
Is it a problem right now? And for who?
Arguably, the only worthwhile benefit to fixing malleability is to solidify 0-conf reliability for unconfirmed parent transactions.
But we have a long ways to go on merchant adoption, and we should not put the cart before the horse. Let’s get so many merchants on board, so that this becomes an actual (rather than theoretical) problem.
That will be the right time to address malleability as a priority.
Written by Jonald Fyookball
Jonald Fyookball (pseudonym) is a cryptocurrency enthusiast, best known as the project leader of the Electron Cash wallet, and for a series of hard hitting articles on the Bitcoin scaling debate. Jonald is a computer scientist, businessman, investor, libertarian, and Bitcoin advocate.
Do you think that malleability is an important problem to solve or a political issue? If it is the latter, what is the solution? Share your thoughts in the comments section below!
This is an Op-ed article. The opinions expressed in this article are the author’s own. Bitcoin.com does not endorse nor support views, opinions or conclusions drawn in this post. Bitcoin.com is not responsible for or liable for any content, accuracy or quality within the Op-ed article. Readers should do their own due diligence before taking any actions related to the content. Bitcoin.com is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any information in this Op-ed article.
Images courtesy of Shutterstock
At news.Bitcoin.com all comments containing links are automatically held up for moderation in the Disqus system. That means an editor has to take a look at the comment to approve it. This is due to the many, repetitive, spam and scam links people post under our articles. We do not censor any comment content based on politics or personal opinions. So, please be patient. Your comment will be published.
