Light Client Architectures

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 ElectrumX protocol) provides a JSON-RPC interface for querying blockchain data.

Architecture Overview

Protocol Methods

Script Hash Addressing

Electrum uses script hashes rather than addresses for efficient indexing:

scriptPubKey: OP_0 OP_PUSH_20 <20-byte-hash>
              = 0x0014{hash160}

SHA256(scriptPubKey) = abc123...def456

script_hash (little-endian hex) = 56f4de...23c1ab

Server Implementations

20.3 Privacy Analysis of Electrum

What the Server Learns

Timing Attacks

Even beyond direct address queries, timing patterns reveal information:

• Wallet creation: Sequential address queries reveal when the wallet was created
• HD derivation: Query patterns reveal BIP-32 derivation paths
• Change addresses: Immediate queries after broadcasts reveal change outputs
• Session correlation: Multiple sessions can be linked by query patterns

Mitigations

Other mitigations:

• Tor: Hide IP address (but server still sees addresses)
• Multiple servers: Split queries across servers (partial mitigation)
• Electrum Personal Server: Minimal server for single wallet
• Gap limit increase: Query more addresses to add noise

20.4 Esplora and Block Explorer APIs

Many wallets use HTTP APIs provided by block explorers. While convenient, these have significant trust and privacy implications.

Common API Patterns

GET /address/{address}              # Address info
GET /address/{address}/txs          # Transaction history
GET /address/{address}/utxo         # Unspent outputs
GET /tx/{txid}                      # Transaction details
POST /tx                            # Broadcast transaction
GET /block/{hash}                   # Block data
GET /blocks/tip/height              # Current height

Esplora

Esplora (by Blockstream) is an open-source block explorer with a well-defined API. Many wallets support Esplora-compatible backends.

// Get UTXOs for address
GET https://blockstream.info/api/address/bc1q.../utxo

Response:
[
  {
    "txid": "abc123...",
    "vout": 0,
    "status": {"confirmed": true, "block_height": 800000},
    "value": 10000
  }
]

Trust Model

Self-Hosted Esplora

Running your own Esplora instance provides:

• Privacy: No third-party sees your queries
• Availability: You control uptime
• Integrity: Backed by your own full node

Requirements: Full node + Esplora indexer (~100 GB additional 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

The previous sections described how light clients obtain and verify inclusion of transactions in blocks. But inclusion is not the same as validity. This section examines precisely what a light client cannot verify and considers 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 that the total does not exceed the known subsidy for that block height plus the claimed 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. 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. 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