Bitcoin Discovery.

The Bitcoin whitepaper, published October 31, 2008 under the pseudonym Satoshi Nakamoto, is the founding specification of the system. Every subsequent question about Bitcoin's identity, design, and direction can be measured against what the paper actually says. The text is short — nine pages, twelve sections — and remarkably specific about what it is proposing and what problems it is solving.

Five passages bear directly on the questions that would later define the block-size conflict.

Four properties are specified in this passage that will matter later: non-reversibility of transactions, the explicit inclusion of small casual transactions as a use case, the displacement of trusted third parties, and the security model that depends on honest nodes — meaning, by implication, nodes that actually perform verification.

The definition is structural: a coin is a chain of digital signatures. Verification is performed by checking those signatures. Any change to where signatures live in the data structure changes what verification means.

This section solves the storage-scaling problem the 1 MB blocker faction would later claim required artificial block-size restriction. Satoshi specified that nodes can prune historical transaction data — discarding everything except block headers and the current UTXO state — without breaking the chain's hash structure. The mechanism is built into the original design.

Section 8 specifies SPV as the lightweight participation mode. Combined with §7's pruning, the architecture allows the network to scale to many transactions without every participant needing to store every byte — but the participants who do validate must actually perform validation for the security model to hold.

The security model rests on honest nodes refusing invalid transactions and invalid blocks. Refusal requires verification. A node that cannot verify cannot refuse. This becomes important when we discuss SegWit.

These five passages — non-reversibility, coins as chains of signatures, pruning, SPV, and the security model of verifying nodes — form the textual specification that any implementation calling itself Bitcoin must operate within. Departures from these specifications can be evaluated against the text. The text speaks for itself.

For the first five years of its existence, Bitcoin operated as the whitepaper specified. Transactions were non-reversible. Fees were low. Small casual transactions worked. The community discussed scaling openly and the discussion was anchored in the original architecture, not in alternative paradigms.

Several primary-source exchanges from this period establish what the consensus was and where Satoshi stood. They have been documented extensively in a chronological compilation of cryptography mailing list posts, BitcoinTalk forum threads, and Hearn email exchanges. Three of those exchanges are foundational.

November 2008, on the cryptography mailing list: James A. Donald responded to Satoshi's whitepaper announcement with the concern that the system would not scale to required size. Satoshi's reply is the foundational scaling document.

Satoshi's scaling vision was Visa-scale on-chain transactions, with most users running SPV clients and a smaller number of specialized nodes performing validation. The architecture was designed for this from the beginning. The bandwidth and storage requirements were calculated and considered manageable under Moore's Law.

July 2010, on the BitcoinTalk forum: User "Bytemaster" — later known as Dan Larimer, who would go on to found BitShares, Steemit, and EOS — proposed scaling Bitcoin via a side-chain or "bit-bank" architecture that would aggregate transactions off-chain and settle to the main chain periodically. This was an early articulation of the layer-2 thesis that would later become Lightning. Satoshi rejected it.

In the same exchange, responding to Bytemaster's concern that ten minutes was too long to verify a payment, Satoshi pointed to the "snack machine thread" — a discussion of how a payment processor could detect fraud in seconds, well within the time needed for a vending machine to release product. The point was that Bitcoin's design did not require waiting for confirmations to be useful for everyday commerce. Fast on-chain payment was achievable; second-layer aggregation was not necessary and would compromise the architecture.

October 2010, on the BitcoinTalk forum: Jeff Garzik proposed an increase to the block size to match Paypal's transaction rate. Satoshi cautioned that the change was not yet necessary — the network was small and the limit wasn't binding — but he laid out how the upgrade could be phased in when needed.

Satoshi specified the upgrade path for raising the block size before he disappeared from public communication. The mechanism was simple, coordinated, and described in plain code. Raising the limit was always part of the roadmap. The 1MB limit existed as a temporary anti-spam measure.

Another of the most consequential primary-source exchanges of this period was Satoshi's email correspondence with Mike Hearn, an early Bitcoin developer and senior software engineer at Google. Hearn joined the project in 2009, eventually authoring Bitcoinj — the Java implementation of the Bitcoin protocol that would power most early mobile wallets. In one of his exchanges with Satoshi about scaling, Hearn asked specifically how Bitcoin would handle the bandwidth and computational requirements of a planet-wide deployment processing billions of transactions per hour. Satoshi's reply was characteristically direct:

Hearn's role in the pre-conflict period would prove important later. The same Hearn whom Satoshi was explaining on-chain scaling to in 2010 would become, five years later, the developer who co-led Bitcoin XT (the first major big-blocker update attempt to implement the long-agreed block-size upgrade) and who would publicly leave the Bitcoin project in January 2016 with an essay documenting the 1 MB blocker capture in real time. His credibility as one of Satoshi's direct correspondents and as the author of the most-used Bitcoin library outside Bitcoin Core made his departure essay particularly difficult to dismiss, which is part of why the responses to it focused on personal attacks rather than substantive engagement. Section III returns to him.

The origin of the 1MB limit itself is documented by Ray Dillinger (forum handle Cryddit), who reviewed the original Bitcoin code with Hal Finney before its release. In a 2015 BitcoinTalk post he wrote:

Three of the people closest to Bitcoin's design — Satoshi, Hal Finney, and Ray Dillinger — agreed at the time of launch that the 1MB cap had to be temporary. The cap was an emergency measure against denial-of-service attacks during the network's earliest days. It was never intended as a permanent architectural feature.

This is the pre-conflict consensus. Bitcoin was designed for on-chain scaling. The whitepaper specified the architecture. Satoshi explicitly rejected second-layer scaling approaches. The 1MB limit was a temporary measure that everyone involved expected to remove. There was no serious technical disagreement about any of this until much later, when the disagreement became financial and political rather than technical.

But before turning to what happened later, two events from the end of Satoshi's public participation deserve attention. They are not technical events — they are political and structural — and they bear on how the post-Satoshi development environment took shape.

December 5, 2010 — the WikiLeaks warning. In late 2010, WikiLeaks was under coordinated financial blockade. Visa, Mastercard, PayPal, and major banks had cut off payment processing to the organization following its publication of US State Department cables. A BitcoinTalk forum user proposed that the Bitcoin community should "bring it on" by encouraging WikiLeaks to accept Bitcoin donations. Satoshi's response was unusually direct and uncharacteristically alarmed:

Six days later, after WikiLeaks had announced anyway that it would consider Bitcoin donations, Satoshi posted again with what reads in retrospect as a warning to the entire project:

The next day — December 12, 2010 — Satoshi posted what would be his final public message on the forum, a brief technical note about denial-of-service protections in the 0.3.19 build. He never posted publicly again. Private correspondence with Gavin Andresen and Mike Hearn continued for several more months.

April 27, 2011 — the CIA briefing announcement. Just over four months after Satoshi's last public post, Gavin Andresen — by then Bitcoin's lead maintainer with commit access to the codebase, designated by Satoshi himself — announced on BitcoinTalk that he had accepted an invitation to present Bitcoin at a conference organized by In-Q-Tel, the venture capital arm of the Central Intelligence Agency. Andresen disclosed the decision to Satoshi privately before announcing it publicly. He wrote in his email to Satoshi:

Satoshi's last documented private correspondence came within days of this announcement. After this point, communications attributed to Satoshi — including a last email to Mike Hearn stating he had "moved on to other things" — became sparser and then ceased entirely. The chronology can be stated factually without claiming causation: Satoshi's disappearance from communication coincided with the CIA briefing announcement. Andresen attended the In-Q-Tel conference at CIA headquarters on June 14, 2011, delivering his Bitcoin presentation.

It is important to be precise about what Andresen's role was and was not. Andresen was the recipient of Satoshi's keys, but he was not the architect of what BTC would later become. Throughout the 2014–2017 block-size conflict, Andresen was aligned with the big-blocker position. He publicly supported on-chain scaling. He worked on Bitcoin XT, then Bitcoin Classic, both of which proposed block-size increases consistent with the original roadmap. In May 2016, when Andresen publicly endorsed Craig Wright's (subsequently discredited) claim to be Satoshi, the 1 MB blocker faction that had taken effective control of Bitcoin Core revoked his commit access entirely and removed him from the bitcoin GitHub organization. Whatever one concludes about the CIA briefing, Andresen was eventually pushed out by the same faction that captured the development direction — which is itself evidence that he was not part of that capture.

The actual chain of custody, and the institutional shift that mattered, runs through different hands. To see the shift clearly, the chronology needs to be followed in proper sequence — because the institutional figures who would eventually shape BTC's direction appeared in the ecosystem at specific moments that bear on what subsequently happened.

April 17, 2013 — Adam Back's appearance. Adam Back is the inventor of Hashcash, the proof-of-work precursor cited in Bitcoin's whitepaper §3. Satoshi reached out to Back directly in August 2008, before the whitepaper was published, in a five-email correspondence that concluded on January 10, 2009. Back was therefore aware of Bitcoin from before its launch. He was a cryptographer of standing in the cypherpunk community, with senior roles at Microsoft, EMC, VMware, and Zero-Knowledge Systems (a venture-backed Canadian privacy-tech company) prior to his Bitcoin involvement.

But from 2009 through early 2013 — the entire period during which Satoshi was active, then disappeared, then in which Bitcoin grew from obscurity to its first significant market peak — Back was conspicuously absent from public Bitcoin discussion. He did not join the BitcoinTalk forum. He did not contribute to development. He did not publish about Bitcoin. For a cryptographer whose work was directly cited in the whitepaper, this non-participation is striking.

Back joined the BitcoinTalk forum on April 17, 2013 — the same day the size of Satoshi's Bitcoin holdings (approximately one million BTC, then worth roughly $100 million and later understood as the largest concentrated holding in the system) first became public knowledge. The economic significance of Bitcoin's early founder-era concentration was now visible. Back's first public Bitcoin engagement timed precisely to that disclosure.

April 8, 2014 — the maintainership transition. One year after Back's BitcoinTalk arrival, Andresen formally stepped down as lead maintainer of Bitcoin Core and nominated Wladimir van der Laan as his successor. From 2014 until 2023, van der Laan was the second post-Satoshi holder of the final commit access keys to the Bitcoin Core repository. His salary during this period was paid by MIT's Digital Currency Initiative. Van der Laan took what he described as a more conservative approach to scaling, generally aligning with Bitcoin Core's emerging 1 MB blocker consensus and treating hard forks as something to be avoided rather than coordinated.

But van der Laan was a maintainer, not the architect of direction. The architectural direction came from the developers and the institution that emerged in parallel with the chain-of-custody transition.

Roger Ver — early advocate and the naming asymmetry. Roger Ver was one of the earliest Bitcoin adopters and investors, active in the project from the 2011–2014 period when its public identity was still forming. His public advocacy consistently framed Bitcoin in the terms drawn from the whitepaper's §1: peer-to-peer electronic cash, displacement of trusted-third-party financial intermediation, freedom of transaction for ordinary participants. He owned and operated Bitcoin.com, which became one of the major alternative information venues for the peer-to-peer-cash position after Bitcoin.org's content control by the 1 MB blocker faction made that primary venue inaccessible to dissenting views. The structural fact worth noting is that the domain's title — "Bitcoin.com" — carried the peer-to-peer electronic cash positioning that the BTC chain later abandoned through the protocol changes documented in Sections V through X. What survived as peer-to-peer electronic cash now wears the Bitcoin Cash branding; the title that originally promoted the peer-to-peer cash framing pre-dated the chain split that produced the naming asymmetry. Ver's 2024 book Hijacking Bitcoin: The Hidden History of BTC (co-authored with Steve Patterson) is a primary-source first-hand account from a participant in the events of 2014–2017; specific findings from it are cited inline in the sections that follow where they bear on the structural argument.

November 2014 — Blockstream is founded. Seven months after Andresen's handoff to van der Laan, and nineteen months after Back's BitcoinTalk appearance, Blockstream launches as the central institutional vehicle of what would become the 1 MB blocker development program. Its founders include Adam Back (CEO), Gregory Maxwell, Pieter Wuille, Matt Corallo, and others — all Bitcoin Core developers or longtime contributors. The company raises a $21M seed round in 2014. A $55M Series A follows in February 2016, led by AXA Strategic Ventures (the venture arm of the global insurance giant AXA), Horizons Ventures, and Digital Garage. A 2021 round adds $210M, with investors including iFinex — the parent company of Tether and Bitfinex.

Blockstream's business model is structurally aligned with the 1 MB blocker direction. The company's main product, the Liquid Network, is a federated sidechain operated by a fixed set of fifteen functionaries who hold custody of pegged BTC. Users wishing to access Liquid's faster transactions and confidential-transaction features must deposit their BTC with the federation, which issues an equivalent amount of L-BTC on the sidechain. The whitepaper, in §1, identified financial institutions serving as trusted third parties as the problem Bitcoin was designed to displace. Liquid reintroduces a federation of trusted third parties as the architecture for Bitcoin scaling. This is not an incidental design choice; it is the business model.

For a custodial sidechain architecture to make commercial sense, the base layer must remain expensive and capacity-constrained enough to make off-chain alternatives attractive. If the BTC base layer scaled on-chain via the §7 architecture Satoshi specified, the commercial demand for Liquid would be much smaller. The 1MB block-size restriction was therefore not just a technical position; it was a precondition for the business viability of the 1 MB blocker faction's primary institutional vehicle. The technical argument and the commercial interest pointed in the same direction.

Whatever one concludes about motive or coordination, the structural picture is clear. Bitcoin's first two years operated under the direction of an anonymous founder explicitly concerned with avoiding state-level attention until the project was technically resilient enough to withstand it. From 2014 onward — beginning roughly with Adam Back's 2013 appearance, the 2014 maintainership transition to van der Laan, and the founding of Blockstream — Bitcoin operated under a development structure in which the holders of the final commit access keys were employed or salaried by institutions whose commercial or institutional interests aligned with keeping the base layer constrained. The transition from the first regime to the second was not chosen by Satoshi; it happened in the years after he had disappeared, and the institutions that emerged to shape what Bitcoin became were precisely the kind of trusted third parties that the whitepaper had identified as the problem Bitcoin was designed to solve.

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.

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:

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.

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:

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 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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):

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:

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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 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:

1. Refuse Bitcoin entirely as a payment method, eliminating the use case from that merchant.
2. 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.
3. 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 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 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.

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 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:

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 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.

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 §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 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.

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.

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.

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.

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 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.

One of the most consistent 1 MB blocker arguments has been that on-chain scaling produces a storage explosion that makes running a full node infeasible. The argument: if blocks grow to support meaningful transaction volume, the total blockchain size grows past what ordinary participants can store, validation becomes the province of a few well-resourced entities, and decentralization erodes.

This argument depends on ignoring §7 of the whitepaper, which solves the storage problem directly.

Section 7's specification: once a transaction has been buried under enough subsequent blocks, the historical transaction data can be discarded. Only the Merkle root and the block header need to be retained. The interior hashes of the Merkle tree can be removed. This reduces a node's storage requirement from "every transaction ever" to "current UTXO state plus block headers." The mechanism is built into the original design.

The technical implementation of this specification is known in current discourse as pruning (for the historical-data discard) combined with UTXO commitments (for the verifiable state synchronization). A working implementation exists in the Bitcoin Cash ecosystem. Bitcoin Verde and BCHD have both implemented fast-sync via UTXO commitments. The mechanism reduces full-node storage from approximately 150GB (full blockchain history) to approximately 25GB (current UTXO state), with verifiable state hashes that prove the pruned data was discarded honestly. This is exactly what §7 specified, implemented as the whitepaper described it.

The implication: the storage-explosion argument against on-chain scaling fails on whitepaper grounds. Large blocks plus §7 pruning solves the storage problem without requiring layer-2 architecture. The 1 MB blocker insistence that decentralization requires artificial restriction of block space depends on either ignoring §7 or rejecting it — and rejecting §7 is rejecting the whitepaper.

The same argument cuts in the other direction against a different BCH-related chain. Bitcoin SV's position that blocks should grow without bound to support arbitrary data storage (terabyte-scale blocks holding video files, archives, and permanent records) also violates §7. The whitepaper specifies that transactions can be discarded once buried. A chain that treats every block as a permanent record of arbitrary data, never pruned, never compacted, is operating against the same section that BTC's 1 MB blockers cite to justify their position. Both directions of departure from §7 — artificial block-size restriction and unbounded permanent data storage — violate the original specification.

This is the strongest version of the case for big blocks plus pruning as Bitcoin's specified scaling path. It does not rely on retrospective interpretation or on what Satoshi "would have wanted." It relies on the literal text of Section 7 and on working implementations that demonstrate the specification is buildable. The on-chain scaling path is the path the document specifies. Any other path is a departure.

The block-size war was not the only force shaping what Bitcoin became after 2017. Beginning in late 2017, a parallel transformation occurred in how Bitcoin was traded and held. The transformation involved derivatives, leverage, and the introduction of synthetic Bitcoin claims that were not Bitcoin but that traded against Bitcoin's price.

The pivotal moment was December 17, 2017, the day the Chicago Mercantile Exchange (CME) launched Bitcoin futures. This was the same day Bitcoin reached its all-time high of approximately $19,500. The two events were not coincidence.

Leo Melamed, Chairman Emeritus of CME Group, said publicly in a Reuters interview ahead of the launch:

This is a publicly stated intent to bring Bitcoin under traditional-finance disciplines. "Tame" is the operative word. The framing is not neutral — it does not describe accommodation or coexistence. It describes capture: bringing an asset originally specified as outside the traditional financial system into that system's rule-set.

The mechanism of capture was the futures market itself. Before futures, BTC could only be bought and held. Bearish positions required not buying. After futures, pessimistic capital could short BTC at scale, with leverage, without ever touching the underlying asset.

This was not just plausible speculation. The Federal Reserve Bank of San Francisco published an economic analysis in May 2018 — Economic Letter 2018-12, authored by Hale, Krishnamurthy, Kudlyak, and Shultz — that concluded the BTC price decline following the futures launch was structurally consistent with futures-market introduction effects observed in other assets. The paper's framing:

The Fed paper makes a structural claim that does not require conspiracy: the introduction of futures markets enables pessimistic positioning, which puts downward pressure on the spot price. The CME launch and the BTC peak coincided on the same day. The subsequent year-long decline coincided with the deepening of the futures market and the entry of additional derivatives venues (CBOE, then perpetual-futures platforms like BitMEX).

The deeper structural argument is about scarcity. Bitcoin's supply schedule is hard-capped: 21 million coins, with the issuance curve fixed and verifiable. This scarcity was promoted as a foundational property — "digital gold," "sound money," etc. But scarcity is only economically meaningful if the tradeable supply matches the actual supply. When derivatives allow one BTC of collateral to support ten or a hundred BTC of synthetic exposure, the effective tradeable supply expands without the underlying supply changing. The hard cap remains on the chain; the trading universe operates with no such cap.

The Tether/Bitfinex layer. Compounding the derivatives effect is the role of Tether (USDT) — a dollar-pegged stablecoin issued by Tether Limited, ultimately owned (through iFinex Inc. and DigFinex Inc.) by the same group that operates the Bitfinex cryptocurrency exchange. The common ownership is documented in court filings (the In re Tether and Bitfinex Crypto Asset Litigation consolidated amended complaint, 2021) and confirmed in regulatory settlements.

The structural concern with Tether is twofold. First, Tether's claim to dollar-backing has been subject to repeated regulatory action. The New York Attorney General's investigation resulted in a February 2021 settlement: $18.5 million paid by iFinex and Tether, an agreement to cease trading with New York customers, no admission of wrongdoing — but the consent order specifically addressed commingling of client and corporate funds and misleading statements about USDT backing. In October 2021, the U.S. Commodity Futures Trading Commission fined Tether $41 million for making false statements about the 1:1 backing of USDT.

Second, the court record from the consolidated complaint cited specific transactions that strain credibility under a 1:1-backing model. From the court's recitation:

The court filing also cited Telegram messages from Tether/Bitfinex CFO Giancarlo Devasini warning that if USDT redemption requests could not be honored — exposing USDT as unbacked — "BTC could tank to below 1k" if action was not taken quickly. The implication acknowledged by an insider: USDT issuance was structurally connected to BTC's price support.

The academic literature on this connection includes Griffin and Shams (2018), "Is Bitcoin Really Un-Tethered?" in the Journal of Finance, which found that USDT issuance was statistically associated with significant BTC price increases during the 2017 bull run. The paper's methodology has been contested in subsequent work, but the underlying correlation — USDT mint timing aligning with BTC price moves — is observable in the on-chain data and has not been satisfactorily explained as pure market-driven demand.

The combination of derivatives, leverage, and stablecoin-driven liquidity injection creates a market structure in which the price of BTC is determined largely by synthetic positioning rather than by the supply and demand of actual on-chain Bitcoin. This is a structural departure from Bitcoin as the whitepaper specified it. The original asset was supposed to be the thing being traded. The current BTC market is structured such that derivative claims and stablecoin-mediated speculation are the dominant pricing forces, with the underlying chain serving more as a settlement layer for traditional finance positions than as a payment system for end users.

The cross-cycle correlation. The pattern documented above for 2017 was not a one-time event. Each major BTC bull run since has coincided with a major USDT supply expansion. The 2017 cycle: USDT supply grew from approximately 10 million in January 2017 to approximately 1 billion by late 2017, a hundredfold expansion, while BTC moved from roughly $1,000 to approximately $19,500 in the same period. The 2020–2021 cycle: USDT supply grew from approximately $4 billion in early 2020 to approximately $80 billion in November 2021, a twentyfold expansion, while BTC moved from roughly $10,000 to approximately $69,000. The proportional relationship between USDT supply growth and BTC price growth across two complete cycles is observable in publicly available data from CoinMarketCap, CoinGecko, and on-chain USDT mint records.

The correlation has been documented across multiple sources beyond Griffin and Shams. CoinDesk's reporting on Tether's reserve disclosures (May 2021, June 2023), the New York Attorney General's settlement documents (February 2021), the CFTC settlement (October 2021), the consolidated class-action complaint filings, Federal Reserve research notes on stablecoin market behavior (December 2025 publication on the SVB-USDC episode and earlier related work), and academic literature subsequent to Griffin and Shams have all examined the relationship between USDT issuance and BTC price action. The conclusions differ on magnitude and on causal mechanism, but the underlying observation — that USDT supply expansions and BTC price expansions move together in proportion, across multiple cycles — is not contested in the data itself. The contested question is what the correlation means.

The interaction effect. The correlation between USDT issuance and BTC price action is one of two structural forces that produced the BTC dominance narrative in the period 2017–2021. The other is the captured information environment described in Section III of this document and addressed in detail in the companion volume Vol.14 — The Information Environment. The two forces compound: the financial-layer manipulation provides the price action; the captured information environment produces the discourse that frames the price action as evidence of market validation. Considered alone, the documented USDT issuance pattern and the documented court-filing evidence would establish that the BTC price action of these years was not purely market-driven. Considered alongside the information-environment capture, the question becomes whether the price action and its broad social acceptance can be cleanly separated at all. The position taken in this document is that the price action was a major driver of perceived BTC dominance but not the sole driver — because the captured information environment was already in place to interpret it, frame it, and propagate the dominance narrative regardless of the underlying mechanics. Without that environment, the documented manipulation would have been almost the entire driver of perceived dominance, because the discourse would have produced no countervailing interpretation.

The structural landscape. The Tether dynamic documented above is one observable consequence of a broader structural property of the current financial system. The asset landscape across commodities, fiat currencies, crypto-native assets, and structured financial instruments organizes along two axes: whether the asset is its own value or a claim on an underlying (the backing relationship axis), and whether that relationship is enforced by physical reality or protocol invariant on one hand, or by institutional mechanism on the other (the enforcement axis). Mapping the four resulting combinations produces the diagram below.

The structural argument for why a fiat-pegged stablecoin can produce this kind of market effect — and why the mechanism is not a deviation from how stablecoins work but a property of how they work — is developed in the companion document Asset Types and Backing Standards. That document examines the chain of unbacking (a fiat-pegged stablecoin is a claim on a fiat currency that itself has no operative redemption to an underlying asset), the soft-enforcement mechanisms that maintain stablecoin pegs through market liquidity rather than protocol invariant, and the historical record of stablecoin and pegged-asset failure (Tether/NYAG 2021, TerraUSD/Luna 2022, USDC/Silicon Valley Bank 2023) as evidence of the structural property. The Tether/BTC dynamic documented in this section is one observable consequence of that structural property at work at scale.

Taproot activated on the BTC chain in November 2021 (block 709,632), introducing Schnorr signatures, MAST (Merkleized Abstract Syntax Trees), and Tapscript. The activation was promoted as a significant privacy and efficiency upgrade. The structural picture, examined against the whitepaper's actual privacy specifications, is more mixed than the promotion suggested.

The technical components have real cryptographic merits. Schnorr signatures are mathematically clean and enable signature aggregation (multiple signers producing a single combined signature). MAST allows complex spending conditions to be hashed into a single commitment, with only the executed branch revealed at spending time. Tapscript provides additional flexibility for contract construction.

The privacy claim, as promoted, is that Taproot key-path spends produce on-chain outputs structurally indistinguishable from single-signature spends, masking complex multi-party arrangements as simple transfers. This is true within Taproot — a Taproot output spending via the key path looks the same on-chain regardless of how complex the underlying contract is. The claim is also conditional in ways the promotional framing tends to omit, and it operates at a different layer than the whitepaper's actual privacy specification.

What §10 actually specifies, and what Taproot does to it. The whitepaper's Section 10 (Privacy) describes a specific protocol-level privacy mechanism. The text:

"The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone... As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner."

The §10 privacy architecture has two specifications: (1) public keys remain anonymous (pseudonymous identifiers not directly linked to real-world identity), and (2) a new key pair should be used for each transaction to prevent linking transactions to a common owner. Privacy is built into the protocol at the address/key-pair level. The mechanism is freshness: each transaction gets a fresh key pair, and the chain stores a sequence of transactions between fresh key pairs, preventing common-owner linkage at the protocol layer.

Taproot does not preserve this specification. Taproot does not change the §10 specification either — users can still use fresh key pairs with Taproot outputs in principle. But Taproot's actual design and deployment in the BTC ecosystem shifts the privacy model in specific ways:

Taproot's deployment encourages key aggregation across multiple parties through MuSig and similar schemes. This is a different model from §10's "new key pair per transaction." Aggregated keys are used across many transactions; the privacy mechanism shifts from "fresh keys break linkability" to "aggregated keys look like single keys." The §10 mechanism (freshness preventing linkage) is not enhanced by aggregation; aggregation operates at a different layer and serves a different privacy goal — making complex multi-party arrangements look like simple single-party transactions.

The script-path branch of Taproot, when used, reveals the spending condition that was executed. Current data shows roughly 60-80% of Taproot spends use the key-path (which preserves indistinguishability) and 20-40% use the script-path (which reveals one branch of the spending logic). The script-path reveals what spending condition was used, leaking information about the contract structure that would not have been disclosed under the simpler transaction types Taproot replaces. The original protocol's simpler structures (P2PKH, P2SH) revealed less about internal spending logic than the script-path branch of Taproot does.

Taproot was designed in coordination with Lightning Network operations. A substantial portion of the "privacy improvement" the BTC discourse celebrates is about making Lightning channel closes indistinguishable from ordinary spends. The privacy story is largely a privacy story for layer-2 operations on-chain — making channel close events less visible to chain analysts. This is privacy for the layer-2 architecture, not privacy for the §10-specified peer-to-peer payment model. Lightning itself introduces surveillance vectors (probing attacks, balance probing, path-finding analysis, watchtower involvement, routing-node inventory inspection) that operate above the base protocol and are not addressed by Taproot's cryptographic improvements.

Address-type fingerprinting persists, and the mechanism is more specific than fingerprinting alone. Taproot outputs are themselves a distinct address type (bc1p...), distinguishable from earlier address types (P2PKH, P2SH, native SegWit). During the multi-year adoption period, the minority of users transacting via Taproot are identifiable specifically because their address type marks them. Privacy claims that depend on most users adopting the new format require that most users actually adopt it — which has not happened. The data shows Taproot adoption is partial: the 60-80% key-path / 20-40% script-path split is among users who use Taproot at all, while the broader user base still transacts using earlier address types. Privacy gains conditional on universal adoption do not deliver until universal adoption arrives.

The specific clustering mechanism that each new address type introduces is worth stating explicitly because it operates in a way the dominant discourse around these upgrades does not engage with. Bitcoin's UTXO model means that when a user makes a payment, the transaction typically has two outputs — one to the recipient, and one back to the sender as a change output. In a historical period where everyone uses the same address type (such as the original P2PKH addresses starting with "1"), both outputs look the same from a chain analyst's perspective. The analyst cannot determine which output is the payment and which is the change. The user has privacy through the indistinguishability of payment and change outputs.

When a new address type is introduced, an asymmetry emerges. The recipient might use the new format (bc1... for SegWit, bc1p... for Taproot). The sender's wallet, by default, continues creating change outputs in the format it was already using (1... for legacy senders, bc1... for SegWit senders sending to Taproot). The transaction now has two outputs of different types — one matching the input's address type, one not. The analyst can trivially determine which output is the change: it is the one matching the input. The change address can be linked to the input address as belonging to the same person. This is the foundational technique that chain-analysis firms (Chainalysis, Elliptic, TRM Labs) use to cluster addresses to common owners, and it is the foundational input to identity deanonymization at exchanges and other KYC chokepoints.

This means the introduction of each new address type is itself a privacy degradation event during the period before universal adoption. The history of Bitcoin's address-type expansion — P2PKH (original), P2SH (2012), P2WPKH and P2WSH (SegWit, 2017), P2TR (Taproot, 2021) — is a history of clustering vulnerabilities created at each expansion. SegWit's introduction created the P2PKH-versus-bc1 clustering opportunity, which operated throughout SegWit's multi-year adoption period and continues operating in 2026 for users who still transact with legacy addresses. Taproot's introduction creates the same opportunity at a new layer: P2TR change outputs reveal sender identity through type mismatch, and the multi-year adoption of P2TR ensures this opportunity persists for years to come. Each new type is promoted as a privacy improvement; each new type, during its adoption period, produces a new clustering vulnerability that did not exist before.

The independent 2020 analysis published by Nikita Zhavoronkov of the blockchain-analytics firm Blockchair ("Negative Impact of Taproot on Bitcoin's Privacy Based on the Experience with SegWit") laid out this mechanism in technical detail before Taproot activation, urging miners to thoroughly examine the privacy implications before voting. The analysis was not engaged with substantively in the BTC discourse. Taproot activated in November 2021 and the documented clustering opportunity it produces has operated for the four-plus years since. The "Taproot improves Bitcoin privacy" framing presented in the BTC discourse omits the mechanism described here, which is specific, verifiable, and was published in advance of the activation that produced it.

The broader privacy ecosystem around BTC has degraded substantially during the period Taproot was being developed and activated. The §10 specification is about protocol-level privacy. Surrounding the protocol layer, the BTC ecosystem in 2026 has produced: KYC infrastructure at exchanges (which the protocol cannot prevent but the surrounding ecosystem has institutionalized); chain analysis firms (Chainalysis, Elliptic, TRM Labs) with sophisticated transaction-graph clustering tools used by law enforcement, exchanges, and compliance vendors; OFAC compliance at mining pools filtering transactions that touch sanctioned addresses; mempool surveillance and IP-layer deanonymization that links pseudonymous addresses to real-world identities; and address-reuse defaults in most consumer wallets (despite §10's explicit specification that fresh keys should be used per transaction).

The "Taproot improves privacy" framing presents a narrow cryptographic improvement as if it addresses the broader privacy degradation occurring across the ecosystem. It does not. The protocol-level privacy specification in §10 (fresh keys per transaction, public keys anonymous) is not enhanced by Taproot. Taproot is orthogonal to §10's mechanism; its main practical privacy benefit is in making certain layer-2 operations less distinguishable on-chain, which is a different concern than §10's specification of how peer-to-peer payment privacy should work.

This is the same inversion pattern that applies to RBF and SegWit. RBF was sold as fee management, and what it actually did was break non-reversibility. SegWit was sold as scalability, and what it actually did was break the verification architecture of §7 and §8 while routing scaling to a layer-2 model. Taproot was sold as privacy improvement, and what it actually did was enable layer-2 architectures (whose privacy implications are different from §10's specifications) while not preserving or enhancing the protocol-level privacy mechanism the whitepaper specified. For each major upgrade, the stated purpose and the structural effect point in different directions, with the structural effect serving the interests of the institutional layer that funded and promoted the upgrade.

For the purposes of this document, Taproot is one more example of the BTC chain's trajectory: increasingly complex consensus changes activated through coordinated coercive-upgrade campaigns, each presented as an enhancement, each adding architectural surface area beyond the whitepaper's specifications, each shifting the chain's actual operation further from what the whitepaper describes. Whether any individual change is on balance positive is debatable; the cumulative drift away from the original specification is not.

The Bitcoin Cash chain did not adopt Taproot.

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.

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 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.

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 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.

This document has presented documented behavior and pattern coherence. It has not made claims about coordinated intent that go beyond what the documentary record supports.

What the documentary record supports, taken as a whole:

The whitepaper specifies certain properties. The BTC chain has departed from those properties on multiple load-bearing points. The departures have been consistent in direction — each one has moved the chain away from peer-to-peer cash and toward asset-class behavior compatible with traditional finance infrastructure. The departures have been coordinated through coordinated activation events, coordinated messaging discipline, and coordinated suppression of dissenting views in the major discussion venues. The financial actors who benefit from BTC being an asset class rather than a payment system — exchanges, derivatives venues, custodial services, ETF issuers, stablecoin operators — are well-resourced and operationally active in shaping the discourse.

What the documentary record does not establish, with the same rigor:

Whether the pattern reflects explicit coordination among specific actors (a conspiracy), implicit convergence among actors with shared incentives (institutional inevitability), or some intermediate combination. The pattern is consistent enough that pure coincidence is implausible; the documentary record on direct coordination is incomplete enough that strong claims about who specifically agreed to what cannot be made with confidence. The reader is free to interpret.

The Vol.10 epistemic model applies here as it did to the gold-standard treatment. Authorities exercising their lawful power in their own interest can produce outcomes structurally indistinguishable from coordinated capture. The reader who wants to see the BTC trajectory as the natural result of self-interested actors operating independently can find that reading coherent with the evidence. The reader who wants to see it as deliberate coordination among aligned interests can also find that reading coherent. Both readings agree on the underlying facts.

Taken as a whole, the structural lesson visible in this history is that systems requiring trust in operators are systems that eventually have those operators serve interests other than the original users'. The whitepaper specified Bitcoin as a system that did not require such trust. The BTC chain has progressively become a system that requires increasing trust in increasingly large institutional actors. The BCH chain has held the original line on most of the questions in dispute, with what cost and benefit time will show.

For any technical or economic system that depends on the structural properties Bitcoin was specified to provide — non-reversibility, on-chain capacity, intact verification architecture without SegWit-introduced gaps, and a supply that has not been dissolved through derivative-mediated synthetic claims — the choice of base layer matters. The base layer determines what is structurally possible on top of it. A payment system cannot operate on a chain that allows transaction replacement after the fact. A privacy-preserving protocol cannot operate on a chain that has structurally disabled the original SPV verification model. A bearer-instrument architecture cannot operate on a chain where the relationship between on-chain supply and tradeable supply has been dissolved through synthetic exposure mechanisms. Measured against the whitepaper, BCH retains these structural properties; BTC has lost most of them. What each chain enables at the application layer is downstream of what each chain preserves at the protocol layer.