Soft Forks & the "Anyone-Can-Spend" Trick

How do you upgrade a decentralized system with no admin, no version server, and millions of nodes run by people who may never update — without splitting the network in two? Bitcoin’s answer is one of the most elegant ideas in the whole protocol, and almost no one outside core development understands the mechanism. It hinges on a deliberately-chosen asymmetry between two kinds of rule change.

Hard fork vs soft fork: the key asymmetry

HARD FORK  — LOOSENS the rules                SOFT FORK — TIGHTENS the rules
(makes previously-INVALID things valid)       (makes previously-VALID things invalid)

old nodes REJECT the new blocks               old nodes still ACCEPT the new blocks
→ network SPLITS into two chains              → network stays UNIFIED
→ requires EVERYONE to upgrade                → only a miner majority must upgrade
  e.g. raising the block size limit             e.g. SegWit, CLTV, Taproot

The insight: if a rule change only tightens what’s allowed, then every new, valid-under-new-rules block is also valid under the old rules — so un-upgraded nodes happily follow along, none the wiser. A soft fork is backward-compatible; a hard fork is not. Bitcoin upgrades almost exclusively via soft forks precisely to avoid forcing a coordinated flag-day on the entire world.

But this raises a puzzle: how do you add a brand-new feature (which sounds like loosening) using only tightening?

The “anyone-can-spend” trick

The answer is a gorgeous piece of misdirection. You hide the new feature inside something old nodes consider trivially spendable, then have upgraded nodes enforce extra rules on it.

To an old node, a SegWit output looks like an output that anyone can spend — its script places data on the stack and leaves a true-ish result, no real signature required. An old node thinks: “weird, but valid; anyone could claim this.” It will accept a block containing such a spend.

New nodes know better. They interpret that same output as a SegWit program and demand a valid witness (signature). So the new rule is purely a restriction: “this anyone-can-spend output actually requires a proper signature.” That’s a tightening — a soft fork — yet from the user’s perspective an entirely new capability appeared.

        The SAME output on the chain:

OLD node:  "anyone-can-spend — looks valid, I'll accept it"     (sees less, stays compatible)
NEW node:  "this is SegWit — REQUIRES a valid witness signature" (enforces the real rule)

Result: new feature deployed, old nodes never split off.

The safety condition: a miner majority

The trick only stays safe if a majority of hash power enforces the new rules. If most miners didn’t, someone really could spend those outputs as “anyone-can-spend” and steal funds, and old nodes would accept it. That’s why soft forks ship with activation mechanisms (BIP 9 version-bit signaling, BIP 8, and the “Speedy Trial” used for Taproot) that confirm sufficient miner adoption before anyone relies on the new rules. Activation is a social/coordination process bolted onto the technical trick.

This single pattern is how P2SH (2012), SegWit (2017), and Taproot (2021) were all deployed — each dressed up as something older nodes saw as benign.

Storing data in transactions: OP_RETURN

People quickly wanted to embed arbitrary data (timestamps, proofs, asset metadata) in the chain. The naïve way — stuffing data into fake output addresses — is actively harmful: those outputs are indistinguishable from real coins, so they get stuck in the UTXO set forever (see UTXO set vs chain), bloating the one data structure every node must keep.

OP_RETURN is the sanctioned alternative: an opcode that marks an output as provably unspendable.

OP_RETURN <arbitrary data>
   │
   └─ provably unspendable → nodes can SKIP it in the UTXO set → no permanent bloat

Because an OP_RETURN output can never be spent, nodes don’t have to track it in the UTXO set — the data lives in the (prunable) block history instead of the (forever) chainstate. It’s the polite way to write data to Bitcoin. (The size cap was always a relay-policy choice, not consensus: nodes long defaulted to ~80 bytes per OP_RETURN, until Bitcoin Core 30 in late 2025 raised the default to effectively unlimited — a hotly contested change.)

Witness data & inscriptions (Ordinals)

Here’s a rare, current twist that ties several threads together. SegWit moved signatures into the witness, and Taproot relaxed limits on what witness scripts can contain. Inscriptions (Ordinals, 2023) exploit this: they embed arbitrary content — images, text, even small programs — inside the witness data of a Taproot script-path spend, where it’s comparatively cheap thanks to the SegWit witness discount (witness bytes count as ¼ toward block weight).

This produced genuinely new phenomena and controversy:

• It works without any new opcode — it’s a creative use of existing Taproot script rules, not a feature anyone designed for it.
• The “ordinal theory” overlay assigns a serial number to every individual satoshi (by mining order), letting people treat specific sats as collectible NFTs — a convention layered on top of Bitcoin, enforced by software, not by consensus.
• It reignited an old debate: is putting JPEGs in blocks legitimate use of paid block space, or spam? Either way, it’s a vivid lesson that what people do with a protocol is not limited to what its designers intended — and that fee-paying demand, not gatekeeping, is what ultimately rations the chain.

It actually happened — the accidental fork of March 2013

Soft forks are engineered compatibility; the flip side is what happens when two versions disagree by accident. In March 2013, a block produced by the new Bitcoin 0.8 was rejected by 0.7 nodes, which hit an undocumented BerkeleyDB lock limit that 0.8 no longer had. For about six hours the network ran on two chains at once — a real, unplanned chain split, with at least one opportunistic double-spend against a payment processor. The fix wasn’t code; it was coordination: developers and miners agreed over IRC to have the upgraded miners downgrade back to 0.7, abandoning the longer 0.8 chain so the whole network reunited on rules everyone could enforce. It’s the cautionary twin of the anyone-can-spend trick: a consensus rule isn’t what the spec says, it’s what the software actually does — and getting two implementations to agree bit-for-bit is brutally hard. (Documented afterward in BIP 50.)

The thread

How does this help untrusting strangers agree on one ledger? Soft forks let strangers upgrade the rules of agreement without ever having to agree to upgrade in lockstep — old and new software keep sharing one chain. And the data-storage story (OP_RETURN, witness discount) is the ongoing negotiation over what the shared ledger is for: every byte is a scarce, permanent, globally-stored resource, so the protocol’s job is to price and shape that demand rather than to forbid it.

The architect’s lens

The soft-fork machinery is a deliberate asymmetry — interrogate why Bitcoin upgrades almost only this way:

• Why does it exist? To upgrade a leaderless network of millions of never-updating nodes without splitting it — by only ever tightening the rules, so a block valid under the new rules stays valid under the old ones and un-upgraded nodes follow along, none the wiser.
• What problem does it solve? Shipping new features with no flag-day. The anyone-can-spend trick hides a feature inside an output old nodes see as trivially spendable, while new nodes enforce the real witness requirement — a pure restriction. OP_RETURN solves data storage without UTXO-set bloat by marking outputs provably unspendable.
• What are the trade-offs? Safety hinges on a miner majority enforcing the new rule (otherwise those outputs really could be spent as anyone-can-spend and stolen), so activation needs signaling mechanisms (BIP 9, BIP 8, Taproot’s “Speedy Trial”) bolted on as a social process.
• When should I avoid it? It’s structurally impossible for any change that must loosen the rules — raising the block-size limit makes previously-invalid blocks valid, which only a hard fork (and a coordinated worldwide upgrade) can do.
• What breaks if I remove it? Every upgrade becomes a hard fork forcing a global flag-day, so in practice the rules freeze — no P2SH, SegWit, or Taproot — because getting millions of independent node-runners to agree bit-for-bit in lockstep is effectively impossible (see the March 2013 accidental split).

Check your understanding

1. State the precise rule that distinguishes a soft fork from a hard fork, in terms of loosening vs tightening. Which one splits the network?
2. How can adding a brand-new feature be implemented as a restriction? Walk through the anyone-can-spend trick from both an old and a new node’s view.
3. Why does a soft fork’s safety depend on a miner majority, and what mechanism confirms that before activation?
4. Why is OP_RETURN the responsible way to store data, compared with encoding data in fake output addresses?
5. How do inscriptions store data without a new opcode, and why does the witness discount make it attractive?

Show answers

1. A soft fork only tightens the rules (makes previously-valid things invalid), so new blocks stay valid under the old rules and old nodes follow along — the network stays unified. A hard fork loosens the rules (makes previously-invalid things valid), so old nodes reject the new blocks and the network splits. The hard fork is the one that splits.
2. You hide the feature inside something old nodes consider anyone-can-spend, then have upgraded nodes enforce an extra restriction on it. From an old node’s view a SegWit output is trivially spendable (data on the stack leaving a truthy result), so it accepts the spend; a new node interprets it as a SegWit program and demands a valid witness signature. Adding the requirement is a tightening, yet a brand-new capability appears.
3. If most miners didn’t enforce the new rules, someone could really spend those “anyone-can-spend” outputs and steal funds, and old nodes would accept it — so safety needs a miner majority enforcing the restriction. Activation mechanisms (BIP 9 version-bit signaling, BIP 8, and Taproot’s “Speedy Trial”) confirm sufficient miner adoption before anyone relies on the new rules.
4. OP_RETURN marks an output as provably unspendable, so nodes can skip it in the UTXO set — the data lives in the prunable block history instead of the forever chainstate. Encoding data in fake output addresses is harmful because those outputs are indistinguishable from real coins and get stuck in the UTXO set forever, bloating the one structure every node must keep.
5. Inscriptions embed content in the witness data of a Taproot script-path spend, using existing Taproot script rules — no new opcode designed for it. The witness discount (witness bytes count as ¼ toward block weight) makes storing that data comparatively cheap, which is why it became attractive.