SegWit: soft fork by classification, hard fork by function

What SegWit changed

BIP 141 moved transaction signatures — the "witness" — out of the transaction body committed to the block's Merkle tree, and into a separate structure that legacy nodes do not read. A SegWit output's script uses a template recognisable to SegWit nodes as a witness program; to a pre-SegWit node, that same script executes as one that leaves a non-zero value on the stack, which the pre-SegWit rules treat as valid without demanding a signature. The pre-SegWit node accepts the transaction. It has no idea a signature was supposed to exist elsewhere.

That is the mechanism by which SegWit qualified as a soft fork under the standard definition. Old rules are strictly tightened, not loosened; every SegWit-valid block is also a legacy-valid block. Legacy miners can even build on top of SegWit blocks. Nothing crashes.

What legacy nodes lost

Before SegWit, a Bitcoin full node did one thing that mattered: it independently verified every signature on every transaction in every block. That verification is what made a full node trustless — the node's operator did not have to believe anyone else about whether a coin's history was valid, because the node checked it.

After SegWit, a legacy node accepts SegWit blocks — as the soft-fork property requires — but cannot access the witness section where SegWit signatures live. It therefore accepts the transaction without verifying its signature. Its security model has been changed from trustless verification to trust that the SegWit majority is honest — which is the model of a lightweight (SPV) wallet, not a full node. The change happened without any action on the node operator's part; the software they were running did not become invalid, it became functionally reduced.

The whitepaper's definition, and what happened to it

Section 2 of the Bitcoin whitepaper defines an electronic coin as "a chain of digital signatures". Each owner transfers the coin by signing a hash of the previous transaction and the public key of the next owner. "A payee can verify the signatures to verify the chain of ownership." That last clause is the operational content of the definition: what makes something a Bitcoin transaction, in the whitepaper's terms, is that any payee can independently verify its signature.

For legacy nodes running the pre-SegWit rules, that property no longer holds for SegWit-era transactions. The signature exists on the network, but not in a form the legacy node can see. The historical ledger stored on that node will contain permanent blind spots for every SegWit-era signature — regions of the record it cannot retroactively audit. Whether the whitepaper's definition still describes the chain from the perspective of a legacy node is a judgement. Whether the whitepaper's definition was quietly changed is not: it was.

Why the miners activated it

SegWit was deployed under BIP 9, which required 95% of miners over a 2016-block window to signal support. Through the first half of 2017, signaling stalled at around 30%. Most miners preferred the block-size scaling path.

A coordinated group of node operators responded with BIP 148, a "User Activated Soft Fork" that flipped the incentive: starting 1 August 2017, BIP 148 nodes would refuse — and orphan — any block that did not signal SegWit. A miner not signaling would produce blocks that BIP 148 nodes would reject, splitting the network and destroying that miner's block subsidy on the majority chain. UASF was described by its opponents as coercion; it was also described by its supporters as coercion (see the Bitmain UAHF contingency-plan post from June 2017). Miners signalled SegWit under that threat.

Activation is a fact, not a judgement. Whether an activation forced under economic threat is meaningfully different from an activation that had 95% organic support is a question that got much less coverage than it deserved. On the site's reading, an activation that had to be coerced by threatening to destroy the block subsidy of non-compliant miners was not the coordinated upgrade a hard fork's critics say soft forks avoid.

Why 95% at all — the threshold is the tell

The 95% miner-signal threshold in BIP 9 is itself evidence that SegWit was not a soft fork in the orthodox sense. A true soft fork — one that only tightens rules, so old nodes still accept new blocks — does not need a supermajority to deploy safely. Compare with the closest analogues in Bitcoin's own history: P2SH (BIP 16) activated at a 55% miner threshold; CLTV (BIP 65) and CSV (BIP 68/112/113) at similar low thresholds. Nobody demanded 95% for those. A minority producing "old-style" blocks would just find them accepted by everyone and built on normally — no split risk to defend against.

SegWit needed 95% because after activation the rule enforced by upgraded nodes is stricter than "old blocks still valid": every block must commit to the witness Merkle root in the coinbase. Legacy blocks lack that commitment. Post-activation, upgraded nodes reject them. That is a hard-fork rule change — it invalidates blocks that were valid ten minutes earlier under old rules. The 95% threshold is not there to make the fork soft. It is there to make sure the minority producing the invalidated blocks is small enough that their orphaned-from-the-majority-chain hashpower dies before it becomes an economically viable chain of its own.

BIP 148 is the belt-and-braces companion move. You do not need a threat mechanism to deploy a real soft fork; you need one to force through a change that would otherwise produce a live split. If the 95% miner threshold looked shaky, user nodes would orphan non-signalling blocks directly. That coerces miners into signalling, and the split never becomes visible. The whole apparatus — supermajority threshold plus UASF backstop — was designed for the specific problem of deploying a hard-fork-in-mechanism as if it were a soft fork. If it were truly backward-compatible, none of that coordination overhead would be needed.

So the honest read: SegWit required a supermajority not because it was safe as a soft fork, but because it was unsafe as anything else, and the supermajority requirement was the only way to prevent the split from being visible.

The naming decision that followed

Classifying SegWit as a soft fork carried an operational consequence beyond the technical description. A hard fork produces a chain divergence that requires the market to decide which chain inherits the name. A soft fork, by construction, does not — the activation stays on the pre-existing chain, and the pre-existing ticker follows. So the classification decided the naming outcome. Under a functional definition of "hard fork" — one that asks whether legacy validation survives, not merely whether legacy software crashes — SegWit would have been the fork requiring a new ticker, and the chain running the block-size scaling path would have inherited BTC.

That is what the naming asymmetry documented elsewhere in the Journal comes down to on the mechanics. The event that inherited the ticker changed what a Bitcoin transaction is, and the event that did not inherit the ticker changed the number of bytes a block can hold. Which of those describes a larger departure from the pre-2017 protocol is, on the mechanics, not close.

What the counting rule does with this

Neither of these arguments changes what the counting rule counts. Both chains have their own base-layer blockchain and their own consensus mechanism; both are counted. Both are Bitcoin lineages that took different upgrade paths from the same pre-2017 protocol.

Where the site does have a position: the "soft fork" classification of SegWit is accurate as a description of what legacy nodes did not do (they did not crash), and misleading as a description of what SegWit actually was (a change to the whitepaper's operational definition, forced by economic threat, that inherited the ticker as a consequence of its own classification). If a soft fork can do all that, "soft" was doing a lot of quiet work in the name.

Whitepaper Section 2 and the BIP documents linked above are the primary sources. Activation dates, signaling numbers and the UASF/Bitmain sequence are read from the historical record. This post argues about mechanics and framing, not figures — it does not carry a data stamp.