BIP 66

BIP-66 tightened Bitcoin's signature encoding rules to require strict Distinguished Encoding Rules (DER) format. Activated as a soft fork in July 2015, its main aim was to stop Bitcoin's consensus rules from depending on how the OpenSSL library happened to read signatures. It also cut down one kind of transaction malleability, which the BIP lists as an added benefit.

The problem: before BIP-66, Bitcoin accepted any signature that OpenSSL accepted, and OpenSSL was loose. The same logical ECDSA signature could be encoded multiple ways - leading zeros, varying integer encodings, padded buffers. Each encoding parsed to the same actual signature, but the bytes differed, which meant the transaction's txid (computed over those bytes) differed.

This was a form of transaction malleability: someone could intercept a broadcast transaction, re-encode the signature in a different valid way, and rebroadcast with a different txid. The original sender's wallet would lose track of the transaction even though it eventually confirmed. Mt. Gox famously blamed malleability in February 2014 for the losses that ended the exchange, which it later put at about 850,000 BTC. Christian Decker and Roger Wattenhofer of ETH Zurich studied more than a year of network data and found no widespread use of malleability attacks before then. By their count, at most about 386 BTC could have been taken that way, from Mt. Gox or anyone else.

BIP-66's fix: require signatures to be in canonical DER format - one specific byte layout per logical signature. Anything else gets rejected by every node.

That closed off the encoding tricks. It did not stop every way of altering a signature. An ECDSA signature still verifies if its S value is swapped for its mirror image in the other half of the allowed range, so anyone relaying a transaction could turn a "low-S" signature into a "high-S" one and change the txid. BIP-66 left that alone. Bitcoin Core has refused to relay high-S signatures since version 0.11.1, but that is only relay policy. BIP 146, which proposed making it a consensus rule, was closed without being deployed. Some changes to a transaction's unlocking script also stayed valid.

The fix at the root came with SegWit, enforced from block 481,824 in August 2017. When a transaction spends SegWit outputs, its signatures sit in a separate witness section that the txid does not cover, so changing them no longer changes the txid. Transactions spending older, non-SegWit outputs remain malleable in principle. BIP-66 was a useful intermediate step.

BIP-66 reused the version-number switchover from BIP-34: once 950 of the previous 1,000 blocks were version 3, version 2 blocks became invalid. The BIP-9 version-bits mechanism came later, and its first deployment was the CSV soft fork of 2016 (BIP-68, BIP-112 and BIP-113).

Enforcement began on July 4, 2015. Shortly after, a small miner that had not upgraded produced an invalid block, and miners who were not fully validating extended it into a 6-block chain before the valid chain pulled ahead. How Bitcoin Works puts that fork alongside the other deep reorgs in Bitcoin's history.