What is light client?

A wallet or node that verifies block headers and requests proofs for the few transactions it cares about, rather than downloading the whole chain.

Bitcoin's original design anticipated this: a header chain plus a Merkle branch proves a transaction is in a block without the block (source: the Bitcoin white paper, section 8). The trade-off is that a light client learns which addresses interest it from whoever serves it, and it trusts that it is being shown the real header chain.

Most phone wallets work this way, and many desktop wallets do too. The distinction that matters is between verifying and asking: a light client checks proofs, while a wallet that simply queries an API and displays the answer is trusting that server completely.

How it works

A full node downloads and validates every block and every transaction, which costs hundreds of gigabytes and hours of initial synchronization. A light client does far less and still gets a meaningful guarantee.

1. It downloads only block headers, which are small. On Bitcoin a header is 80 bytes, so the whole header chain is a few tens of megabytes rather than hundreds of gigabytes.
2. It verifies that the headers form a valid chain with the expected proof of work, which means it can tell a real chain from a fabricated one without seeing any transactions.
3. For a transaction it cares about, it requests a Merkle branch: the short set of hashes proving that transaction is included in a block whose header it already has.

What it cannot do is check that the transactions inside those blocks are themselves valid, because it never sees them. It is relying on the assumption that producing a chain of valid headers is expensive enough that nobody would build a fraudulent one to fool a phone wallet.

The privacy cost is separate and real. Asking a server for proofs about specific addresses tells that server which addresses are yours. Filter-based approaches, where the client downloads compact filters and decides locally which blocks to fetch, reduce that leak considerably.

On proof-of-stake chains the header check is replaced by verifying signatures from a rotating committee, which is what Ethereum's sync committee exists to provide.

Example

Illustrative arithmetic. Bitcoin headers are 80 bytes each and blocks arrive roughly every ten minutes, so a year is about 52,560 blocks, which is roughly 4.2 megabytes of headers. Fifteen years of history is under 70 megabytes. The full chain over the same period is measured in hundreds of gigabytes. A phone can hold and verify the first and cannot reasonably hold the second, which is the entire reason the design exists.

Why it matters when you buy

When you withdraw from an exchange to your own wallet, what the wallet shows depends on how it learns about the chain. A light client verifies inclusion for itself; a wallet querying a hosted service is showing you that service's answer, which is also why a balance can lag. The block explorer guide covers checking a transaction independently, and the chain pages show typical confirmation times per network.

Related terms

• full node: validating every transaction independently
• merkle tree: the structure inclusion proofs come from
• confirmation: what a proof of inclusion establishes
• sync committee: the proof-of-stake equivalent mechanism
• block height: the position a header occupies
• watch only wallet: tracking balances without spending keys

Questions

Is a light client less secure than a full node?

It has a weaker guarantee. It confirms that a transaction sits in a chain that cost real work to produce, without checking the validity of everything else in that chain.

Does my phone wallet run one?

Some do. Many instead query the provider's servers over an API, which is faster and gives up verification entirely. The wallet's documentation is where this is stated.

Does it reveal my addresses?

Naive designs do, since asking for proofs about specific addresses identifies them. Compact block filters mitigate this by letting the client scan locally.