Simplified Payment Verification (SPV)

Simplified Payment Verification (SPV) is the technique, described in Section 8 of Satoshi Nakamoto's Bitcoin whitepaper, that lets a lightweight wallet confirm a payment without downloading the entire blockchain. Instead of validating every transaction, an SPV client keeps only the chain of 80-byte block headers and asks peers for a short proof that a given transaction is included in a block. It is the original answer to a question that still shapes wallet design: how much can you verify with almost no resources?

How the Merkle proof works

Each block header commits to all of its transactions through a single Merkle root. To prove a transaction is in a block, a node supplies the transaction plus the handful of intermediate hashes — the Merkle proof — needed to recompute that root. The SPV client hashes its way up the path; if the result matches the root in a header buried under sufficient proof-of-work, the transaction is confirmed as included. The proof grows only logarithmically with block size, so a block of thousands of transactions needs roughly a dozen 32-byte hashes to prove membership. The whole scheme requires kilobytes per proof and a header chain measured in tens of megabytes, against hundreds of gigabytes for the full chain.

Trade-offs and the privacy problem

SPV trades full verification for efficiency. A light client confirms inclusion and the work behind a chain, but it does not independently check that every transaction obeys consensus rules — it trusts that miners and the honest network did. Under a majority-hashrate attack an SPV client could in principle be shown a valid-looking proof from an invalid chain, which a full node would reject outright. There is also a privacy cost the whitepaper never addressed: to learn about its transactions, a classic SPV wallet must tell somebody what to watch. Bloom-filter-based scanning (BIP-37) leaked wallet contents badly enough that the modern replacement, compact block filters (BIP-158), inverts the model — the node publishes a per-block filter and the client downloads whole blocks that might be relevant, revealing nothing about which transactions it cares about.

Where SPV fits a sovereign stack

SPV underpins most mobile wallet designs, many hardware wallet companion apps, and the inclusion-proof logic inside second-layer and bridge protocols such as BitVM. The honest hierarchy is straightforward: a full node verifies everything and is the sovereign baseline; a pruned node verifies everything while storing little; SPV verifies inclusion-plus-work and trusts the rest. For meaningful sums, run your own node and point your wallets at it. For the phone in your pocket, SPV with BIP-158 filters is a respectable compromise — engineered trust-minimization rather than blind trust. D-Central's advice mirrors its repair-bench ethos: know exactly which checks your setup performs and which it delegates, and never confuse the two.

One more nuance rewards attention: SPV security is probabilistic and grows with confirmations. A proof under one block of work is cheap for an attacker to fake privately; a proof buried under six blocks requires out-mining the honest network for an hour, and the cost climbs from there. That is why light wallets wait for confirmations scaled to the amount at stake, and why the whitepaper itself framed SPV as adequate "as long as honest nodes control the network." The design has aged remarkably well for a few paragraphs written in 2008 — most of what changed since is not the proof mechanism but the privacy engineering around asking for proofs, which BIP-158 finally put on sound footing. Satoshi even anticipated the residual weakness, suggesting businesses accepting frequent payments should "probably still want to run their own nodes" — advice that has not aged a day.