MASTERING-BITCOIN · Unit 11 · Video 4

Lightweight Clients & SPV: Interactive Practice

IKey Reference Facts

Concept	Value / Formula	Description
Block header size	$\approx 80$ bytes	Fixed-size summary of a block
Full block size	up to $\approx 1{,}000{,}000$ bytes	Header + all transactions
Merkle proof size	$O(\log_2 n)$ hashes	Inclusion proof for $n$ transactions
SPV verifies	Proof-of-work + inclusion	NOT individual transaction validity
Confirmations	blocks mined on top + 1	Cumulative work protects past txs

IIVisualization 1: Storage Scaling — Full Node vs Lightweight Client

The blockchain grows by one block roughly every 10 minutes. A full node stores every transaction in every block. A lightweight client stores only the 80-byte header.

Use the slider below to choose a blockchain height (number of blocks) and an average block size, and see how the two storage requirements diverge.

⚙ interactive visualization — coming to this page format soon

Reflect: Try moving the height slider all the way up. Notice that even at 900,000 blocks the SPV storage is well under 100 MB — small enough for any phone. The ratio between full and lightweight storage stays in the range of roughly 10,000×, which is exactly why SPV makes mobile Bitcoin possible.

IIIVisualization 2: Merkle Inclusion Proofs Grow Logarithmically

To prove your transaction is inside a block, a peer sends a merkle path: just the sibling hashes from your transaction up to the root. For a block with $n$ transactions, that's only $\lceil \log_2 n \rceil$ hashes.

Adjust the number of transactions in a block and see how the proof size compares to downloading the whole block.

⚙ interactive visualization — coming to this page format soon

Notice: As you double the number of transactions in a block (move k up by 1), the full block size doubles too, but the merkle proof only grows by one hash (32 bytes). This is the magic of $O(\log n)$ verification — even blocks with millions of transactions would only need ~20 hashes to prove inclusion.

IVVisualization 3: Confirmations as "Proof by Proxy"

SPV doesn't validate transactions in later blocks — it trusts that the work piled on top of your transaction makes reversal economically prohibitive. Each additional confirmation requires an attacker to outpace honest miners over more blocks.

Adjust the number of confirmations and the attacker's share of total hashpower to see how the probability of a successful double-spend collapses.

⚙ interactive visualization — coming to this page format soon

Reflect: With an attacker holding only 10% of hashpower, just 6 confirmations drops the double-spend probability to a tiny fraction of a percent. But push the attacker share above 50% and the probability becomes 1 — any number of confirmations can be reversed. This is why SPV's security ultimately rests on the assumption that honest miners control the majority of hashpower.

VQuiz Questions

Question 1

A Bitcoin block header is roughly 80 bytes, while a full block can be around 1,000,000 bytes (1 MB). Approximately how much smaller is the header compared to the full block?

✅ Correct! 1,000,000 / 80 ≈ 12,500, which is about four orders of magnitude.

❌ Not quite. Divide the full block size by the header size: 1,000,000 ÷ 80.

Show solution

Solution:

$\frac{\text{Full block}}{\text{Header}} = \frac{1{,}000{,}000 \text{ bytes}}{80 \text{ bytes}} = 12{,}500 \approx 10{,}000$

So a header is about four orders of magnitude smaller than a full block. This is the central efficiency win of SPV: by storing only headers, a lightweight client shrinks its storage requirement by roughly 10,000×, which is what makes Bitcoin usable on phones and embedded devices.

Question 2

A block contains $n = 1024$ transactions arranged in a merkle tree. How many hash values must a peer send you to prove that one specific transaction is included in the block?

✅ Correct! log₂(1024) = 10, so only 10 sibling hashes are needed.

❌ Not quite. Merkle proofs scale as log₂(n), not n or n/2.

Show solution

Solution:

A merkle inclusion proof needs one sibling hash at each level of the tree, from the leaf up to the root.

$\text{Proof size} = \lceil \log_2 n \rceil = \log_2(1024) = 10 \text{ hashes}$

That's only about 320 bytes (10 × 32 bytes) to prove inclusion in a block with 1024 transactions — instead of downloading all 1024 transactions. This logarithmic scaling is what makes SPV practical.

Question 3

True or False: An SPV client can prove that a transaction does not exist in the blockchain, in the same way it can prove a transaction does exist.

✅ Correct! SPV proves inclusion but never exclusion — the verification is asymmetric.

❌ Not quite. Think about what a merkle path can and cannot demonstrate.

Show solution

Solution:

The answer is False. SPV verification is asymmetric:

Existence: A merkle path proves a transaction is in a specific block. ✓
Non-existence / uniqueness: There is no compact proof that a transaction is absent from the blockchain, or that no conflicting transaction exists somewhere else.

This is the "23 Church Street" problem from the video: the tourist can confirm one address exists, but cannot rule out duplicates on side streets they never visit. Consequently, SPV cannot detect double-spends on hidden chains or transactions that peers omit from view.

Question 4

An attacker performs a Sybil attack against your SPV wallet, surrounding it with fake peers they control. Which of the following best describes the resulting security situation?

✅ Correct! Sybil attacks exploit SPV's reliance on peers — without an honest connection, the wallet can be fed any chain the attacker chooses.

❌ Not quite. Remember: SPV clients trust peers for headers and proofs, and headers are authenticated by proof-of-work, not signatures.

Show solution

Solution:

The correct answer is the third option.

SPV clients do not validate every transaction themselves — they trust peers to deliver headers and merkle proofs.
Block headers are not signed by miners; their authenticity comes from proof-of-work, which an attacker with modest hashpower could fake on a small scale for a wallet that sees no other chains.
An attacker doesn't need 51% of global hashpower to deceive a partitioned wallet — they only need to outpace honest miners for the wallet they've isolated, which is far cheaper.

The standard defense is to connect to many randomly chosen peers and hope at least one is honest. That's why we say SPV is trust-minimized, not trustless. Running a full node is the only way to eliminate this peer-trust assumption.

Solved: 0 / 4