What SPV Proofs Let Bitcoin Wallets Verify

On May 24, 2017, BIP 157 specified a client-side filter system that lets an SPV wallet find candidate Bitcoin transactions, while Merkle proofs let it verify their inclusion in the most-work header chain. The mechanism changed who performs the search: instead of revealing a wallet-shaped query to a server, the wallet can inspect standard filters locally and request relevant blocks. That improves discovery and privacy, but it does not turn a light wallet into a full validator.

What does an SPV proof actually prove?

An SPV proof proves that a specified transaction was committed to by the Merkle root in a particular block header. The wallet hashes the transaction through the supplied Merkle branch, compares the result with the header’s root, verifies the header’s proof of work and follows the header chain with the most accumulated work.

• The transaction appears in the claimed block.
• The block header satisfies its stated proof-of-work target.
• The header links to the wallet’s view of the chain.
• Later headers show the transaction’s confirmation depth.

The proof is compact because the branch contains only the sibling hashes needed to reconstruct the root, not every transaction in the block. Bitcoin’s original paper describes 80-byte headers and explicitly says the simplified client cannot check the transaction’s acceptance for itself as a full node can.

What can an SPV wallet not verify?

It cannot prove that every transaction in the block obeys Bitcoin’s consensus rules, that no relevant transaction was withheld, or that an unseen transaction does not exist. A valid inclusion proof says “this transaction is here”; it is not a proof of completeness. Nor does confirmation establish the current mempool state, the best fee for the next block or irreversible settlement. A wallet isolated by hostile peers may also receive a misleading view until it reaches an honest peer with the stronger chain.

The risk allocation is therefore clear. Miners supply hash power, bear equipment and electricity risk, and collect block subsidies and transaction fees. Full-node operators validate blocks and supply peer data without receiving a protocol-level serving fee. The light-wallet user saves storage and computation but accepts residual peer-selection and incomplete-validation risk.

How did compact block filters improve SPV?

Compact block filters moved matching from the serving node to the wallet. Under BIP 37, a wallet sent a probabilistic Bloom filter to a peer, which matched transactions and returned partial Merkle data; this could expose wallet interests, consume server resources and permit omission. Under BIP 157, nodes construct the same deterministic filter for each block, clients test it privately, and matching blocks can be fetched from different peers. Filter headers help expose inconsistent responses, although they do not make filters consensus commitments.

This is verification infrastructure, not a liquidity venue. In a comparison of Fraxswap and Uniswap, liquidity providers take inventory risk and traders pay execution fees; SPV peers instead relay evidence without an embedded fee market. Our assessment is that SPV is materially useful for constrained wallets, but unsuitable as a claim of full validation. What remains implementation-dependent is peer diversity, filter support and how clearly each wallet communicates those limits.