The Bitcoin whitepaper explained and commented: part 8 — Simplified Payment Verification
This is the 8th part of my series explaining Satoshi Nakamoto’s 2008 Bitcoin whitepaper. As previously, quotes and diagrams are from the whitepaper.
Blockchain takes space
Storing Bitcoin’s blockchain in full takes up hundreds of gigabytes. As we learned in the previous section, storing the full blockchain is not always necessary, but running a node (= running Bitcoin’s software) also means verifying the validity of every transaction that’s added in a new block and that can be a task too intense for a mobile device.
Satoshi was aware of this and therefore proposed in the whitepaper a scheme to implement secure payments that would work even on a tablet or a mobile phone.
Storing headers only
This method, called Simplified Payment Verification or SPV, only requires downloading the block headers (that is the metadata at the beginning of each block) but not the transactions themselves. By doing so, SPV can run with less than 100 MB of header data, instead of the current 324 GB of blockchain data (as of March 2022.)
Let’s see how that works:
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
Let’s say you only have access to the block headers of the blockchain and you want to verify that a transaction (a payment) is valid. How can you do it?
Merkle tree = efficient storage and verification
Remember from the previous section that transactions inside a block are organized into a very efficient data structure called a Merkle tree. Think of it as a pyramid with the hashes (IDs) of the transactions as the bottom, and…