What is Transaction Malleability?
Transaction malleability is a quirk of early Bitcoin (and some other UTXO chains) where a third party can modify the data inside a pending transaction in a way that changes its transaction ID (txid), while keeping the transaction itself valid and the funds moving to the same destination. The signature is still correct, the amount is unchanged, and the payment still goes through — but the identifier of that payment is now different.
That sounds harmless until you realize how many systems track payments by txid. Exchanges, payment processors, and multi-signature wallets historically used the txid to confirm “did this withdrawal go through?” If the txid could be changed mid-flight, an attacker could request a withdrawal, then malleate the transaction so the exchange couldn’t find the original txid, claim the withdrawal “failed,” and get paid twice. This single flaw enabled repeated exchange thefts and was a central motivation for Segregated Witness (SegWit).
How Transaction Malleability Works / Technical Details
A Bitcoin transaction’s txid is the SHA-256 hash of the transaction’s serialized data — including the cryptographic signature. The signature proves the spender authorized the transaction, but the signature itself is not “signed.” That created a circular dependency: the txid depended on data that could be subtly altered without breaking validity.
What Could Be Changed?
Several components of a signature were not themselves covered by the signature:
- The ECDSA signature encoding — different but equally valid DER encodings of the same signature produce different txids
- The scriptSig in certain standard transaction types
- Optional opcodes and padding inside the signature script
Anyone on the network — not just the sender — could take a pending transaction, re-encode the signature into a different valid form, and rebroadcast it. Whichever version a miner included first became the “real” transaction, but with a new txid.
The Resulting Attack Loop
- Attacker deposits BTC to an exchange, getting an internal credit
- Attacker requests a withdrawal to their address
- Exchange broadcasts the withdrawal; attacker watches the mempool
- As soon as it appears, attacker rebroadcasts a malleated copy with a new txid
- The malleated copy gets mined; the original txid is now unfindable
- Attacker tells the exchange “my withdrawal never confirmed”
- Exchange, unable to find the original txid, resends — paying the attacker again
Notable Examples and Incidents
Mt. Gox (2014)
Mt. Gox famously blamed transaction malleability for the disappearance of hundreds of thousands of bitcoin, claiming attackers had used it to withdraw repeatedly. While later investigation showed the exchange had far deeper insolvency problems, transaction malleability was a real and actively exploited vector at the time, and the incident put the flaw on every developer’s radar.
Exchange Withdrawal Abuse
Multiple smaller exchanges reported repeated double-withdrawals attributable to malleability before SegWit fixed it. The standard mitigation was to track payments by output (address + amount) rather than by txid, but that was error-prone.
Multi-Signature (P2SH) Headaches
Malleability broke transaction chains — spending an unconfirmed output — because the child transaction references the parent’s txid. If the parent’s txid changed after malleation, the child became invalid. This made complex multi-signature contracts and the early Lightning Network impractical until SegWit landed.
How SegWit Fixed It
Segregated Witness (SegWit), activated on Bitcoin in 2017, solved malleability cleanly by moving the signature data (the “witness”) out of the part of the transaction that determines the txid:
- The txid now covers only the transaction’s inputs, outputs, and amounts
- The signature lives in a separate “witness” field that is not part of the txid
- Because signatures no longer affect the txid, no one can malleate a SegWit transaction’s identifier
SegWit transactions are therefore non-malleable, which is exactly what enabled the Lightning Network: payment channels rely on pre-signed transactions that must remain spendable later, so their txids must be stable.
Remaining Malleability on Legacy Outputs
Pre-SegWit (legacy and some P2SH-wrapped) outputs remain malleable today. Wallets that still create legacy transactions — or that build Lightning channels on non-SegWit outputs — are still exposed, which is why the Lightning Network mandates SegWit (and increasingly Taproot) addresses.
How to Protect and Understand Malleability
- Use SegWit or Taproot addresses. Any bech32 (bc1q…) or Taproot (bc1p…) address produces non-malleable transactions. Avoid legacy (starting with “1”) addresses for new activity.
- Track payments by output, not txid. If you build a payment system, key your records on the output script and amount, and reconcile by scanning the chain for matching outputs, not by looking up a single txid.
- Don’t chain unconfirmed transactions. Avoid building child transactions that spend outputs whose parent txid could change.
- On other chains, note that Ethereum’s account model is largely immune to malleability in this form because transactions are identified by sender + nonce and a signed hash, though signature-replay issues exist separately.
Frequently Asked Questions
Q: Can transaction malleability let someone steal my coins? A: Not directly. Malleability changes the identifier of a payment, not who receives the funds. The danger is indirect: it enables double-withdrawal fraud against services that rely on txids to confirm payments.
Q: Is Bitcoin still vulnerable to transaction malleability? A: Only legacy (pre-SegWit) transactions. SegWit and Taproot transactions are non-malleable. The vast majority of modern Bitcoin traffic uses SegWit or later and is not affected.
Q: Why didn’t the developers just fix signatures instead of inventing SegWit? A: Changing the signature format would have been a far more disruptive hard fork that broke existing transactions. Segregating the witness into a new field achieved non-malleability while keeping older transaction types compatible.