Chapter 25

Claims and Misconceptions

Stating Common Claims Precisely

This chapter examines commonly repeated claims about Bitcoin, by critics and by advocates, using the definitions and results of the preceding volumes. Each claim is stated precisely, its implicit assumptions identified, and its scope established.

Each unit below states a claim, with its provenance where one can be given, then analyzes it; the conclusion follows the analysis. Section 25.8 records the procedure the analyses share.

25.1 Claims about SPV

Claim 25.1 (SPV Equivalence). A simplified-payment-verification client provides the same security as a full node, since it verifies proof-of-work and transaction inclusion.

The whitepaper (Nakamoto 2008, §8) is cited in support: simplified payment verification "is reliable as long as honest nodes control the network."

Remark 25.1 (SPV Trust Model)

An SPV client accepts a transaction as valid if:

  1. The transaction is included in a block (Merkle proof)
  2. The block has valid proof-of-work
  3. The block is in the most-work chain

What SPV does not verify:

  • Transaction validity (correct signatures, not double-spent)
  • Block validity (all transactions valid, correct subsidy)
  • Consensus rule compliance (block size, script rules)
SPV Client Merkle inclusion proof Valid proof-of-work Most-work chain Valid signatures No double-spends Correct subsidy Consensus rules ✗ = trusted, not verified strict subset Full Node Merkle inclusion proof Valid proof-of-work Most-work chain Valid signatures No double-spends Correct subsidy Consensus rules ✓ = independently verified
Figure 25.1: SPV verification is a strict subset of full-node verification. SPV checks inclusion and work but trusts miners for everything below the line.

A full node independently validates every transaction and block. If miners produce an invalid block (for example, one that inflates the supply), full nodes reject it. An SPV client sees only the proof-of-work and assumes validity.

Consider the scenario the trust model exposes. Miners controlling a majority of hashrate create an invalid block awarding themselves a 1000 BTC subsidy instead of 3.125 BTC, and continue building on it. Full nodes reject the block; once it is buried in the most-work header chain, SPV clients accept it.

The whitepaper's security claim is conditional: "as long as honest nodes control the network." If majority hashrate is malicious, SPV verification fails entirely, while full nodes continue enforcing the correct rules.

Conclusion. SPV verification is a strict subset of full-node verification (Figure 25.1). An SPV client trusts miners not to produce invalid blocks; a full node detects and rejects them. The equivalence claim holds only under the whitepaper's own hypothesis of honest majority hashrate, and the two models diverge exactly when that hypothesis fails.

Remark 25.2 (Appropriate Use of SPV)

SPV provides probabilistic security against double-spends by verifying proof-of-work. It is appropriate for low-value transactions where the cost of an attack exceeds the value at stake. It is not a substitute for full validation when rule enforcement matters.


Claim 25.2 (Fraud-Proof Sufficiency). Fraud proofs will allow SPV clients to detect invalid blocks, achieving the security of a full node at SPV cost.

The whitepaper (§8) sketches the idea: network nodes could alert light clients to invalid blocks, prompting a download of the full block. Later proposals develop the mechanism (Section 17.7).

Remark 25.3 (Fraud-Proof Limitations)

Effective fraud proofs require:

  1. Data availability: Fraud proof data must be accessible
  2. Honest relayer: Someone must generate and transmit proofs
  3. Timeliness: Proof must arrive before the SPV client acts on the fraud
  4. Completeness: All fraud types must be provable

In an eclipse attack (an SPV client connected only to the attacker), fraud proofs cannot arrive. The fundamental assumption shifts from "majority of miners honest" to "at least one honest connection."

Conclusion. Fraud proofs, if deployed, would narrow the gap between SPV and full validation but would not close it: they transform the trust assumption rather than removing it. No general fraud-proof system exists for Bitcoin as of 2026.

25.2 Claims about Scaling

Claim 25.3 (On-Chain Scaling Sufficiency). Bitcoin's limit of roughly 7 transactions per second is an artificial constraint; raising the block size, eventually to gigabyte scale, would allow throughput comparable to major card networks, and is the only scaling path that preserves Bitcoin's properties.

A claim common in the scaling debates of 2015–2017 (Chapter 33).

The figure of 7 transactions per second belongs to the claim's own voice; the limit established in Chapter 15 is approximately 3–7 transactions per second depending on transaction mix. The substantive question is what raising the limit costs, and what the alternatives cost.

Remark 25.4 (Scaling Approaches)

On-chain scaling (larger blocks):

  • Throughput increase: linear with block size
  • Node requirements: linear increase in bandwidth, storage, CPU
  • Decentralization impact: fewer nodes can participate
  • Security: unchanged per transaction, but network effects weaken

Layer 2 scaling (channels, rollups):

  • Throughput increase: multiplicative (many transactions per on-chain tx)
  • Node requirements: unchanged for base layer
  • Decentralization impact: base layer unaffected
  • Security: varies by construction (channels: near-base-layer; custodial: trust)

Example 25.1 (Scaling Comparison)

Target: 1 million transactions per second. Assume an average transaction size of approximately 240 bytes, and amortize 1000 payments over each channel's on-chain footprint.

Approach Block Size Node Requirements
Pure on-chain ~144 GB/block ~150 GB bandwidth per 10 min
Lightning (1000 tx/channel) ~1 MB (current) Current requirements

Under these assumptions, layer 2 achieves the same throughput with approximately 150,000 times less on-chain footprint. The costs that layer 2 itself incurs are recorded in Remark 25.5.

Pure on-chain target: 1 million TPS one block ~144 GB every 10 minutes every node: ~150 GB bandwidth per 10 min Lightning channels target: 1 million TPS off-chain payments 1000 tx per channel anchored by ~1 MB node requirements: unchanged Same throughput with ~150,000x less on-chain footprint
Figure 25.2: On-chain scaling grows node costs linearly with throughput; layer 2 anchors many off-chain transactions with one small on-chain block.

Remark 25.5 (Costs of Layer 2)

The comparison is not free. Lightning requires inbound liquidity before a user can receive (Section 24.6), pathfinding can fail for large payments (Section 24.4), and every channel open or close is itself an on-chain transaction, so onboarding users onto layer 2 remains bounded by base-layer capacity. The defensible claim is comparative: layer 2 multiplies the value of each on-chain byte; it does not make block space irrelevant.

Conclusion. On-chain throughput grows linearly with block size, and so do the resource requirements of every verifying node; layer-2 designs multiply the number of payments per on-chain transaction while leaving base-layer requirements unchanged (Example 25.1). Larger blocks are one scaling instrument among several, with costs concentrated on verification (Chapter 15); the claim that they are the only instrument does not survive the comparison, even after layer 2 is charged with the costs of Remark 25.5.


Claim 25.4 (Lightning Balances as IOUs). A Lightning channel balance is an IOU, comparable to a bank balance: the funds are not real bitcoin until they are settled on-chain.

A claim common in critiques of layer-2 designs.

Proposition 25.1 (Lightning Ownership)

Consider a Lightning channel whose funding output is a 2-of-2 multisignature output, observable on-chain, and suppose that a commitment transaction broadcast by either party confirms within its negotiated timelock. Then:

  • each party holds a fully signed commitment transaction spendable without the counterparty's cooperation;
  • either party can unilaterally close the channel and claim its balance;
  • no third party can prevent the close or reassign the funds.

Proof (by construction).

Alice's commitment transaction (Chapter 23) is a valid Bitcoin transaction already signed by Bob. If Alice broadcasts it and it confirms, she receives her balance after the timelock; no further action by Bob is required, and nothing Bob withholds can invalidate a signature he has already given. The most Bob can do is broadcast his own commitment transaction, which pays Alice the same balance. ∎

The confirmation hypothesis is substantive: sustained majority censorship, or fee conditions under which the commitment transaction cannot confirm within the timelock, violate it. This failure mode motivates anchor outputs and fee-bumping (Chapters 23 and 24). The enforcement, where the hypothesis holds, is cryptographic rather than legal: no court order and no counterparty cooperation is required.

Conclusion. A Lightning balance is a claim on bitcoin locked in an on-chain contract, enforceable unilaterally under the hypothesis of Proposition 25.1. A custodial IOU is enforceable only with the custodian's cooperation: the third party controls the funds and can refuse withdrawal. The comparison fails at the point of enforcement.


Claim 25.5 (Continuous Liveness Requirement). A Lightning user must monitor the blockchain continuously, or risk losing channel funds to a counterparty broadcasting an outdated state.

A concern raised against penalty-based channel designs since their publication (Chapter 23).

Remark 25.6 (Liveness Requirements)

With an LN-Penalty channel:

  • Minimum: Check the blockchain once per to_self_delay (the OP_CHECKSEQUENCEVERIFY relative-timelock delay on revoked commitments, not Chapter 22's "CSV" client-side validation; commonly 144–2016 blocks: 1 day to 2 weeks)
  • With watchtower: A watchtower monitors on the operator's behalf
  • eltoo/LN-Symmetry channels (proposed; requires SIGHASH_ANYPREVOUT, Section 24.7): no punishment needed; old states are superseded rather than punished

The risk is real but bounded. Checking at intervals shorter than the negotiated to_self_delay is sufficient: once per week comfortably covers a 2016-block (2 week) delay. Watchtowers (Chapter 23) delegate the task, at the cost of assuming the watchtower is online and honest.

Conclusion. The liveness requirement is periodic, with period set by the negotiated timelock, not continuous; a watchtower delegates it under an explicit additional assumption. The claim overstates a bounded, negotiable obligation as an absolute one.

25.3 Claims about Cryptography

Claim 25.6 (Quantum Collapse). Quantum computers will break the elliptic-curve cryptography that secures Bitcoin, and holdings will be stolen at scale when they arrive; the system will collapse.

A claim common in popular coverage of quantum computing.

Remark 25.7 (Quantum Threat Model)

Quantum computers threaten Bitcoin in two ways:

  1. Signature forgery (Shor's algorithm): Breaks ECDSA/Schnorr, requires thousands of logical qubits
  2. Mining speedup (Grover's algorithm): Quadratic speedup to hash search, requires millions of physical qubits

Remark 25.8 (Quantum Mitigations)

For signature forgery:

  • Addresses only reveal public keys when spent
  • Hash-based addresses (P2PKH, P2WPKH) hide public keys until spending
  • Post-quantum signatures can be added via soft fork
  • User migration can occur before quantum computers are viable

For mining:

  • Grover's provides only a √N speedup (not exponential)
  • Difficulty adjustment compensates automatically
  • Replacing SHA-256 itself, were it ever necessary, is the fork question analyzed under Claim 25.7

Conclusion. Published expert estimates for cryptographically relevant quantum machines range from the 2030s to several decades. The mitigations of Remark 25.8 require deployment ahead of that horizon, and already-exposed public keys are the unresolved part of the problem (Chapter 39). The claim compresses a migration problem with known mechanisms and one open sub-problem into a collapse scenario.


Claim 25.7 (Imminent Hash-Function Failure). Cryptographic hash functions are eventually broken; SHA-256 will follow MD5 and SHA-1, and its failure will destroy Bitcoin's security.

A claim that generalizes from the documented failures of MD5 (collisions, 2004) and SHA-1 (collisions, 2017).

Remark 25.9 (SHA-256 Security Status)

As of early 2026:

  • Collision resistance: 2¹²⁸ operations (birthday bound); no attacks on full SHA-256 significantly better than this
  • Preimage resistance: 2²⁵⁶ operations; no attacks better than brute force
  • Second preimage: 2²⁵⁶ operations; no practical attacks

Even if preimage resistance were weakened from 2²⁵⁶ to 2¹²⁸ operations, 2¹²⁸ remains computationally infeasible; collision resistance already stands at 2¹²⁸ by the birthday bound.

SHA-1 was broken after years of published, gradually improving attacks on reduced and then full versions. SHA-256 shows no comparable trajectory.

Conclusion. No attack on full SHA-256 meaningfully better than the generic bounds is known as of early 2026 (Remark 25.9), and the historical pattern of hash-function failure (long public erosion before a break) has not begun for SHA-256. If weaknesses emerged, script-level uses of SHA-256 could be supplemented by soft fork; replacing the proof-of-work or transaction-identifier hash would be a hard fork requiring the coordination of Chapter 16.

25.4 Claims about Consensus

Claim 25.8 (Majority Hashrate as Control). An attacker with 51 percent of the hashrate controls Bitcoin: it can steal coins, change the rules, inflate the supply, or shut the network down.

A reading suggested by the term "51% attack" itself; common in popular coverage.

Proposition 25.2 (Majority-Hashrate Capabilities)

Suppose an attacker controls a majority of hashrate, that the economy's full nodes enforce the validation predicate V(C, B) of Definition 13.18, and that the attacker holds no private keys other than its own. Then the attacker can:

  • Double-spend its own transactions
  • Censor specific transactions or addresses
  • Execute selfish mining for increased rewards
  • Reorganize recent blocks

The attacker cannot:

  • Spend coins for which it does not hold keys
  • Create coins beyond the subsidy schedule
  • Change consensus rules (full nodes reject invalid blocks)
  • Prevent users from transacting on a minority chain: immediately, if that chain changes the proof-of-work function (Chapter 26), or once the attack ceases, if it retains the same proof-of-work; while the attack is sustained, a same-proof-of-work minority chain can be reorganized at low marginal cost

Proof.

Hashrate determines which valid blocks become part of the chain, not what constitutes a valid block. A block that spends coins without their keys' signatures, or that exceeds the subsidy schedule, fails V(C, B), and full nodes reject it regardless of its proof-of-work.

If the attacker mines invalid blocks, honest nodes ignore them and follow the valid chain, even if it has less work. The most-work rule applies only among valid chains. The positive capabilities follow from majority control of block production: the attacker outpaces the honest chain in expectation, so it can reorganize recent blocks, replace its own transactions, and exclude transactions from its blocks while orphaning blocks that include them. ∎

An attacker with majority (51%) hashrate Can ordering of valid blocks Double-spend own transactions Censor specific transactions Selfish-mine for extra reward Reorganize recent blocks Cannot what counts as valid Steal coins without the keys Create coins beyond subsidy Change consensus rules Stop a minority chain Validity is decided by full nodes, not hashrate
Figure 25.3: Majority hashrate controls the ordering of valid blocks, not what is valid; the boundary is enforced by full nodes.

Conclusion. Majority hashrate confers control over the ordering of valid blocks, not over what is valid (Figure 25.3). The capabilities it grants (reorganization, double-spending of the attacker's own coins, censorship) are serious, and Chapter 36 analyzes them further; arbitrary control is not among them.


Claim 25.9 (Miner Sovereignty). Miners decide Bitcoin's rules: if a majority of hashrate wants a rule change, the change happens, and users must accept it.

A claim common in the governance debates of 2017 (Chapter 33).

Remark 25.10 (Rule Enforcement Hierarchy)

Bitcoin rule enforcement:

  1. Users run full nodes that enforce their chosen rules
  2. Miners produce blocks that must satisfy user node rules
  3. Invalid blocks are ignored regardless of hashrate
  4. Economic consensus determines which chain has value

Example 25.2 (BIP-148 and SegWit Activation)

In 2017, BIP-148 committed participating nodes to reject, from 1 August 2017, blocks that did not signal for SegWit. Miners began enforcing SegWit signaling via BIP-91 in July 2017, ahead of the BIP-148 enforcement date, and SegWit locked in shortly afterward. Whether BIP-148 was the decisive cause is debated; the episode demonstrates that user-side enforcement was credible enough to enter miners' calculations.

Conclusion. Miners select and order transactions within rules enforced by the full nodes of the economy. A rule change that economic nodes reject produces blocks those nodes ignore, whatever its hashrate (Proposition 25.2). The 2017 episode (Example 25.2) shows user-side enforcement entering miners' calculations; Chapter 33 treats the governance question in full.

25.5 Claims about Economics

Claim 25.10 (Fee-Market Insufficiency). Bitcoin cannot function once the block subsidy approaches zero: fee revenue will not replace the subsidy, miners will leave, and security will collapse.

Raised in academic work on the long-term security budget and common in long-horizon critiques; Chapter 38 treats the question at length.

Remark 25.11 (Long-Term Security Budget)

Security budget sustainability requires:

Cost of Attack ≥ Value Extractable by an Attack

where the cost of attack is determined by the hashrate that fee revenue (plus subsidy) can sustain.

This depends on:

  • BTC price (fees denominated in BTC)
  • Transaction volume and fee rates
  • Layer 2 settlement frequency
  • Required security level

Example 25.3 (Fee Revenue History)

Historical fee revenue during demand peaks (all figures approximate):

  • 2017 peak: ~10 BTC/block in fees (daily average, December 2017)
  • 2021 peak: ~2 BTC/block in fees (daily average, April 2021)
  • 2023: inscription demand produced repeated spikes above ~1 BTC/block in daily averages (May and December 2023)
  • April 2024: the halving block, block 840,000, carried ~37.6 BTC in fees, an extreme single-block outlier driven by demand for its block space

As the subsidy declines, fees must supply a growing share of any given security budget; whether demand supplies them is the open question of Chapter 38.

Remark 25.12 (Open Question: Fee-Based Security)

The transition to fee-based security is genuinely uncertain. It depends on future transaction demand, BTC price, and layer 2 adoption. This is an open research question, not a solved problem; neither is it a demonstration of inevitable failure.

Conclusion. Fee revenue is variable and demand-driven (Example 25.3), and the subsidy declines on a fixed schedule (Chapter 14). The claim asserts as certain an outcome that the analysis of Chapter 38 leaves open in both directions: neither sustained fee-funded security nor its failure is established.


Claim 25.11 (Energy Waste). Bitcoin mining consumes as much energy as a mid-sized country and produces nothing of value; the consumption is waste.

A claim common in environmental coverage; comparisons of mining consumption to national totals are typically cited in support.

The technical content separates from the normative content. What can be established is the relationship between consumption and security: the cost to attack Bitcoin is approximately the cost of acquiring and powering hardware equivalent to the existing hashrate (Chapter 14). Energy expenditure is not incidental to the security; it is the mechanism that makes block production costly to replicate. A system with the same consumption and no proof-of-work would obtain no security from it, and a proof-of-work system with negligible consumption would be cheap to attack.

Remark 25.13 (The Externality Question)

Whether the security purchased is worth the energy consumed is a normative question, and this book does not adjudicate it. Critics argue that the externalities of mining (emissions, grid load, hardware turnover) exceed the social value of the service, and that comparable monetary properties could be obtained more cheaply by other consensus designs. Proponents argue that the consumption is purchased voluntarily at market prices, that miners seek the cheapest available energy, and that the service secured, settlement without a trusted issuer, has no demonstrated substitute with the same properties. Both positions begin from the same technical facts stated above and diverge on valuation, not on mechanism.

Conclusion. The provable part of the claim's subject is the mechanism: attack cost approximates the cost of replicating the honest hashrate, and energy expenditure is how that cost is imposed. The claim's verdict (that the consumption is waste) is a valuation, contested on both sides, and is recorded as such in Remark 25.13.

25.6 Technical Misconceptions

Claim 25.12 (Address Blacklisting). Regulators can compel miners to blacklist addresses, rendering particular coins unusable.

A claim common in regulatory and compliance discussions.

Remark 25.14 (Censorship Properties)

Bitcoin addresses are pseudonymous identifiers with no protocol-level identity:

  • Anyone can generate unlimited addresses without permission
  • No transaction field carries identity, and nothing in V(C, B) (Definition 13.18) references a blacklist
  • As long as some miners include a transaction and the majority does not orphan their blocks, it eventually confirms (soft censorship, Definition 36.6): with non-censoring fraction q of hashrate, the expected inclusion delay is 1/q blocks, and censored users can pay higher fees to non-censoring miners

Two caveats sharpen the analysis rather than weaken it. A majority coalition willing to orphan non-compliant blocks could enforce hard censorship (Definition 36.6), at the visible cost of attacking the chain itself. And a soft fork could, in principle, make specific outputs unspendable: freezing is not "technically impossible," it is a rule change, and a rule change must win the fork game of Chapter 26 against the economic weight that rejects it. That is a stronger defense than impossibility: it does not depend on no one trying, only on the economy declining to follow.

Conclusion. The protocol has no freeze mechanism: nothing in the validation predicate references identity or a blacklist. Imposing one would require either majority-hashrate censorship sustained at visible cost, or a consensus change that the economy accepts (Remark 25.14); the claim, as stated, assumes a capability the protocol does not provide.


Claim 25.13 (Node Irrelevance). A non-mining full node contributes nothing: it adds no hashrate, secures nothing, and confers no power on its operator.

A claim made during the 2015–2017 scaling debates.

Remark 25.15 (Full Node Value)

A full node provides its operator:

  • Rule enforcement: Only accepts valid transactions
  • Privacy: No third party observes the operator's queries
  • Independent verification: No reliance on third parties for validation
  • Fork protection: The node remains on its operator's chosen ruleset

Economically significant users (exchanges, merchants) running full nodes create the economic reality that miners must respect.

Conclusion. A full node enforces the validation predicate for its operator and, when the operator is economically significant, contributes to the aggregate enforcement that disciplines miners (Remark 25.10). The claim confuses the absence of hashrate with the absence of function; validation and block production are different roles (Figure 25.3). The converse overstatement, that every node protects the network, is examined as Claim 25.19.

25.7 Claims from Within the Community

The claims above circulate mostly among Bitcoin's critics. The same instruments apply to claims that circulate among its advocates; the results of earlier chapters settle several of them.

Claim 25.14 (An Unbroken Record). Bitcoin has never been hacked: more than fifteen years of operation, with large value at stake, and the protocol has never failed.

A staple of advocacy.

In August 2010 the value-overflow bug let an attacker create 184 billion BTC in one transaction; the chain was rolled back 53 blocks by a coordinated upgrade (Remark 26.8, Example 36.1). In March 2013 an unwritten, environment-dependent rule split the network for 24 blocks (Example 33.7). In July 2015 half the hashrate extended an invalid chain six blocks deep (Example 17.2). (CVE-2018-17144, a 2018 inflation bug found and patched before exploitation, is a further near-miss rather than a failure.)

Conclusion. The precise claim is true and worth stating: the cryptographic primitives of Volume I have never been broken, and no theft has resulted from a protocol flaw that the network declined to fix. The consensus layer, however, has failed at least three times, and each failure was repaired within hours by exactly the social coordination that Claim 25.18 denies. The strong version of the slogan erases the most instructive events in Bitcoin's history.

Claim 25.15 (The Cap as Mathematical Law). The 21 million coin limit is mathematically guaranteed: the cap cannot change because the mathematics cannot change.

Common in advocacy, where the supply schedule is presented as a law of mathematics.

Definition 15.2 is a rule inside V(C, B) (Definition 13.18), and rules are changeable by the same processes that created them (Chapter 16). What mathematics guarantees is conditional: under the current rules, total issuance is bounded by 20,999,999.9769 BTC. What protects the rules themselves is the coordination game of Section 26.4 and the incentive analysis of Chapter 38: any chain that inflates the cap must win the fork game of Chapter 26 against the entire economic weight of the existing one.

Conclusion. The cap is a rule of the validation predicate, protected by a coordination game, not by mathematics. That protection is of a different kind from a theorem: an equilibrium of Chapter 26's fork game in which every holder is paid to defend the cap. Describing it as mathematical misstates where the security resides: in participants continuing to choose these rules.

Claim 25.16 (Decentralization as a Settled Property). Bitcoin is decentralized.

Asserted as a settled boolean property, in advocacy and in policy discussion alike, usually as the contrast with every alternative system.

Validation is genuinely permissionless and widely distributed; that much the device-tier analysis of Section 34.1 supports. But block template construction is concentrated in a handful of mining pools; maintainer influence over the de facto specification is real (Remark 33.6); the supermajority of nodes run one implementation (Remark 33.13); and most users occupy the custodial rungs of the ladder in Section 34.5, where they verify nothing. Each of these is a measured quantity that moves over time.

Conclusion. Decentralization is a vector of measurable quantities, several of which are measurably concentrated; it is not a boolean property. "Is Bitcoin decentralized?" is not a well-posed question; "decentralized in which dimension, measured how, compared to what?" is—and the answers differ by dimension.

Claim 25.17 (Anonymity). Bitcoin transactions are anonymous.

Persisting from the protocol's early reputation; asserted by admirers as freedom and by critics as menace.

Every transaction is public indefinitely, and addresses cluster: common-input ownership, change detection, and exchange identity links collapse pseudonyms wholesale. The BIP-37 privacy failure (Chapter 18), the engineering effort behind compact filters (Chapter 19), and the Electrum leakage analysis (Section 20.3) are all responses to the fact that the base protocol leaks. A bank record is private from the public and visible to the state; Bitcoin's ledger is the reverse: visible to everyone, deniable to no one, indefinitely.

Conclusion. Bitcoin is pseudonymous with a permanent public record, and its privacy is poor by default; the privacy chapters of this volume exist because of it. Whether the visibility trade is desirable is debatable; that the system is anonymous is false: the analyses of Chapters 18–20 quantify the linkage.

Claim 25.18 (Code as Law). The rules are whatever the software enforces; no human authority can override them.

A slogan common in advocacy, inherited from broader debates on software governance.

March 2013 is the decisive counterexample: the 0.8-valid chain was abandoned by agreement, with miners deliberately reorganizing onto the chain the buggy software preferred (Example 33.7): human coordination overruling the deployed code's verdict, within hours. Section 33.9 gives the structural reason the slogan cannot be exact: no canonical statement of the rules exists apart from software that humans write, review, ship, and choose to run.

Conclusion. The code's authority is itself a social fact, and the network has overridden the code's verdict when consensus demanded it. The defensible content of the slogan is narrower: no small group can quietly override the rules, because overriding them requires the broad coordination of Chapter 33.

Claim 25.19 (Nodes as Network Protection). Every full node strengthens Bitcoin; running one is a duty with network-wide effect.

The advocate-side mirror of Claim 25.13; common in community guidance.

Remark 25.15 established what a node provides its operator: independent verification of the operator's own funds. Network-level effects are real but aggregate: what disciplines miners is the enforcing economic fraction e of Section 34.4 (validation by actors whose acceptance gives coins value), not the raw count of listening nodes, which is cheaply inflatable and economically weightless. One more node behind a home connection changes e by approximately nothing; a merchant, exchange, or payment processor validating independently changes it materially.

Conclusion. A full node primarily protects its operator; network-level power is a property of the aggregate enforcing economy. Both extremes fail (Claim 25.13 in one direction, this claim in the other), and the resolution is the same in both: verification matters in proportion to the economic activity that depends on it.

25.8 A Procedure for Evaluating Claims

The analyses of Sections 25.1 through 25.7 follow a common procedure, which applies equally to claims from critics and from advocates, and to claims not treated in this chapter.

Remark 25.16 (Evaluation Procedure)

  1. State the claim precisely: What exactly is being asserted?
  2. Identify the model: What assumptions does the claim require?
  3. Check against the protocol: Does the claim match what the code does?
  4. Analyze incentives: Would rational actors behave as claimed?
  5. Consider adversarial scenarios: What attacks does this enable or prevent?
  6. Check empirically: Has this been tested or observed?

Example 25.4 (Applying the Procedure)

Consider the claim: "Lightning is centralized because it has hubs."

  1. Precise statement: Large routing nodes give Lightning a hub-and-spoke topology, and this topology concentrates power
  2. Model: Assumes that topology implies control
  3. Protocol check: Any node may route; the protocol grants hubs no special authority
  4. Incentives: Routing nodes compete on fees; senders choose routes
  5. Adversarial: A hub can refuse to route or close channels, but cannot steal funds (Proposition 25.1)
  6. Empirical: Topology measurements show routing concentration but no gatekeeping power over channel creation; any node may open channels

The topology claim and the power claim come apart at step 3: routing concentration is measurable and real; custodial control does not follow from it.

Exercises

Exercise 25.1

Consider the claim: "Bitcoin is deflationary because 21 million coins." Apply the evaluation procedure (Remark 25.16). Is this technically correct? What nuance is missing?

Exercise 25.2

Calculate the hashrate needed for an attacker to reliably double-spend a 6-confirmation transaction. What is the economic cost?

Exercise 25.3

Someone argues: "If all exchanges implemented address blacklists, blacklisted coins would be worthless." Analyze this claim using game theory.

Exercise 25.4

Construct a precise attack scenario where SPV fails but a full node would succeed. Calculate the attack cost and success probability.

Exercise 25.5

"Layer 2 reduces security because funds are not on the base layer." Evaluate this claim for Lightning, sidechains (Chapter 31), and custodial solutions.

Exercise 25.6

Research and evaluate: "Taproot makes Bitcoin less private because it reveals which transactions use it." Is this technically accurate?

Chapter Summary

Volume III Conclusion

We have traveled from the theoretical foundations of SPV through the practical realities of light clients, node optimizations, client-side validation, payment channels, and the Lightning Network. Along the way, we have stated common claims precisely and established their scope.

The base layer provides settlement and verification; upper layers provide throughput. The preceding chapters quantify the trade at each level.

The reader who has worked through all three volumes now possesses the mathematical and protocol knowledge to understand Bitcoin from first principles: to verify rather than trust, to analyze rather than believe, and to build rather than merely use.