Home › Glossary › SPV (Simplified Payment Verification)

SPV (Simplified Payment Verification)

Also called: SPV, Simplified Payment Verification, SPV wallet, light client, lightweight wallet.

SPV (Simplified Payment Verification) is how light wallets check payments using only block headers and Merkle proofs, without downloading full blocks.

SPV, or Simplified Payment Verification, is a way to check that a transaction is in the blockchain without downloading and validating every block. It is described in section 8 of the Bitcoin whitepaper. An SPV client, or light client, keeps only the chain of block headers (80 bytes each) and checks their proof of work.

How SPV works

  1. Download all block headers and follow the chain with the most work.
  2. For a transaction of interest, get a Merkle proof: the hashes linking its txid to the Merkle tree root in a block header.
  3. Count confirmations by how many headers have been built on top.

A proof is small, about log2(n) hashes for a block of n transactions, so even a phone can verify payments cheaply.

Finding relevant transactions

The client also has to learn which transactions are its own. BIP 37 Bloom filters asked full nodes to filter for it, at a cost to privacy. BIP 157 and BIP 158 compact block filters let the client do the matching itself.

SPV's security assumption

An SPV client doesn't check the consensus rules; it assumes the chain with the most work is valid. That holds while most hash power is honest, but the client can't detect, say, a block that creates too many coins. BIP 141 discusses fraud proofs as a possible improvement, BIP 180 proposed one for oversized blocks, and BIP 54 proposes banning 64-byte transactions, which can be used to forge an SPV inclusion proof. Running a full node remains the way to verify everything yourself.

BIPs that define SPV (Simplified Payment Verification)

  • BIP 37: Connection Bloom filtering: Deployed. Lets lightweight wallets hand a full node a Bloom filter (a compact, approximate summary of what they care about) so they receive only relevant transactions. This made phone wallets practical,…
  • BIP 157: Client Side Block Filtering: Deployed. Defines a protocol for lightweight wallets in which full nodes publish compact summaries (filters) of each block, and wallets download them to check locally which blocks matter. Unlike the older…
  • BIP 158: Compact Block Filters for Light Clients: Deployed. Specifies how to build the compact block filters used by the BIP 157 light-client protocol, a compressed summary of the addresses and data touched in each block. Wallets use these filters to decide…
  • BIP 141 (SegWit): Segregated Witness (Consensus layer): Deployed. Defines Segregated Witness (SegWit), which moves signatures into a separate "witness" section of each transaction while remaining compatible with older nodes. This fixed transaction malleability,…
  • BIP 180: Block size/weight fraud proof: Closed. Describes a compact "fraud proof" that lets lightweight wallets learn that a block breaks Bitcoin's size or weight limit without downloading the whole block. This would help light clients avoid…
  • BIP 54: Consensus Cleanup: Complete. Bundles fixes for several long-standing protocol weaknesses: the timewarp attack (manipulating block timestamps to speed up coin issuance), blocks that take extremely long to validate, Merkle tree…

Related terms

  • Merkle tree: A Merkle tree hashes many items into one 32-byte root, so any single item can be proven to be included with a short proof instead of the whole list.
  • Bloom filter: A Bloom filter is a compact probabilistic set; BIP 37 used one so light wallets could ask full nodes for only the transactions matching their addresses.
  • Compact block filters: Compact block filters (BIP 157 and 158) are small per-block summaries that let light wallets find their transactions without revealing their addresses.
  • Node: A Bitcoin node is a computer running Bitcoin software that downloads, checks and relays blocks and transactions; a full node verifies every rule itself.