DEVIANT · The Block Size Wars 

Deviant

Companion extract · The block-size conflict

BSW 
The Block Size Wars. 

How the consensus broke, and what each chain became.

The social, political, and protocol-level conflict over Bitcoin's block-size limit — from the 2015 suppression of on-chain-scaling proposals to the August 2017 chain split and the divergences that followed.

For: Sophisticated readers and historical analysts 
Date: May 2026 
Status: Extract / working draft — expansion in progress 

The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
— Bitcoin whitepaper, §11 

A protocol is a specification; a chain is an implementation. The block-size war was the conflict over which of those two would govern the other. This document collects the war chronology and its protocol consequences, extracted from Vol.13 — Bitcoin Discovery for focused expansion. The conclusions about who did what, and why, are left to the reader.

On provenance and section numbering

This document is extracted from Vol.13 — Bitcoin Discovery and retains that volume's original section numbering (III, IV, V, …) so that cross-references remain stable against the parent text. Cross-references to sections not reproduced here — for example Section I (the whitepaper specification), Section II (pre-conflict consensus, 2009–2014), or Section IX (derivatives and leverage) — point to the parent volume. The material reproduced here is the war spine and its immediate protocol consequences; additional material is being added to this document directly.

On this front arc

Sections A–H below are original to this document — the why behind the chronology and the what each side was defending. They precede Vol.13's Section III and leave its numbering unchanged. As throughout this volume, the documented facts and the mechanism are given; the attribution of motive is left to the reader.

A · The premise

The vector the security model leaves open.

The epigraph above sorts the world into honest nodes and attacker nodes and locates safety in the ratio of power between them — as if honesty were a fixed trait of a miner. The whitepaper says otherwise four sections earlier: nodes are honest because honesty pays (§6 — "He ought to find it more profitable to play by the rules…" ). Honesty here is not a virtue. It is a behavior produced by an incentive — and an incentive can be bought.

That is the door the model leaves open. An adversary with sufficient capital need not assemble attacker nodes, and need not corrupt a single miner's character. He reshapes the incentive field itself — the price, the mining profitability, the story told about what the asset is — one layer above the protocol, in the economy the protocol cannot see. Honest, profit-following miners then flow toward his preferred chain, behaving exactly as the design instructs, while serving an end the design never modeled. There is no "cooperating group of attacker nodes" to out-power. There is honest hashpower, captured from outside. 

The miners are the medium of such an attack, not its agent . They do not choose dishonesty; the party who engineers the incentive field does. The protocol performs exactly as specified. The contest is decided one layer up — in the incentive-formation layer the security model treats as a given rather than as terrain. That layer is the subject of this document.

B · The warning

Satoshi's last public messages.

Satoshi's final public messages, December 2010, warned about exactly this exposure: premature attention. In the thread on WikiLeaks adopting Bitcoin —

No, don't "bring it on". … Bitcoin is a small beta community in its infancy. … the heat you would bring would likely destroy us at this stage.
— Satoshi Nakamoto, 5 December 2010 

It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.
— Satoshi Nakamoto, ~12 December 2010 (last public post) 

The stated concern is timing and scale: Bitcoin needed to grow gradually , so the system could be strengthened along the way, before it drew the attention of powerful adversaries. The reasonable reading — left to the reader — is that Satoshi wanted organic, utility-driven adoption ahead of speculation : a thing not yet rooted in use is a thing whose properties can be reshaped before it can defend them.

On the limit of this inference

Satoshi did not name futures, leverage, or stablecoins — those instruments existed for commodities but not yet for Bitcoin. That he understood the general mechanism of financialization is well-grounded from the design (Section D); that he foresaw the specific later operationalization against Bitcoin is the reader's to weigh.

C · From warning to hash war

Miner incentives, and why hashpower is not the threat.

A compressed arc from the warning to the splits: (1) the warning (2010) — grow gradually, adoption not speculation; (2) the ideological split (2014–2017) — one faction defends the 1 MB cap and routes scaling off-chain, the other holds to on-chain scaling (the chronology is Section III); (3) the chain split (August 2017) — Bitcoin Cash forks to preserve on-chain payments; (4) the hash wars (2018, 2020) that tested the surviving chain (Section E).

Miner incentives — the reasoning. A miner is a profit-follower (§6). Bigger blocks → more transactions → more fee revenue → a rational reason to back on-chain scaling. The Emergency Difficulty Adjustment period of late 2017 is the documentary proof that the same SHA-256 miners moved hashpower onto Bitcoin Cash whenever it was profitable — blocks were mined far faster than schedule during the influx. Miners allocate power where it pays and provide it to the chain when it is needed; they did not abandon it.

Why the hashpower vector is not the one to fear. The cheap zero-confirmation double-spend fails by design — first-seen-safe, no RBF, Double-Spend Proofs (demonstrated empirically: a same-node conflict is rejected as a mempool conflict; a two-node race resolves to exactly one winner, with the conflicting transaction dropped). A confirmed reversal requires majority hashpower — the explicit §6/§11 model, economically gated, not impossible : it has occurred only where hashpower was cheap (Ethereum Classic, Bitcoin Gold, and Bitcoin Cash's own May-2019 reorg) and never on a high-hashpower chain in fifteen years. The residual — a subsidized reorg — is bounded by scaling settlement confirmations to value. Hashpower is a tail risk on large settlements, not the primary vector. On this axis the network is battle-tested .

D · Scarcity

Four anchors: the design understood the disease.

You cannot program scarcity as a remedy without understanding the disease it remedies. The design is itself the evidence; four primary sources make it documentary.

The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust.
— Satoshi Nakamoto, P2P Foundation, February 2009 

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.
— Headline embedded in the genesis block (block 0) coinbase 

As a thought experiment, imagine there was a base metal as scarce as gold but … with one special, magical property: can be transported over a communications channel.
— Satoshi Nakamoto, bitcointalk, 27 August 2010 

The steady addition of a constant amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.
— Bitcoin whitepaper, §6 

Programmed scarcity was built because trust-based supply gets debased. That is the property everything below concerns.

E · Three splits, one survivor

What the original roadmap survived.

The original-roadmap chain has been forked from three times and has retained the roadmap each time.

BTC (August 2017). The 1 MB-blocker chain; on-chain payments progressively removed (RBF, SegWit, Lightning as the substitute) and the asset reframed as "digital gold — hold, don't spend" (Sections F–G).

BSV (November 2018). The "Satoshi Vision" identity claim. As documented in Section XII, its published positions on trusted third parties, privacy, reversibility, censorship, and law each diverge from the whitepaper. A failed identity claim — neither what the whitepaper specifies nor widely perceived as such — and marginalized.

eCash / XEC (November 2020). The Infrastructure Funding Plan proposed a consensus rule diverting part of the coinbase to a whitelist of developer-funding addresses — a protocol-enforced tax with a privileged recipient. The community rejected it; the centralizing faction forked off as eCash; Bitcoin Cash kept the chain, hashpower, name, and community. Read correctly this is an immune response : a centralization vector, attempted from inside, visible and on-chain , rejected by consensus.

A charitable counterweight, and a double standard

The IFP tried to solve a real problem — decentralized development funding — with a centralizing mechanism; the community rejected the mechanism, and the problem itself remains open. The BTC community used the split as "Bitcoin Cash keeps splitting → failure." Yet BTC's own developer funding is concentrated off-chain (BitMEX Research, 2020: of 33 Core developers, only 11 independent; the rest funded by Blockstream, Chaincode, MIT DCI, Brink and similar). Bitcoin Cash's centralization attempt was forced into the open and defeated by consensus ; BTC's was never put to a vote it could lose. The attribution of intent is left to the reader; the asymmetry is in the record.

The splits were costly — brand confusion, lost mindshare — but the roadmap survived all three. Resilience demonstrated under repeated attack : battle-tested, not immune.

F · The vectors that remain

Ideological subversion, synthetic price, and the counterfeit of scarcity.

Two live vectors remain — and they are one apparatus .

1 · Ideological / informational subversion. Media capture, venue control, and the "dead coin / fork that lost" framing (documented across Section III and Vol.14). Bitcoin Cash is inoculated, not immune : a community with a fixed, explicit roadmap is harder to capture by the same narrative twice, because the narrative has a fixed referent to check against. The residual is the persistent "failed / copy" frame.

2 · Price speculation via synthetic ("counterfeit") market tools. Futures, margin, options, and leverage are centuries old and have a documented history of managing commodity prices — the London Gold Pool, the Hunt silver corner, and most concretely JPMorgan's ~$920M CFTC spoofing settlement (2020) , the largest on record. These instruments did not exist for Bitcoin until later; the category, and its effect, predate it.

The synthetic-market problem. A paper claim on a commodity is a synthetic unit treated as the real thing. When paper claims exceed the physical base, price is discovered in the paper market — which can be expanded at will. That is counterfeiting scarcity: the same disease (inflatable supply) that programmed scarcity was built to cure, re-applied from outside. The Bitcoin instance is documented — the Federal Reserve Bank of San Francisco's study of CME futures (the December-2017 launch coincided with the all-time top, consistent with futures opening the short side), and the Tether layer detailed later in this volume (the CFTC found USDT backed only 27.6% of days; an insider warned that exposing it as unbacked could send "BTC … below 1k" ).

On the strength of the claim

The maximal "the metal price is permanently suppressed" thesis is contested in mainstream economics. The specific manipulation cases and the leverage ratios are documented facts — those are what is relied on here.

Why the two vectors are one move. A commodity used as money resists paper suppression better than one only held — mechanically:

Utility creates demand for the real unit. You need actual coins to transact; that demand drains the paper game and forces physical price discovery. A hold-only asset can be held entirely as paper — which is precisely the condition that lets synthetic supply set the price.

So "digital gold — hold it, don't spend it" is not only narrative capture. It is structurally the thing that makes the asset suppressible — it converts the coin into the hold-only, paper-friendly form, the way gold is held. The narrative (vector 1) reshapes the asset into the form the instruments (vector 2) can control. One apparatus, aimed at one property.

That a synthetic claim can never equal the asset it stands in for — that paper is not gold, a derivative is not the coin, a layer-2 balance is not the chain — is one structural argument with many targets. It is developed in full, project-agnostically, in the companion reference The On-Chain-Only Design Philosophy (the gold-standard parallel, §II).

G · Two views of the coin

What each side was defending.

Reduced to its root, the war was between two definitions of what a bitcoin is for . These were the two ideological splitting points: the RBF/SegWit path (hold — use less) against the Bitcoin Cash path (use fully on-chain — useful) .

Dimension 
View 1 — Hold (store of value) 
View 2 — Use (electronic cash) 

Slogan 
"Digital gold. Don't spend it." 
"Peer-to-peer cash. Use it." 

Protocol path 
1 MB cap · RBF · SegWit · Lightning 
On-chain scaling (whitepaper roadmap) 

Behavior produced 
Hold-only → paper-friendly 
Transact → demand for real coins 

Price discovery 
Migrates to the synthetic / derivatives layer 
Anchored to on-chain utility 

Suppression exposure 
Maximal (held as paper) 
Resistant (use drains the paper game) 

Chain 
BTC 
Bitcoin Cash 

RBF removed the practical reversibility that made everyday payments safe; SegWit restructured around the 1 MB base and enabled the Lightning substitute; together they moved the asset away from being used and toward being held . Bitcoin Cash kept the use.

H · The subtle attack

How the changes were made acceptable.

It is tempting to say the protocol was never attacked — only the definition of what the coin is for . That is too clean. The protocol was attacked: RBF, SegWit, Taproot, and full-RBF are protocol changes. But the attack did not arrive as force. It arrived as manufactured consent — the definition was captured first, so the changes were received by the public as useful, necessary improvements rather than as the redefinition they were.

Two domains at once. The captured discourse ran two contradictory framings in parallel.

Domain one — "Bitcoin must not be changed." Wielded against Bitcoin Cash, whose on-chain-scaling upgrade was cast as the illegitimate change — the "altcoin," the deviation, the bad actor.

Domain two — changing it. Shipping opt-in RBF (2016), SegWit (2017), Taproot (2021), and full-RBF default (2024) on BTC, each sold as improvement. Enforcing on an opponent a rule one exempts oneself from is, in Saul Alinsky's Rules for Radicals , to "make the enemy live up to its own book of rules." The injunction "don't change Bitcoin" was applied to the chain that kept the design and waived for the chain that changed it.

The brand is not the definition

The maneuver rests on a confusion it also cultivates: Bitcoin is defined by its technical document, not by its ticker, label, or brand name. By retaining the established name, BTC retained the presumption of legitimacy — but the name is not the specification. For the broad public the relationship is inverted: the brand is the definition, and whoever holds the name holds the meaning. That inversion is the lever — holding the name "Bitcoin" let the chain that changed present itself as the chain that did not. And the binding itself is a social convention, not a consensus fact : no quantity of hashpower confers the name, which lives in collective usage rather than in the protocol — which is exactly why it could be fought over at all (the @Bitcoin handle, Section III) and why holding it settled nothing about which chain implements the specification.

The asymmetric acceptance. Confront the framing with the fact that BTC was changed too, and the reply migrates: the whitepaper is old; Bitcoin must move on; the technology has advanced; smart people are improving it. "Moving on" is granted to BTC and refused to Bitcoin Cash — which moved on in the direction the whitepaper specifies. One case is accepted for oneself and rejected for the competitor. And when the founding document itself stops persuading — when pointing to the specification no longer moves the listener — that condition has a name in the literature of narrative capture: demoralization . (Offered as an interpretive lens; the attribution of intent is left to the reader.)

An insider's confirmation — Cobra (@CobraBitcoin)

These positions were stated openly by a figure on the BTC side who could hardly be better placed: Cobra, the pseudonymous co-operator of bitcoin.org — the site that hosts the whitepaper. 

On the document (October 2017): "Whitepaper is outdated and incorrect, promotes flawed understanding of Bitcoin, responsible for a lot of the 'longest chain is Bitcoin' FUD." An operator of the whitepaper's canonical home disparaging the whitepaper — and dismissing its own §11 longest-chain rule as "FUD" — is the "move on from the document" position, from the source itself.

On payments (March 2018): "Increased my holdings of Bitcoin Cash today… Bitcoin Cash has much better chances of winning the upcoming payments war than LN." The same figure conceding the use-as-payments thesis (Sections F and I) and rating on-chain Bitcoin Cash above the Lightning substitute.

On the brand (November 2018): "Bitcoin Cash was built on the premise that hashpower determines consensus… If Bitcoin SV wins the hash war, then it is Bitcoin Cash, even if this means it's led by Craig Wright and Calvin Ayre." This is the exact error the "brand is not the definition" callout above identifies: hashpower secures transaction ordering; it does not confer a name. The name-binding is a social convention, not a consensus fact — so "whoever wins the hash war holds the name" does not follow. Preserved as a documented instance of the confusion, not as an authority — and note its tension with the first quote, which dismisses the longest-chain rule as FUD while this one treats hashpower as identity-conferring.

Sources: @CobraBitcoin, posts of Oct 2017 / Mar 2018 / Nov 2018. The X/Twitter links require authentication and rot; permanent archive captures (Wayback / archive.today) should be added to the reference list before publication.

The "it would have come later" defense

A recurring defense of the period — reported as Cobra's view, among others — holds that had the big-blockers not forced a contentious hard fork into Bitcoin Cash, scaling consensus had progressed far enough that a clean mainnet block-size increase would have come naturally, later. The claim is double-edged. First, it concedes the big-blockers' technical premise : that an on-chain increase was needed at all. Second, it is refuted by the outcome — no such increase came. Nine years after the 2017 split, BTC's base block-size limit is unchanged, and the one formal promise of a later increase, the Hong Kong Agreement's 2 MB hard fork (February 2016) , was never delivered. "It would have come later" is the same unkept promise the period was built on, restated as a grievance against the chain that stopped waiting for it. (Reported characterization; the primary statement was not located and should be sourced, or the attribution softened, before publication.) 

The sequencing — wait, fix, then move

The order of operations is itself part of the record. When the conflict escalated, the changes waited : first the split was allowed to settle; then the Bitcoin Cash upgrade was framed as the illegitimate change and BTC's own position fixed as the unchanged one, the good actor; and only once that position had hardened did the further changes proceed (SegWit's consolidation, Taproot, full-RBF default). The tell sits at the start of the sequence — opt-in RBF (BIP 125, 2016) arrived before the split, while both camps still shared one chain. The Bitcoin Cash side rejected it, and rejecting RBF was a return to the §1 non-reversibility the whitepaper specifies, not a departure from it. The chain that preserved the original design was cast as the one that changed it.

The protocol was attacked — but subtly, presented as useful and necessary improvement. Force was never required: capture the definition of what the coin is for, and the changes are accepted as progress.

I · Why on-chain matters

Use is the defense.

The hashpower vector is battle-tested and not the worry. The live vectors are ideological subversion and synthetic-price suppression — and they are one apparatus, aimed at the precise property the design built in on purpose: scarcity that is used , not merely held.

The solvent for both is on-chain utility. You cannot counterfeit the coins people are actually spending. Real usage forces demand for the real unit, drains the paper layer, anchors price discovery to the chain rather than to the derivatives stack, and leaves the "failed coin" narrative nothing to hold once the asset is visibly used. This is why on-chain matters — not as one roadmap among two, but as the structurally suppression-resistant one: the posture the whitepaper specified, and the one the surviving chain kept through three splits.

The operational form of this defense — relocating backing, exchange, voting, ownership, and value itself onto protocol enforcement rather than any layer above it — is set out in the companion reference The On-Chain-Only Design Philosophy ; this section applies it to the specific case of the block-size war.

The protocol became changeable only after the definition did. Reverse the order — restore use — and the chain defends itself.

III · The block-size war

How the consensus broke.

Beginning around 2014, a faction within the Bitcoin development community began arguing that the 1MB limit should be preserved indefinitely and that scaling should happen through layers built on top of Bitcoin rather than through on-chain capacity expansion. The conventional name for this faction is "small-blockers," but the term is misleading. "Small-blocker" implies a moderate position favoring smaller-than-large blocks. The actual position defended was specifically the 1 MB cap, against any increase, including modest doublings to 2 MB. The faction was not advocating for "smaller blocks in general" against "very large blocks"; they were defending a specific historical limit against any change. The accurate name is 1 MB blockers , and this document uses that term. Their opponents — who held to the original roadmap of on-chain scaling via block size increases — came to be known as the big-blockers.

(A clarification on what "1 MB" means in this document: the 1 MB base block-size limit on the BTC chain is preserved after SegWit activation. SegWit introduced a weight-unit system that allows witness data to be discounted, producing typical effective block capacity of approximately 1.7 MB after activation — a roughly 70 percent increase over the strict pre-SegWit 1 MB cap. The defended position throughout the conflict was nonetheless the 1 MB base limit; SegWit's modest effective capacity gain was achieved through architectural restructuring rather than through raising the base limit, and the architectural costs of that restructuring are documented in Section VI. "1 MB blocker" remains accurate as the name of the defended position because the base limit was preserved and the proposed increases to the base limit were rejected. The effective capacity is referred to in this document as "approximately 1.7 MB after SegWit" or "the 1 MB base limit with SegWit weight-discount" where precision matters.)

The technical arguments on each side can be summarized briefly.

Small-blocker position: larger blocks would increase the cost of running a full node, reducing decentralization by concentrating verification capability among well-resourced operators. Therefore the 1MB limit should remain, and scaling should occur through second-layer protocols (Lightning Network, side chains) that batch transactions off-chain and settle to the main chain periodically. On-chain fees would naturally rise as block space became scarce, but this was framed as a feature rather than a problem — a "fee market" that incentivized miners to keep mining as block rewards halved over time.

Big-blocker position: the 1MB limit was always temporary, the architecture was specified to scale on-chain via pruning and SPV, and second-layer protocols introduced new trust assumptions and complexity that contradicted the whitepaper's design. High on-chain fees would push users into custodial solutions, which Bitcoin was specified to displace, not require. The "fee market" framing inverted the original use case: small casual transactions, explicitly named in §1 as something Bitcoin was designed to enable, would become economically impossible.

The technical disagreement was real, but the conflict that emerged was not primarily technical. It was social, financial, and increasingly hostile. The documentary record from 2015 through 2017 shows a pattern of consistent suppression of big-blocker viewpoints across the primary discussion venues, accompanied by personal denigration of big-blocker advocates that went well beyond technical disagreement.

r/bitcoin moderation under user Theymos became the most visible mechanism of viewpoint suppression. Pro-big-block posts were systematically removed. Users discussing alternative implementations — Bitcoin Classic, Bitcoin Unlimited, Bitcoin XT — were banned. Discussion of block size increases was treated as off-topic, "altcoin promotion," or "concern trolling." Theymos publicly defended this policy on the grounds that any chain operating with rules different from Bitcoin Core's was effectively a different coin and should not be discussed on the Bitcoin subreddit. The migration of dissenting discussion to r/btc — a forum specifically created to escape this moderation — preserved a record of how the conversation actually went, viewable today by anyone willing to search the archives.

Bitcoin.org content was controlled by a small group aligned with the 1 MB blocker position. Articles, guides, and educational content that supported on-chain scaling were rejected or removed. The website became a de facto megaphone for the Bitcoin Core development team's preferred narrative. New users seeking to understand Bitcoin from what appeared to be the project's primary informational venue received an account of the protocol shaped by the faction that was actively changing it.

The most prominent alternative information venue during this period was Bitcoin.com , operated by Roger Ver. The split between Bitcoin.org and Bitcoin.com — and the eventual association of Bitcoin.com with Bitcoin Cash after the August 2017 chain split — was not an accident of branding. It emerged from the content control documented above. With Bitcoin.org operationally captured for one viewpoint, Ver provided one of the few major venues where alternative technical analysis, dissenting voices, and primary-source documentation of the protocol changes could reach a substantial audience. The captured discourse subsequently treated this as evidence of Ver's "bias" — a peculiar framing given that Bitcoin.com existed precisely because Bitcoin.org had become unusable for anyone holding views the 1 MB blocker faction wished to suppress. The structural fact is that the captured side controlled the primary venue and used it to control the narrative; the alternative side ran a parallel venue to preserve the conversation. The asymmetry is at the level of who was suppressing whom, not at the level of who had a venue.

Social media discourse in this period documented a consistent pattern of contempt toward big-blocker advocates. Public posts mocked, dismissed, and personally attacked them as "scammers," "shills," "stupid," and worse. The pattern was visible in real time on Twitter, Reddit, and Bitcoin-focused publications, and is preserved in archives. The substance of the discourse was often not just disagreement but ridicule, sustained at a scale that would be difficult to explain by spontaneous individual contempt at that consistency.

On documenting the social conflict

The hostility pattern is part of the historical record, but documenting it carries an interpretive risk: the existence of widespread contempt is observable, but attributing it to coordinated action versus spontaneous convergence is interpretive. What can be said with confidence: the contempt was widespread, sustained, and consistently directed at one side of a technical disagreement. What requires more careful framing: whether the consistency reflects shared institutional incentives, coordinated messaging discipline, or some combination. The structural argument of this document does not depend on resolving that question. The pattern itself is documented; its causes are for readers to weigh.

The @Bitcoin handle — a contest over the name itself. The sharpest single illustration of the information environment as contested ground is the @Bitcoin account on Twitter (later X) — the bare, unqualified handle carrying the protocol's own name. This case runs ahead of the chronology, since its decisive events fall in 2017–2019, after the split; it belongs with the information-environment material because it is the naming asymmetry documented elsewhere in this volume playing out on a single high-visibility account. Through the period spanning the August 2017 chain split, the account that held the unqualified name "Bitcoin" was loud about which chain was the real Bitcoin — arguing the peer-to-peer-electronic-cash position, that the chain preserving on-chain payments rather than the chain that had abandoned them was the genuine continuation, and, after the split, promoting Bitcoin Cash in those terms. The handle bearing the name was making the argument the captured venues were suppressing.

The account's stance then changed sharply, in steps that coincide with changes in who controlled it. The operator had at one point leased programmatic (OAuth) posting access to an outside publisher; that access was abruptly terminated at the start of 2018, after which the account's messaging consolidated around the peer-to-peer-cash position and Bitcoin.com content exclusively. On April 8, 2018, Twitter suspended the account; when it was restored it had shed roughly 750,000 followers — a suspension widely read in the big-blocker community as the deplatforming of the most prominent venue still arguing their side under the protocol's own name. In August 2019 the account was sold, after which its messaging realigned again and it dropped its Bitcoin Cash advocacy. The same handle that had spent the split period insisting one chain was the real Bitcoin was, within two years and one or more changes of control, arguing the other way.

Ownership of the account was never public, which is the structural center of the episode. The entrepreneur Roger Ver was repeatedly accused of secretly operating it to promote Bitcoin Cash; he denied it directly:

I've never owned the @Bitcoin account. It is owned by someone involved in Bitcoin since 2009. He supports #BCH, is well known in the Bitcoin ecosystem, but doesn't want to deal with incessant trolling so he has chosen not to make his identity public.
— Roger Ver, denying ownership of the @Bitcoin account 

The denial is part of the record; so is the fact that it cannot be independently confirmed either way. What is documented is the sequence — the pro-cash stance through the split, the OAuth-access termination at the start of 2018, the April 2018 suspension and follower loss, the 2019 sale, and the subsequent reversal — not the identity of whoever held the account at each stage, nor why the stance moved when it did.

Why an account could matter — the platform as authority. The weight of the episode rests on what Twitter was in this period: not one venue among many but a platform widely treated as an authoritative public square, where a verified handle carrying a term's exact name held a presumption of speaking for it. Whether a private platform's power to suspend, throttle, or de-amplify an account was censorship or merely a company exercising its editorial prerogative was itself one of the era's defining public arguments — and the @Bitcoin suspension was contested in exactly those terms in real time, reported under headlines debating the "death of free speech." The platform-level question the episode raised was later made explicit from the platform's own side: after the 2022 change of ownership, the internal-moderation disclosures known as the "Twitter Files" documented how suspension and visibility decisions had been made, and the new owner publicly reframed the prior regime as one in which "moderation" had served as a euphemism for centralized information control. That characterization is itself contested and is not endorsed here; what the record establishes is narrower — that the contest over the @Bitcoin handle was an early, concrete instance of a dispute the platform's own later disclosures placed at the center of how the information environment had been governed. The platform-level treatment belongs to Vol.14; the @Bitcoin case is where it intersects the protocol's own name.

On the @Bitcoin account

The control-change events are documented in contemporaneous reporting: the OAuth-access termination, the April 2018 suspension and follower loss, and the 2019 sale. What is not documented is the cause of each narrative shift. An anonymous account whose stated positions reverse around changes in control is consistent with several readings — a voluntary change of mind by a stable owner, a transfer of the handle to a differently-aligned owner, a leased-access dispute, or external pressure — and the public record does not establish which. The episode is included as an instance of the information environment being contested at the level of the protocol's own name; the attribution of motive, here as elsewhere in this volume, is left to the reader.

What makes the episode diagnostic is precisely the opacity. The exact mechanism — a suspension, a sale, an extraction of leased access, a quiet change of hands — is not on the public record, and that uncertainty is not a gap in the account so much as a property of how capture operates in an information environment. The other mechanisms documented in this section are visible in their outputs but opaque in their coordination: the r/bitcoin moderation removed posts without disclosing who set the policy; bitcoin.org rejected content without a public editor; the developer-funding concentration aligned a nominally decentralized community through employment relationships that surfaced only when researchers reconstructed them after the fact. The @Bitcoin handle is the same phenomenon at the level of the protocol's own name — the single most visible venue still arguing the peer-to-peer-cash case under the word "Bitcoin" stopped arguing it, around changes of control no one can fully document, in the same window the rest of the environment was consolidating the other way. No single one of these — the subreddit, the website, the funding map, the handle — establishes capture on its own. Taken together, operating in the same direction across independent venues over the same period, they are what the phrase information environment in this volume actually denotes: not one suppressed channel, but the convergence of every major channel toward a single narrative, with the dissenting case progressively losing the venues from which it could be made. The detailed reconstruction of that convergence — media ownership, funding, and discursive control — is the subject of the companion volume Vol.14 — The Information Environment ; the @Bitcoin episode is one of its sharpest single instances precisely because the capture reached the protocol's own name and left, as capture tends to, no documented hand behind it.

The war was substantially decided well before the August 2017 chain split. The conventional framing places the conflict as resolved by the split — two chains, two camps, clean separation. The historical record shows the actual outcome was determined in 2015–2016, during a sequence of events that one of the most credible developers from the inside described publicly, in detail, eighteen months before any chain split occurred.

August 2015 — Bitcoin XT. Gavin Andresen and Mike Hearn released Bitcoin XT, an alternative Bitcoin client implementing BIP 101: an immediate block-size increase to 8MB with doubling every two years, following the original Satoshi-specified roadmap of phased on-chain scaling. The intent was a coordinated network upgrade, not a chain split — the same upgrade mechanism Satoshi himself had described in October 2010 ( "if (blocknumber > 115000) maxblocksize = largerlimit" ). The activation logic was designed around miner signaling: once 75% of blocks indicated support for the upgrade, the block-size increase would take effect on the network. A chain split would only occur if a significant minority refused to upgrade — which is what subsequently happened, but was not the goal of the project. Hearn, who had been one of Satoshi's direct correspondents and was the author of Bitcoinj (the Java implementation of Bitcoin powering most early mobile wallets), was a major credibility anchor for the project. Andresen, still the recipient of Satoshi's keys, was the other.

The response from the 1 MB blocker faction and their aligned community channels was not technical disagreement. It was operational suppression.

Bitcoin XT nodes were subjected to sustained DDoS attacks. Hearn later wrote that one attack on his XT node took down his rural ISP entirely — "everyone in five towns lost their internet service for several hours" because of the traffic volume directed at his connection. Discussion of Bitcoin XT was banned from r/bitcoin under Theymos's moderation. The bitcoin.org website refused to acknowledge XT as a Bitcoin implementation. The censorship was explicit and documented: in one widely-quoted directive, Theymos stated that posts about XT would be deleted unless they introduced "very substantial new ideas about the subject," a standard he was the sole arbiter of.

XT failed to reach activation threshold. By early 2016, the project was effectively dead. A successor effort, Bitcoin Classic (February 2016), proposed a more modest 2MB block-size increase. It met the same treatment — DDoS attacks, censorship, character assassination of its supporters — and similarly failed to reach activation. The 1 MB blocker faction had not won by technical argument; they had won by ensuring that no alternative implementation could establish itself, and that no discussion of alternatives could occur in the venues where Bitcoin users learned about the project.

January 14, 2016 — Mike Hearn's departure. One of the most consequential documents of the entire block-size conflict is Mike Hearn's blog post "The resolution of the Bitcoin experiment," published on Medium on January 14, 2016. The essay announced that Hearn was leaving Bitcoin development entirely and had sold all of his bitcoins at approximately $400. It was widely picked up by mainstream press as "Bitcoin developer declares Bitcoin a failure," which was the literal framing but missed the structural argument Hearn was making.

The structural argument was that Bitcoin had been captured. The essay's opening reads:

Why has Bitcoin failed? It has failed because the community has failed. What was meant to be a new, decentralised form of money that lacked "systemically important institutions" and "too big to fail" has become something even worse: a system completely controlled by just a handful of people. Worse still, the network is on the brink of technical collapse. The mechanisms that should have prevented this outcome have broken down, and as a result there's no longer much reason to think Bitcoin can actually be better than the existing financial system.
— Mike Hearn, "The resolution of the Bitcoin experiment," January 14, 2016 

This is testimony from inside the project — from someone who had corresponded directly with Satoshi, had spent five years developing on the Bitcoin protocol, had authored the most-used Bitcoin library outside of Bitcoin Core, and had personally co-led the most credible alternative-implementation effort. By the time he wrote this essay in January 2016, the conflict had already been decided in everything but ceremony. The remaining question was simply whether the big-blocker remnant would continue on the BTC chain as a permanent minority or would eventually create a separate chain to preserve the original roadmap.

Hearn's essay also documented several specific structural problems that the document has covered elsewhere, but its 2016 date makes the documentation particularly important — these were not retrospective claims made years later, but real-time observation by a senior developer at the moment the capture became operationally visible:

The introduction of RBF as a fundamental break. Hearn specifically called out the (then-just-shipped) BIP 125 opt-in RBF as introducing a reversibility primitive contrary to the whitepaper's foundational property.

The 1MB cap as artificial. Hearn described it as "an entirely artificial capacity cap of one megabyte per block, put in place as a temporary kludge a long time ago" that had not been removed.

The information suppression. Hearn documented the censorship on r/bitcoin and the conflict between Coinbase and bitcoin.org, observing that "one of the most disturbing things that took place over the course of 2015 is that the flow of information to investors and users has dried up."

The capture by a small group. Hearn explicitly noted the change in developer behavior after key figures were hired by Blockstream, and the way that scaling discussions stopped being productive once corporate alignments emerged.

The essay was met with hostility from the same channels that had attacked Bitcoin XT. Hearn was accused of being a paid R3 operative (he had taken a position at R3, a consortium-blockchain company, around the same time), of being bitter about XT's failure, of being a "shill" — the standard pattern. The mainstream press picked up the "Bitcoin is dead" framing because it was the headline-friendly version. The structural critique within the essay was largely ignored, which is itself evidence of how the information environment was already operating by that point.

Hearn left. Andresen continued working on big-blocker alternatives for some months but was effectively isolated within the development community. In May 2016, after he endorsed Craig Wright's (subsequently discredited) claim to be Satoshi, his commit access was revoked. By mid-2016, the big-blocker side had lost its two most credible technical figures. The conflict that would formally produce the chain split in August 2017 had been decided in operational terms by early 2016.

The New York Agreement of May 2017 was an attempt at compromise that came after the war was essentially over. A group of miners, exchanges, and businesses representing a majority of network hashpower agreed to a two-part plan: SegWit activation first, then a block-size increase to 2MB three months later. Both halves were supposed to ship together as a package. SegWit activated. The block-size increase, known as SegWit2X, was abandoned in November 2017 amid pressure from the 1 MB blocker faction and Bitcoin Core developers, who had never supported the agreement to begin with. The compromise collapsed and the underlying disagreement remained unresolved — except now the 1 MB blocker side had achieved its primary goal (SegWit activation) while the big-blocker side had received nothing in return.

By August 2017, the conflict had reached a point where the big-blocker faction could no longer remain on the same chain as the 1 MB blocker faction. The block-size increase the original roadmap had called for was not going to happen on the BTC chain. The decision to proceed with the upgrade anyway, on a separate chain, was the proximate cause of what would later be called "the fork" — but as the chronology shows, this was the formal recognition of a separation that had already occurred operationally in the eighteen months prior.

And the conflict was never only about block size. The same Bitcoin Core release that the big-blocker side was contesting in February 2016 — Bitcoin Core 0.12.0 — was the release that introduced BIP 125 opt-in RBF . The protocol change that broke whitepaper §1's non-reversibility specification shipped the same month Bitcoin Classic launched as a coordinated-upgrade alternative, and one month after Hearn's departure essay had specifically called out the imminent RBF activation as a fundamental whitepaper violation. By the time the chain split formally occurred in August 2017, the BTC chain had already shipped both the artificial 1MB cap that violated §7's scaling architecture and the RBF policy that violated §1's non-reversibility property. SegWit was activating that same month, breaking §2's coin-as-chain-of-signatures specification and degrading the verification architecture of §7 and §8 by separating signature data from the Merkle commitment that pruned nodes and SPV clients rely on for validation.

The chain split was not a single-issue divergence over block size. It was the moment when continued coexistence under one rule set became impossible because the BTC side had already broken the whitepaper specification on multiple load-bearing sections: §1 (RBF), §2 (SegWit signature segregation), and the verification architecture of §7 and §8 (SegWit's separation of authorization data from the original Merkle commitment). The big-blocker remnant that became BCH had to refuse not only the 1MB cap but also RBF and SegWit — all of which had become operationally present on the BTC side by mid-2017.

The institutional structure of the 1 MB faction. The Adam Back / Blockstream chronology documented in Section II is the most visible single thread, but the structural picture is broader. The 1 MB faction was not a community of independent developers who happened to share a technical conviction. It was a group whose employment and funding flowed almost entirely through a small set of organizations whose business models aligned with the 1 MB position.

A 2020 BitMEX research report examining the funding of all Bitcoin Core developers active at that time found that of 33 developers, only 11 were genuinely independent — meaning they were not employed by, or receiving fixed funding from, one of the major institutional sponsors. The remaining 22 were directly employed or contracted by a small constellation of entities. A more recent 2025 panoramic analysis of 41 active Bitcoin Core developers (those whose code has been merged at least five times) found the same concentration pattern persisting and intensifying.

The major funding entities, in approximate order of developers funded:

Blockstream. Adam Back, CEO. Pieter Wuille, Gregory Maxwell, Matt Corallo, Jorge Timón, Mark Friedenbach as co-founders, plus subsequently hired Bitcoin Core developers Gregory Sanders, Patrick Strateman, Glenn Willen, Andrew Chow. Luke Dashjr as contractor. Backed by AXA Strategic Ventures, Horizons Ventures (Li Ka-shing), Digital Garage, Reid Hoffman, and (from 2021) iFinex (Tether/Bitfinex parent). Total funding over $200M. Primary commercial product Liquid Network — a federated sidechain operated by fifteen functionaries who custody pegged BTC.

Chaincode Labs. Founded 2014 in Manhattan by Alex Morcos and Suhas Daftuar. Morcos's prior career was in automated and quantitative trading. Daftuar co-founded Hudson River Trading LLC (HRT) , one of the largest high-frequency trading firms in the world. They founded Chaincode while coming directly from high-frequency-trading backgrounds. Chaincode has funded Pieter Wuille (subsequently), John Newbery, Russ Yanofsky, Marco Falke, Carl Dong, and others.

MIT Digital Currency Initiative. Launched 2015 to absorb Bitcoin Core developers after the Bitcoin Foundation dissolved. Hired Wladimir van der Laan as lead maintainer in 2014. Hired Cory Fields and others. Funded by "unrestricted gifts" from sponsors including Circle (USDC issuer), Chain (API provider), Nasdaq stock exchange, Fred Wilson (Union Square Ventures), Reid Hoffman (LinkedIn co-founder), BitFury, and Bitmain.

Brink. Founded 2020 by Mike Schmidt and former Chaincode Labs developer John Newbery. Provides $120K–180K annual salaries to 4–6 developers per year. Nearly all newcomers to the Bitcoin Core maintainer team after 2022 have received Brink funding or training, including Gloria Zhao (now a Bitcoin Core maintainer).

Spiral (formerly Square Crypto). Funded seven developers. Square / Block, Inc., the payment company founded by Jack Dorsey.

BitMEX Grants. Funded developers since 2019. BitMEX is the offshore Seychelles-based derivatives exchange that pioneered Bitcoin derivatives trading; its founder Arthur Hayes was subsequently prosecuted in the US for Bank Secrecy Act violations.

Coinkite. Hardware wallet provider where Peter Todd (co-author of BIP 125 opt-in RBF) has been "Chief Naysayer" advisor since 2014.

OKX. Crypto exchange funding developers.

Several structural patterns emerge from this employment landscape, observable independently of any conclusion about motive:

Direct ties to traditional finance. AXA Strategic Ventures (Blockstream's largest early backer) is the venture arm of one of the world's largest insurance companies. iFinex (Blockstream investor) controls Tether and Bitfinex. The MIT DCI sponsor list includes Nasdaq itself.

Direct ties to high-frequency trading. Chaincode Labs's founders came directly from automated/quantitative trading and HRT. HRT is one of the largest high-frequency trading firms globally — a business model whose profitability depends on extracting micro-edges from market microstructure, which is structurally aligned with derivatives-mediated price discovery rather than peer-to-peer payment systems.

Direct ties to derivatives infrastructure. BitMEX (early developer funder) is the company that pioneered Bitcoin derivatives. The derivatives infrastructure documented in Section IX overlaps with the developer-funding infrastructure documented here. The same institutional layer that builds the derivatives that shape BTC price discovery also funds the developers who maintain BTC consensus.

Direct ties to the layer-2 business model. Lightning Labs, Blockstream's Lightning team, and Spiral all build the layer-2 infrastructure that profits from the base layer being constrained. The same network that maintains Bitcoin Core also builds the products that exist because of the limits the core maintainers preserve.

Geographic and institutional concentration. The "decentralized developer community" is concentrated in a handful of organizations in New York (Chaincode, HRT roots), Manhattan, MIT (DCI), Montreal (Blockstream HQ). Twenty-six of thirty-three developers with disclosed locations were in the US or Europe as of 2024.

This is not, in itself, evidence of coordinated action. Independent developers can hold the same position for independent reasons, and shared employer does not preclude independent judgment. What the structural picture establishes is that the 1 MB position was held by a group whose employment and funding were systematically aligned with that position — and that the institutional layer funding the development is the same institutional layer profiting from the protocol's resulting configuration. The technical position, the commercial model, the funding source, and the protocol outcome all point in the same direction. Whether by coordination or by emergent alignment, the outcome is the same: a chain configured to extract fees through artificial capacity constraint while routing ordinary payments through trusted-third-party intermediaries that the funding institutions either operate, invest in, or benefit from.

On Peter Todd and BIP 125

BIP 125 (opt-in Replace-By-Fee), the protocol change that broke whitepaper §1's non-reversibility specification, was co-authored by David Harding and Peter Todd and shipped in Bitcoin Core 0.12.0 in February 2016. Todd has been an advisor to Coinkite, a hardware wallet provider, since May 2014. Coinkite's business model depends on Bitcoin operating as a settlement layer with users holding their own keys through hardware wallets — a use case aligned with the store-of-value direction. The "Bitcoin not for payments" position is structurally compatible with the hardware-wallet business model in a way that "Bitcoin as everyday payment system" would not be, because everyday payments rarely use hardware wallets. This is not evidence of bad faith; many people work for companies whose products align with their views, and the alignment may be genuine. It is evidence that the BIP authors' employment placed them in a commercial relationship with one possible direction of Bitcoin's evolution rather than another. The same observation applies broadly across the developer ecosystem documented in this subsection: the technical authors of the changes that produced the captured protocol were employed by companies whose business models benefited from those changes.

The economic test the 1 MB faction never published. The 1 MB faction's central public argument was that the cap was necessary to keep node operation affordable for ordinary users. The implicit claim: high hardware costs would exclude ordinary participants from running nodes, which would centralize the network. The argument was deployed against every proposal to increase the cap, including modest doublings to 2 MB and the BIP 101 phased approach starting at 8 MB. What the faction did not do — over a decade of defending this position — was publish the cost calculation that would actually test the claim.

The test is direct. An ordinary user faces two costs on the chain: the hardware cost of running a node (if they choose to), and the transaction-fee cost of actually using the chain to pay for things. If the 1 MB cap protects ordinary users from hardware costs by keeping the chain affordable to run, but imposes transaction fees that exceed the hardware costs by an order of magnitude, then the position has cost ordinary users more than it has saved them. Whether the faction would have endorsed that trade-off is a separate question; whether the trade-off is honest is what the numbers establish.

The data: average BTC transaction fees per year (rounded, from blockchain.info and bitcoinfees.com historical data) compared to consumer storage cost per GB and amortized full-node hardware cost (assuming a five-year refresh cycle on a modest machine plus a 2 TB drive):

Year 
Avg BTC fee/tx 
2 TB drive cost 
Node 5-yr amortized 
Active Joe annual fees (200 tx) 

2015 $0.20 $100 $120 $40 

2017 $12.00 $80 $100 $2,400 

2018 $4.50 $70 $90 $900 

2021 $4.80 $44 $70 $960 

2024 $8.50 $32 $50 $1,700 

2026 $4.50 $28 $44 $900 

The "Active Joe" column models someone using BTC roughly four times a week — a realistic profile for a person actually using the chain as a payment system, which is the population the cap was supposedly protecting. The cumulative comparison across 2017–2026:

User profile 
Tx/year 
10-year fees 
10-year hardware 
Ratio 

Light user (1/month) 12 $600 $796 0.8× 

Regular user (1/week) 52 $2,600 $796 3.3× 

Active user (4/week) 200 $10,000 $796 12.6× 

Heavy user (10/week) 500 $25,000 $796 31.4× 

Power user / merchant 1500 $75,000 $796 94.2× 

The arithmetic produces an unambiguous result. A user transacting four times a week on BTC has paid roughly 12.6 times more in fees over the past decade than the entire hardware budget that the 1 MB cap was supposed to protect them from. A merchant or business owner transacting daily has paid 94 times more. These ratios are not approximations of marginal differences; they are orders of magnitude.

The 2015 baseline makes the position most clearly indefensible. In 2015, when the block-size war was most intense, BTC average fees were around $0.20 and a 2 TB drive cost about $100. The proposal on the table was a move from 1 MB to 2 MB blocks — a change that required no hardware upgrade at all. Hardware running 1 MB blocks was the same hardware that would run 2 MB blocks. The 8 MB BIP 101 proposal would have required, at most, a 2 TB drive — the same drive that cost $100 in 2015 and approximately $30 today. The "centralization through hardware costs" argument was deployed against a doubling that required no incremental hardware, by people whose own funding came from organizations with business models that benefited from the cap being preserved.

What the faction did not publish: this calculation. The argument was structured around hardware costs as the binding concern, while transaction costs were either dismissed (Lightning will solve this) or rationalized (Bitcoin isn't for small payments anyway). The latter is the explicit 180-degree inversion documented below. The honest version of the 1 MB position would have stated: "We are choosing to optimize the chain for high-value transactions and institutional settlement. Ordinary users will be priced out of the base layer. They will need to route through intermediaries. This is the trade-off we are making." That position is defensible as a policy choice for an institutional asset. It is not what the faction stated publicly. They stated they were protecting ordinary users from hardware costs while imposing on those same users transaction costs that exceeded the hardware costs by an order of magnitude.

Note on Moore's Law and the original technical concern

Some technical concern about block-size increases existed in 2015 and was, in narrow form, legitimate at extreme scales. The whitepaper itself addresses this: Satoshi explicitly referenced hardware progress and Moore's Law as the mechanism that would allow the chain to scale. At 2010 storage costs (~$0.07/GB) and 2010 residential bandwidth, very large blocks would have created propagation problems. At 2026 storage costs ($0.015/GB) and gigabit residential fiber widely deployed, the propagation problem has been resolved by ordinary technological progress — exactly as the whitepaper anticipated. The position that maintained the 1 MB cap from 2015 through 2026 outlasted the technical concern that originally motivated it by approximately a decade. A position held against empirical falsification of its premises is no longer about its stated reasons. None of this applies in 2015 to the 2 MB or 8 MB proposals on the table — those required no hardware that didn't already exist.

On the asymmetric use of "fork." A small but structurally telling pattern. The word "fork" is deployed in the dominant discourse with notable asymmetry. The August 2017 implementation of the block-size upgrade is described constantly as "the Bitcoin Cash fork" or "BCH forked off Bitcoin," with the implication that BCH departed and BTC remained. The technical reality is that both chains continued from block 478,558 under divergent consensus rules; neither chain is the original Bitcoin chain, which ended at that block.

The August 2017 SegWit activation was, technically, a hard fork in the sense that nodes running pre-SegWit consensus rules could not validate post-SegWit transactions correctly. SegWit transactions appear to non-SegWit nodes as transactions with anyone-can-spend outputs, which means non-SegWit nodes do not actually verify them — they accept them without verification because the witness data lives in a structure those nodes cannot see. SegWit only avoided a visible chain split because the nodes that would have rejected it had already left for the BCH chain, and because the remaining miners were coerced into coordinated upgrade through the UASF mechanism described below. The dominant discourse does not refer to "the SegWit fork" or "SegCoin." The asymmetry is not technical; it is rhetorical.

The same applies to Taproot. The 2021 Taproot activation also depended on miner coordination, and pre-Taproot nodes see Taproot outputs as anyone-can-spend in the same way pre-SegWit nodes saw SegWit outputs. Had a significant minority of miners refused to coordinate Taproot adoption, the chain could have split. The dominant discourse does not refer to "the Taproot fork" or "TapCoin." Similarly, BIP 125 opt-in RBF (February 2016) and Bitcoin Core 28.0 full-RBF default (October 2024) were consensus-relevant protocol changes that altered what the network considers valid state transitions. They are not described as "the RBF fork" or "RBF Bitcoin." The neutral and accurate terminology is upgrade or protocol update or, for consensus-rule changes specifically, rule change — applied symmetrically across all such events.

The soft-fork / hard-fork distinction as deployed rhetorically

The conventional framing presents soft forks as backwards-compatible rule changes that pre-upgrade nodes can still validate, and hard forks as breaking changes that require coordinated upgrade. This framing is technically incomplete in ways that matter for the discourse around BCH versus BTC.

Pre-SegWit nodes do not actually validate SegWit transactions — they accept them as anyone-can-spend outputs because the witness data is invisible to them. This is acceptance without verification, not backwards-compatible validation. The pre-SegWit node operator after activation is no longer security-equivalent to a SegWit node operator; they are trusting that miners and SegWit nodes correctly verified what they themselves cannot check. The same property applies to Taproot. Both changes degraded the validation strength of nodes that did not upgrade, while preserving the appearance that those nodes remained part of the network.

From a network-operation standpoint, both SegWit and Taproot required near-unanimous miner coordination to avoid producing visible chain splits. If a significant minority of miners had refused to upgrade and continued building on what they saw as anyone-can-spend transactions (claiming the outputs for themselves), SegWit-validating nodes would have rejected those blocks and the chain would have split. The mechanism by which this minority refusal was prevented is the structural fact that the "soft fork" framing obscures: the coordination was enforced through coercive pressure on miners, not avoided through technical backwards-compatibility.

The 1 MB faction's framing of soft forks as fundamentally different from hard forks — therefore allowing their own consensus-rule changes (SegWit, RBF, Taproot) to be presented as ordinary protocol evolution while BCH's block-size upgrade was presented as rule-breaking departure — is rhetorical. Both kinds of changes required the same kind of coordinated upgrade. Both could produce chain splits when coordination failed. The labels make some instances of coordinated rule change appear acceptable and others unacceptable, but the underlying structural process is the same.

The UASF coercion of miners during SegWit activation. The mechanism by which SegWit reached activation in August 2017 illustrates the rhetorical nature of the soft-fork framing concretely. By mid-2017, miner signaling for SegWit had stalled at approximately 30% — far below the 95% threshold the BIP9 activation mechanism required. The 1 MB faction's response was not to negotiate a compromise that miners would accept. The response was to organize a User Activated Soft Fork (UASF) under BIP148, which would orphan any block that did not signal SegWit support starting August 1, 2017.

The mechanism was openly described as coercion. UASF-aligned full nodes would reject any block from miners who continued building on non-signaling blocks. The threat made to miners was explicit: if they did not coordinate adoption of SegWit by the August 1, 2017 flag day, their blocks would be orphaned, their mining revenue eliminated, and their economic position destroyed. UASF advocates used the term "wipe out" to describe what would happen to the chain miners continued to mine on if they refused. The Bitmain UAHF (User Activated Hard Fork) contingency-plan post from June 2017 described UASF as "an attack against users and enterprises who disagree with activating SegWit right now without a block size increase." 

The campaign was extensively documented in real time on Twitter, GitHub, Medium, and Bitcoin-focused forums. Prominent figures of the 1 MB faction openly threatened miners with revenue destruction if they did not comply. The Jimmy Song Medium piece from August 2017 modeled the game-theoretic scenarios explicitly: if miners refused to upgrade, blocks would come slowly, transactions would back up, fees would spike, and miners would either capitulate or be economically destroyed. The pressure was not subtle.

SegWit reached activation not because miners chose to upgrade voluntarily but because they were threatened with their blocks being orphaned and their revenue eliminated if they did not. The Braiins blog (2020 anniversary post) characterizes this approvingly: "The pressure from the UASF was enough to force miners to adopt SegWit." The word force is being used accurately. A change that requires threatening miners with economic destruction to coordinate adoption is, structurally, requiring coordinated upgrade in exactly the way a hard fork does. The "soft fork" label describes only the technical surface of how validation occurs; it does not describe the actual coordination requirements or the social process by which adoption was secured.

This is the structural meaning that the soft-fork / hard-fork framing obscures: SegWit was a hard fork in everything but rhetorical framing. It required coordinated miner upgrade. It threatened those who did not coordinate with revenue destruction. It would have produced a visible chain split had a meaningful minority refused. The same applies to Taproot, RBF, and the other changes the 1 MB faction implemented. The "we are not changing Bitcoin" position, applied to BCH, was held simultaneously with the active implementation of multiple consensus-rule changes that required exactly the kind of coordinated upgrade the position claims to oppose.

The term UASF itself is a constructed piece of rhetorical apparatus that deserves examination on its own terms. "User Activated Soft Fork" presents the operation as something fundamentally different from a hard fork. The name does three things rhetorically: it locates agency with "users" (suggesting democratic legitimacy), it calls the change a "soft fork" (suggesting compatibility and non-disruption), and it omits any mention of the coercive mechanism that actually produced activation. The phrase, examined, describes nothing the operation actually was.

Stripped of marketing language, what happened was this: one faction of nodes adopted new rules and threatened to refuse blocks from anyone who did not follow them. That is, structurally, identical to what would happen during a hard fork in which a chain split occurred. The "soft" terminology presents this as if no split is possible, when in fact the entire mechanism requires the threat of a split to function. If soft forks were technically benign and did not require all participants to coordinate, no threat mechanism would be necessary; miners could continue at their own pace and the network would converge. The fact that the UASF mechanism required threatening miners with block orphaning is direct evidence that the change did, in fact, require coordinated upgrade — which is the property the "soft fork" label is supposed to deny.

The "user-activated" prefix added a layer of democratic legitimacy on top of the soft-fork framing. The phrase presents the operation as a grassroots movement of ordinary users asserting their position against recalcitrant miners. The reality is that the operation was organized by a small group of technically sophisticated developers and influencers with the resources and platform access to coordinate node-software releases, social-media campaigns, threat communication to mining pools, and exchange coordination. The "users" in "user-activated" were targets of the messaging, not authors of the campaign. The construction of "UASF" as a category answers a specific rhetorical need: the 1 MB faction needed to frame their own coordinated coercive upgrade as something fundamentally different from BCH's coordinated upgrade. The term does that work by attaching benign-sounding labels to mechanisms whose actual operation those labels misdescribe.

"We are doing a soft fork that does not require all nodes to upgrade, and to enforce it we will orphan the blocks of any node that does not upgrade." These two statements cannot both be true. The first is the public framing of UASF. The second is the operational mechanism. The contradiction is on the surface of the construction, not buried in it.

The narrative flexibility of the 1 MB faction. Across the decade of the block-size conflict and afterward, the 1 MB faction's public position has not been a stable doctrine. It has been a set of mutually inconsistent positions held simultaneously or transitioned between depending on which suited the rhetorical moment. The pattern is structurally diagnostic: a position defended by switching between incompatible justifications is a position not actually defended on the merits of any individual justification.

Two examples of the pattern, both observable in the public record:

(a) "Bitcoin should not be changed" — applied selectively. Throughout the block-size conflict and after the August 2017 chain split, the 1 MB faction's framing of the BCH block-size upgrade was that BCH represented a "structural change" to Bitcoin and that the BTC chain was the conservative continuation. The implicit principle: Bitcoin must remain unchanged; departures from the existing rule set are illegitimate.

The same faction simultaneously implemented substantial structural changes to the BTC chain: SegWit (a hard fork in technical terms, soft-forked through anyone-can-spend witness output mechanics), opt-in RBF (a consensus-relevant change to the interpretation of unconfirmed transactions), full-RBF as default (October 2024, completing the abandonment of non-reversibility), Taproot (2021, modifying transaction script semantics), and ongoing development of layer-2 routing architectures that fundamentally alter how value moves on the chain. The "Bitcoin should not be changed" principle was applied to BCH and withheld from BTC. The same actors who described BCH as "altering Bitcoin" were actively altering Bitcoin.

(b) The frame-shift on the whitepaper. When the 1 MB faction's protocol changes are compared to the whitepaper's specifications and found to depart from them on multiple load-bearing points, the response is not a defense on whitepaper grounds. The response is a shift to a different frame entirely. The whitepaper, it is then argued, is not a credible source. The whitepaper is old. Bitcoin has evolved beyond it. Technology has moved on. The original document should not be treated as the authoritative description of what Bitcoin is.

This is the opposite frame from the "Bitcoin should not be changed" position used elsewhere. The two are not compatible: if Bitcoin should not be changed, then the whitepaper specifications it was launched with are authoritative; if Bitcoin should evolve beyond the whitepaper, then BCH's implementation of upgrades the whitepaper specified is no more illegitimate than BTC's implementation of changes the whitepaper does not. The faction holds whichever position is convenient. To opponents who advocate any upgrade: Bitcoin should not be changed. To opponents who cite the whitepaper as authority: the whitepaper is not authoritative. The two together produce a defensible discursive shell with no defensible center.

The escalation pattern is also visible in the discourse on fees. Early in the conflict: "we need the cap to keep node operation affordable for ordinary users." When fees rose past the point ordinary users could afford: "Bitcoin isn't for small payments anyway." When fees rose past the point most payments could afford: "high fees are good because they pay miners and secure the network." Some advocates explicitly argued that $100-per-transaction fees would be beneficial for network security. The argument's premises and conclusions migrated to keep pace with the protocol's outcomes, rather than the protocol being adjusted to match the original argument's premises.

A position defended by switching between incompatible justifications, depending on which suits the rhetorical moment, is a position not actually defended on the merits of any individual justification. The 1 MB faction's central claim — that they defend an unchanged Bitcoin against alteration — is held simultaneously with their active alteration of Bitcoin and their dismissal of the document that defines what Bitcoin originally was. The structural meaning of holding both positions together is that neither is the actual position.

This is the structural meaning of the August 2017 split that the dominant narrative obscures. BCH did not "fork off Bitcoin." BCH preserved Bitcoin as the whitepaper specified it — non-reversible, on-chain-scaling, coin-as-chain-of-signatures — at a moment when the chain calling itself Bitcoin had stopped operating that way on multiple fronts simultaneously. The split was the formal recognition that the two rule sets had become incompatible at the level of the protocol's foundational properties, not just at the level of one parameter.

The 180-degree inversion. The protocol-level capture described in this section had a discursive counterpart that is equally significant and equally documented. The 1 MB blocker faction did not merely defend a parameter choice; they progressively reframed what Bitcoin was supposed to be. The reframing inverted the whitepaper's stated purpose at every load-bearing point.

The goalpost that kept moving. The inversion did not arrive as a single announced reversal; it arrived as a deferral that never resolved. In the early phase of the dispute the public 1 MB-blocker position was rarely a flat "the base layer should never carry ordinary payments." It was a temporal claim: that an on-chain capacity increase was premature — that the software was not yet ready, that the risks to node decentralization needed more study, that second-layer protocols would shortly make a base-layer increase unnecessary, that the increase could be revisited later under safer conditions. Each of these framings preserved the appearance of an open question: not "no," but "not yet." The structural observation, visible only over time, is that "not yet" never became "now." Every concrete proposal to raise the limit — 8 MB (BIP 101), 2 MB (Classic), the 2 MB second half of the New York Agreement — met the same deferral, and the deferral never once resolved in the direction of an increase. A claim presented as a question of timing functioned, across a decade, as a settled refusal that was never put to a decision.

The terminal phase removed even the temporal framing. The "not yet" of 2015–2016 gave way, by roughly 2018 onward, to positions that no longer treated base-layer payment capacity as a goal being deferred but as a purpose being denied — that Bitcoin was not for everyday payments at all, that ordinary users should transact through layer-2 networks, payment processors, or the legacy financial system, and that the base layer was a settlement and store-of-value system rather than a payment one. The endpoints of that reframing — "store of value, not a payment system," "digital gold," the explicit retirement of the coffee-payment thesis — are traced in the remainder of this subsection through the primary sources of senior figures across the BTC-aligned ecosystem. What the chronology adds is that the endpoint was not reached by an open argument that won on its merits; it was reached by a deferral that was never allowed to resolve. The question stayed nominally open precisely long enough to stop being asked.

A contemporaneous witness account

The drift was legible in real time to observers who began from the opposite presumption. One such account, from a then-skeptic: in 2017, with the split already an established fact and Bitcoin Cash under heavy and largely hostile media framing, the reasonable prior for a newcomer was that BTC was the legitimate chain and BCH a likely scam — and that is where this observer started. What did not resolve was the scalability question. The BTC-aligned position conceded that scaling mattered and pointed to Lightning and other second layers, but on the specific matter of the base-layer block size it held that an increase was simply too early. Watched over time, "too early" did not move; it repeated. The possibility of ever raising the limit was first deferred indefinitely and then dropped from the conversation altogether, replaced by the flat claim that Bitcoin was not for payments — that one should use a credit card, or dollars, for that. The reversal was not a debate that reached a conclusion; it was a debate that was closed by ceasing to hold it. For this observer the unidirectional drift — from an open technical question to a non-discussable one — was itself the signal that the matter was no longer being decided on technical grounds. This is a single observer's recollection, offered as testimony rather than proof; its evidentiary weight is in how closely it tracks the documented chronology above and below it.

The whitepaper's first sentence reads: "A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution." The §1 abstract opens by identifying financial institutions serving as trusted third parties as the problem Bitcoin was designed to displace. Bitcoin's purpose, as stated in its founding document, was to provide ordinary participants with a payment system that did not require a financial institution as intermediary.

By the period covered in this section — roughly 2018 onward — the dominant framing within the BTC-aligned discourse had inverted this purpose. Bitcoin was now described as:

A store of value, not a payment system

"Digital gold" — an asset for long-term holding, not a currency for transacting

A settlement layer for large-value transfers between institutions, not a payment rail for individuals

An infrastructure for the same financial institutions the whitepaper had identified as the problem

Unsuitable for everyday transactions, with ordinary users directed to layer-2 networks, payment processors, or the legacy financial system

This inversion is documented in primary sources from senior figures across the BTC-aligned ecosystem. Saifedean Ammous's The Bitcoin Standard (2018), one of the foundational books of the 1 MB blocker discursive position, states the inversion directly: "Rather than serving as a currency and network for consumer purchases, the author argues Bitcoin is better suited as a store of value and network for settlement between large financial institutions." The book includes a fee calculation that establishes the design logic explicitly: "A bitcoin transaction fee of one dollar can be 100% of the price of your coffee, but it would be 0.0000001% of a billion-dollar transaction." The implication of that arithmetic, which the book embraces rather than identifies as a problem, is that the chain is structurally optimized for large transactions and structurally unfit for small ones.

In a 2021 podcast appearance (SALT Talks #127), Ammous extended the framing: "A few years ago, a lot of people used to think that when is Starbucks going to adopt Bitcoin? When is McDonald's going to adopt Bitcoin? In their minds you would be able to pay for your coffee or your burger with Bitcoin. But I think what we're seeing is that we're going to be witnessing Bitcoin transactions being performed... Bitcoin coming into those companies from the balance sheet, not from the [point of sale]. They're going to hold it as cash rather than accepted for small payments." The retired-the-coffee-payment-thesis framing is explicit. Bitcoin is for corporate balance sheets, not for ordinary transactions.

The same framing has been articulated more recently by institutional figures. Robbie Mitchnick , head of digital assets at BlackRock (the world's largest asset manager, managing approximately $11 trillion), stated in a November 2025 podcast interview that the firm's clients treat Bitcoin "primarily as a store of value, not a future payments network." Mitchnick added: "For us, and most of our clients today, they're not really underwriting to that global payment network case." He characterized the payments use case as "out-of-the-money option value" — language drawn from derivatives pricing, indicating that institutional investors regard the whitepaper's stated purpose as a low-probability scenario not central to their investment thesis.

This is the position of the largest pool of institutional capital allocating to Bitcoin: the whitepaper's stated purpose is, from their perspective, not what they are buying. They are buying digital gold. The peer-to-peer electronic cash use case, named in the whitepaper's title and described in its first sentence, is treated as a residual upside rather than the protocol's design intent.

The structural fact this produces is direct. The chain has been optimized for the use case the dominant holders care about (institutional balance-sheet holding, large-value settlement) and de-optimized for the use case the whitepaper specified (ordinary peer-to-peer payments). The 1MB cap binds capacity tight enough that fees price ordinary transactions out of the base layer. RBF makes 0-confirmation reliability impractical for merchants. SegWit and Lightning push everyday payments into layer-2 architectures that involve their own custody, intermediation, and counterparty risk. Ordinary users who want to participate in Bitcoin payments must do so through payment processors, custodial wallets, exchanges, or layer-2 networks — each of which is, in some form, the trusted third party the whitepaper §1 was designed to displace.

The whitepaper opens by identifying financial institutions serving as trusted third parties as the problem. The dominant framing of Bitcoin as a chain in 2026 positions it as infrastructure for those same financial institutions. The protocol stated in the founding document and the protocol described in the current dominant discourse are not the same protocol. The inversion is documented, and the documents are public.

It is worth noting what this means for the question of who Bitcoin is for. The whitepaper does not specify a user class. It specifies a payment system: peer-to-peer, with the parties direct and the financial institution removed. Anyone running the software and holding a private key is a participant in the system the whitepaper describes. The discursive inversion, by contrast, has produced a system structurally suited for participants who can absorb high transaction costs (institutions, large allocators, high-net-worth individuals) and structurally unsuited for participants who cannot (ordinary users transacting in everyday amounts). Without naming this as a class outcome — the document leaves that inference to the reader — the structural fact is that the chain has been engineered into a configuration the whitepaper neither describes nor endorses, and the discourse around the chain has been engineered to legitimize that configuration.

The discursive inversion is documented separately

The capacity for this kind of inversion to take hold and become broadly believed depends on the information environment in which the discourse circulates. The major crypto news outlets, conference organizations, social media moderation, and influencer networks of the BTC-aligned ecosystem have substantial ownership, funding, and structural linkages to the same institutional layer whose interests the discursive inversion serves. The CoinDesk/Digital Currency Group relationship (2016-2023), the Bitcoin Magazine / BTC Inc / Nakamoto Inc institutional-treasury vehicle structure, the Alameda/FTX-funded buyout of The Block , and the r/bitcoin moderation policies under Theymos are all documented. These structural linkages between the information environment and the institutional interests that benefit from the dominant framing are themselves part of the historical record this document examines. A separate companion piece — Vol.14, The Information Environment — provides the detailed investigation of media ownership, funding sources, and discursive control in the crypto information ecosystem. This document refers to that companion piece rather than reproducing its content here, because the investigation is substantial enough to deserve its own treatment.

For the purpose of this document, what matters is the structural fact: the protocol changes described in this section did not happen in a neutral information environment. They happened in an environment where the dominant outlets, conferences, social-media venues, and opinion-shaping figures were either directly owned by, funded by, or structurally aligned with the institutions whose interests the protocol changes served. The reader who has worked through this section now has the chronology of the technical and institutional shifts; the reader who works through Vol.14 will have the chronology of how those shifts were made widely believable despite contradicting the founding document of the protocol.

IV · August 2017

The split at block 478,558.

On August 1, 2017, at block 478,558, the Bitcoin chain diverged into two chains operating under different consensus rules. One chain — the one that maintained the 1MB block limit and accepted SegWit activation — continued under the BTC ticker. The other chain — which raised the block-size limit to 8MB and did not accept SegWit — became Bitcoin Cash (BCH).

Both chains share the same history up to block 478,557. They share the same genesis block, the same fifteen years of accumulated transactions, the same UTXO set up to the point of divergence, the same set of addresses. Every holder of Bitcoin at the moment of the split automatically held both BCH and BTC at the same address, in the same amount, on both chains. Neither chain was created in 2017; both chains continued from 2017.

The framing of this event in the dominant narrative has been asymmetric. "BCH forked off Bitcoin" became the standard phrasing. Bitcoin Cash was treated as the new chain that had departed from the canonical Bitcoin. The BTC chain was treated as Bitcoin proper, continuing without interruption.

This framing requires examination. Technically, both chains were the result of the same divergence event. Calling one side "the fork" and the other side "Bitcoin" is a naming choice, not a technical claim. The question of which chain stayed closer to the protocol Satoshi specified is a separate question — and on that question, the side that maintained on-chain scaling (against the 1MB limit that Satoshi, Hal Finney, and Ray Dillinger had all agreed was temporary) is the side that operated more consistently with the documented original design intent.

Both chains continued from the same chain. Neither was created in 2017. The decision about which side gets to be called "Bitcoin" was a naming decision, not a technical fact — and naming decisions in contested spaces go to whoever has the louder media reach.

What can be said with technical confidence: BCH and BTC both inherit the pre-fork chain history. Both have legitimate claims to continuity. Which one operates closer to the whitepaper specification is a question this document will answer in Section XI by direct comparison against the text. The asymmetric framing — one side as "Bitcoin," the other as "the fork" — is a media convention, not a structural fact.

What happened after the split is where the divergence becomes substantive. Both chains had to make ongoing decisions about consensus rules, upgrade paths, and protocol direction. Those decisions diverged in ways that can be measured against the whitepaper. The next several sections walk through the specific divergences on the BTC side — RBF, SegWit, Lightning promotion, derivatives debasement, Taproot, full-RBF default — and what each one means in terms of fidelity to the original specification.

V · RBF

The reversibility shift.

The whitepaper's §1 specifies non-reversibility as foundational. The opening paragraph identifies the problem Bitcoin was designed to solve: financial institutions acting as trusted intermediaries because completely non-reversible transactions are not really possible in their model. The proposed solution: cryptographic proof that makes transactions "computationally impractical to reverse." Non-reversibility is not an incidental property. It is what distinguishes Bitcoin from credit card networks and bank wires.

The introduction of Replace-by-Fee on the BTC chain in February 2016 — one and a half years before the August 2017 chain split — is therefore not a peripheral technical detail. It is one of the foundational whitepaper violations that made the eventual chain split necessary. The big-blocker side did not just object to RBF philosophically. They objected because RBF, taken together with the artificial block-size restriction and the pending SegWit activation, made the BTC chain structurally incompatible with the protocol Satoshi had specified.

RBF introduces a mechanism by which transactions can be reversed before confirmation, by replacing them with a higher-fee version. The original is dropped from the mempool; the replacement takes its place. From the recipient's perspective, a transaction that was "in the network" can vanish and be replaced by a different transaction sending to a different address.

RBF entered Bitcoin Core in two stages. The first was BIP 125, "Opt-in Full Replace-by-Fee," merged in early 2016 and shipped in Bitcoin Core 0.12.0. The "opt-in" framing made it sound consensual: a sender could flag a transaction as replaceable, and only those flagged transactions could be replaced. Transactions not flagged as replaceable would not be subject to the new behavior.

The opt-in framing concealed the structural change. Before BIP 125, the network treated all transactions as final upon broadcast (subject to confirmation depth). After BIP 125, the network treated transactions as potentially replaceable as a category. The default behavior changed for the network as a whole. Merchants accepting zero-confirmation transactions — a use case Bitcoin had originally supported and that Satoshi had described in the snack machine thread — now had to inspect each incoming transaction for the RBF flag and decide whether to accept it. The reversibility door had been opened, even if only certain transactions walked through it initially.

The second stage came in October 2024 with Bitcoin Core version 28.0, which made full-RBF the default . Under this policy, any unconfirmed transaction can be replaced by a higher-fee version, regardless of whether the original sender flagged it for replacement. The opt-in distinction was abandoned. Reversibility, before confirmation, became the default behavior of the network.

From the whitepaper's perspective, this is a complete abandonment of the property identified in §1 as foundational. Non-reversibility is not a feature that can be turned on or off by policy; it is what Bitcoin is , according to the specification. A chain that allows transactions to be reversed before confirmation, as a default policy, is operating outside that specification.

The whitepaper's first paragraph identifies non-reversibility as the problem Bitcoin is solving. Bitcoin Core 28.0 makes reversibility the default. The trajectory from "opt-in" in 2016 to "default" in 2024 is the trajectory of the original specification being abandoned at the policy level, in stages, with each stage framed as a small adjustment.

The merchant-acceptance consequence. The specification-level violation has a direct real-world consequence that is rarely discussed in the technical framing of RBF: it destroys the cash use case that the whitepaper title names. The document is called "Bitcoin: A Peer-to-Peer Electronic Cash System." Cash, by physical nature, is non-reversible — once a banknote changes hands, the seller cannot reach into the buyer's pocket and take it back. The whitepaper's §1 makes non-reversibility foundational precisely because non-reversibility is what makes cash usable as cash for irreversible transactions.

Consider what a merchant needs to know before accepting payment. For non-reversible services — food and drink already consumed at a café, a haircut already performed, a hotel night already provided, a streamed video already delivered, a ride already taken, admission already granted, software already downloaded, an event already attended — the seller cannot un-render the service. If the payment is later cancelled or charged back, the seller absorbs a total loss. This is why physical cash exists for these transactions: the irreversibility of the cash exchange matches the irreversibility of the service rendered.

Before RBF, Bitcoin operated this way at zero confirmations. A transaction broadcast to the network would either confirm in the next block or be dropped, but it would not be replaced by a different transaction sending to a different address . For low-value point-of-sale transactions, the cost of attempting a double-spend exceeded the value at stake, and merchants could accept payments at 0-confirmation with reasonable confidence. This was the cash-equivalent property §1 of the whitepaper had specified.

After RBF, the merchant must assume any incoming unconfirmed transaction can be cancelled by the sender and replaced with one sending the funds elsewhere. The merchant who renders a non-reversible service against a 0-confirmation RBF-flagged transaction risks providing the service and then receiving nothing — the customer walks out with the service consumed and the bitcoin returned to their own address. From a merchant's risk perspective, accepting unconfirmed BTC under an RBF-enabled network is structurally equivalent to accepting a personal check that the customer can cancel after the goods leave the counter.

The merchant is therefore left with three options, none of which preserve Bitcoin's original cash use case:

Refuse Bitcoin entirely as a payment method, eliminating the use case from that merchant.

Require multiple confirmations before considering payment final — meaning ~10 minutes per block, often more for high-value items, which makes point-of-sale Bitcoin impractical for anything where the customer expects to take the service or product immediately.

Use a payment processor (BitPay, Coinbase Commerce, OpenNode, and others) which takes on the settlement risk in exchange for fees and friction, typically converting to fiat immediately. The merchant doesn't actually receive Bitcoin; they receive fiat from an intermediary who took the Bitcoin risk on their behalf.

The third option is the one most merchants chose, and it deserves attention because of what it structurally is. The payment processor sits between the customer and the merchant, holds the bitcoin briefly, converts to fiat, and settles to the merchant. This is precisely the role §1 describes: "financial institutions serving as trusted third parties to process electronic payments." The whitepaper opens with this description of the problem Bitcoin was designed to displace. RBF, taken together with fee pressure and volatility, made the trusted-third-party model the only practical option for most merchants — which means the protocol changes drove merchants back into the exact architecture the whitepaper was designed to make obsolete.

This is the structural function of RBF when viewed alongside the other accumulated changes. Fee pressure (driven by the 1MB cap) makes ordinary transactions expensive. Volatility (driven by speculation rather than transactional use) makes pricing unstable for merchants holding bitcoin. RBF (introduced as a "solution" to the fee pressure that the 1MB cap created) destroys 0-conf reliability for non-reversible services. Together, the three changes make peer-to-peer merchant acceptance impractical, and push merchants into payment-processor intermediation — restoring the trusted third party that §1 was structured to eliminate.

The downstream-consequence pattern

RBF is often presented as a neutral technical improvement: users want to bump fees on stuck transactions, RBF lets them, problem solved. The framing presents RBF as solving a user problem. But the user problem itself was a downstream consequence of the 1 MB blocker faction's prior decision to maintain the block-size limit artificially. The constraint was not on quantity (no Bitcoin "scarcity" was being engineered); the constraint was on a parameter — block size — that was deliberately kept unchanged past its original temporary purpose. Without the cap, fees would not routinely escalate, transactions would not routinely get stuck, and users would not need to bump fees.

The pattern is: (1) maintain the block-size limit artificially despite the original temporary purpose, (2) users hit friction from fee escalation as capacity binds, (3) introduce a protocol change to relieve the friction, (4) the change happens to violate the whitepaper's foundational property. Each step is presented as a small adjustment responding to a real user need. The cumulative effect is structural protocol drift away from the original specification, in a direction that progressively re-enables the trusted-third-party model the protocol was designed to displace. RBF is a solution to disperse adoption, not to support it.

The merchant-adoption collapse — chronology. The structural argument above is supported by an empirical record. Between 2014 and 2018, Bitcoin went from being adopted by tens of thousands of merchants worldwide to being effectively abandoned as a direct-acceptance payment method by all but a handful of major retailers. The chronology of that collapse maps directly onto the protocol changes the document has been describing.

2014 — Major merchants begin accepting Bitcoin directly: Dell , Microsoft , Expedia , Newegg , Overstock , Valve (for Steam), Stripe , Fiverr , PayPal (for merchant-side acceptance). The adoption curve is steep through 2014–2015 as the user experience matches the whitepaper's intent: fast, cheap, irreversible payments with reliable 0-confirmation handling for low-value transactions.

February 2015 — The number of merchants accepting Bitcoin globally crosses 100,000 . This is the documented peak of direct merchant acceptance. Transaction fees at this period typically run in the $0.05–$0.20 range. Block utilization is well below the 1MB ceiling.

2015–2016 — Block utilization approaches the 1MB ceiling on a routine basis. The mempool — the queue of unconfirmed transactions — begins exhibiting persistent backlogs. Fees begin escalating as users bid against each other for limited block space. The fee-pressure dynamic that the cap had not previously created becomes the new normal.

February 2016 — Bitcoin Core 0.12.0 ships BIP 125 opt-in RBF. The merchant impact of this change is structural and immediate: merchants accepting 0-confirmation Bitcoin payments now have to inspect each incoming transaction for the RBF flag and decide whether to accept it. Payment processors begin building RBF-detection into their flows, with the recommendation to reject RBF-flagged transactions at 0-confirmation. The 0-conf reliability that made Bitcoin practical for point-of-sale begins eroding from this point.

2017 — Throughout the year, fees escalate as block-space competition intensifies. Major merchants begin reconsidering their Bitcoin acceptance. Dell quietly discontinues Bitcoin acceptance during 2017 (the company has never publicly confirmed an exact date, but its Bitcoin checkout option disappears).

December 6, 2017 — Valve announces that Steam , the largest PC gaming platform in the world, is discontinuing Bitcoin acceptance. Valve's published reasons are diagnostic of the entire collapse: transaction fees that had been around $0.20 per transaction when Steam adopted Bitcoin had risen to approximately $20 per transaction by late 2017. For a typical $30 video-game purchase, a $20 fee made the transaction economically nonsensical. Steam also cited Bitcoin's price volatility — the price could swing 5–10% between the moment a customer initiated checkout and the moment the transaction confirmed, making it impossible for the merchant to know how much fiat-denominated value they were actually receiving. Steam was an early and committed adopter; its withdrawal signaled that even technically sophisticated merchants with substantial Bitcoin volume could no longer make the economics work.

December 17, 2017 — BTC reaches its all-time high of approximately $19,500. The merchant-acceptance collapse and the speculative-price peak occur within eleven days of each other. The price was rallying while the network was failing as a payment system. These two facts being simultaneous on the same chain is itself a structural observation: the BTC chain by late 2017 had become better suited for speculation than for payments, and the protocol changes that made it so were the same changes that broke its merchant-acceptance case.

Late December 2017 to early January 2018 — Average BTC transaction fees peak at approximately $54 , with individual transactions during congested periods reportedly costing over $60 . The North American Bitcoin Conference, scheduled for Miami in mid-January 2018, announces that it will stop accepting Bitcoin for ticket purchases , citing "network congestion and manual processing" — a Bitcoin-focused conference unable to accept Bitcoin for its own tickets is the iconic image of this period.

January 22, 2018 — Microsoft temporarily suspends Bitcoin payments at the Microsoft Store, citing "instability." Microsoft later restores partial acceptance but at substantially reduced scope from its 2014 implementation.

January 24, 2018 — Stripe , the dominant payments-infrastructure company, announces it will phase out Bitcoin support entirely by late April 2018. Stripe's stated reasons, as reported by industry press: "declining demand, rising fees and longer transaction times." Stripe had been a flagship adopter — its withdrawal removed Bitcoin acceptance from thousands of online merchants who had relied on Stripe's checkout integration.

April 2018 — Stripe's Bitcoin support fully ends.

Mid-2018 — Crypto merchant-processor receipts collapse. Industry data from companies including BitPay, Coinify, and GoCoin shows merchant-processed Bitcoin payment volume falling from approximately $411 million in September 2017 to approximately $60 million in May 2018 — a decline of roughly 85% in eight months. This decline is occurring while the BTC price (though off its December 2017 peak) remains substantially elevated against its pre-2017 baseline. Merchants are not abandoning Bitcoin because Bitcoin is cheap; merchants are abandoning Bitcoin because using Bitcoin for payments no longer works for them.

2018–2020 — Steady attrition continues. Expedia drops direct Bitcoin acceptance. Fiverr drops Bitcoin acceptance. Most merchants who continue to "accept Bitcoin" do so through payment-processor intermediation — the processor receives Bitcoin from the customer, immediately converts to fiat, and settles to the merchant in their local currency. The merchant does not actually hold Bitcoin at any point. This is structurally a credit-card-style settlement model with Bitcoin as the transit asset, not Bitcoin functioning as the merchant's accepted currency.

Putting this chronology beside the protocol-change chronology gives the structural picture. The merchant-adoption peak (February 2015, ~100,000 merchants) preceded the 1MB cap binding meaningfully (2015–2016) and the RBF activation (February 2016). The merchant-adoption collapse (peak in December 2017 through April 2018) immediately followed the period in which RBF was operationally deployed, fees were escalating uncontrollably, and SegWit was activating without addressing the underlying capacity constraint. Steam's December 2017 withdrawal — citing the $0.20-to-$20 fee escalation explicitly — is the empirical signature of exactly the dynamics the structural argument above describes.

The merchant who stopped accepting Bitcoin in 2017–2018 was responding to a real change in what Bitcoin was. They were not making a market call against cryptocurrency. They were making a practical call against a payment system that no longer worked as a payment system. The protocol changes that produced that response were the same protocol changes that the document has been describing in their specification-fidelity terms: the cap, RBF, SegWit. The merchant-acceptance collapse is the empirical evidence that those changes had real-world consequences.

The Bitcoin Cash chain did not adopt RBF in either form. Transactions on BCH remain non-reversible upon broadcast in the way the whitepaper specified. Merchants on BCH can accept 0-confirmation payments with the same confidence that the original Bitcoin design provided. This is one of the concrete divergences between the two chains, measured directly against the §1 text — and the divergence has direct consequences for which chain can actually function as peer-to-peer electronic cash in the merchant-acceptance sense the whitepaper's title names.

VI · SegWit

The validation shift.

SegWit — Segregated Witness — was activated on the BTC chain in August 2017. The technical mechanism: separate the digital signatures (the "witness" data) from the main transaction data and store them in a parallel structure. The stated purposes included fixing transaction malleability, enabling certain second-layer protocols (notably Lightning), and providing an effective block-size increase without changing the literal 1 MB limit.

The actual capacity gain

The base block size on the BTC chain remains capped at 1 MB. SegWit introduced a weight unit system that discounts witness data (counting it as 1 weight unit per byte rather than 4 weight units per byte for legacy transaction data), with a maximum block weight of 4 million weight units. In practice, this produces typical effective block-carrying capacity of approximately 1.7 MB with the transaction mix actually observed on BTC, varying between roughly 1.3 MB and 2.3 MB depending on the ratio of legacy to SegWit transactions. The theoretical maximum of 4 MB-equivalent is reached only in extreme cases dominated by witness-heavy transactions (such as inscriptions and Ordinals). The capacity increase delivered by SegWit, measured against the 1 MB pre-SegWit baseline, is therefore approximately 70 percent — meaningfully less than a doubling. The block-size proposals on the table during 2015–2017 ranged from a 2 MB doubling (Bitcoin Classic) to 8 MB starting with doubling every two years (BIP 101) to up to 32 MB miner-voted (BIP 100). SegWit's ~70 percent capacity increase was substantially smaller than any of these proposals, while carrying the architectural costs documented in this section (§2 coin-identity break, §7/§8 verification architecture degradation, anyone-can-spend treatment of witness data by pre-SegWit nodes). The capacity gain was modest; the architectural cost was substantial.

The structural consequence of separating signatures from transactions, measured against whitepaper §2, requires careful reading.

Section 2 specifies that an electronic coin is a chain of digital signatures. The signatures are not metadata about the coin; they constitute the coin's existence and chain of ownership. A payee verifies ownership by checking those signatures directly. The relationship between coin and signature, in the whitepaper's specification, is identity, not annotation.

SegWit modifies this relationship. Signatures are moved out of the transaction data structure and into a separate witness structure. For nodes that understand SegWit, this is a presentational change — they can read the witness data and perform verification as before. For nodes operating under the pre-SegWit protocol, the signatures are no longer where they were specified to be. These nodes can still see SegWit blocks pass through the network, but they cannot independently verify the signatures protecting the SegWit outputs in those blocks. From a legacy node's perspective, SegWit outputs are "anyone-can-spend" outputs that the legacy node treats as valid because someone else verified them.

This is the structural change. Legacy nodes after SegWit activation are no longer performing verification in the §2 sense. They are accepting blocks because the SegWit-running majority validated them. The security model specified in §1 and §11 — honest nodes refusing invalid transactions, the network secure as long as honest nodes control more CPU power than attackers — depends on those nodes actually verifying . A node that cannot verify cannot refuse. It can only accept on faith.

The framing of SegWit as a "soft fork" deserves examination. The technical definition of a soft fork: a consensus rule change that is strictly more restrictive than the previous rules, allowing legacy nodes to continue accepting blocks under the new rules even though they don't enforce the new rules themselves. By this definition, SegWit is a soft fork — legacy nodes do continue accepting blocks.

But this definition does not capture what changed. A more honest taxonomy would distinguish three categories:

Category 1 
Trivial soft fork

New rules are strictly tighter than old rules. Legacy nodes' verification remains meaningful under the new rules — they may not enforce everything the new rules require, but what they do enforce is correct. No security degradation. The honest nodes of the whitepaper security model are still doing the verification they were specified to do.

Category 2 
Coercive soft fork

New rules introduce data structures that legacy nodes cannot parse or verify. Legacy nodes accept blocks but cannot independently confirm the validity of the new structures. Their participation degrades from "verifying" to "trusting the upgraded majority verified correctly." The security model changes even though block acceptance does not. Legacy nodes can either capitulate to non-verification, or upgrade. They cannot stay where they were and continue doing what they were doing.

Category 3 
Hard fork

Explicit incompatibility between rule sets. The chain visibly splits. Both sides openly carry different rules. No ambiguity about what changed.

SegWit was Category 2, framed and presented as Category 1. The framing was rhetorically accurate (legacy nodes did accept blocks) but structurally misleading (legacy nodes could no longer verify what they had previously verified). The "soft fork" label suggested that nothing important had changed for non-upgrading participants. In substance, what had changed for non-upgrading participants was that their verification capability had been silently disabled.

The softness was purchased, not intrinsic — and the split between verifying and mining nodes is where it shows. A non-upgraded verifying node (one that checks blocks but does not produce them) keeps checking against the old rules, and in normal operation it accepts SegWit blocks, because a SegWit spend appears to it as the spending of an anyone-can-spend output, which the old rules permit. Such a node does not diverge — it stays on the chain, silently downgraded from verifying signatures to trusting that someone else did. A non-upgraded mining node (a block producer) is the other case. If it produces a block under the old rules that violates SegWit's — for instance, spending a SegWit output without a valid witness, valid to old nodes but invalid to SegWit nodes — the SegWit-enforcing majority orphans that block. The old-rules miner is thereby economically forced to adopt SegWit or have its blocks discarded. The no-split outcome is therefore not a property of the change: it is bought, block after block, by the majority of hashpower enforcing SegWit. Withdraw that majority and the old-rules chain diverges — a hard fork in fact , not merely in security-model terms. The "soft" in "soft fork" was the coordination of mining power, not the code — which is why the coercion documented below was required to produce it.

The activation dynamics reinforce this reading. Miners did not voluntarily adopt SegWit out of technical enthusiasm. The activation was pressured through the UASF (User-Activated Soft Fork) threat, exchange signaling, and miner coordination. The mining majority adopted SegWit because the alternative — maintaining the legacy protocol while a SegWit-enforcing minority operated separately — would have produced a visible chain split, which the coordinating actors wanted to avoid. The hashpower coordination is what made SegWit appear smooth. Without that coordination, the change would have been visible as the hard fork (in security-model terms) that it structurally was.

A node performing actual whitepaper-spec validation on the BTC chain after SegWit activation has exactly two choices: capitulate to non-validation, or diverge into irrelevance. The "soft fork" framing presents the first option as if it preserves the node's role. It doesn't. It preserves the node's block-acceptance behavior while eliminating its security contribution.

SegWit and the verification architecture of §7 and §8. The §2 violation described above is the most direct whitepaper conflict SegWit introduces, but it is not the only one. SegWit also undermines the verification architecture that §7 (Reclaiming Disk Space) and §8 (Simplified Payment Verification) specify, in a way that is even more structurally significant.

Both §7 and §8 depend on a single critical property: the Merkle root in the block header must fully commit to everything that determines whether transactions in the block are valid. The §7 pruning mechanism — full nodes discarding old transaction data while preserving the header chain — works because the header's Merkle root commits to the transactions that produced it. A pruned node can verify any transaction by being given the transaction plus a Merkle proof that hashes correctly to the committed root. The §8 SPV mechanism — lightweight clients verifying payments without running full nodes — works for the same reason. The SPV client maintains only block headers and requests Merkle proofs from full nodes for transactions it cares about; the proofs verify against the header's root.

SegWit moves signature data — the witness — out of the transaction structure that the original Merkle root commits to, into a separate witness structure with its own commitment scheme. The block header's original Merkle root no longer commits to the signatures. Signatures live in a parallel witness data structure with a separate witness commitment, anchored differently in the block structure.

The consequence for pre-SegWit nodes operating under SegWit-active rules: the block header's Merkle root commits to transactions whose signatures have been stripped. The pre-SegWit node sees a Merkle root that commits to transactions, but the transactions the root commits to are not the full transactions. The signatures live elsewhere, in a structure the pre-SegWit node does not see and cannot validate against. The architectural property the whitepaper specified — that header commitment equals validity commitment — no longer holds. A pre-SegWit node is verifying block structure against header commitment, but it is not verifying transaction validity in the full sense the original architecture provided. It can prune transaction data because it has the header committing to it, but the header does not commit to the witness data that determines whether the spending was authorized. It is pruning data it was never validating.

The consequence for SPV clients built against the original §8 specification is parallel. The §8 architecture assumes that a Merkle proof against the block header's root is sufficient to verify a transaction. Under SegWit, this is no longer true. An SPV client could receive a Merkle proof showing a transaction is included in a block, but the inclusion proof does not tell the client whether the witness data — which determines whether the transaction was actually authorized — is valid. The SPV client would need a separate proof against the witness commitment, which lives in a different place in the block structure and which the original §8 architecture did not anticipate.

This compounds with the §2 problem. §2 specifies a coin as a chain of digital signatures, where each transfer's signature becomes part of the transaction hash that subsequent transfers reference. SegWit's removal of signatures from the transaction proper means transaction IDs no longer include signatures, breaking the §2 specification of coin identity. The §7 and §8 architecture, which depends on header commitment equaling validity commitment, is broken because the original Merkle root no longer commits to authorization-relevant data. Three load-bearing sections of the whitepaper are affected by SegWit, not one.

The degradation is structurally entrenched. Restoring the original architecture — re-coupling the witness to the transaction's identity so that the header's Merkle root again commits to authorization data — would mean undoing the malleability fix and changing how existing SegWit outputs are referenced: a disruptive hard fork that breaks live coins. No such reconstruction has been part of the BTC roadmap; the direction has been the opposite — Taproot (2021) builds further on the SegWit witness structure, so each later change deepens the dependence on the post-SegWit commitment model and raises the cost of any return. What §2, §7, and §8 lost was not restored, and the roadmap has made restoration progressively more costly. Bitcoin Cash, having never adopted SegWit, retains the original commitment architecture and faces no such reconstruction.

The §7 and §8 architecture is how the whitepaper specifies scaling. Pruning allows full nodes to operate without storing complete chain history. SPV allows lightweight clients to verify payments without running full nodes. Together these mechanisms are how the system was designed to support a large user base — most users on SPV clients, infrastructure operators on pruned full nodes, miners and businesses on archival full nodes. SegWit's modification of the commitment structure means that §7-pruned nodes and §8 SPV clients no longer have the verification guarantees the original architecture specified. They have something weaker: structural validity (the chain is well-formed) without authorization validity (the spends are authorized).

A SegWit-aware node maintains both commitments and gets full validation. A pre-SegWit node, an SPV client built against the original §8 specification, or any verifier operating only on the original Merkle root structure, gets degraded validation that the original architecture did not contain. The degradation is structural and silent. The "soft fork" framing makes it invisible.

The status of §8 SPV on BTC as of 2026

The whitepaper §8 SPV architecture (BIP 37 in the BTC codebase) is no longer maintained as a recommended client architecture on BTC. The BTC development community has formally declared BIP 37 SPV insecure, citing "known flaws that weaken the security and privacy of clients and allow denial-of-service attack vectors on full nodes." The replacement architecture is BIP 157 / BIP 158 (commonly called Neutrino, after the Lightning Labs reference implementation), with status "Deployed" since 2019. Neutrino works fundamentally differently from whitepaper §8: instead of clients downloading block headers and requesting Merkle proofs from full nodes for specific transactions, full nodes generate compact filters (~20 KB per block) that clients download and check locally against their own addresses. This is approximately 250× more bandwidth per block than the original §8 mechanism required. The filter commitments are not anchored in the block header chain; they live in a separate commitment structure. Adoption in the BTC mobile wallet landscape has been slow; most light clients on BTC continue to use electrum-server-style architectures that rely on trusted full nodes, which is itself a departure from §8's trustless model. The structural fact: the verification model the whitepaper §8 specifies is not the verification model BTC operates with in 2026. The original specification has been deprecated and replaced with a different architecture that has different security properties, different bandwidth requirements, and different trust assumptions. BCH, by contrast, retains the original §8 SPV architecture as one of multiple supported client architectures.

The big picture, observable evidence

Looked at as a sequence rather than a series of separate technical decisions, the SegWit activation operation has three observable structural components, each documented independently in this section and Section III:

(A) A group of developers with documented ties to financial institutions (Blockstream / AXA / iFinex), high-frequency trading (Chaincode / Hudson River Trading), derivatives infrastructure (BitMEX), and layer-2 business models (Lightning Labs, Blockstream's Lightning team, Spiral) proposed an upgrade that — when examined technically — required the same kind of coordination that hard forks require, while framing it as a "soft fork" that did not.

(B) The same group coordinated public pressure on miners to adopt the new rules. The pressure was openly described as coercion in the campaign's own materials: orphan-block threats, social-media campaigns, threat communication through forums and Twitter, exchange coordination. The Bitmain real-time documentation characterized the operation as "an attack." The Braiins anniversary post celebrated that "the pressure from the UASF was enough to force miners to adopt SegWit."

(C) The mechanism by which compliance was enforced was the threat of revenue destruction. Miners who did not adopt SegWit would have their blocks orphaned by the coordinating nodes; the SegWit-aligned portion of the economic network would refuse to buy coins from non-compliant chains, making continued operation economically unsellable. The combined threat is functionally identical to economic coercion in any other context — comply with these rules or be denied access to the market that prices your output. The mechanism is structurally identical to extortion regimes that operate through control of distribution rather than control of production.

The technical surface (signature restructuring, Merkle commitments, witness data) is a technical implementation. The operational layer (orphan-block threats, coordinated economic pressure, refusal-to-deal mechanics) is a coercion regime. The institutional layer (who organized, who funded, who benefited) is a question of corporate-finance and intermediation-business interests. Examined at all three layers, the operation is not a neutral protocol upgrade; it is a coordinated economic action by a group whose employment and funding aligned with the protocol direction the operation produced.

The UASF operation read against the whitepaper. The August 2017 events were not an attack on the whitepaper's specific §11 attack vector, and getting the reading right matters. Section 11 (Calculations) addresses one specific scenario: an attacker attempting to modify recorded transactions by mining a longer alternative chain that overtakes the honest chain's accumulated work. The math in §11 calculates the probability that an attacker with less than majority CPU power could catch up and rewrite chain history through proof-of-work competition. The defense mechanism §11 specifies is honest-majority hashpower; the attack vector §11 models is mining-based chain reorganization.

The UASF was not an instance of this. No coordinating group attempted to mine an alternative chain to reverse transactions; no party attempted to overtake the honest chain through accumulated hashpower; no §11-style reorganization attack occurred. The UASF mechanism operated at a different layer entirely. The threat to miners was not that the UASF coalition would out-mine them; the threat was that the economic network — exchanges, businesses, payment processors, the institutional infrastructure that determines which chain has market value — would refuse to recognize the existing-rules chain as Bitcoin. Miners who continued mining the existing-rules chain would produce blocks containing transactions in coins that the economic network would not accept.

This is structurally adjacent to §11's "cooperating group of attacker nodes" language but is not the attack §11 specifies a defense against. §11 protects against mining attacks on transaction history. The UASF operated above that defense, at the social and economic layer where chain legitimacy is determined by network-effect commitments rather than by accumulated proof-of-work. The whitepaper's §11 security model was not defeated in August 2017 in the sense of being attacked through its specified vector and failing; it was circumvented by an attack that operated at a layer §11 did not directly anticipate.

The more directly applicable whitepaper sections are §1 and §12.

§1 (Introduction) specifies that the system's design purpose is to remove trusted third parties — "allowing any two willing parties to transact directly with each other without the need for a trusted third party." The UASF operation was organized by a specific coordinating group (the UASF developer faction, the institutional layer documented in Section III, the exchanges and businesses that publicly committed to following the UASF chain). The operation reintroduced a coordinating-third-party layer that determined which rules would be enforced and which chain would be recognized as Bitcoin. This is structurally an attack on §1's anti-intermediation principle, not on §11's anti-reorganization defense. The third parties §1 specifies the system displaces returned as the entities deciding the protocol's direction.

§12 (Conclusion) states the whitepaper's closing principle: "The network is robust in its unstructured simplicity. Nodes work all at once with little coordination." The UASF was the structural opposite of this — a high-coordination operation organized through specific channels (developer communications, social-media campaigns, coordinated exchange announcements, threat messaging through Twitter and Medium and Reddit), executed through specific threat mechanisms (block orphaning by UASF nodes, economic recognition refusal by participating exchanges), and depending on the success of that coordination to produce the rule change. The whitepaper's described mode of operation — low-coordination, structurally simple, robust through unstructured competition — was inverted by an operation that required high coordination among a small group to force rule change against the existing-rules miners.

§11 still applies, but in the broader sense. §11's principle that security depends on honest nodes following the existing consensus rules collectively does map onto what happened, even if the specific attack vector §11 models (mining-based reorganization) is not what the UASF actually did. The miners who continued operating under the existing consensus rules were, in §11's technical sense, the honest nodes. The UASF coalition was a cooperating group attempting to impose new rules — adjacent to §11's "cooperating group of attacker nodes" language even though the attack mechanism differed from the one §11 calculates probabilities for. The cooperating group succeeded not by overwhelming honest hashpower (§11's specific scenario) but by capturing the economic-recognition layer that determines which chain miners can profitably mine. The honest nodes — the miners — were forced through economic coercion at a layer above §11's defense into coordinating dishonestly with respect to the original consensus rules.

The dominant framing of the UASF inverts what actually happened. The UASF was presented by its proponents as "users defending Bitcoin against dishonest miners who refused to upgrade." Read against §1, §11, and §12 together, the structure is the opposite: a high-coordination institutional faction (in violation of §12's low-coordination principle) operating through reintroduced trusted-third-party mechanisms (in violation of §1's anti-intermediation purpose) succeeded at forcing the existing-rules miners (the honest nodes per §11's technical definition) into rule change through economic-network coercion that operated above the §11 mining-based defense. The UASF was not "users defending Bitcoin." It was an institutional operation that succeeded by attacking Bitcoin at structural layers the whitepaper's specific defense mechanisms did not anticipate.

The August 2017 events were not a §11-style mining attack on transaction history. They were a multi-layer institutional operation that succeeded by attacking the chain at the social and economic-network layers — layers the whitepaper described principles for in §1 (anti-intermediation) and §12 (low-coordination simplicity) but did not specify defense mechanisms for. The honest nodes — the existing-rules miners — were not overwhelmed by superior hashpower. They were rendered economically untenable by a cooperating group that captured the economic-recognition layer that determines which chain has market value. The defense §11 specifies was not defeated; it was circumvented.

What's been built on SegWit since 2017 — Lightning's commitment-transaction format, Taproot's witness-version mechanism, the policy shift toward layer-2 architectures — all depends on the witness segregation introduced in 2017. The change was not just a one-time modification; it was a foundation for a different architectural direction than the whitepaper specified. The Bitcoin Cash chain did not adopt SegWit, which is why subsequent BTC-side changes that depend on SegWit (Taproot, certain Lightning capabilities) do not apply to BCH.

VII · Lightning

The layer-2 distraction.

The Lightning Network was promoted as Bitcoin's scaling solution beginning around 2015. The pitch: rather than increasing on-chain capacity, build payment channels off-chain that batch transactions and settle to the main chain periodically. Each channel is a smart contract committing some BTC to a two-party (or multi-party) state that updates without on-chain transactions until the channel closes. The promise: low fees, instant settlement, theoretically unlimited scaling.

Satoshi had been asked about exactly this kind of architecture and had rejected it. The 2010 Bytemaster "bit-bank" proposal — described above in Section II — was structurally the same idea, and Satoshi's response was that Bitcoin's design supported scaling on-chain through SPV and pruning, not through second-layer aggregation. James A. Donald's 2008 "binks" proposal was also rejected on similar grounds. The Lightning architecture was not novel in concept; what was novel was the political success of promoting it after the 1 MB blocker faction had captured the development direction of the BTC chain.

Four structural critiques of Lightning are worth stating directly, because they have been made consistently by big-block advocates throughout the period 2015–2026 and the technical reality has borne them out.

1. Centralization and custodianship. Lightning channels require liquidity to be staged in advance — both inbound (to receive payments) and outbound (to send them). For an individual user, managing channel liquidity is technically complex and operationally costly. The path of least resistance for ordinary users is to delegate liquidity management to a Lightning Service Provider (LSP), which means handing custody (or near-custody) of their channel state to a third party. The "trustless peer-to-peer" promise of Bitcoin is reintroduced as a "trust your LSP" requirement at the Lightning layer. This is the exact pattern §1 of the whitepaper identifies as the problem Bitcoin was designed to solve.

2. The peg-asset structure. A Lightning balance is not BTC. It is a commitment-transaction state that can be redeemed for BTC by closing the channel — at which point an on-chain transaction is required, at whatever fee the BTC chain demands at that moment. During the lifetime of the channel, the balance exists as a contract obligation rather than as on-chain Bitcoin. This is structurally equivalent to a pegged or wrapped asset: the Lightning balance derives its value from the underlying BTC commitment, but it is not BTC. The relationship is closer to a bank deposit (claim on the underlying asset) than to physical cash custody. The whitepaper specified Bitcoin as electronic cash, not as an asset whose claims live in a separate layer.

3. Fractional reserve risk. Once Lightning carries claims that are structurally distinct from on-chain BTC, the door opens for those claims to exceed on-chain backing in aggregate. LSPs holding deposits, custodial Lightning wallets, channel coordinators with offline state — each represents an institution that could issue Lightning-denominated claims in excess of its actual BTC backing if oversight failed. This is the same mechanism by which gold certificates exceeded vaulted gold during the gold standard era. The parallel is structural: an asset that lives in a layer of indirection is an asset that can be over-issued by the layer's operators, and only audit (or refusal to trust at all) can prevent this.

4. The scaling claim does not survive examination. Lightning's "theoretically unlimited" scaling assumes that channel openings and closings are cheap — but channel state changes require on-chain transactions, and on-chain transactions on the BTC chain are expensive precisely because of the 1MB block limit that Lightning is supposed to solve. The proposal is recursive: scaling solves the fee problem by requiring on-chain transactions to enter and exit, which generates more on-chain transactions, which raises fees, which makes the on-chain entry and exit expensive. For occasional power users with persistent channels to other power users, Lightning may work. For the small casual transactions §1 of the whitepaper specified Bitcoin to enable, it does not work — those users cannot afford to open and close channels.

A representative critique from the BCH community

"Scaling with Lightning will require a lot of onchain transactions, people will want to move funds back and forth, that will cost more money than simply supporting bigger blocks. Second reason is that the lightning peg is based on trust — if the Lightning Network can issue any other token or stablecoin to make transactions with, nothing prevents it from issuing more Lightning BTC at some point. Also lightning is something like a derivative, not real asset. A derivative is an asset which value derives from something else."

— Anonymous, r/btc, posted as discussion of Lightning's structural limitations.

The Lightning Network has been "the BTC scaling solution" for over a decade. Its actual usage statistics — channel count, capacity, routed volume — remain a tiny fraction of what would be required for it to function as the scaling layer for a globally adopted payment system. The on-chain capacity that Satoshi specified as sufficient for Visa-scale transactions has been deliberately not built on the BTC chain, while a layer-2 architecture has been promoted as the alternative — an alternative that Satoshi explicitly rejected when it was proposed during his active period.

The architectural separation between LN and BTC. The four critiques above describe specific functional problems with Lightning. A deeper structural reading goes further: Lightning is not a layer-2 of Bitcoin in the sense the discourse claims. It is a separate network that uses BTC as a configurable settlement anchor through a delegated-trust bridging mechanism. The distinction matters because it changes what the user is actually holding when they hold "Lightning BTC."

Consider what is verifiable from the BTC chain's perspective. A Lightning channel opens with a 2-of-2 multisig transaction broadcast on-chain. This commits a specific amount of BTC to an output that requires both parties' signatures to spend. From this point forward, the BTC chain sees nothing of what happens inside the channel. The chain's view of the channel is frozen at the moment of opening; the chain does not know who currently holds what fraction of the channel's balance, what payments have routed through it, or what its current state is. The BTC chain knows only that an output is locked.

The current state of the channel exists entirely in commitment transactions held by the two parties — transactions that are signed but not broadcast. These commitment transactions are off-chain artifacts that the BTC chain has never seen and cannot verify. When a channel closes (cooperatively or unilaterally), one of these commitment transactions is broadcast, and only at that moment does the BTC chain learn what the channel's final state was.

This produces three structural facts that the LN discourse does not engage with honestly:

LN nodes cannot independently verify the BTC chain through any protocol-level mechanism. The LN protocol requires LN nodes to observe BTC chain state — to detect channel closes, broadcast justice transactions, and monitor counterparty behavior. But the LN protocol does not specify how this observation must occur. An LN node operator can run a local BTC full node, connect to a trusted external BTC API service, use a BIP 157/158 light client, or rely on a watchtower service that observes the chain on their behalf. The verification of BTC chain state is delegated to whatever mechanism the LN node operator chooses. There is no LN-protocol-level consensus mechanism that ensures all LN nodes agree on BTC chain state. Each node trusts its chosen observation mechanism.

LN balance state is not verifiable from outside the channel. The on-chain 2-of-2 multisig commits the maximum the channel can settle for. But the current distribution of value within the channel — who holds what fraction — is known only to the two parties holding the commitment transactions. From outside the channel, the represented balance can be anything the two parties choose to represent. The on-chain commitment bounds the maximum aggregate; it does not bound the internal accounting.

LN can operate with any asset, or with no asset at all. The LN protocol uses BTC's scripting capabilities (multisig, timelocks, HTLCs) as the underlying settlement primitives, but these capabilities are not unique to BTC. The protocol has been ported to Litecoin and operates today on multiple chains. The Taproot Assets Protocol extends LN to handle arbitrary token assets, with channels carrying balances in tokens other than BTC. The connection between LN and BTC specifically is a configuration choice, not a protocol requirement. LN nodes can be configured to handle channels in any supported asset, including assets that have no on-chain backing at all — the protocol does not enforce that channel balances correspond to actual locked reserves on any specific chain.

The structural consequence: LN is best understood not as "Bitcoin payments at scale" but as a separate trust-based payment network whose state is anchored to BTC through optional settlement transactions whose verification is delegated to each node operator's chosen observation mechanism . The "trustless peer-to-peer scaling of Bitcoin" framing presents LN as preserving Bitcoin's consensus properties. The structural reality is that LN has no consensus mechanism, no protocol-level verification of the underlying chain, and no enforcement that LN balances correspond to on-chain reserves. The protocol works on bilateral trust between channel parties, delegated trust to watchtower services for monitoring, delegated trust to chosen chain-observation mechanisms for BTC state, and trust that routing intermediaries will honor their commitments during payment forwarding.

Each of these trust assumptions is documented in the LN specifications and implementations. None of them is hidden from technical readers. What is missing from the dominant discourse is the integration of these trust assumptions into a clear statement of what Lightning actually is versus what its promotional framing claims it to be.

Lightning is not a layer-2 of Bitcoin. It is a separate network that uses BTC as an optional settlement anchor through a delegated-trust bridging mechanism. The protocol has no consensus mechanism. It cannot verify the BTC chain — each node trusts its chosen observation mechanism. It does not enforce that channel balances correspond to on-chain reserves. It can be configured to handle any asset on any chain, or no asset at all. The structural reality of what Lightning is, examined against the trust-elimination model the Bitcoin whitepaper specifies, is a category-different system whose connection to BTC is a configuration choice rather than an architectural necessity.

The recent published critique by Singular Grit (November 2025) frames this directly: "Lightning's outcome is not corruption of design; it is the design, unfolding without deviation. To throttle settlement is to enthrone the custodian. To outsource vigilance is to invite surveillance. To mistake code for law is to mistake mechanism for morality. What began as a rebellion against banks concludes as their digital reincarnation — efficient, compliant, and elegantly enslaved." The critique identifies the structural problem with watchtowers specifically — that the mechanism designed to enforce self-sovereignty either disintegrates into theft when users go offline or matures into custodianship when users delegate vigilance to professionalized services. Either outcome eliminates the trustless property the system claims to preserve.

This is what the BTC discourse has not engaged with honestly: Lightning is presented as the answer to every objection about base-layer payment functionality, while its structural properties contradict the trust-elimination model that the whitepaper specifies as Bitcoin's central distinguishing feature. The "Lightning makes Bitcoin payments scale" framing presupposes that Lightning balances are Bitcoin payments. The structural reality is that Lightning balances are claims against bilateral counterparties, anchored to BTC by configuration choice and verified through delegated-trust mechanisms. A user holding "1 BTC on Lightning" does not hold 1 BTC; they hold a claim against their channel partner that may be enforceable on-chain under specific conditions, may be eroded by counterparty failure, may be lost through watchtower failure, and operates under trust assumptions that the whitepaper §1 was explicitly designed to displace.

The trajectory: configuration as the modification path. The architectural separation between Lightning and Bitcoin produces a specific structural prediction that follows directly from how the two systems are governed. Bitcoin has consensus rules enforced across thousands of nodes globally. Modifying Bitcoin requires either coordinated upgrade through the coercion mechanisms documented in Section III and Section VI, or producing a chain split that the economic network must accept. The capture of Bitcoin took roughly a decade of sustained effort by a well-funded institutional coalition, and even that effort required the documented coercion campaigns and the consolidated information environment to succeed. Bitcoin was difficult to modify, and the modifications are visible in retrospect because every step left documentary traces.

Lightning has no consensus rules. It has implementations. The dominant implementations (LND from Lightning Labs, c-lightning from Blockstream, Eclair from ACINQ, ldk from Spiral) are maintained by a small set of organizations whose institutional alignments overlap substantially with those documented in Section III. Modifying Lightning requires modifying the implementations and the configurations under which they operate. There is no equivalent of BIP activation thresholds, no equivalent of the August 1, 2017 UASF coordination requirement, no equivalent of the SegWit miner-coercion campaign. A configuration change pushed by these organizations propagates through the network as users update their software. No global coordination is required. No public deliberation is required. The change can occur in a release note.

This asymmetry is the structural fact that the Lightning discourse does not engage with. The same institutional coalition that took a decade to capture Bitcoin's consensus rules can modify Lightning's operational properties with a release. The coordination cost is orders of magnitude lower. The visibility of the modification is much weaker. The resistance capacity from the broader user base is essentially absent because most Lightning users do not run nodes that participate in any consensus process — they use provider-mediated services that update on the provider's schedule with the provider's preferred configurations.

The gold standard parallel. The structural trajectory this enables has a precise historical analog. The gold standard worked for an extended period because gold certificates circulated as 1:1 representations of vaulted gold, the system was operationally honest, and the institutions that managed it had not yet decided to change the rules. The decoupling from 1933 onward was incremental: fractional backing was authorized, the ratio shifted, redemption to private citizens was suspended (Roosevelt's gold seizure), the international gold window narrowed, and finally Nixon closed the window entirely in August 1971. The public held certificates whose backing was progressively diluted, then formally eliminated, by decisions made above their participation level. The transitions were not announced as removal of backing; they were announced as stability measures, regulatory updates, technical adjustments. The framing apparatus prevented public engagement with the structural reality until after the structural reality had already been altered.

Lightning has the architectural properties to support the same trajectory and operates within an institutional environment closely resembling the one that produced the gold standard's collapse. The path from current state to complete decoupling can be sketched in stages, each of which is operationally supported by what Lightning already is:

Stage 1 (current): Lightning balances correspond to locked BTC 1:1 by configuration. Channels open with real on-chain commitments. Closing returns the represented balance up to the commitment amount. The system works as advertised when participants are honest and watchtowers function correctly.

Stage 2 (substantially already underway): Lightning Service Providers and provider-mediated wallets become the dominant access pattern for ordinary users. The "everyone runs their own LN node" model has not materialized at scale because operational complexity makes self-custody on Lightning harder than self-custody of base-layer BTC. The first shift from non-custodial to provider-custodial has been operationally completed without formal announcement.

The economic mechanism that drives Stage 2 is direct and bears explicit naming. Opening a Lightning channel requires an on-chain BTC transaction; closing the channel requires another. Both pay the prevailing BTC chain fee. For ordinary users transacting at small scales — the population the whitepaper §1 specifies as Bitcoin's intended users — the on-chain costs of opening and closing personal channels can exceed the value the user wants to transact through the channel during its lifetime. A user planning to send $20 in payments over a month faces channel-open and channel-close costs that may exceed the $20 they intend to transact. The economic logic of running personal Lightning channels falls apart at the scales that matter most to the chain's intended use case. The path of least resistance is not user-by-user choice to use custody; it is the economic impossibility of operating non-custodially. The user does not need to be persuaded into custody by marketing or coerced into custody by regulation. The user is pushed into custody by the economic structure of the captured base layer. The user does not perceive this as a transition because no transition is announced; the wallet works, the payments process, and the architectural shift is invisible from the user's perspective.

The structural symmetry completes here. The captured BTC base layer makes ordinary on-chain operation expensive. The expensive base layer makes ordinary Lightning self-custody uneconomical. The uneconomical self-custody pushes users to Lightning custodial providers. The custodial providers are the institutional layer that benefits from the captured base layer in the first place. The system is closed. Each piece reinforces the others. No piece can be removed without disrupting the others, and no piece reveals itself as part of the broader pattern when examined in isolation. The 1 MB cap is not a separate phenomenon from Lightning custody adoption; it is the same phenomenon operating at two layers, with the same institutional layer benefiting from both.

Stage 3: Fractional backing becomes operationally normal. LSPs issue Lightning-denominated balances that exceed their actual locked reserves on-chain. Because not all users close channels simultaneously, the system remains operationally solvent even when aggregate represented balance exceeds aggregate on-chain backing. The mechanism is identical to fractional reserve banking: as long as withdrawals remain a minority of activity, the operational reality of fractional backing does not surface to users.

Stage 4: Formal fractional ratios. Authority structures explicitly authorize fractional backing of Lightning balances against on-chain reserves. The ratio is set somewhere — 10:1, 100:1 — and the operational reality becomes the formal arrangement. Users continue to use Lightning balances as money; the backing ratio is no longer the user's concern because the practical experience does not change. The 1:1 representation in the user interface is preserved; the backing reality is different.

Stage 5: Complete decoupling. The connection to BTC base-layer reserves is formally severed. Lightning operates with its own token, possibly still called "Bitcoin" or "Lightning Bitcoin" in user-facing language, but with no on-chain backing requirement. The base layer is described as unnecessary, redundant, expensive, environmentally problematic, or whatever framing the discourse environment supports. The base-layer BTC reserves held by major LSPs and institutions may be confiscated, seized, frozen, or made inaccessible through regulatory action against the entities that hold them. Users continue to use what they call "Bitcoin"; what they use is no longer connected to the system the whitepaper describes.

This is the gold standard trajectory applied to a system that has the architectural properties to support it. The trajectory does not require unique malice from the participants. It requires only the same institutional dynamics that produced the gold standard's collapse, operating on a system that is orders of magnitude easier to modify than Bitcoin's consensus rules. Authorities authorize what is operationally happening. Operations expand until they exceed reserves. Reserves are reduced or seized. The link is severed. The framing apparatus presents each step as something other than what it structurally is.

The future changes to Lightning's backing model, redemption mechanics, or asset relationships would not be announced as removal of backing. They would be announced as efficiency improvements, regulatory compliance updates, security enhancements, or scaling solutions. The captured information environment — the same outlets, conferences, and discourse venues that did not engage substantively with the §7/§8 verification architecture being broken by SegWit — will not engage substantively with Lightning's backing ratio shifting. The same institutional coalition that produced the Bitcoin capture is structurally positioned to produce the Lightning capture, with far less effort required because the system has no consensus to resist with.

The same institutional layer that took a decade to capture Bitcoin's consensus rules can modify Lightning's operational properties with a release note. Lightning has no consensus mechanism, no protocol-level enforcement of reserve backing, no global coordination requirement for configuration changes, and no resistance capacity from a broader user base that mostly does not run nodes. The trajectory from 1:1-backed Lightning to fractional-reserve Lightning to completely-decoupled Lightning is not a hypothetical risk requiring novel institutional malice. It is the structurally predicted path of least resistance from where Lightning is today to where the institutional layer's business model is most efficiently served. The gold standard followed this trajectory under similar dynamics; the architectural and institutional conditions for Lightning to follow it are already present.

The structural prediction does not depend on any specific institutional actor choosing to execute it. It depends on the architectural properties of the system, the institutional alignment of the maintainers, the absence of a consensus mechanism to resist changes, the captured information environment that prevents public engagement with structural realities, and the historical pattern of how similar systems have evolved under similar dynamics. Each of these is independently documented. The trajectory is what the documented factors produce when allowed to operate without active resistance — and active resistance is the property the existing system has been designed to minimize.

What the adoption data shows. The trajectory analysis above is structural; the empirical data is also worth examining. Lightning Network adoption metrics through 2025 are publicly available from mempool.space, Bitcoin Visuals, 1ML, and the major Lightning operators themselves. The picture they show is diagnostic.

Public Lightning channel capacity declined from over 5,400 BTC in late 2023 to approximately 3,850–4,200 BTC by August 2025 — a roughly 20–30% drop over less than two years. Public channel counts dropped from a 2022 peak to approximately 41,724 channels by mid-2025, with the decline persistent rather than punctuated. Node counts have followed a similar trajectory. The empirical picture is sustained contraction in the public Lightning network across capacity, channels, and nodes throughout 2024–2025.

The remaining liquidity is heavily concentrated. As of August 2025, the top ten operators controlled approximately 2,389 BTC of the 3,850–3,870 BTC total — roughly 62 percent of public network capacity held by ten entities. Hosting is similarly concentrated: clearnet Lightning nodes (the majority of capacity) are hosted predominantly on Amazon, Google Cloud, DigitalOcean, and Hetzner — major centralized cloud providers operating under US and European jurisdictions. The "decentralized payment network" running on cloud infrastructure controlled by a handful of providers is not the architectural property the discourse claims it to be.

Meanwhile, the user-facing adoption story that is publicly celebrated comes almost entirely from custodial integrations. CoinGate reports Lightning accounting for approximately 16 percent of Bitcoin orders on its platform (up from 6.5 percent two years prior). Coinbase, after integrating Lightning in 2024, reports approximately 15 percent of Bitcoin withdrawals routed through Lightning by mid-2025. Strike, Wallet of Satoshi, Phoenix in semi-custodial mode, Cash App, Revolut (via Lightspark), and a small number of similar providers handle the bulk of user-facing Lightning activity. The user is on Lightning operationally; the user does not run a Lightning node; the user's balance is held by the provider in pooled channels; the provider's chain observation, channel management, and routing decisions are not the user's. This is the stage-2 transition documented operationally in network adoption data: public self-custodial Lightning is contracting, custodial Lightning is growing, and the user-facing growth is concentrated in a small set of provider entities aligned with the institutional layer documented in Section III.

The discursive treatment of the public-capacity decline is itself diagnostic of the captured information environment Vol.14 documents in detail. The pattern in the major BTC-aligned outlets across 2025: the public capacity decline is real and verifiable from mempool.space; the framing in articles covering the decline is uniformly that the decline is "structural evolution," "optimization," "consolidation toward better-managed hub nodes," "channel splicing reducing the need for new channels," or that "public capacity is a lagging and incomplete indicator." Each of these framings may have some technical basis. The pattern of every contraction metric being reframed as evidence of improvement rather than evidence of decline — across many outlets simultaneously, with similar language — is the same pattern documented throughout this volume. The information environment around the BTC ecosystem produces a discourse in which negative empirical signals are systematically reframed as positive structural signals, while positive signals (like the 1,212% growth in routed payments between 2021 and 2023, which occurred during a period of modest capacity growth) are emphasized as evidence of success. The asymmetric reframing is consistent enough across outlets that calling it editorial coincidence becomes structurally untenable.

The empirical adoption picture, read without the reframing, is consistent with the structural analysis. Lightning self-custody is operationally contracting because the economics make it untenable for small users (as documented in the stage-2 analysis above). Custodial Lightning is growing because it is the path of least resistance for users who want fast BTC payments on a chain whose base layer fees make on-chain operation expensive. The institutional layer benefits from this transition; the captured information environment frames the transition as success. The user-perceived experience preserves the appearance of "Bitcoin payments at scale" while the operational reality is that Bitcoin payments at scale, for most users, now means custodial-Lightning payments mediated by a small set of institutionally-aligned providers running on cloud infrastructure under regulatory jurisdiction. The architecture the whitepaper §1 specifies — payments without trusted third parties — is not what Lightning operationally delivers in 2025–2026 for the population the whitepaper's payment-system specification was about.

XI · Side-by-side

What each chain represents now.

The accumulated divergences between BTC and BCH can be summarized directly. The comparison is against the whitepaper specifications cited in Section I, not against any third party's preferred narrative about what Bitcoin "should" be.

Whitepaper property 
Bitcoin 
Bitcoin Cash 

Non-reversibility 
§1. Introduction 

Abandoned. RBF opt-in 2016; full-RBF default 2024. Transactions reversible before confirmation by policy. 
Maintained. No RBF. Transactions non-reversible upon broadcast per the original specification. 

Small casual transactions 
§1. Introduction 

Economically impossible at typical fees. Block-size constraint prevents on-chain handling of microtransactions. 
Economically feasible. Sub-cent transactions routinely processed on-chain. 

Displacement of trusted third parties 
§1. Introduction 

Effectively reversed. High fees push users to custodial exchanges, ETFs, and Lightning Service Providers. 
Direct on-chain use remains the default. Non-custodial wallets handle the standard use case. 

Coin as chain of signatures 
§2. Transactions 

Modified by SegWit. Signatures segregated from main transaction data. Legacy nodes cannot verify witness data. 
Unmodified. Signatures remain in the transaction data structure as specified. 

Honest verifying nodes 
§1. Introduction · §11. Calculations 

Legacy nodes structurally unable to verify SegWit signatures. Security contribution reduced to acceptance-on-faith. 
All nodes can verify all transactions under the protocol they operate. Security model intact. 

Reclaiming Disk Space 
§7. Reclaiming Disk Space 

Base block size capped at 1 MB; SegWit weight-unit system permits typical effective capacity of approximately 1.7 MB. On-chain scaling not implemented as the path; layer-2 architectures promoted as alternative. 
Block size raised to 32 MB. UTXO commitments and pruning implementations active (Bitcoin Verde, BCHD). 

Simplified Payment Verification 
§8. Simplified Payment Verification 

BIP 37 (the §8 implementation) deprecated by the development community as insecure. Replaced by BIP 157/158, which uses different commitment structure, ~250× more bandwidth, and is not anchored in block headers. Most mobile wallets use trusted-full-node architectures instead. 
Original §8 SPV architecture preserved. Wallet implementations available for low-resource devices using header-only verification per the whitepaper specification. 

Privacy 
§10. Privacy 

Address-reuse defaults in most wallets despite §10 specification. Taproot shifts privacy model toward aggregated keys (used across many transactions) and layer-2 privacy rather than protocol-level fresh-key privacy. 
Address-reuse discouraged in standard wallet implementations. §10 specification operationally available without architectural complications introduced by SegWit-Taproot stack. 

Adoption pathway 
§1. Introduction · §7. Reclaiming Disk Space 

The chain's institutional messaging directs ordinary users to off-chain alternatives — Lightning Network, the Liquid sidechain, custodial exchanges, and ETF intermediation rather than to on-chain transactions. "Bitcoin is not for payments — use Lightning" is the explicit position taken by the chain's institutional spokespeople (Ammous 2018, Mitchnick 2025). The base layer is positioned as settlement infrastructure for second-layer architectures and institutional custody, not as the venue for ordinary user transactions. 
On-chain transaction is the primary path. The 32 MB base block size with substantial capacity headroom, the preserved first-seen-safe 0-conf semantics, and the absence of an institutional layer pushing users to layer-2 architectures together produce a coherent stance: ordinary users transact on L1. Layer-2 solutions exist as available options but are not promoted as the scaling path. The base layer is treated as the operational ground for user transactions, consistent with §1's specification of peer-to-peer electronic cash and §7's on-chain scaling architecture. 

The table is empirical. Each cell is verifiable. The pattern across the cells is consistent: the BTC chain has moved away from the whitepaper specifications at every load-bearing point, while the BCH chain has maintained or operationalized those specifications.

This is not a value judgment about which chain is "better." It is a textual claim: one chain operates closer to what was specified in the founding document. The reader who finds the whitepaper authoritative will draw one conclusion. The reader who treats the whitepaper as a starting point that can be revised through subsequent consensus will draw a different conclusion. Both readings are coherent. What is not coherent is denying the divergence itself.

The dominant narrative places BTC as the canonical Bitcoin and BCH as a departure. Measured against the founding text, the relationship is closer to the opposite. The departures have all been on the BTC side; the BCH side has held the original positions on the questions in dispute.

XII · The third chain

Bitcoin SV, the Satoshi Vision claim, and the whitepaper.

The chain landscape in 2026 contains a third Bitcoin lineage that this document has, until now, treated only in passing: Bitcoin SV , where SV stands for "Satoshi Vision." BSV emerged from a November 2018 hard fork of Bitcoin Cash, three years after the events documented in Section II established the institutional alignment that captured the BTC development direction. The project's central claim is that it restores the original Bitcoin protocol as envisioned by Satoshi Nakamoto. Examining that claim requires the same discipline the document has applied to BTC: place the claim alongside the source document it depends on and observe whether they match.

The substantive content of BSV's "Satoshi Vision" has been articulated extensively in the public writings of Dr. Craig S. Wright , the figure around whom BSV's interpretive frame was constructed. This document does not engage with the question of whether Dr. Wright is Satoshi Nakamoto — that question has been adjudicated in court (Mr Justice Mellor, High Court of England and Wales, March 2024, finding that "Dr Wright is not Satoshi Nakamoto. Dr Wright did not author the Bitcoin White Paper" ) and is documented in publicly available judicial records. The structural question that matters here is different: the BSV community has accepted Wright's writings as authoritative explanations of what Bitcoin is and was designed to be. Those writings are on his public blog at craigwright.net and his Medium account. Read against the whitepaper — which is also publicly available — they describe a different system than the whitepaper describes.

Seven specific divergences between Wright's published positions and the whitepaper's text are documented below. Each one places his quoted text alongside the whitepaper's text on the same subject. Anyone able to read both sources can verify the comparison directly.

Pair 1 · On trusted third parties

Whitepaper §1: "An electronic payment system... allowing any two willing parties to transact directly with each other without the need for a trusted third party." 

Wright (craigwright.net, 2019): "Bitcoin does not remove the need for all third parties. Anyone who thinks so should have a read of Coase's seminal contribution to economics in his theory of the firm... at times intermediaries will minimise the costs associated with exchanges even when associated with a system such as Bitcoin." 

The whitepaper's central design purpose is the displacement of trusted third parties. Wright's position is that Bitcoin does not do this.

Pair 2 · On privacy

Whitepaper §10: "Privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous... As an additional firewall, a new key pair should be used for each transaction." 

Wright (craigwright.net, 2019): "In the new privacy model created with Bitcoin, transactions are no longer private. In order to stop the main problem with digital currencies, double spending, it has been necessary to create a system that announces all transactions publicly and which can be viewed and analysed at will." 

The whitepaper's §10 specifies pseudonymity through fresh keys per transaction as the structural privacy mechanism. Wright reframes the privacy property as no longer associated with transactions at all.

Pair 3 · On who can audit what

Whitepaper §10: "The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone." 

Wright (craigwright.net, 2019): "Where every transaction is split into multiple payment amounts and coins, we allow even for the ability to monitor meta data in a manner similar to how a tickertape or stock exchange would aggregate data; everything can be audited without the public knowing all of the information about a transaction... commercial exchanges and contracting cannot occur without knowledge of the other party." 

The whitepaper §10 firewalls identities from the public. Wright reframes the chain as an open audit registry where everything can be monitored.

Pair 4 · On censorship resistance

Whitepaper §11: "The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes." 

Wright ("What is Censorship Resistance," July 2020): "The myth that Bitcoin is designed to be 'censorship-resistant' is just that... Bitcoin is not designed to stop the government from freezing bitcoin, and it is not censorship-resistant. Bitcoin is public. What Bitcoin does is work within the rule of law." 

The whitepaper's §11 specifies the security model that protects the chain from a cooperating group attempting to impose new rules over the honest majority. Wright dismisses the censorship-resistance property as a myth and reframes Bitcoin as operating within the rule of law.

Pair 5 · On reversibility and freezing

Whitepaper §1: "With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need... Transactions that are computationally impractical to reverse would protect sellers from fraud." 

Wright ("What is Censorship Resistance," July 2020): "When I introduced the alert key... I allowed nodes to freeze unspent transaction outputs (UTXOs) and transactions... There are never more than four entities that would be needed to meet a court order of any kind. In other words, a court order against four Bitcoin nodes (miners) may result in a transaction being required to be frozen and then reallocated." 

The whitepaper's §1 makes non-reversibility the foundational property Bitcoin displaces from the trusted-third-party model. Wright frames freezing and reallocation through miner court compliance as a feature.

Pair 6 · On immutability

Whitepaper §11: "To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it... the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added." 

Wright ("What is Censorship Resistance," July 2020): "The ability of Bitcoin's miners to change consensus rules by majority agreement is a feature, not a bug. But it is also proof that what many regard as an immutable blockchain is not actually immutable at all." 

The whitepaper builds immutability into the proof-of-work accumulation mechanism. Wright explicitly denies that the chain is immutable.

Pair 7 · On the relationship to law and authority

Whitepaper: Does not mention government, law, regulation, compliance, identity verification, or audit anywhere in the nine-page document. Specifies a peer-to-peer electronic cash system for online payments. Names only one design purpose: removing the trusted-third-party financial institutions that mediate electronic payments.

Wright (multiple posts, 2019–2021): "Bitcoin is keeping details away from the public; not those who were involved in the exchange and certainly not those who are required by law to monitor exchanges... Bitcoin was designed to ensure privacy and utterly destroy anonymity... Anonymity is the realm of cowards and those without courage." 

The whitepaper is silent on the relationship to government and regulation. Wright fills the silence with statements that center government oversight as Bitcoin's design intent and dismisses cypherpunk-aligned positions as cowardice.

These seven pairs do not exhaust the divergences but they cover the load-bearing ones. Anyone wishing to verify them can read Wright's posts at craigwright.net and his Medium account, and read the whitepaper at bitcoin.org/bitcoin.pdf or any of dozens of mirrors. The pairs are public-record-against-public-record.

Read together, the pairs describe two different systems. The system the whitepaper specifies is a peer-to-peer payment network designed to remove trusted third parties, preserve pseudonymity through fresh keys per transaction, prevent transaction reversal through proof-of-work immutability, and resist cooperating groups attempting to impose new rules through an honest-majority security model. The system Wright's writings describe is a public audit-friendly registry designed to operate within the rule of law, where transactions are no longer private, where chain content is structurally available for compliance monitoring by parties "required by law to monitor exchanges," where miners can freeze and reallocate funds in compliance with court orders, where the immutability property is acknowledged as not actually present, and where the cypherpunk framing of anonymous peer-to-peer exchange is dismissed as the "realm of cowards." These are not minor differences in emphasis. They are descriptions of categorically different systems.

The Satoshi Vision as articulated by BSV's central authority figure is, on the substance, a description of a system that does what the whitepaper says Bitcoin does not do, and does not do what the whitepaper says Bitcoin does . The "restoration of the original Bitcoin protocol" claim depends on this description being faithful to the whitepaper. The description is not.

The BSV chain operates technically. The on-chain capacity is real — the Teranode infrastructure and the multi-gigabyte block demonstrations are real engineering. The protocol-level non-reversibility holds. But the interpretive claim on which the chain's identity rests — that the project represents what Satoshi specified Bitcoin to be — depends on a description of Bitcoin that the whitepaper does not support. The chain exists; the claim that constitutes the chain's identity does not match the source document the claim depends on. The §7 violation noted earlier in this document (Section IX) — that unbounded on-chain data storage operates against the whitepaper's specification that transactions can be discarded once buried — is the technical complement to this interpretive divergence. Both the technical implementation and the philosophical framing diverge from the whitepaper in their own ways.

For readers who wish to verify the seven pairs at greater depth, the companion document What the BSV — Bitcoin Satoshi Vision actually says about Bitcoin provides the full citation chain, additional supporting quotes from Wright's writings beyond the seven anchor pairs, and the structural reading at greater length. This section condenses that material to the minimum necessary to support Vol.13's chain-landscape analysis.

References

Primary sources cited.

Direct quotations and verifiable references

Nakamoto, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System. October 31, 2008. The whitepaper.

Nakamoto, Satoshi. Cryptography mailing list, November 2008. Reply to James A. Donald on scaling.

Nakamoto, Satoshi. BitcoinTalk forum, July 2010. Response to Bytemaster (Dan Larimer) on bit-bank proposals.

Nakamoto, Satoshi. BitcoinTalk forum, October 2010. Response to Jeff Garzik on block size increase mechanism.

Nakamoto, Satoshi. BitcoinTalk forum, December 5, 2010. Appeal to WikiLeaks not to use Bitcoin.

Nakamoto, Satoshi. BitcoinTalk forum, December 11, 2010. "Hornet's nest" warning about WikiLeaks adoption.

Nakamoto, Satoshi. BitcoinTalk forum, December 12, 2010. Final public post (build 0.3.19, DoS controls).

Nakamoto, Satoshi. Email correspondence with Mike Hearn, 2010–2011. Includes the "It never really hits a scale ceiling" scaling explanation and the final April 2011 message ("I've moved on to other things. It's in good hands with Gavin and everyone."). Five emails publicly released by Hearn in 2017.

Hearn, Mike. "The resolution of the Bitcoin experiment." Medium / plan99.net blog, January 14, 2016. Public departure essay documenting the 1 MB blocker capture and information suppression in real time.

Valve Corporation. "In the Steam Community: Bitcoin Payments No Longer Supported." Steam Blog, December 6, 2017. Cites fee escalation from $0.20/transaction to $20/transaction and BTC price volatility as reasons for discontinuing Bitcoin acceptance.

Stripe Inc. "Ending Bitcoin Support." Stripe blog post, January 23, 2018, by Tom Karlo. Cites declining demand, rising fees, and longer transaction times as reasons for phasing out Bitcoin support by April 2018.

CNBC. "Bitcoin conference stops accepting cryptocurrency payments." January 10, 2018. Documents the North American Bitcoin Conference's inability to accept Bitcoin for its own tickets due to network congestion.

Bloomberg. Reports on merchant-processor receipts data from BitPay, Coinify, and GoCoin, 2018. Documents the decline from $411M (September 2017) to $60M (May 2018) in monthly merchant-processed BTC volume.

Ammous, Saifedean. The Bitcoin Standard: The Decentralized Alternative to Central Banking. Wiley, 2018. ISBN 978-1119473862. Foundational text of the 1 MB blocker discursive position, framing Bitcoin as a store of value and settlement network for large financial institutions rather than as a peer-to-peer payment system.

Ammous, Saifedean. SALT Talks #127 podcast, October 2021. Statement on the retirement of the coffee-and-burger payment thesis: "Bitcoin coming into those companies from the balance sheet, not from the [point of sale]." 

Mitchnick, Robbie (BlackRock, head of digital assets). Podcast interview, November 2025, reported in Cryptonews and Bitbo: "For us, and most of our clients today, they're not really underwriting to that global payment network case." Characterizes payments use case as "out-of-the-money option value." 

BitMEX Research. "Bitcoin Open Source Development." 2020 report analyzing employment and funding of Bitcoin Core developers. Found that of 33 active Bitcoin Core developers, only 11 were independent (not on fixed funding from a sponsor organization). The remaining 22 were directly employed or contracted by Blockstream, Chaincode Labs, MIT DCI, Square Crypto, BitMEX, Xapo, OKCoin, Bitfinex, or similar institutional entities.

ChainCatcher. "41 developers support a $1.7 trillion empire: A panoramic analysis of the Bitcoin core development team and its financial backers." December 2025. Comprehensive analysis of the 41 active Bitcoin Core developers as of 2024, including funding sources, geographic distribution, and institutional alignments. Documents Brink as having funded nearly all newcomers to the Bitcoin Core maintainer team after 2022.

van Wirdum, Aaron. "Who Funds Bitcoin Core Development? How the Industry Supports Bitcoin's 'Reference Client'." Bitcoin Magazine, April 2016. Documents the founding of Blockstream by Bitcoin Core developers (Maxwell, Wuille, Corallo, Timón, Friedenbach), the AXA Strategic Ventures investment, and the MIT DCI sponsor list including BitFury, Bitmain, Circle, Chain, Nasdaq, Fred Wilson, and Reid Hoffman.

Coinkite. Advisory announcement, May 15, 2014: "Coinkite Taps Bitcoin Developer Peter Todd For Advisory Role." Coinkite is a hardware wallet provider; Todd has held the "Chief Naysayer" advisory role since 2014.

Harding, David; Todd, Peter. "BIP 125: Opt-in Full Replace-by-Fee Signaling." Bitcoin Improvement Proposals repository. The protocol change that broke whitepaper §1's non-reversibility specification. Merged into Bitcoin Core 0.12.0, February 2016. Bitcoin Core 28.0 (October 2024) changed the default to full-RBF, completing the abandonment of non-reversibility as a chain property.

Historical BTC transaction fee data: blockchain.info, bitcoinfees.com, mempool.space. Annual averages used in this document are rounded from publicly available block-by-block records.

Consumer hard drive cost history: Backblaze hard drive cost trend reports, archived consumer pricing data from Newegg and similar retailers. Storage costs cited in this document reflect approximate consumer pricing in each year (2010: $0.07/GB; 2015: $0.04/GB; 2020: $0.025/GB; 2026: $0.015/GB).

BIP148 / User Activated Soft Fork documentation. UASF Working Group, "BIP148 & UASF FAQ" at uasf.org. Documents the threat mechanism: full nodes running BIP148 software would orphan blocks not signaling SegWit support starting August 1, 2017.

Bitmain. "UAHF: A contingency plan against UASF (BIP148)." Bitmain blog, June 2017. Real-time documentation of the coercion mechanism, including the explicit characterization of UASF as "an attack against users and enterprises who disagree with activating SegWit right now without a block size increase" and the use of the term "wipe out" to describe what would happen to the chain miners continued to mine on if they did not coordinate.

Song, Jimmy. "UASF BIP148 Scenarios and Game Theory." Medium, August 2017. Game-theoretic analysis of UASF scenarios from a 1 MB faction perspective, documenting the explicit reasoning by which miner economic destruction would be used to force SegWit activation.

Braiins. "Anniversary of the BIP148 UASF." Braiins blog, August 2020. Three-year-anniversary retrospective on UASF SegWit activation, characterizing the campaign approvingly: "The pressure from the UASF was enough to force miners to adopt SegWit." 

Osuntokun, Olaoluwa; Akselrod, Alex. "BIP 157: Client Side Block Filtering." Bitcoin Improvement Proposals repository. Status: Deployed. The replacement architecture for BIP 37 (§8 SPV), specifying a new light client protocol based on full nodes generating compact filters that clients download and check locally against their own addresses.

Osuntokun, Olaoluwa; Akselrod, Alex. "BIP 158: Compact Block Filters for Light Clients." Bitcoin Improvement Proposals repository. Status: Deployed. Specifies the filter construction (Golomb-Rice coded sets) used in BIP 157.

Spark. "Bitcoin Light Clients: SPV, Neutrino, and Compact Block Filters." Spark Money research, February 2026. Documents the BTC development community's position that BIP 37 SPV (the §8 specification) has "known flaws that weaken the security and privacy of clients." Quantifies the bandwidth difference: BIP 37 SPV used ~80 bytes per block header; BIP 158 filters are ~20 KB per block (approximately 250× more bandwidth).

Bitcoin Core. PR #16442 (jimpo, 2019): "Serve BIP 157 compact filters." The implementation of BIP 157 in Bitcoin Core that allows nodes with filter indexing enabled to serve compact filters to light-client peers. PR #12254 (jimpo, 2018) implemented BIP 158 filter construction.

Wuille, Pieter; Nick, Jonas; Towns, Anthony. "BIP 341: Taproot: SegWit version 1 spending rules." Bitcoin Improvement Proposals repository, January 2020. Status: Final. Specifies the Taproot output type, key-path and script-path spending mechanics, and Merkleized Abstract Syntax Tree (MAST) commitment structure.

The Capital Pulse / CryptoSlate. "This 'quantum-safe' Bitcoin idea removes Taproot's key-path." February 2026. Documents that Taproot key-path spends dominate at "roughly 60-80% of all P2TR transactions, with script-path usage spiking during specific periods." Source for the data on Taproot adoption split and the script-path information leakage.

Biryukov, Alex; Khovratovich, Dmitry; Pustogarov, Ivan. "Deanonymisation of clients in Bitcoin P2P network." University of Luxembourg, arxiv 1405.7418, 2014. Documents IP-layer deanonymization linking pseudonyms to IP addresses behind NATs, demonstrating that protocol-level pseudonymity does not survive network-layer surveillance even before the broader chain analysis ecosystem matured.

Bitcoin Optech newsletter #156. October 2025. Documents the Taproot descriptor implementation in Bitcoin Core PR #22051, including notes on key aggregation, script-path audit-trail patterns, and the recommendation that internal keys commit to unspendable script trees to prevent attacks against naive key aggregation schemes.

Singular Grit. "Lightning's Velvet Manacles: Watchtowers, Custody, and the Quiet Return of Shadow Banking." Substack, November 12, 2025. Substantive published critique of the Lightning Network's structural properties, identifying that watchtowers either disintegrate into theft (when users go offline without monitoring) or mature into custodianship (when users delegate vigilance to professionalized services). Either outcome eliminates the trustless property the system claims to preserve.

Lightning Labs. LND watchtower documentation. github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md. Documents the watchtower architecture: encrypted blobs, justice transaction broadcasting, the dependence on watchtower availability and honesty.

Decred Documentation. Watchtowers. docs.decred.org/lightning-network/watchtowers/. Documents the structural requirement that LN nodes "respond in a timely manner in case of channel breaches" — the impossibility for "many end-users" to maintain 24/7 monitoring, requiring delegation to watchtower services.

Taproot Assets Protocol. Lightning Labs specification for handling arbitrary token assets through Lightning channels. Documents the protocol's support for assets other than BTC, demonstrating that the connection between LN and BTC specifically is a configuration choice rather than an architectural requirement.

Zhavoronkov, Nikita (Blockchair). "Negative Impact of Taproot on Bitcoin's Privacy Based on the Experience with SegWit." Presentation slides, November 27, 2020 (published in advance of Taproot activation in November 2021). Empirical analysis of the entire chain (~600 million transactions) showing that SegWit's new address types roughly doubled the share of transactions leaking the sender/change distinction (~27% → ~55%, above 70% on some days), arguing the new P2TR type would compound it; documents the change-output clustering vulnerability that each new Bitcoin address-type introduction produces during its adoption period, using SegWit as the worked example for what Taproot was about to repeat.

Ver, Roger; Patterson, Steve. Hijacking Bitcoin: The Hidden History of BTC. May 2024. ISBN 979-8987415603. First-person account from one of the most public early Bitcoin advocates of how the 1 MB blocker faction captured the development direction of Bitcoin from 2014 onward. The book is the most detailed published primary-source account of the events covered in Sections II and III of this volume.

US Department of Justice. United States v. Roger Ver (case filed April 2024). Indictment alleging mail fraud, tax evasion, and filing false tax returns related to Ver's expatriation tax obligations following his 2014 renunciation of US citizenship. Ver was arrested in Spain in April 2024 at the request of the US government; the Department of Justice is seeking his extradition. Public DOJ press release available at justice.gov.

Carlson, Tucker. Interview with Roger Ver, November 2024. Primary-source video account of Ver's perspective on the prosecution.

On the structure of the Ver prosecution: CNBC, "DOJ charges 'Bitcoin Jesus' with $48 million tax fraud, seeks extradition" (May 1, 2024), on the charge counts, the alleged ~$48M IRS loss, and the extradition request; The Block, "Roger Ver, facing 109-year sentence over 'exit tax' scandal, sues Spain to block US extradition," on the nominal sentencing exposure and the detention/extradition posture; and reporting (New York Times, via Blockworks, October 2025) on a tentative ~$48 million monetary settlement to resolve the charges, pending court approval. The 2014 expatriation and the ~$240M November 2017 bitcoin sale are recited in the DOJ indictment.

Cointelegraph. "BCH-Promoting Twitter Account @Bitcoin Suspended, Internet Debates 'Death Of Free Speech'." April 2018. Documents the April 8, 2018 suspension of the @Bitcoin account and its pro–Bitcoin Cash positioning around the chain split. Companion reporting: CCN, "Tweet Firestorm: Twitter Suspends, Then Reinstates, @Bitcoin" (2018), documenting the restoration and follower loss.

Cointelegraph. "Crypto World Skeptical as @Bitcoin Twitter Account Ditches BCH Support." 2019. Documents the post-sale reversal of the account's Bitcoin Cash advocacy following the August 2019 change of ownership.

Decrypt. "Who owns @Bitcoin on Twitter and why are they selling ads?" 2019. Documents the account's anonymous ownership, the leased OAuth-access arrangement and its early-2018 termination, the 2019 sale, and Roger Ver's denial of ownership ( "I've never owned the @Bitcoin account… owned by someone involved in Bitcoin since 2009… supports #BCH… has chosen not to make his identity public." ). Companion reporting: news.bitcoin.com, "Attempts to Deplatform @Bitcoin Account Reveal Private Message With Twitter CEO" (2018).

On the platform-level free-speech / moderation debate that the @Bitcoin suspension instantiated: NPR, "Elon Musk is using the Twitter Files to discredit foes and push conspiracy theories" (December 14, 2022), documenting the December 2022 release of internal Twitter moderation records to selected journalists following Musk's October 2022 acquisition; Musk's public framing that "moderation is a propaganda word for censorship" and that Twitter is "the digital town square"; and FIRE (thefire.org), "Free speech culture, Elon Musk, and Twitter," on the contested question of whether private-platform moderation constitutes censorship.

Wright, Craig S. "Bitcoin Is Anything BUT Anonymous." Personal blog at craigwright.net, October 2019; also republished on Medium (@craig_10243). Source for Pairs 1, 2, 3, and 7 in Section XII. Statements include: "Bitcoin does not remove the need for all third parties" ; "In the new privacy model created with Bitcoin, transactions are no longer private" ; "Everything can be audited without the public knowing all of the information about a transaction" ; "Bitcoin is keeping details away from the public; not those who were involved in the exchange and certainly not those who are required by law to monitor exchanges." 

Wright, Craig S. "What is Censorship Resistance." Personal blog at craigwright.net, July 10, 2020. Source for Pairs 4, 5, and 6 in Section XII. Statements include: "The myth that Bitcoin is designed to be 'censorship-resistant' is just that... Bitcoin is not designed to stop the government from freezing bitcoin, and it is not censorship-resistant" ; "When I introduced the alert key... I allowed nodes to freeze unspent transaction outputs (UTXOs) and transactions" ; "A court order against four Bitcoin nodes (miners) may result in a transaction being required to be frozen and then reallocated" ; "What many regard as an immutable blockchain is not actually immutable at all." 

Wright, Craig S. "The false lure of anonymity." Medium (@craig_10243), 2020. Source for the explicit framing that "Bitcoin was designed to ensure privacy and utterly destroy anonymity" and that "Anonymity is the realm of cowards and those without courage." 

Wright, Craig S. "We don't want to lead with 'anonymous.'" Medium (@craig_10243), December 2021. Additional context on Wright's stated framing of Bitcoin's relationship to government regulation: "There has been no point in Bitcoin's history where it was outside the reach of government, and in fact, there never will be such a point." 

CoinGeek. "Craig Wright's recent blog explains digital signatures and identity in Bitcoin." June 2025. Third-party BSV-aligned publication that quotes and contextualizes Wright's blog statements, including: "Bitcoin... does not attempt to present an anonymous, untraceable system. Instead, it presented a pseudonymous/private system that maintains traceability. Bitcoin, unlike the others, does not mitigate the need for identity." 

Crypto Open Patent Alliance v. Wright. Mr Justice Mellor, High Court of England and Wales, judgment delivered March 14, 2024, written judgment May 20, 2024. Ruling: "Dr Wright is not Satoshi Nakamoto. Dr Wright did not author the Bitcoin White Paper... Dr Wright is not the person who adopted or operated under the pseudonym Satoshi Nakamoto." Wright was subsequently referred to the Crown Prosecution Service for perjury in July 2024.

BSV Blockchain Association. Official materials and X profile (@BSVBlockchain). Source for BSV's self-positioning as "The Scalable Blockchain for Enterprise & Government. High Throughput, Low Fees, Micropayments, Big Data, Smart Contracts, Tokens. Law & Environment-friendly." 

mempool.space. Lightning Network statistics dashboard. Source for the August 2025 capacity figure of 3,850–3,870 BTC, the 41,724 channel count, the persistent decline through 2024–2025, the cloud-hosting breakdown (Amazon, Google Cloud, DigitalOcean, Hetzner), and the top-10-operators concentration of 62 percent of capacity.

Bitcoin News (news.bitcoin.com). "Data Shows Sustained Slide in Lightning Network Capacity, Channels Through 2025." August 27, 2025. Documents the ~1,500–1,700 BTC decline in public Lightning capacity from mid-2024 to August 2025 and the concentration of remaining liquidity among a small set of top operators.

CryptoSlate. "Why Lightning Network Capacity Declining 20% in 2025 is NOT as Bad as it Sounds." August 6, 2025. Documents both the empirical capacity decline (5,400 BTC late 2023 → 4,200 BTC August 2025) and the reframing pattern in which the decline is presented as structural evolution rather than contraction.

CoinGate. Annual report data through 2024–2025. Source for Lightning accounting for approximately 16 percent of Bitcoin orders on the platform by 2024, up from 6.5 percent in 2022 — illustrating that user-facing Lightning growth is concentrated in custodial-exchange flows.

Lightspark / Coinbase. Reports through mid-2025 indicating approximately 15 percent of Bitcoin withdrawals on Coinbase routed via Lightning following the 2024 integration — further evidence of growth concentrated in custodial provider flows.

Andresen, Gavin. Email to Satoshi Nakamoto, April 26-27, 2011. Disclosure of In-Q-Tel/CIA presentation invitation, later made public on BitcoinTalk. Andresen presented at CIA headquarters on June 14, 2011.

Andresen, Gavin. "Bitcoin Core Maintainer: Wladimir van der Laan." Bitcoin Foundation blog, April 7, 2014. Formal transfer of lead maintainer role.

Blockstream. Series A funding announcement, February 3, 2016. $55M led by AXA Strategic Ventures, Horizons Ventures, and Digital Garage; total raised $76M.

Blockstream. 2021 funding round announcement, August 2021. $210M, with iFinex (Tether/Bitfinex parent) among the investors.

Back, Adam & Nakamoto, Satoshi. Email correspondence, August 2008 – January 2009. Five emails released in 2024 during the Wright v. COPA proceedings.

BitcoinTalk forum. Adam Back's account registration, April 17, 2013 (coinciding with the public disclosure of Satoshi's holdings). Background: Wikipedia, Adam Back .

Dillinger, Ray (Cryddit). BitcoinTalk forum, February 2015. On the origin of the 1MB block limit.

Anonymous. "Satoshi Nakamoto was a big blocker." Medium, June 2021. Chronological compilation of primary-source quotations.

Melamed, Leo. Reuters interview, November 2017. "Tame Bitcoin" statement ahead of CME futures launch.

Hale, Galina; Krishnamurthy, Arvind; Kudlyak, Marianna; Shultz, Patrick. "How Futures Trading Changed Bitcoin Prices." Federal Reserve Bank of San Francisco, Economic Letter 2018-12, May 7, 2018.

Griffin, John M.; Shams, Amin. "Is Bitcoin Really Un-Tethered?" Journal of Finance, June 2018 (working paper); revised and published October 2020.

In re Tether and Bitfinex Crypto Asset Litigation. Consolidated Amended Complaint, U.S. District Court for the Southern District of New York, 2021. Court record establishing iFinex/DigFinex common ownership of Tether and Bitfinex.

Office of the New York Attorney General. Settlement with Bitfinex and Tether, February 23, 2021. $18.5 million paid; cessation of New York trading; no admission of wrongdoing.

U.S. Commodity Futures Trading Commission. Order against Tether Limited, October 15, 2021. $41 million fine for false statements regarding USDT backing.

joshmgreen. "Reclaiming Disk Space on Bitcoin Cash: Pruning, Fast Sync, & UTXO Commitments." read.cash, 2021. Technical description of §7 implementation in the BCH ecosystem.

Bitcoin Core Project. Release notes for version 0.12.0 (BIP 125 opt-in RBF, early 2016) and version 28.0 (full-RBF default, October 2024).

The Block Size Wars · extracted from Vol.13 · Bitcoin Discovery · May 2026

The whitepaper is short. Anyone can read it. The chains are observable. The comparison is direct. Nothing here depends on trust.