Soft fork

Every upgrade bitcoin has actually shipped works this way. Making the rules stricter means an old node still accepts the new blocks, because they break none of the rules it knows about. The soft forks between April 2012 and November 2021 gave bitcoin script hash addresses, timelocks, SegWit and Taproot, and not one of them stranded a wallet.

How it works

A soft fork narrows the set of valid blocks, so everything the upgraded network produces was already legal under the previous rulebook.

The trick that makes this possible is that bitcoin's script language left doors open on purpose. Ten opcodes were defined as no-ops that succeed without doing anything, and outputs of a type nobody had defined yet were treated as spendable by anyone who could satisfy them. A soft fork walks through one of those doors: it takes something old nodes wave through and attaches a real requirement to it. OP_NOP2 became OP_CHECKLOCKTIMEVERIFY in December 2015 and OP_NOP3 became OP_CHECKSEQUENCEVERIFY in July 2016, and to a node from 2014 both are still no-ops in a script that still passes.

The consequence is a split in who does what. Un-upgraded nodes keep verifying every rule they know and stay on the same chain as everyone else. Upgraded nodes verify more. Miners are the group that actually has to move, because a miner who has not upgraded can build a block that upgraded nodes reject, lose the reward, and pull anyone following them onto a doomed branch.

That is why activation is the hard part rather than the code. If most hash power enforces the new rule, blocks that violate it are orphaned and the tightening sticks. If it does not, the network splits along a fault line the soft fork was designed to avoid. Bitcoin has tried several ways of establishing that majority: a supermajority count of block versions, the version bits scheme of BIP-9, the timeout options of BIP-8, and the three month Speedy Trial window used for Taproot.

A soft fork can also be undone in a way a hard fork cannot. Since the new rule is a restriction the old software never demanded, abandoning it puts everyone back on a chain that all versions still consider valid.

Why this matters when you buy bitcoin

The honest headline is that soft forks are the reason bitcoin upgrades have never cost ordinary holders anything.

There is no migration, no deadline, no announcement you can miss. Coins sitting at a P2PKH address created in 2013 are spendable today by the same key with the same software, and every soft fork since has been careful to keep it that way. Compare that with any other financial platform you use, and it is the single most underrated property of the system.

What you do notice is lag, and it lands at the edges. The protocol activates a new output type; wallets take a year to make it the default; exchanges take longer to let you withdraw to it; some never do. Among the exchanges we review, support for sending to bech32 addresses is now routine while support for bech32m Taproot destinations is still uneven, which is a four year lag on a change that was consensus law from day one. That gap, not the protocol, is what decides whether you can actually use a new feature.

The practical rule that follows is simple. Keep one address of an older type available for platforms that have not caught up, and check the withdrawal screen before you assume a format works. A rejected withdrawal address is annoying; a support ticket about one that was accepted and then failed is worse.

Pay to script hash, the soft fork that made multisig usable

P2SH is the earliest soft fork worth studying, because it shows the pattern in miniature.

Before April 2012, paying to a multisig arrangement meant the payer had to put the entire script in the output they were funding. That made the sender responsible for someone else's security policy, produced enormous outputs, and made a printed or spoken address impossible. BIP-16 replaced all of it with a 20 byte hash of the script, wrapped in an address beginning with the digit 3.

To a node running the old rules, the output script is a hash comparison that succeeds when the spender pushes matching data. To a node running the new rules, that pushed data is then executed as a script and must itself be satisfied. The new rule is strictly stronger, so old nodes accept every valid new spend, which is the definition of a soft fork.

Activation was messy in a way that has repeated ever since. A competing proposal, BIP-17, split developer opinion; the deadline slipped from February 1 to April 1, 2012; and miners signaled support by writing the string "/P2SH/" into the blocks they mined. Nearly every address beginning with 3 in existence, including the ones exchanges hand out for deposits, descends from that argument.

Soft fork vs BIP

A BIP is a document; a soft fork is a rule that nodes enforce. BIP-341 is a text file in a GitHub repository that anyone could have written, while Taproot is what became consensus law at block 709,632 on November 14, 2021. The distinction matters because most BIPs never activate, BIP-17 and the covenant proposals among them, and because a single soft fork often spans several documents at once, as SegWit did across BIP-141, BIP-143, BIP-144 and BIP-147. Saying a BIP number when you mean an activated rule is harmless in conversation and misleading when you are trying to work out what your node actually enforces.