Credit Card Terminal

Why is SPV so misunderstood?

As far as one can tell, no business today uses Simplified Payment Verification (SPV) as described in the Bitcoin white paper today in commerce. Some services and miners on the Bitcoin SV network have implemented SPV to a degree, but due to the lack of Bitcoin adoption in the real-world economy no incentive exists to use it.

Much discussion has been had about section 8 of the white paper, particularly within the BSV space yet there is still clearly a gap between what Satoshi was thinking and what the typical user understands.

What is SPV?

SPV is a technique leveraged to validate that a customer has sufficient funds to transact before the merchant accepts the transaction. The primary scenario would be a customer purchasing an item from a merchant at a physical store where the customer hands the transaction directly to the merchant in true peer-to-peer fashion (without broadcasting to the Bitcoin network).

However, the merchant is not aware if the customer has double spent those funds in the transaction, and if they are offline, the merchant cannot normally validate if those coins (UTXOs) have been spent. Satoshi envisioned that the merchant could have all the block headers downloaded on their Point of Sale (POS) locally, which would be a tiny amount of data (megabytes) compared to storing the entire blockchain (Terabytes as of writing).

Simplified Payment Verification illustration
Source: BitcoinSV.com

Since the customer hands the merchant the full raw transaction, the merchant can extract the transaction IDs of the coins, and quickly execute an SPV check locally against the block headers to ensure those transactions are valid.

However, here exists the gripe critics have about SPV; this check only validates those transactions were valid in a block at some point in the past, but no guarantee that these coins have not been spent since that block height, or since the last block (unconfirmed).

I recall the heated debates years ago about the safety of zero-confirmation transactions. Unsurprisingly, the entire space’s misunderstanding about that concept directly relates to SPV. The first argument is that most customers do not steal just as most customers did not bounce checks (when those were a thing). For the technocrats, this is considered a weak argument because we know some customers did bounce checks and will steal.

Given the allusion to real-world commerce, let us examine the riskiest of monetary transactions, purchasing a home. Buyers (cash or mortgage) must undergo varying levels of scrutiny, whether they must demonstrate proof of funds or proof of income respectively.

The top financial institutions require formal proof of funds letters or previous pay stubs of the buyer as industry standard. Yet, these are snapshots of account balances or proof of payments in the past. The sellers and attorneys involved in the closing of a home have no idea if these funds (sometimes submitted weeks before actual closing) are since spent, or income is still valid. The buyer could have withdrawn all their cash from an ATM or lost their job on their way to the actual closing meeting, and no one would know. Yet, mortgages are not double spent.

Why? Incentives. No sane person will undergo the scrutiny of providing so much personal information and wait days or weeks just to not buy the home at the last minute.

Banks and underwriters essentially perform an SPV check against the buyers to protect themselves and the seller against fraud. Satoshi implemented a similar technique with Bitcoin, but many still “don’t get it” because of the “Code is Law” fallacy.

Watch: BSV Global Blockchain Convention presentation, LiteClient: Scaling Blockchain with Simplified Payment Verification

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]