Simplified Payment Verification

Simplified Payment Verification (SPV) is described in section 8 of the Bitcoin whitepaper. It allows a user to prove or verify that a transaction is in the Block chain without downloading the full chain.

To create a Merkle proof, a user or (or their wallet) simply needs the block header for a given block (80 bytes) and the Merkle path within that block of the transaction they need to validate. Together, these two items will be sufficient to prove that a given transaction exists in the chain at a given block height.

To validate a proof, a user (or their wallet) only needs the 80 byte header for the block where the transaction appeared. They don't need all of the transactions within block (which could be very large). By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.

Advantages

The advantages of using SPV are clear in terms of the volume of data required:

• a wallet only needs around 50MB to store the block headers for the entire block chain (as at January 2020, with 80 bytes per block and around 620,000 blocks in the chain). This grows linearly with each block mined (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block, so we can expect it to grow at around 4MB per year.)

• contrast this with the hundreds of gigabytes which would be required to store the entire chain, if SPV were not being used

• The size of the data required for the merkle paths is of maximum $64log_{2}{n}$ bytes, where $n$ is the total number of transaction in one block.

Approach

An article in March entitled Merkle Trees and SPV (Craig Wright, 2019) clarified some previous misunderstandings around SPV and transaction verification. Previously, the custom had been for the person receiving a payment to poll the block chain repeatedly, to confirm that their transaction had reached a certain depth. Dr Wright stated that this was unnecessary and said as follows:

In contrast, the present invention requires that the necessary SPV check be performed on a transaction’s inputs prior to its broadcast [emphasis added]. The shift in emphasis greatly reduces the burden and traffic on the network in dealing with invalid transactions.

A second important paradigm in the existing [i.e. the prior] SPV system is that an SPV client must query full nodes [emphasis added] on the network to obtain the Merkle path required for the SPV check ... SPV checks that remove such burden on the network [emphasis added], by stipulating the lightweight Bitcoin client where users keep, maintain, or at least have access to their own copies of Merkle paths pertinent to the unspent transaction outputs owned by them, allow Bitcoin to scale. [emphasis added]

The article referenced above included the following diagram which shows how transaction hashes can be related to the Merkle root in a block header:

Merkle Trees and Merkle Paths

A Merkle Tree is a structure used in computer science to validate data - see https://en.wikipedia.org/wiki/Merkle_tree for more information

SPV Wallet

An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct bitcoin transactions and payments.

To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:

1. $Transaction_{0}$ - the transaction that contains the UTXO as an output,
2. The Merkle path of $Transaction_{0}$
3. The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
4. $Transaction_{1}$ - the transaction that spends the UTXO

To validate the information, a user computes the Merkle root from the Merkle path of $Transaction_{0}$. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that $Transaction_{0}$ is in the chain.

Offline Payment

Note that by storing $Transaction_{0}$ locally, a user will be able to sign $Transaction_{1}$ offline, as any signature on $Transaction_{1}$ requires the scriptPubKey (locking script) part from $Transaction_{0}$.