Chapter 20

Light Client Architectures

From Electrum to Modern Wallet Backends

Not every user can or wants to run a full Bitcoin node. Light clients provide a spectrum of trade-offs between resource requirements and trust assumptions. Understanding these trade-offs is essential for choosing—or building—appropriate wallet infrastructure.

This chapter surveys the major light client architectures in use today, from the Electrum client-server model to modern approaches combining multiple techniques. We analyze each approach's trust model, privacy characteristics, and suitability for different use cases.

20.1 The Light Client Spectrum

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

Full Validation

Trust: None (trustless)

Resources: ~550 GB storage, continuous bandwidth

Example: Bitcoin Core

SPV / Light Node

Trust: Miners (majority honest)

Resources: ~60 MB headers + filters

Example: Neutrino, BIP-157

Server-Dependent

Trust: Server operator

Resources: Minimal

Example: Electrum (public servers)

Definition 20.1 (Light Client)

A light client is any Bitcoin client that does not independently validate all transactions and blocks. Light clients necessarily trust some external party—miners, servers, or peers—for certain guarantees that full nodes verify independently.

Trust Requirements by Architecture

Architecture	Transaction Validity	Inclusion Proof	Privacy
Full Node	Self-verified	Self-verified	Perfect
Pruned Node	Self-verified	Self-verified	Perfect
BIP-157/158	Trust miners	Merkle proof	Good
Electrum (personal)	Trust miners	Server provides	Good
Electrum (public)	Trust server + miners	Server provides	Poor
Centralized API	Trust service	Trust service	None

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

Figure 20.1 — Electrum architecture: clients connect to servers that maintain an address-indexed database built from a full node. The server sees all client addresses and queries.

Protocol Methods

Definition 20.2 (Core Electrum Methods)

Method	Purpose	Privacy Impact
`blockchain.scripthash.get_history`	Get transaction history for address	Reveals address ownership
`blockchain.scripthash.get_balance`	Get address balance	Reveals address ownership
`blockchain.scripthash.listunspent`	Get UTXOs for address	Reveals spendable outputs
`blockchain.scripthash.subscribe`	Watch address for changes	Reveals ongoing interest
`blockchain.transaction.broadcast`	Submit transaction	Reveals spending intent
`blockchain.transaction.get`	Fetch raw transaction	Reveals transaction interest
`blockchain.headers.subscribe`	Get new block notifications	Minimal

Script Hash Addressing

Electrum uses script hashes rather than addresses for efficient indexing:

Definition 20.3 (Electrum Script Hash)

For any scriptPubKey, the Electrum script hash is:

script_hash = SHA256(scriptPubKey), reversed to little-endian hex

This provides a uniform 32-byte identifier regardless of address type.

Example 20.1 (Script Hash Computation)

For a P2WPKH address with scriptPubKey:

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

SHA256(scriptPubKey) = abc123...def456

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

Server Implementations

Definition 20.4 (Electrum Server Software)

Software	Language	Index Size	Notes
ElectrumX	Python	~50 GB	Reference implementation
Fulcrum	C++	~100 GB	Faster, more features
electrs	Rust	~30 GB	Efficient, minimal
Electrum Personal Server	Python	~0 GB	Single-wallet, no index

20.3 Privacy Analysis of Electrum

What the Server Learns

Theorem 20.1 (Electrum Privacy Leakage)

When a client connects to an Electrum server, the server learns:

Every address the wallet has ever generated
The complete transaction history for those addresses
Current balances and unspent outputs
Which addresses are monitored in real-time
When and what transactions the user broadcasts
Client IP address (without Tor)
Wallet software and version (from protocol negotiation)

Proof.

The Electrum protocol requires the client to send scriptPubKey hashes to query address history. The server must store and respond to these queries, necessarily learning the queried addresses. Subscription requests explicitly reveal ongoing interest. Transaction broadcasts reveal spending before the transaction propagates through the P2P network. ∎

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

Running Your Own Electrum Server

The privacy concerns above apply to public Electrum servers. Running your own server (ElectrumX, Fulcrum, electrs) connected to your own full node eliminates third-party privacy leakage, though requires the resources to run both services.

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

Definition 20.5 (Block Explorer API Endpoints)

Typical REST endpoints:

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.

Example 20.2 (Esplora Query)

// 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

Theorem 20.2 (API Trust Requirements)

When using a third-party API:

Availability: Service can deny access or go offline
Integrity: Service can return false data (balances, history)
Privacy: Service logs all queries with IP addresses
Censorship: Service can refuse to broadcast transactions

Without independent verification (Merkle proofs, header validation), the client must trust the API operator completely.

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

Figure 20.2 — Hybrid architecture: wallets can support multiple backends with configurable priority, optimizing for security when available and falling back to less private options when necessary.

Verification Layers

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

Definition 20.6 (Layered Verification)

Layer	Verification	Protects Against
Header chain	Validate PoW chain	Fake blocks with low work
Merkle proofs	Verify tx inclusion	Fabricated transactions
Filter headers	Multi-peer consensus	Transaction omission
Multiple servers	Cross-reference responses	Single malicious server

Example 20.3 (Verification-Enhanced Electrum)

A wallet using Electrum can add security by:

Requesting Merkle proofs for all transactions
Maintaining a validated header chain locally
Verifying transactions are included in headers
Querying multiple Electrum servers for consensus

This doesn't fix privacy (servers still see addresses) but prevents balance manipulation attacks.

20.6 Wallet Architectures in Practice

Desktop Wallets

Wallet	Backend	Privacy	Verification
Bitcoin Core	Built-in full node	Perfect	Full
Electrum	Electrum servers	Configurable	Merkle proofs
Sparrow	Core/Electrum/Public	Configurable	Merkle proofs
Wasabi	BIP-157/158	Good	Filters + headers

Mobile Wallets

Wallet	Backend	Privacy	Notes
BlueWallet	Electrum/own server	Configurable	Can use own server
Blockstream Green	Blockstream servers	Trust Blockstream	Multisig option
Phoenix (LN)	ACINQ servers	Trust ACINQ	Lightning-focused
Breez (LN)	Neutrino	Good	BIP-157/158

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.7 Choosing an Architecture

Decision Framework

Definition 20.7 (Architecture Selection Criteria)

Consider these factors when choosing a light client architecture:

Privacy requirements: Who can see your addresses?
Trust requirements: What can a malicious server do?
Resource constraints: Storage, bandwidth, always-online?
Use case: Savings, spending, Lightning, business?
Technical ability: Can you run your own infrastructure?

Recommendations by Use Case

Use Case	Recommended	Rationale
Long-term savings	Full node + hardware wallet	Maximum security for large amounts
Privacy-focused	Full node or personal Electrum	No third-party sees addresses
Mobile spending	Wallet with own server	Balance convenience and privacy
Lightning node	Full node or Neutrino	Need to monitor channels
Casual/learning	Any reputable wallet	Convenience acceptable for small amounts
Business/exchange	Full node required	Cannot trust third parties

The Path to Self-Sovereignty

Progressive Decentralization

Users often progress through trust levels as they gain experience:

Start with convenient public server wallet
Add Tor for IP privacy
Run personal Electrum server
Eventually run full Bitcoin Core node

This progression reflects increasing value stored and deepening understanding.

Exercises

Exercise 20.1

Set up electrs (Rust Electrum server) connected to Bitcoin Core in regtest mode. Query it using the Electrum protocol and observe the raw JSON-RPC messages.

Exercise 20.2

Compare the bandwidth requirements for syncing a 100-address wallet from genesis using: (a) full node, (b) BIP-157/158, (c) Electrum server queries. Assume average block has 2500 transactions.

Exercise 20.3

Design an attack where a malicious Electrum server profits by lying about transaction confirmations. What verification would detect this?

Exercise 20.4

Explain why running an Electrum server over Tor still leaks privacy to the server operator, while BIP-157/158 over Tor provides meaningful privacy even against the peer.

Exercise 20.5

A wallet queries three Electrum servers and receives conflicting balance information. Design a protocol to identify which server(s) are lying using Merkle proofs.

Exercise 20.6

Calculate the storage requirements to run: (a) Bitcoin Core, (b) pruned Bitcoin Core, (c) Bitcoin Core + ElectrumX, (d) Bitcoin Core + Fulcrum. Which setups can run on a Raspberry Pi with 1TB storage?

Chapter Summary

Light clients exist on a spectrum from trustless (full node) to fully trusted (centralized API), with various trade-offs in between.
Electrum's client-server model provides efficient address queries but reveals all wallet addresses to the server.
Running your own Electrum server eliminates third-party privacy leakage but requires additional infrastructure.
Block explorer APIs are convenient but provide no verification and complete privacy loss to the operator.
Hybrid approaches combine multiple backends with verification layers to optimize for different requirements.
The best architecture depends on your specific privacy, security, and resource requirements—there is no one-size-fits-all solution.