Transaction malleability

Also called: malleability, txid malleability, tx malleability, signature malleability.

Transaction malleability is the ability to change a transaction's ID without changing what it does, for example by re-encoding its signatures.

Transaction malleability means a transaction can be altered so that its txid changes while it still spends the same coins to the same outputs. Before SegWit, signatures were part of the data hashed into the txid, and a signature can be written in more than one valid form. Anyone relaying a transaction could change that form, producing a different txid for an equivalent transaction, and either version might be the one that confirms.

Why malleability was a problem

The payment itself was safe, but anything that referred to the original txid broke. Wallets could lose track of their own payments, and protocols that pre-sign a child transaction spending an unconfirmed parent, such as payment channels, could be left with a refund that points to a parent that never confirms. In 2014 the exchange Mt. Gox cited malleability when it halted withdrawals.

How it was fixed

Bitcoin closed the gaps step by step:

• BIP 62 catalogued the sources of malleability and proposed a rule for each; it was later closed, as SegWit solved the problem more thoroughly.
• BIP 66 made strict DER signature encoding a consensus rule (block 363,725, July 2015).
• BIP 146 proposed low-S signatures and NULLFAIL, and BIP 147 required the dummy element of CHECKMULTISIG to be empty (NULLDUMMY).
• BIP 141 moved signatures into the witness, which the txid doesn't cover. Once every input is a signed SegWit input, third parties can't change the txid at all.

Fixing malleability is what made the Lightning Network practical, and Tapscript closes further gaps by making MINIMALIF a consensus rule. See the malleability topic for every related BIP.