Light Clients and the Validation Gap

20.1 The Light Client Spectrum

Light clients exist on a spectrum from "minimal trust, maximal resources" to "maximal trust, minimal resources":

Trust Requirements by Architecture

20.2 The Electrum Protocol

Electrum, created in 2011, pioneered the client-server model for Bitcoin wallets. The Electrum protocol (also called the ElectrumX protocol) provides a JSON-RPC interface for querying blockchain data.

Architecture Overview

Trust Model and Indexing

The protocol consists of a small set of JSON-RPC methods through which the client retrieves transaction history, balances, and unspent outputs for its scripts, subscribes to changes, and broadcasts transactions. Nearly every method transmits a script identifier to the server, so the query interface itself—not any implementation defect—is what discloses the wallet's contents. The trust model follows directly: the client trusts miners for transaction validity (as in any SPV design) and trusts the server to report history completely and honestly, although Merkle proofs, when requested, let the client verify inclusion of reported transactions against its own header chain.

One detail of the indexing scheme matters for what follows: servers index the blockchain not by address but by a hash of the output script.

Several server implementations exist (ElectrumX, electrs, Fulcrum, Electrum Personal Server), differing mainly in whether they maintain a full script-hash index of the chain—tens of gigabytes beyond the full node itself, allowing the server to answer queries for arbitrary wallets—or, as in the personal-server design, track only the wallets registered with them and require essentially no index at all.

20.3 Privacy Analysis of Electrum

What the Server Learns

Timing Attacks and Mitigations

Beyond the addresses themselves, query patterns leak information: the order and timing of script-hash queries reveal when a wallet was created and how its keys are derived (hierarchical-deterministic structure under BIP-32, a wallet standard outside this book's scope), queries issued immediately after a broadcast identify change outputs, and recurring patterns allow a server to link separate sessions to the same wallet.

The structural leak admits one complete mitigation and several partial ones. The complete mitigation is to operate the server oneself, connected to one's own full node: the protocol still discloses everything, but only to infrastructure the user controls. Partial mitigations include connecting over Tor (which hides the client's network identity but not its addresses) and splitting queries across multiple servers (which gives each server a partial view at the cost of disclosing to more parties).

20.4 Esplora and Block Explorer APIs

Many wallets query HTTP APIs provided by block explorers, of which Esplora (an open-source explorer by Blockstream) defines the de facto standard interface. The API is a catalog of REST endpoints keyed by address, txid, and block hash: the client fetches history, balances, and unspent outputs for each of its addresses in plaintext and posts raw transactions for broadcast. The disclosure is therefore the same as Electrum's—the server learns every address—but the verification is weaker: responses carry no Merkle proofs, so the client has no means of checking them against the header chain.

Trust Model

As with Electrum, the trust and privacy problems are problems of public infrastructure: a self-hosted Esplora instance backed by one's own full node restores privacy, availability, and integrity at the cost of roughly 100 GB of additional index storage.

20.5 Hybrid Approaches

Modern wallets often combine multiple approaches to optimize for different requirements.

Multi-Backend Wallets

Verification Layers

Even when using a server backend, clients can add verification:

20.6 The Validation Gap

This section is the theoretical core of the chapter. The architectures surveyed so far differ in who serves the data, but they share one limit: they obtain and verify inclusion of transactions in blocks, and inclusion is not the same as validity. We now examine precisely what a light client cannot verify—the validation gap—and consider how the gap might be narrowed incrementally.

What Full Nodes Check

Recall from Chapter 15 that consensus requires every block to satisfy a comprehensive set of rules. A full node verifies all of them; a light client verifies almost none. The following table classifies every major consensus check by whether a light client can perform it.

Fraud Proofs: Compact Evidence of Rule Violations

The Bitcoin whitepaper, in its discussion of simplified payment verification, anticipated that full nodes could alert light clients when they detect an invalid block. This concept is now called a fraud proof: a compact piece of evidence that demonstrates a specific consensus violation.

BIP 180 specifies a fraud proof for the block weight rule (Class F above). The proof works by including SHA-256 midstate data that allows reconstruction of the merkle root from partial transaction size information. If the reconstructed merkle root matches the header and the computed weight exceeds the consensus limit, the proof is valid. The total evidence is approximately 1–2 KB, compared to the full block which may be several megabytes.

Similar constructions work for other Class F rules. A coinbase inflation proof, for instance, requires only the coinbase transaction (typically 200–500 bytes) and its merkle inclusion proof (about 11 hashes for a block of 2000 transactions). The light client verifies the merkle proof against the header it already holds, parses the coinbase outputs, and checks them against the known subsidy for that block height. Note the limit: verifying the fee component would require the input values of every transaction in the block, so a compact fraud proof can only catch coinbase outputs exceeding the subsidy plus an independently proven fee total.

The Data Availability Problem

Fraud proofs assume that block data is available to honest full nodes. But a malicious miner could publish a valid header—one with sufficient proof of work—while withholding the corresponding block data. In this scenario:

• The light client sees a valid header and accepts the block.
• Full nodes cannot download the block to verify it.
• No fraud proof can be generated because the evidence is hidden.

This is the data availability problem, and its sting is sharper than the withholding scenario alone suggests. Suppose an honest node raises the alarm: "the data for block B is unavailable." That claim is unattributable. Unavailability is not a property of the block but of the network at a moment in time—the withholder can release the data the instant anyone investigates, at which point the alarm looks false and the alarmer looks dishonest. No proof of past unavailability is possible, so no one can be punished: not the miner (the data is now available) and not the alarmer (perhaps it really was unavailable when they checked). The consequence is that unavailability alarms are a free, unpunishable denial-of-service vector: an adversary can cry wolf endlessly, forcing light clients either to download whole blocks (defeating the purpose) or to learn to ignore alarms (defeating the alert system). This dilemma, not the absence of a UTXO commitment, is the structural reason the whitepaper's suggestion that full nodes could "alert" light clients (Section 17.7) has never been made to work.

Solutions proposed in other systems include data availability sampling, where light clients request random fragments of the block and use erasure coding to detect withholding probabilistically (Al-Bassam, Sonnino & Buterin, 2018). Bitcoin does not currently implement such a mechanism.

Compact Clients: Header Distribution via Relay Networks

A practical obstacle for light clients is obtaining block headers reliably. Traditional SPV clients connect to the Bitcoin peer-to-peer network directly, which exposes them to eclipse attacks where all connected peers are controlled by an adversary.

An alternative approach distributes headers through a separate relay network. Full nodes acting as publishers serialize each new block header and broadcast it through the relay layer. Light clients subscribe to multiple independent publishers and verify the header chain locally.

This architecture offers improved eclipse resistance compared to traditional SPV. An attacker must compromise all relay endpoints simultaneously rather than surrounding a single node in the P2P network. Publisher identity is cryptographically fixed, so the client knows exactly which full nodes it is trusting and can select publishers operated by independent parties.

Incremental Verification Tiers

Combining the classification above with the compact client architecture yields a natural progression from minimal to near-full verification:

Each tier strictly reduces the trust surface. A Tier 0 client trusts that the majority of mining hash rate produces valid blocks. A Tier 1 client only trusts that miners do not violate the specific Class F rules and that no honest full node detects the violation, which is a strictly weaker assumption. The progression continues until Tier 3, which approaches full node security but depends on infrastructure that does not yet exist in Bitcoin's consensus layer.

20.7 Wallet Architectures in Practice

Desktop Wallets

Mobile Wallets

Hardware Wallet Integration

Hardware wallets (Ledger, Trezor, Coldcard) are signing devices, not full wallets. They require a software companion for blockchain queries:

• Vendor software: Ledger Live, Trezor Suite (use vendor servers)
• Third-party wallets: Electrum, Sparrow (configurable backend)
• Best practice: Use hardware wallet with personal server backend

20.8 Choosing an Architecture

Decision Framework

Recommendations by Use Case

The Path to Self-Sovereignty