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 <up to ~80 bytes of 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 byte cap is a relay-policy choice intended to discourage abuse.)

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.

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.

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?