Simplified Payment Verification

Satoshi Nakamoto described the method in section 8 of the 2008 whitepaper, as the way to use bitcoin without running a server. It is cheap because a block header is 80 bytes: at around 960,000 blocks the whole header chain is roughly 77 MB, against 759 GB for the blocks themselves in August 2026. It buys you proof that miners committed to your payment, and nothing whatsoever about whether that payment was legal.

How it works

Simplified payment verification answers one question with two pieces of evidence.

The first is the header chain. Every block header is exactly 80 bytes and contains the hash of the previous header, the merkle root of the transactions inside, a timestamp, and the difficulty target the miner had to beat. A client downloads headers only, checks that each links to the one before it and that each hash actually falls below its stated target, and ends up with a chain it can price in electricity. Faking it is not a matter of lying convincingly; it means redoing the mining.

The second is the merkle branch. Transactions in a block are hashed together in pairs until one root remains, so proving that a specific transaction is in a block takes only the handful of sibling hashes along the path to that root. The count is logarithmic: a block with 4,096 transactions needs 12 hashes, which is 384 bytes, and doubling the block only adds one more. Your client hashes its way up the branch, compares the result with the merkle root in the header it already trusts, and either the transaction is in that block or it is not.

Put the two together and you have the claim simplified payment verification makes: this transaction was committed to by a block, and a measurable quantity of work has been piled on top of it since.

Now the gaps, because they are the useful part. Inclusion is not validity. The method cannot tell you that the coins being spent existed, that the signatures were good, that the block awarded the miner the correct subsidy, or that the same coins were not spent in a different branch. It cannot prove a negative either: a server that simply omits a payment leaves no evidence behind. Satoshi wrote the caveat into the whitepaper directly, noting that the technique is reliable while honest nodes control the network and that businesses receiving frequent payments will still want to run their own.

Why this matters when you buy bitcoin

The green checkmark in a phone wallet is usually not verification at all.

Most wallets people install after their first exchange purchase never build a header chain. They ask a company's server how much you have, print the answer, and label it confirmed. That is a weaker guarantee than the whitepaper's method, and the whitepaper's method is itself weaker than a node. For small everyday balances that chain of trust is fine, and pretending otherwise helps nobody. It stops being fine at the point where the amount would hurt.

The practical question is who you are trusting and for how long. Our exchange reviews list what each platform requires before releasing a withdrawal, and every one of those confirmation counts is a report from that exchange's own node. When the coins arrive, the wallet showing them to you is reporting from somebody else's node again. Neither party is likely to be lying. Both of them can be wrong, offline, or serving a chain they were fed, and neither will tell you when that happens.

There is a privacy dimension too. The 2014 study of bloom filter clients found that the filters meant to hide which addresses a wallet cared about gave most of them away. That is why Bitcoin Core switched the feature off by default in version 0.19.0 in November 2019, and why newer light wallets download compact filters instead of uploading requests.

What simplified payment verification would have missed in September 2018

CVE-2018-17144 is the cleanest illustration of the difference between inclusion and validity in bitcoin's history.

An optimization added in Bitcoin Core 0.14.0 skipped a check that had been thought redundant, with the result that affected versions would partly process a block containing a transaction that spent the same input twice. Handled one way it crashed the node. Handled another way it let a miner create bitcoin out of nothing. The bug was reported on September 17, 2018, and fixed in Bitcoin Core 0.16.3 the following day. Nobody exploited it on the live network.

Imagine somebody had. A miner produces a block that inflates the supply, with a header carrying entirely genuine proof of work and a perfectly correct merkle tree. An updated full node parses the block, finds the duplicate input, rejects it and disconnects the peer that sent it. A client doing simplified payment verification checks the header, checks the branch, and reports the payment inside as confirmed, because every piece of evidence available to it is valid. It has no access to the input being spent, so the question never comes up.

That is the whole trade. Simplified payment verification inherits its rules from whoever is mining. A node does not.

Simplified payment verification vs Neutrino

Simplified payment verification and Neutrino both let a wallet work without the full chain, and they point the filtering in opposite directions. The classic approach under BIP37 sends your interests to a peer: you upload a filter, the peer searches for you, and it learns roughly which addresses you own. Neutrino, the implementation of BIP157 and BIP158 used by most mobile Lightning wallets, has the node publish one compact filter per block for everyone; your wallet downloads filters, tests them privately, and requests only the blocks that matched. The verification you do afterwards is the same merkle and header arithmetic. What changes is that nobody on the other end learns what you were looking for.