Simplified Payment Verification

Simplified Payment Verification (SPV) is described in section 8 of the Bitcoin whitepaper. It allows a user to prove or verify a payment to them without downloading the full Block chain, by utilising the properties of Merkle proofs. An SPV client "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 branchlinking the transaction to the block it's timestamped in." (link to bitcoin whitepaper) This block header chain is many orders of mangitude smaller than the entire blockchain (with all transactions in it) since it only grows by a fixed amount over time regardless of how big the blockchain grows. "A block header with no transactions would be about 80 bytes. If we suppose blocks aregenerated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year." (link to bitcoin whitepaper)

Advantages

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

• a wallet can store all necessary block headers in around 50MB - this covers the entire block chain (as of January 2020, with 80 bytes per block and around 620,000 blocks in the chain). The total grows linearly at around 4MB per year (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block).

• 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.

SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.

Approach

There have been a lot of previous misunderstandings around SPV and peer-to-peer transacting. Previously, the custom had been for the sender of the payment to just broadcast the payment to the bitcoin network nodes. The receiver of the payment would then need to somehow filter through all of the transactions coming onto the blockchain for specific tranasactions relating to them (an extremely diffficult task in of itself). Even if the sender sent the transaction to the receiver as well as the network nodes, the custom had been for the receiver to always wait for the transaction to be burried into the blockchain at least 6 blocks deep whatever the transaction type or amount or situation.

Transactions between SPV clients are negotiated peer-to-peer and settled on the blockchain through the network nodes. An analogy for this is a transaction done using checks at a much faster speed. The customer hands the the signed check (transaction) to the merchant who then cashes the check (settles the transaction). When/if the merchant is satisfied according to the situtational risk of the transaction, then they can hand over the goods or services. There is no such thing as absolute security, there is always a risk against the cost of being defrauded (which increases exponentially as time goes by). If the transaction is only for a cup of coffee, then the merchant might incur more risk than if the transaction was for a car for example.

An article in March entitled Merkle Trees and SPV (Craig Wright, 2019) clarified some previous misunderstandings around SPV and transaction verification. The article 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.

To create a Merkle proof which proves the existence of a specific transaction in a specific block, a user or (or their wallet) simply needs the Merkle path of the transaction as well as the block header for a given block (80 bytes).

To validate a proof, a user (or their wallet) only needs the chain of block headers (as opposed to the whole blockchain). Using the block header chain, the transaction (or its hash/id), as well as its Merkle proof (also sometimes referred to as an inclusion proof), one does not need any additional information to prove that the specific transaction existed in the specific block.

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}$.