Defense Mechanisms

Remark 37.1 (Trust Accounting: Confirmations)

What is trusted: the honest-majority hypothesis, q < 0.5, together with the assumption that the node observing the confirmations sees the real network rather than an attacker-curated view (Section 37.5). By whom: every recipient who treats a k-confirmed payment as settled. Failure mode: if q ≥ 0.5, Theorem 36.1 gives reversal probability 1 for every k; no confirmation count protects against a majority attacker. Even for q < 0.5 the guarantee is quantitative, not absolute: recall from Chapter 36 that the naive catch-up bound (q/(1−q))ᵏ understates the true probability (at q = 10%, k = 6: about 0.02%, not 0.0002%). Confirmations therefore buy a measured quantity of security against a hypothesized adversary; they do not buy finality.

Remark 37.2 (Trust Accounting: Checkpoints)

What is trusted: the developers who selected the (height, hash) pairs, and the public review process around the release that shipped them. By whom: every node running an unmodified binary containing the checkpoints. Failure mode: a wrong or malicious checkpoint would force nodes onto a developer-chosen history, overriding proof-of-work entirely at the checkpointed heights. The trust is bounded in two ways. First, in scope: checkpoints cover only deep history. The most recent mainnet checkpoint sits at height 295,000 (April 2014), and none has been added since, so checkpoints constrain nothing about recent blocks. Second, in detectability: each pair is publicly checkable against the chain every existing node already holds, so a release containing a divergent checkpoint would fail review or be exposed immediately upon comparison. The trust is in a loud, auditable artifact, not a silent one.

Remark 37.3 (Historical Checkpoints)

Bitcoin Core historically included checkpoints:

// From chainparams.cpp (historical)
checkpointData = {
    {11111,  "0x0000000069e244f73d78e8fd29ba2fd2..."},
    {33333,  "0x000000002dd5588a74784eaa7ab0507a..."},
    {74000,  "0x0000000000573993a3c9e41ce34471c0..."},
    {105000, "0x00000000000291ce28027faea320c8d2..."},
    // ... more checkpoints
};

In exchange for the trust of Remark 37.2, checkpoints provide DoS protection (low-work fake chains are rejected quickly), deep-reorg prevention (no reorg past a checkpoint), and a sync speedup (some validation is skipped before the checkpoint).

Remark 37.4 (From Checkpoints to Weaker Assumptions)

Checkpoints are the most heavily criticized item in the trust ledger: they place the choice of valid history directly in developers' hands, could in principle be used maliciously, and sit uneasily with the "don't trust, verify" ethos. Modern Bitcoin Core has therefore frozen the checkpoint list and replaced its functions with mechanisms that ask for strictly less trust:

• Headers-first sync: verify the proof-of-work chain before downloading blocks (Definition 21.2); trusts nothing beyond proof-of-work itself
• Minimum chain work: reject chains below a work threshold (Section 37.3); trusts one number, not a chosen chain
• AssumeValid: skip signature verification beneath a buried block (Section 37.4); trusts a hash whose effect is void unless an attacker also out-works the honest network

The progression is the central pattern of this chapter: successive defenses retain most of the benefit while shrinking the scope of what must be trusted.

// Approximate minimum chain work (increases with each release;
// shown at its mid-2026 magnitude, roughly 8.5 × 10²⁸)
nMinimumChainWork = 0x0000000000000000000000000000000000000001
                    128750f82f4c366153a3a030;

Remark 37.5 (Trust Accounting: Minimum Chain Work)

What is trusted: that the cumulative-work value recorded in the release is honest, that is, no greater than the work of the actual best chain at release time. By whom: every syncing node. Failure mode: a value set too low (or an old release never updated) weakens the filter, and the node may accept a low-work attack chain as a plausible sync candidate, wasting bandwidth and, in the worst case, following a fake chain until full validation or a higher-work honest chain corrects it. A value set too high, above the honest chain's work, fails loudly: the node refuses to consider any chain valid and cannot complete sync, a denial of service that is immediately visible rather than silently corrupting.

The trust here is strictly weaker than checkpoint trust: the value names no block and selects no chain. Any chain meeting the threshold passes, so developers shipping the number cannot steer nodes onto a particular history; they can only set the height of the bar.

Remark 37.6 (Trust Accounting: AssumeValid)

What is trusted: the release process that selected the buried block hash: the developers who proposed it, the reviewers who checked it, and the signatures on the distributed binary. By whom: every node running with the default setting (it can be disabled with -assumevalid=0). Failure mode: accepting a history containing invalid signatures beneath the buried block. The trust is conjunctive, which is what makes it small: by Theorem 21.1, a malicious hash has no effect unless the chain containing the invalid signatures is also the most-work chain the node sees. An attacker must therefore corrupt the release process and out-work the honest network. The scope is also narrow: only signature checks are skipped, only beneath the buried block; amounts, inflation limits, and all other rules of the validation function (Definition 13.18) are still enforced.

Remark 37.7 (Trust Accounting: AssumeUTXO)

What is trusted: the snapshot hash shipped with the binary, through the same release process as AssumeValid. By whom: nodes that opt in to snapshot-based sync. Failure mode: larger than AssumeValid's. A wrong snapshot hash endorses an arbitrary UTXO set: fabricated balances, erased coins, anything. The bound is temporal rather than structural: by Theorem 21.2, background validation eventually re-derives the UTXO set from genesis, and a node that finds a mismatch rejects the snapshot. The trust is therefore borrowed, not granted: it is real during the window between snapshot load and background-validation completion, and it is repaid in full when the two-phase sync finishes.

Remark 37.8 (Trust Accounting: Peer Selection)

What is trusted: assumptions about network topology: that the DNS seeds and address gossip from which a node learns peers are not wholly attacker-controlled, and that honest listening nodes are spread across many network groups. By whom: every node, since every node must choose peers somehow. Failure mode: the eclipse attack of Section 36.4. An eclipsed node still enforces every consensus rule, so an attacker cannot feed it invalid blocks; but the node's view of the best chain, the mempool, and network time becomes attacker-curated, which undermines the confirmation counting of Section 37.1 and enables the time-dilation attacks of Section 36.5.3. Unlike the mechanisms of Sections 37.2–37.4, this trust cannot be replaced by a hash in a binary; it can only be diversified, which is what the following defenses do.

Remark 37.9 (Eclipse Attack Mitigations)

Bitcoin Core includes multiple eclipse attack defenses:

• Bucketed peer storage: Peers stored in buckets by IP range
• Outbound diversity: Connect to different /16 networks
• Anchor connections: Remember peers across restarts
• Feeler connections: Periodically test new peers
• Peer eviction logic: Protect diverse, long-standing connections

Each defense spreads the topology trust of Remark 37.8 across more independent parties, so that an attacker must control many network groups simultaneously rather than one address range.

Remark 37.10 (Tor and Privacy)

Running over Tor provides additional protection:

• IP address hidden from peers
• Harder to target a specific node
• Onion-only mode possible (-onlynet=onion)

In trust-accounting terms this is a substitution, not an elimination: the node exchanges trust in the visibility of its own network position for trust in the Tor network's relays and directory authorities, and accepts higher latency and exposure to Tor-level attacks in return.

Remark 37.11 (Trust Accounting: The Honest-Majority Hypothesis)

What is trusted: that the incentive structure of mining keeps a majority of hashrate honest, funded by the security budget:

Security Budget = Block Subsidy + Transaction Fees

By whom: everyone relying on confirmation-based security, which by Remark 37.1 is every recipient of a payment. Failure mode: if the budget no longer makes honest mining more attractive than attacking, the hypothesis q < 0.5 can fail, and with it the entire first row of the ledger. The trusted party here is notable: it is not a developer or a release process but a market structure, with no binary to audit and no flag to disable. Chapter 38 examines the conditions under which this trust could erode as the subsidy declines.

Remark 37.12 (Attack-Cost Asymmetry)

What currently keeps the hypothesis funded is an asymmetry between attacking and defending (cost figures in Section 36.6 and Example 36.2):

• An attacker must match the honest hashrate plus some margin
• The attacker pays for hardware, electricity, and opportunity cost
• Honest miners are paid (block rewards)
• Attacker gains are self-limiting: the double-spend value plus any block rewards earned, whose value tends to collapse if the attack undermines confidence

Remark 37.13 (Trust Accounting: The Social Layer)

What is trusted: off-protocol coordination: that an ad hoc set of developers, mining pool operators, and businesses can communicate, agree on a response, and act within hours when the protocol itself fails. By whom: everyone, but only in emergencies; in normal operation this layer is dormant. Failure mode: two-sided. If the trust is misplaced because coordination fails, a consensus emergency goes unresolved and the chain stays split. If the trust is misplaced in the opposite direction, the same small group that can coordinate a rescue could coordinate a rule change, which is precisely the governance concern of Chapter 33 and the maintainer trust vector of Section 33.9. The social layer is the only defense in this chapter whose trusted party is a group of identifiable people acting with discretion rather than an auditable artifact.

Remark 37.14 (Channels of Social Defense)

Beyond technical rules, Bitcoin has social defenses:

• User Activated Soft Fork: Users can reject miner misbehavior
• Exchange monitoring: Detect and respond to attacks
• Community coordination: Share attack intelligence
• Emergency response: Coordinate defensive forks if needed

Remark 37.15 (Practical Finality)

Deterministic finality is not free of trust either: it relocates trust into the validator set and its membership rules. Bitcoin's probabilistic finality becomes practical finality when the cost of reversal exceeds the value at risk: typically 6 confirmations for large amounts, fewer for amounts below the attack-cost threshold of Section 37.6. As always in this chapter, "final" abbreviates a trust statement: final, assuming the honest-majority hypothesis holds and the node's view of the network is genuine.