Glossary / Transactions & fees
Transaction malleability
Also known as Transaction mutability.
- Definition
- Transaction malleability is the flaw that let a third party change a transaction's id without changing where the money went, by re-encoding the signature data it contained.
Specified in BIP-66.
The payment still worked; only its name changed. Bitcoin closed the hole in stages between 2015 and 2017, and SegWit finished the job for inputs that keep signatures in the witness. Legacy inputs remain malleable, which is one more reason to hold coins at a bc1 address.
How it works
A transaction id is a hash of the transaction's bytes, so altering any byte produces a different id, and in a legacy input the signature is one of those bytes.
Three kinds of slack made an alteration possible without breaking anything.
The first is arithmetic. An ECDSA signature is a pair of numbers, r and s, and for every valid s there is a second equally valid value, the curve order minus s. Anyone watching the network can flip it and the verification still succeeds.
The second is encoding. Signatures were wrapped in DER, and the library bitcoin relied on accepted sloppy variants: surplus leading zero bytes, non-canonical length markers, padding no careful encoder would emit. Each variant hashed to a different id.
The third is the unlocking script around the signature. Pushing an extra harmless item onto the stack left the script's result identical and the serialized bytes different.
The repairs arrived one layer at a time. BIP66 made strict DER encoding a consensus rule at height 363,725 on July 4, 2015, an activation remembered mostly because several large pools were building on headers they had not validated and produced a six block fork that afternoon. Bitcoin Core 0.11.1, released in October 2015, made low s values a relay policy rule, later written up as BIP146. BIP62, an attempt to enumerate and forbid every remaining source, was abandoned as unworkable and carries the status Withdrawn to this day. What settled the matter was SegWit, live at height 481,824 on August 24, 2017: signatures moved into the witness, the id is computed without the witness, and for a segwit input there is simply nothing left to mutate.
Where you see it
Malleability never caused theft, it caused accounting failures, and that is still the shape of the risk.
A custodian that tracked withdrawals by the id it broadcast could be shown a confirmed transaction bearing a different id, conclude that its own payment had failed, and send the coins again. That pattern caused real losses at exchanges in 2014, and it is why serious operators reconcile by output address and amount rather than by id alone.
Chained transactions were the other casualty. A child that spends an unconfirmed parent names the parent by id, so a mutated parent leaves the child permanently unspendable. Any protocol that signs a refund before the funding transaction is broadcast, which is exactly what opening a Lightning channel does, was unsafe to build until ids became stable.
For someone buying and holding, one habit covers all of it. An unconfirmed id is not a fact. It can still shift through malleability on legacy inputs, and it now changes routinely for an unrelated reason, because Bitcoin Core relays full replace-by-fee by default and a sender who bumps the fee publishes a new id. Wait for a confirmation, then quote the id to anyone who asks.
Transaction malleability vs double spend
Malleability moves the label; a double spend moves the money. In a mutated transaction the same coins reach the same address for the same amount, and only software that memorized the old id notices anything happened. In a double spend a competing transaction sends those coins elsewhere and one version ends up worthless. Mixing the two up teaches people to distrust confirmed payments, which is the wrong lesson: a confirmed id has never been malleable, because malleability only ever applied while a transaction was sitting unconfirmed.