Simplified payment verification (SPV) is a way for a wallet to check that a Bitcoin transaction has been included in the blockchain without storing or verifying the whole chain. An SPV client downloads only the chain of block headers, the short summaries at the top of each block, and asks full nodes for a compact proof that a particular transaction sits inside a particular block. If the proof checks out against a header that is buried under enough later blocks, the wallet treats the payment as confirmed.
The method was described by Satoshi Nakamoto in section 8 of the 2008 Bitcoin whitepaper and underpins most mobile and lightweight wallets, which are known as SPV wallets or light clients. It is unrelated to the special purpose vehicle used in corporate finance, which shares the same abbreviation.
Simplified payment verification in plain terms
Imagine checking that a cheque was entered in a huge ledger kept in a library. You could read the entire ledger, which would take weeks. Or you could keep a slim index listing each page's official stamp, then ask the librarian for a photocopy of the single line showing your cheque, together with the chain of stamps that proves that line belongs on that page.
SPV works the same way. The wallet keeps the slim index of stamps, which is the block headers, and checks a short proof for its own transactions, trusting that the ledger as a whole was kept honestly by the many people who do read every page.
How SPV works
- Headers. The wallet downloads every block header of the Bitcoin blockchain. Each header is 80 bytes and contains the hash of the previous header, a timestamp, the difficulty target and a summary of the block's transactions, so the full set for the chain's first 900,000 blocks is only about 72 megabytes.
- Proof of work check. The wallet confirms that the headers link together and that each meets the required proof of work, and follows the chain with the most accumulated work.
- Merkle proof. For a transaction it cares about, the wallet requests a Merkle branch: the handful of hashes needed to connect the transaction to the root of the block's Merkle tree, which is stored in the header.
- Confirmations. The wallet counts how many confirmations the payment has, meaning blocks built on top of the one containing it, treating more as safer.
Because a Merkle branch grows only with the logarithm of the number of transactions in a block, the proof stays small even for large blocks.
Trust and security trade-offs
SPV clients do not check that every transaction follows Bitcoin's rules. They assume that the chain with the most work is valid because honest miners would not build on an invalid block. This brings several limitations:
- Majority assumption. If attackers controlled most mining power, as in a 51% attack, they could feed SPV clients a chain containing invalid transactions that a full node would reject.
- Network isolation. A client connected only to dishonest peers could be shown a false or incomplete view, so wallets connect to several nodes.
- Missing information. A node can hide transactions from a light client, so the client can prove a payment exists but not easily prove one does not.
The whitepaper suggested that full nodes could alert SPV clients to invalid blocks, but such fraud alerts were never widely implemented in Bitcoin.
Privacy and later improvements
Early SPV wallets used Bloom filters, defined in BIP 37 in 2012, to ask full nodes for transactions matching their addresses without listing them directly. Research showed that these filters leaked much more information than intended, letting nodes guess which addresses a wallet owned. Newer designs, specified in BIP 157 and BIP 158, reverse the process: full nodes publish compact filters for each block, and wallets download them and decide locally which blocks to fetch, which improves privacy. Many popular light wallets instead connect to specialised servers, as the Electrum wallet does, which is convenient but places more trust in those servers.
SPV in practice
Most people who hold bitcoin in a mobile wallet or a browser extension use some form of light client, either SPV or a server-based model. For everyday amounts the trade-off is generally considered acceptable. Businesses and individuals handling large sums are often advised to run their own full node, or to connect their wallet to one, to verify payments independently. The same basic idea of verifying inclusion with headers and proofs appears in other networks, in light nodes and in some bridges between blockchains.