Volume III measured what it costs to verify Bitcoin: in gigabytes, in megabytes per day, in days of initial synchronization. Chapter 33 asked who governs Bitcoin and answered, in part, "those who enforce the rules." This chapter joins the two questions. The cost of verification determines who can enforce the consensus rules, and therefore who participates in governance, and therefore how far Bitcoin's monetary ambitions can extend without changing character. We assemble the book's own measurements into a hierarchy of verification tiers, ask what other distributed systems teach about driving such costs toward zero, build a small formal model of rule enforcement, and state precisely what the later chapters of this volume quietly presuppose.
34.1 The Binding Constraint
A user "verifies Bitcoin" to the extent that the user computes the validation predicate V(C, B) of Definition 13.18 rather than asking someone else for the answer. Volume III showed that this is not a binary choice: between full validation and blind trust lies a spectrum of architectures, each verifying some properties and delegating others. We now give the spectrum a name and a price list.
Definition 34.1 (Verification Tier)
A verification tier is a class of client architectures characterized by three quantities:
- Setup cost: storage and bandwidth required to reach the chain tip from nothing;
- Steady-state cost: bandwidth and computation required to stay at the tip;
- Verified set: the subset of consensus properties the client checks for itself rather than trusts.
Two clients occupy the same tier when all three quantities agree to within constant factors.
The book has already measured the major tiers. We collect the numbers in one table, citing the chapter in which each was derived. Figures are as of roughly mid-2026, height ≈ 901,000.
| Tier | Setup cost | Steady state | Source |
|---|---|---|---|
| Archival full node | ~600 GB storage; days of IBD | ~245 MB/day; full validation | Ch 21, §21.1 |
| Pruned full node | ~10 GB retained (full IBD bandwidth still required) | ~245 MB/day; full validation | §21.4 |
| AssumeUTXO node | ~10 GB snapshot, then snapshot-to-tip validation; historical validation in background | ~245 MB/day; full validation at the tip | §21.3 |
| Header-only SPV | 80 × height bytes ≈ 72 MB | ~12 KB/day of headers | Remark 17.1 |
| Neutrino (BIP-157/158) | ~72 MB headers + filter headers | ~3–5 MB/day | Example 19.5 |
| API client | zero | zero verification | Ch 20, §20.4, §20.6 |
The tiers map onto device classes. A dedicated server or a desktop with a terabyte disk runs an archival node comfortably. A laptop runs a pruned or AssumeUTXO node, at the cost of days of background computation or trust in a release-embedded snapshot hash. A typical phone does not have 600 GB to spare, and cannot sustain days of CPU-bound validation, but it holds 72 MB of headers without noticing and absorbs 3–5 MB per day of filters within an ordinary data plan: the phone's natural tier is Neutrino. A browser tab, today, occupies only the bottom row: the web wallets in wide use are API clients that verify nothing (Section 20.6 called this the validation gap). Section 34.3 examines whether the browser must stay there.
Remark 34.1 (The Binding Constraint)
The thesis of this chapter, stated precisely: each tier's cost determines what fraction of users can occupy it, and that fraction is not merely a usability statistic. Section 34.4 will show that the fraction of the economy that can cheaply verify a given rule bounds the credibility of enforcing that rule, so the distribution of users across the tiers of this section is politically consequential. Verification cost is the binding constraint simultaneously on Bitcoin's reach (who can hold it sovereignly), on its governance (who can enforce its rules), and (Section 34.6) on the monetary scenarios of Chapter 40. We emphasize that this framing is itself contested: "verification must be cheap" was, historically, the small-block position in the dispute of Section 33.7.1, and Section 34.4 presents the opposing readings rather than adjudicating them.
34.2 Why the Web Scaled
Bitcoin is not the first decentralized system asked to serve billions of clients. The web did it, and Fielding's dissertation later articulated the architectural constraints that made it possible: Fielding, R. T. (2000), Architectural Styles and the Design of Network-based Software Architectures, Ph.D. dissertation, University of California, Irvine, derives in its Chapter 5 the REST architectural style as the set of constraints behind web scale. Each constraint purchases a specific scalability property. We ask which of those purchases Bitcoin's verification stack has already made, and which it cannot make.
Definition 34.2 (REST Constraints)
The principal REST constraints, each with the property it purchases:
- Client–server: separating interface from storage lets the two evolve and scale independently.
- Statelessness: every request carries all context needed to process it, so any server can answer any request and servers can be added or fail freely.
- Cache: responses labeled cacheable can be served by intermediaries, so popular data costs the origin nothing.
- Uniform interface: all parties speak one small vocabulary, so components can be substituted without renegotiation.
- Layered system: each component sees only the adjacent layer, so intermediaries (caches, proxies, gateways) can be interposed without anyone's consent.
Now the mapping, stated as observation rather than design lineage, since Bitcoin's authors did not work from Fielding's text.
Headers-first sync is cacheable, verifiable state transfer. The header chain of Chapter 17 is identical for every client, immutable once buried, and self-authenticating: a client checks the proof-of-work and the hash links itself (Remark 17.1 prices the whole chain at 80 × height bytes). Because verification travels with the data, the data can be served by anyone: an untrusted mirror, a CDN, a peer. This is exactly the property REST's cache constraint purchases, with cryptography substituting for the origin's authority.
Compact filters are a uniform, cacheable interface to chain data. The BIP-158 filter for a block is deterministic: every client requests the identical artifact, and Theorem 19.1 shows that clients downloading it are indistinguishable to the server. A deterministic response to a parameter-free request is the most cacheable object there is, and the interface is uniform in REST's sense: one filter format for all wallets, rather than the per-client bespoke queries of BIP-37 (Chapter 18) or the Electrum protocol (Section 20.2).
The layered money stack is REST's layered system. Chapters 23 and 24 built payments in layers: the chain settles channel opens and closes, channels carry the traffic, and Remark 23.1 gives the multiplier: N payments per channel cost two on-chain transactions. A Lightning payer sees only the adjacent layer; the base chain neither knows nor consents. This is the layered-system constraint applied to settlement rather than to content delivery.
Statelessness maps, partially, to verification locality. In the UTXO model, a transaction's validity depends only on the transaction itself and the outputs it spends (Chapters 10–11), not on account histories or global balances. Each script execution is a self-contained request carrying its own context. The qualification matters: full validation still requires the UTXO set, a global state. The locality is real but bounded.
Remark 34.2 (Where the Analogy Breaks)
The web scaled by not requiring global consistency. Two users may see different versions of a page, stale caches resolve themselves eventually, and nothing breaks. Bitcoin's entire purpose is the opposite guarantee: every node computes the same validation predicate V(C, B) of Definition 13.18 and converges on one chain. Consequently only the read and verify path (headers, filters, blocks, Merkle proofs, all immutable and self-authenticating) scales the way the web scales. The write path, space in blocks, is globally replicated by construction and therefore scarce by construction; no cache or intermediary can manufacture more of it. This asymmetry is not a flaw in the analogy but the justification for the layered architecture: Chapters 23–24 move writes off the scarce resource precisely because reads were the only thing that could be made cheap. We do not claim the web's trajectory predicts Bitcoin's; we claim only that where Bitcoin's verification path has scaled, it has done so by the same architectural moves, and where it cannot, the obstruction is consensus itself.
34.3 The BitTorrent Precedent
A second precedent sits closer to Bitcoin: a peer-to-peer protocol with no servers at all. Cohen, B. (2003), "Incentives Build Robustness in BitTorrent," Workshop on Economics of Peer-to-Peer Systems, described a design in which peers exchange pieces of a file under a tit-for-tat policy, verifying each piece against hashes in a small trusted metadata file. The structural kinship: a compact verified commitment (the torrent's piece hashes; Bitcoin's header chain) lets untrusted peers serve bulk data (file pieces; blocks and filters) that the recipient checks for itself.
BitTorrent's deployment trajectory is the instructive part. It began as a native client that users installed; it was then embedded invisibly inside other applications (game updaters, media distributors); and finally WebTorrent carried the protocol into the browser itself, replacing TCP sockets with WebRTC data channels so that a web page could join a swarm with no installation step at all. Each stage collapsed adoption friction, and the last stage collapsed it to zero: the browser is the one runtime nearly every connected human already has. If Bitcoin verification is to reach the widest tier of Figure 34.1, the browser is where it must run, and the browser imposes its own constraints.
Definition 34.3 (Browser-Tier Constraints)
A verifying client running in an unmodified browser must operate under:
- No listening sockets. A page cannot accept inbound connections; it reaches peers only through outbound WebSocket or WebRTC transports, so some bridge between the browser and the TCP-speaking node network must exist.
- Storage quotas. Persistent storage is limited and evictable. The full header chain (≈ 72 MB, Remark 17.1) fits within typical quotas; a checkpointed anchor (shipping the client with a recent header hash and syncing forward from it) reduces the requirement to megabytes, at a trust cost identical in kind to AssumeValid's release-embedded hash, analyzed in Section 21.2.
- No persistent daemon. A tab does not run while closed. The client therefore synchronizes on open, and the cost of catching up after an absence (the arithmetic of Example 34.1) determines whether opening the wallet is instant or intolerable.
Example 34.1 (A Week Offline, in the Browser)
Suppose a browser-based Neutrino client is opened after seven days closed: 7 × 144 = 1,008 blocks behind. Using the per-block figures of Example 19.5:
- Headers: 1,008 × 80 B ≈ 81 KB
- Filter headers: 1,008 × 32 B ≈ 32 KB
- Filters: 1,008 × ~18 KB ≈ 18 MB
Roughly 18 MB total: a few seconds on a home connection, comparable to loading a media-heavy web page. The catch-up cost is dominated entirely by filters, which is why filter determinism (Theorem 19.1) matters doubly here: a deterministic artifact can be served from any cache or CDN, so the catch-up need not burden full nodes at all.
We state plainly what does not yet exist: as of this writing there is no production browser wallet that verifies headers and filters in the tab. The components exist separately: BIP-157/158 served by Bitcoin Core since version 0.21, WebRTC transports proven by WebTorrent at scale, header validation trivially within browser computational budgets. But no deployed system composes them. The claim of this section is therefore a trajectory with stated engineering constraints, not a description of the present. The constraints are not known to be blocking; neither has anyone yet borne the cost of satisfying them.
Remark 34.3 (The Seeding Problem)
One disanalogy with BitTorrent deserves emphasis. Cohen's protocol is self-provisioning: peers upload to peers that upload to them (tit-for-tat), and seeding beyond that is reciprocal-altruistic but cheap and visible. Bitcoin full nodes that serve filters to light clients receive nothing for it: there is no protocol-level compensation, and a light client by construction has nothing chain- relevant to offer back. At today's light-client population this altruism is ample. Whether it remains ample if the browser tier grows by two orders of magnitude, or whether serving infrastructure would centralize into a few well-funded gateways, recreating at the transport layer the intermediation the architecture removed at the validation layer, is an open question, and we record it as such.
34.4 The Activation Game
We now make the chapter's political claim formal. Chapter 26 analyzed fork adoption as a coordination game (Section 26.4) and proved, in Theorem 26.2, that a soft fork enforced by a majority of hash power produces convergence without a permanent split. That theorem takes the hashrate fraction as given. The question contested in practice, and contested bitterly in 2017, is what determines the hashrate fraction. The model below gives the standard answer: hashrate follows economic weight, and economic weight can enforce only what it can verify.
Definition 34.4 (The Activation Game)
After a contested soft-fork rule change Rnew ⊂ Rold (rule sets as in Definition 26.5), suppose two candidate chains exist: chain N, whose blocks satisfy Rnew, and chain O, which contains at least one block valid under Rold only. Economic actors are weighted by the volume of goods, services, and currency they trade for coins. Each actor accepts coins on exactly one chain. Miners allocate hashrate H freely between the chains to maximize revenue, and each chain's block reward is R coins, valued at prices pN and pO proportional to the economic weight accepting that chain's coins.
Definition 34.5 (Enforcing Fraction)
The enforcing fraction e is the fraction of total economic weight that enforces Rnew, that is, validates incoming coins against Rnew and refuses coins whose history violates it. In the model, pN ∝ e and pO ∝ 1 − e.
Proposition 34.1 (Hashrate Follows Economic Weight)
In the activation game, if e > 1/2, then regardless of how hashrate was initially signaled or allocated:
- in any equilibrium, chain N receives the majority of hashrate and accumulates expected work at a strictly greater rate;
- by Theorem 26.2, all nodes, including those enforcing only Rold, converge on chain N with probability 1; and
- anticipating (2), profit-maximizing miners allocate all hashrate to chain N.
Proof.
(1) With each chain's difficulty adjusted to its hashrate, a miner contributing hash fraction h/Hi on chain i earns that fraction of chain i's rewards, so revenue per unit hashrate on chain i is proportional to R·pi/Hi. If both chains are mined in equilibrium, revenue per unit hashrate must be equal, giving HN/HO = pN/pO = e/(1 − e) > 1; otherwise the corner allocation already favors N. In either case HN > HO, so chain N's expected work grows strictly faster.
(2) Blocks satisfying Rnew also satisfy Rold, since Rnew ⊂ Rold. Nodes enforcing Rold follow the most-work valid chain (Definition 26.10), and by the law of large numbers chain N's work lead grows without bound, so those nodes reorganize onto chain N with probability 1; this is precisely the convergence of Theorem 26.2, with the majority condition supplied by (1) rather than assumed.
(3) Once old-rules nodes converge on chain N, chain O is orphaned and coins minted on it cease to exist on any surviving ledger. A rational miner anticipating this assigns chain-O rewards value approaching zero, making full allocation to chain N the unique best response, independent of initial signaling.
Example 34.2 (Revenue at e = 0.8)
Let e = 0.8 and normalize so a coin's price equals the economic weight accepting it. Before convergence, the interior equilibrium of Proposition 34.1 gives HN/HO = 0.8/0.2 = 4: chain N carries 80% of hashrate and finds blocks four times as fast, so old-rules nodes see chain N pull ahead almost immediately. A miner who instead commits everything to chain O earns rewards worth 0.2/0.8 = 25% of the enforcing chain's per-coin value even before the orphaning of step (3) drives that value toward zero.
Remark 34.4 (Enforcement Requires Verification)
The model's lever is e, and the chapter's central claim, stated carefully: e is bounded above by the fraction of economic weight that can verify the rule Rnew cheaply. Enforcement, by Definition 13.18, means computing the validation predicate oneself; an actor that cannot detect a violation cannot refuse the violating coins, whatever its stated policy. An exchange running an API client enforces nothing. A merchant on a Neutrino wallet enforces header validity but not Rnew (Section 17.4: SPV does not prove rule compliance). Therefore the credibility of a user-activated soft fork (a UASF, in which economic actors threaten to reject non-enforcing blocks) is a function of the verification-cost distribution of Section 34.1: the threat is only as broad as the population that can afford to make it. Conversely, miner-activated soft forks can be read as delegation rather than usurpation: if few economic actors validate, miner coordination of the upgrade reflects where verification actually resides. This reading is itself contested (Remark 34.5).
Remark 34.5 (Two Readings of the Block-Size War)
The model permits a disciplined rereading of Section 33.7.1. One camp reads 2017 as the model vindicated in the users' favor: BIP-148 raised the credible enforcing fraction, miners observed e moving against the non-enforcing chain, and signaling flipped within weeks: users can enforce. The other camp observes that the enforcement which mattered was concentrated: exchanges, payment processors, and a comparatively small population of economic full nodes constituted most of the weight behind e, so the episode demonstrates coordination among large economic actors rather than enforcement by the masses. The readings disagree about who moved e; they agree—and this is the point—that the underlying dispute was about the cost of validation and who could afford it. Larger blocks raise the cost of every tier in Section 34.1's table; one side priced that against on-chain capacity and accepted it, the other did not. The war was the activation game played over the parameter that determines who may play.
Remark 34.6 (Limitations of the Model)
The model is deliberately simple, and its simplifications are not innocent. Price formation is not a weighted vote: markets aggregate speculation, leverage, and liquidity, not merely acceptance, and the 2017 futures markets traded on thin volume. The model is reflexive in practice (miners watch prices that traders set by watching miners), so the clean sequencing of the proof understates the scope for self-fulfilling stampedes in either direction. The enforcing fraction e is not empirically measurable; participants act on noisy proxies (corporate statements, node counts that can be Sybilled, futures prices). Each actor was assigned to exactly one chain, excluding the many who would accept either. And the wipeout asymmetry in step (3) is specific to soft forks: for a hard fork, with neither chain's blocks valid on the other's rules, both chains can persist and the model predicts only the hashrate split of step (1), consistent with the survival of the 2017 hard forks recorded in Chapter 27.
34.5 The Trust-Drift Ladder
Sections 34.1 through 34.4 each examined the verification spectrum from one angle. We now unify it. Read each row of the following table as a rung: descending the ladder, the verified set shrinks, the trusted set grows, and the setup cost falls. The lower rungs are, observably, the populated ones: custodial and API wallets dominate user counts.
| Rung | Verified | Trusted | Analyzed in |
|---|---|---|---|
| Full validation | every rule, every block, from genesis | nothing beyond the software itself and one's own hardware | Ch 13, Ch 21 |
| AssumeValid | everything except historical script signatures | the release process that embedded the assumed-valid hash | §21.2 |
| AssumeUTXO | everything from the snapshot forward, immediately; history verified in background | the snapshot hash, until background validation completes | §21.3 |
| SPV / Neutrino | proof-of-work, header chain, transaction inclusion | majority hashrate for rule compliance of confirmed transactions | §17.2–17.6, Ch 19 |
| Electrum-style servers | headers and Merkle inclusion proofs | the server, for completeness of history and for privacy | §20.2–20.3 |
| API / custodial | nothing | the provider, entirely: balances, history, and in the custodial case the keys themselves | §20.4, §20.6 |
The ladder is a description, not a prediction. The contested question is where, on this ladder, users will actually live as adoption grows, and that question is older than every scaling technology in Volume III.
Remark 34.7 (The Finney Objection)
Hal Finney, the protocol's first recipient, anticipated the bottom of the ladder before any of its upper rungs existed. In a forum post of 30 December 2010 ("Bitcoin Bank," bitcointalk.org), he argued that Bitcoin's natural mature form is a settlement layer among "bitcoin banks": institutions that custody coins and issue their own digital cash against them, with ordinary users transacting in the banks' liabilities and the chain settling among institutions. Critics of layered scaling press this as the realistic reading of the ladder: the bottom rungs are where users actually land, because they are cheapest and most convenient, so "scaling in layers" means in practice custodial drift and the re-intermediation Bitcoin was built to remove: Finney's banks, with better branding. Proponents of layered scaling respond on two fronts: first, the upper rungs of the ladder discipline the lower ones in a way fiat banking never had: a custodian whose liabilities are auditable against a public chain, and whose depositors can exit to self-custody at the cost of one transaction, is constrained as no fractional-reserve bank ever was; second, the alternative of placing all economic activity on-chain fails on arithmetic, since Remark 23.1's two on-chain transactions per channel is already the optimistic case and Chapter 23's throughput analysis admits no global payment volume at the base layer. Both positions are coherent; they weigh the same ladder differently, and this book adjudicates neither.
34.6 Hyperbitcoinization as a Conditional
Chapter 40 will survey monetary futures in which Bitcoin's holders number in the hundreds of millions to billions. Those scenarios are sometimes read as forecasts. Read against this chapter, they are conditionals, and the conditions are the quantities computed above.
Remark 34.8 (The Conditional, Both Branches)
If self-sovereign use is to scale to that population, then verification must reach the phone and browser tiers of Section 34.1 at the costs computed there (tens of megabytes of headers, single-digit megabytes per day), and the enforcing fraction e of Section 34.4 must remain large enough that a contested rule change still requires broad consent. Otherwise, scale arrives anyway, via the bottom rungs of Section 34.5's ladder, and the system that scales is Finney's: custodians transacting on behalf of users who verify nothing, e concentrated in a few large institutions, and the governance model of Chapter 33 changed in character, since the stakeholder map of Definition 33.1 collapses toward whichever actors still compute V. Both branches are internally consistent monetary futures; they differ in who holds the keys and who enforces the rules. The book takes no position on which arrives, and notes that they are not exclusive: every prior monetary technology has settled into a mixture, and the mixture's proportions are exactly what the verification-cost frontier determines.
The mathematics of Volume I made verification possible; the engineering of Volume III made it cheap; whether it becomes universal is the open question of Volume V.
Exercises
Exercise 34.1
Using Remark 17.1, compute the size of the complete header chain at the start of 2031. Take the height as approximately 901,000 in mid-2026 and assume 52,560 blocks per year for the intervening 4.5 years. Does the result change the browser storage-quota analysis of Definition 34.3?
Exercise 34.2
A Neutrino client comes online after 30 days. Using the per-block figures of Example 19.5 (80 B headers, 32 B filter headers, ~18 KB filters, and a false-positive rate of 100/784{,}931 per block for a wallet watching 100 scripts), compute the total catch-up download, including the expected cost of false-positive block fetches at ~2 MB per block.
Exercise 34.3
Using Example 19.5's daily figures (~4 MB/day for Neutrino, ~245 MB/day for full blocks), compute annual bandwidth for each tier and the ratio between them. At what tier of Section 34.1's table does a 2 GB/month mobile data plan permit staying at the tip?
Exercise 34.4
In the activation game with e = 0.6, compute the interior-equilibrium hashrate ratio HN/HO of Proposition 34.1 and the relative per-coin value of rewards on the two chains. Then explain why step (3) of the proof makes even this comparison too favorable to chain O.
Exercise 34.5
Section 34.2 mapped four Bitcoin mechanisms onto REST constraints. Choose one constraint and one mechanism not discussed there; candidates include Utreexo (Section 21.5), the client-side validation of Chapter 22, or transaction relay policy. Argue either that the mapping holds or that it fails. State explicitly what scalability property is or is not purchased.
Exercise 34.6
Restate the Finney scenario and the self-custody scenario of Remark 34.7 in the vocabulary of Section 34.5's ladder: for each scenario, state where the median user sits, where the enforcing fraction e of Definition 34.5 resides, and what mechanism (if any) disciplines the bottom rungs. Which empirical observations, available today, would tell the two trajectories apart?