How witness data enables blind forks. Counterintuitive, huh?
You cannot run the 2015 version of Bitcoin Core today. The software will compile, it will connect, it will sync the chain from genesis, it will validate every block it sees, and it will report itself as fully caught up. But it is not validating Bitcoin. It is validating a fiction.
The 2015 node does not know about SegWit. It does not know about Taproot. It does not know about the witness data that carries the signatures and proofs that authorize every modern spend. When it receives a block, its peers strip the witness data before transmission. The 2015 node sees the non-witness portion — inputs, outputs, versions, locktimes — and validates those perfectly. It does not see that the signatures are missing, because it has no field in which to look for them. It does not see that the authorization layer has been moved to a part of the block it has never heard of.
The node appears to work. It does work, in the narrow sense that it syncs without error. But it is not a full validator of the current chain. It is a blind validator. It validates the envelope and trusts someone else to validate the letter.
Consensus changes in Bitcoin are conventionally described as either soft forks or hard forks. The distinction is clean in theory. In practice, witness-based upgrades introduced a third category that the existing vocabulary cannot describe.
| Fork Type | Old Node Behavior | Network Effect | Security Effect |
|---|---|---|---|
| Soft Fork | Rejects new blocks | Network splits unless supermajority upgrades | Old nodes break explicitly |
| Hard Fork | Accepts new blocks but cannot validate new rules | No split, but new rules unenforced by old nodes | Old nodes are unaware of rule change |
| Blind Fork | Accepts new blocks but cannot see or validate consensus-critical witness data | No split; old nodes appear to work perfectly | Old nodes go blind — they validate a subset and trust the rest |
The blind fork is the mechanism that makes the 0.75 MB gap possible. Old nodes do not break. They do not split from the network. They do not show an error. They go blind — silently, invisibly, and permanently. The operator of a 2015 node believes they are running a full validator. They are running a blind validator. The network has changed what valid means, and the old node has no way to know.
The technical mechanism is the scriptPubKey format for witness outputs. To a pre-SegWit node, a Pay-to-Witness-Pubkey-Hash (P2WPKH) output encodes as the byte sequence 0 <20-byte-hash>. The old software pushes 0 and a 20-byte hash onto the stack. The script ends. The output resolves as anyone can spend — no signature required, no witness data consulted, no authorization checked.
To a post-SegWit node, the same output requires a witness structure containing a valid public key and a valid ECDSA signature. The node hashes the public key, compares it to the 20-byte hash, and verifies the signature against the transaction hash. If the witness is missing, malformed, or forged, the node rejects the transaction and the block containing it.
The same mechanism repeats with Taproot. A Pay-to-Taproot (P2TR) output encodes as 1 <32-byte-x-only-pubkey>. To a pre-Taproot node, this is a script that pushes 1 and a 32-byte value onto the stack and ends — again, anyone can spend. To a post-Taproot node, the witness must contain either a valid Schnorr signature for the internal key or a valid Merkle proof for the script path. Without the witness, the spend is unverified and the block is invalid.
The witness data is not optional metadata. It is the consensus-critical authorization layer. It proves who has the right to spend. Without it, the spend cannot be validated. And pre-witness nodes never receive it.
Old nodes do not break in a blind fork. They degrade. The degradation is not advertised. There is no error message. The operator of a 2015 node sees a node that is synced, connected, and validating. The operator does not see that the node is blind to the consensus rules that govern the majority of modern transactions.
The coercion is security-based, not technical. The old node becomes a liability to its operator. It would accept a block with forged witness signatures that the rest of the network rejects. It would continue building on a chain that post-witness nodes consider invalid. It cannot detect the fraud because the fraud lives in a field the node has no code to parse.
The practical defense is network topology — the majority of nodes are upgraded, so invalid blocks do not propagate. But the security model has fundamentally shifted. In pre-SegWit Bitcoin, any node from any era was a full validator of every rule. In post-SegWit Bitcoin, only nodes from the current era are full validators. Every blind fork narrows the set of full validators further. The network does not split. It stratifies.
The stratification is not theoretical. It is measurable on the live network. The following data is a snapshot of reachable Bitcoin nodes, categorized by the highest consensus rules each node can validate. The categorization is conservative: a node is "full" only if its software version unambiguously supports both SegWit and Taproot. A node is "partial" if it supports SegWit but not Taproot. A node is "blind" if it predates SegWit entirely. "Unknown" nodes report no user agent or run implementations whose consensus support cannot be determined from version strings alone.
| Validator Class | Software Era | Node Count | Share | Can Validate | Cannot Validate |
|---|---|---|---|---|---|
| Full | Core 0.21.1+ | ~17,300 | ~96% | Legacy, SegWit, Taproot | — |
| Blind to Taproot | Core 0.13.1–0.21.0 | ~200 | ~1% | Legacy, SegWit | Taproot |
| Blind to SegWit + Taproot | Core 0.12.x and earlier | ~12 | ~0.07% | Legacy only | SegWit, Taproot |
| Unknown | Custom / unreported | ~450 | ~2.5% | Unknown | Unknown |
The 12 nodes running pre-SegWit software are the most obviously blind. Released before November 2016, they have no code to parse the witness field. They see every SegWit output and every Taproot output as anyone can spend. They would accept a block containing a transaction that forges the witness data for a SegWit UTXO. They would accept a block containing a transaction that forges the witness data for a Taproot UTXO. They have no mechanism to detect either fraud.
The 200 nodes running pre-Taproot software are also blind. They validate SegWit witness data, but they see Taproot outputs as anyone can spend. They would accept a block with forged Taproot witness data. They are running software released between November 2016 and November 2021 — the SegWit-only era. The distinction between "partial" and "blind" is cosmetic. A node that cannot validate Taproot is not a partial validator. It is a blind validator with a narrower blind spot. The blind spot is the only thing that matters: a forged Taproot spend looks valid to these nodes, and they have no mechanism to detect the fraud.
The chart shows the network as a stack of validation capability. The gold band at the top is the full validators — the only nodes that can see and validate every consensus rule currently in force. Below them, in progressively darker bands, are the blind validators. The pre-Taproot band is blind to Taproot but can still validate SegWit. The pre-SegWit band is blind to both. The point is not the thickness of each band. The point is that the bands exist at all. The point is that the mechanism that created them is intentional, repeated, and permanent.
Each witness-based upgrade adds a new layer to the stack. The layers do not replace each other. They accumulate.
SegWit (August 2017): Introduced the witness field. Pre-SegWit nodes went blind to P2WPKH and P2WSH outputs. They see these as anyone can spend. They always will.
Taproot (November 2021): Introduced P2TR outputs and Schnorr signatures in the witness. Pre-Taproot nodes went blind to Taproot spends. They see P2TR as anyone can spend. They always will.
The next blind fork: Will introduce new witness-based rules — perhaps CHECKTEMPLATEVERIFY, perhaps quantum-resistant signatures, perhaps a new script version. Post-upgrade nodes will validate the new witness data. Pre-upgrade nodes will not. They will see the new outputs as anyone can spend. They always will.
The blindness is permanent and irreversible. A node does not accumulate validation capability over time. It accumulates blindness. The 2015 node is blind to SegWit, blind to Taproot, and will be blind to every future witness-based upgrade. The 2020 node is blind to Taproot and will be blind to every future upgrade. Only the latest software version sees everything.
This is the opposite of the pre-SegWit security model. Before 2017, any node from any era was a full validator of every rule. After 2017, the full validator is a moving target. The security model shifted from "any node validates everything" to "only the current node validates everything."
The original Bitcoin security model was simple: run a full node, validate every rule, trust no one. The full node was the root of security. It was the check against miners, against fraud, against consensus drift. The full node was the final arbiter of what Bitcoin is.
After the blind fork, the full node is version-dependent. A full node is not a full node unless it is the latest version. A full node from last year is a blind node today — blind to Taproot and to every future witness-based upgrade. A full node from five years ago is a blind node too — blind to SegWit, blind to Taproot, and blind to everything that comes next. The security model is no longer "run a full node." It is "run the latest full node, and keep upgrading forever."
This is not an accident. It is the intended behavior of the blind fork mechanism. Old nodes do not break — they become security liabilities. The operator must upgrade to maintain full validation. The upgrade is not optional. It is coerced by the progressive blindness of the old software.
The coercion is gentle. There is no deadline. There is no hard cutoff. The node still syncs, still connects, still appears to work. The operator is not forced to upgrade by an error message. The operator is forced to upgrade by the invisible degradation of what their node can actually verify. The node is a full node in name only. In practice, it is a blind node that has not been told it is blind.
The blind fork is the mechanism. The 0.75 MB gap is the effect. The Landauer gap is the cost.
The 0.75 MB Gap shows that the witness discount makes it economical to fill the chain with data the fee market does not price. The blind fork is what makes that discount possible: by moving the authorization layer into a field that old nodes cannot see, the protocol created a space where bytes can be stored at a quarter of their cost. The old nodes are blind to the data. The new nodes are blind to the cost. The gap is the difference.
The Landauer Gap shows that every byte the chain commits is a thermodynamic debt — a cost of persistence that must be paid by someone. The blind fork externalizes that debt to the nodes, just as the witness discount externalizes it to the fee market. The old nodes pay the persistence cost without being able to validate what they are persisting. The new nodes validate what they do not fully price. The debt accumulates in the gap between validation and cost.
Together, the three articles describe a single transformation: the shift from a network where every node validates everything to a network where validation is stratified, cost is hidden, and permanence is subsidized by the very operators who bear its weight. The blind fork is the lever. The 0.75 MB gap is the load. The Landauer gap is the physics that makes the load real.
Each blind fork narrows the set of full validators. The effect is not immediate. It is cumulative. The long-term consequences are not theoretical. They are structural.
Validation centralization. Eventually only the latest software release validates every rule currently in force. The core development team does not control the network — but they are the sole source of full-validation capability. Every node operator who wants full validation must accept their release schedule, their code review process, and their feature priorities. The validator is no longer sovereign. The validator is a subscriber.
The upgrade treadmill. "Run a full node" was the security model. The blind fork changed it to "run the latest full node, and keep upgrading forever." Stop upgrading for one cycle and you go blind. The coercion is not announced by an error message. It is announced by the silent accumulation of transaction types you cannot validate. The treadmill has no off switch.
Chain bloat acceleration. Each blind fork adds new witness features. The witness discount makes witness data artificially cheap in block-weight terms. The incentive to store non-monetary data in the witness grows with each upgrade. The raw byte growth of the chain outpaces its value-mass growth. The 0.75 MB gap widens. The Landauer debt compounds.
Historical integrity erosion. A node from 2015 can still validate pre-2015 blocks perfectly. But it cannot validate post-2017 blocks fully, because it cannot see the witness. The promise that anyone can "verify the entire chain from genesis" is technically broken — you need modern software to verify modern history. The historical record is version-dependent.
Economic stratification. Full validation becomes a privilege. Operators with limited bandwidth, old hardware, or restricted software access fall behind and become blind validators. The network stratifies into those who can afford full validation and those who cannot. The "anyone can verify" property — one of Bitcoin's original value propositions — becomes "anyone with the latest software can verify."
Consensus fragility. Blind nodes cannot detect exploits in the transaction types they are blind to. The defense that "the majority is upgraded" assumes the majority stays upgraded. It assumes no bug in the new witness logic goes undetected because the validating minority missed it. The blind validator is not a safety net. It is dead weight in a crisis.
Permissioned verification. The original Bitcoin value proposition was permissionless verification: anyone could download the software, sync the chain, and validate every rule. Blind forks progressively remove this property. Verification becomes permissioned by software version. You need the latest release to have full verification rights. The kid who sees the Emperor is naked needs the latest binary.