Major protocol upgrades, and how each one was adopted

The first consensus change after launch was the addition of the OP_RETURN opcode in 2010, which gave a transaction a defined way to carry data that is provably unspendable. Before it, the only way to embed data was to create outputs that could never be spent, which permanently added to the set of unspent outputs every node tracks. OP_RETURN replaced that practice with a form that nodes can discard.

Pay to Script Hash followed in 2012, specified as BIP 16. It allowed a payment to be sent to the hash of a script rather than to the script itself, with the script revealed only when the output is spent. The immediate benefit was a smaller on-chain footprint for complex spending conditions, and the longer-term benefit was that new script templates could be introduced without changing the consensus rules again. The address format that carries a script hash is still in wide use.

The most consequential early change was BIP 66, deployed in 2015, which tightened the rules for how a signature must be encoded. Some implementations had accepted signatures that were not strictly valid, and the divergence meant a block could be valid to one node and invalid to another. BIP 66 removed the ambiguity by requiring strict DER encoding. It was the first change deployed with a signalling threshold that miners had to meet, and the debate around it previewed the arguments that would follow over block size.

BIP 65, which made the CHECKLOCKTIMEVERIFY opcode available, was deployed in the same period. It gave a transaction the ability to specify that it could not be mined before a particular block height or time, which is the primitive behind time-locked refund paths and the payment channels that later became the Lightning Network.

Segregated Witness, BIP 141, activated in August 2017. It separated witness data from the bytes a transaction identifier is computed from, which removed transaction malleability, and replaced the one-megabyte block size limit with a weight limit that counts witness bytes at a discount. The SegWit page covers the mechanics; what matters here is that it was the first change deployed through the version-bits signalling mechanism described in BIP 9, and that its activation was the resolution of the block size argument rather than a separate event.

Taproot, specified across BIPs 340, 341 and 342, activated in November 2021. It introduced Schnorr signatures as an alternative to ECDSA, made a set of spending conditions indistinguishable from a single-key spend once revealed, and added a new output type. Like SegWit it was deployed through version-bits signalling, this time under the rules of BIP 8 as implemented in Bitcoin Core's Speedy Trial variant. The Taproot page sets out what it changed.

A published proposal is not a change to the network, and the list of proposals that were written, reviewed and never activated is longer than the list of those that were. Several have been discussed for years without reaching a state where the network would enforce them. Others were superseded by a different design before they could be deployed.

The clearest example is the family of proposals to raise the block size directly. Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited each proposed a larger block limit through a hard fork, and each gathered support without reaching the threshold needed to avoid splitting the network. The argument they represented is the subject of the block size debate page, and the outcome of the disagreement is the Bitcoin Cash fork.

Other proposals remain open questions rather than abandoned ones. Drivechains, covenant proposals such as CHECKTEMPLATEVERIFY, and various approaches to scaling through additional layers have all been specified and discussed. None has been deployed, and none should be described as a feature of Bitcoin. The honest statement is that they are proposals under consideration, and that the process for deciding whether to adopt them is the one described on the how BIPs work page.

The mechanism for activating a soft fork has itself changed over time. The earliest changes were deployed by a flag day: a block height was chosen in advance, and nodes were expected to have upgraded by then. That works when the change is uncontroversial and the upgrade window is generous, and it fails when a meaningful part of the network does not follow.

BIP 9 replaced the flag day with signalling. Miners set bits in the block header's version field to indicate readiness, and the change activated once a supermajority of blocks in a difficulty period had signalled. The mechanism gave the network a way to measure support before committing, and it is the subject of the version bits and soft-fork signalling page. Its weakness is equally important: a change that never reaches the threshold never activates, and there is no defined point at which the attempt is abandoned.

The pattern across all of these changes is the same. A proposal is written and reviewed, an activation mechanism is chosen, the network is given time to adopt it, and the change takes effect only when enough participants enforce it. No single party can force a consensus change on the network, and that is the property the whole process is designed to preserve.