Simplified Payment Verification

Date: 2019-10-09

Source: https://craigwright.net/blog/bitcoin-blockchain-tech/simplified-payment-verification

---

In the Bitcoin white paper, I specified how it is possible to verify payments without running a full network node. The distinct specifications and definitions are important: Section 5 of the white paper defines nodes in Bitcoin; more critically, to be a node, you need to be mining transactions. SPV or simplified payment verification is a critical aspect of scaling Bitcoin. I thought it was rather clear and obvious when I released the white paper, but it seems that people have overlooked or misunderstood all of the different aspects. The truth of the matter is, nobody realised how simple SPV could be. It is critical because you cannot scale the blockchain without SPV, and more importantly, SPV is the peer aspect of Bitcoin. Right now, derivative systems that have forked away from Bitcoin, such as BTC, are not peer-to-peer at all.

By definition, ‘peer-to-peer’ refers to the direct exchange between individuals or other parties. As such, a consumer, Alice, who wishes to purchase goods from a merchant, Bob, would send a transaction directly to Bob. Bob can validate it and send it to the blockchain for clearing and settlement. The process is peer-to-peer. The miners or nodes in the network act as a distributed intermediary. No one intermediary needs to be directly trusted, which differs greatly from any of the current systems. Winston Churchill supported the reintroduction of the gold standard, although at a mispriced level, as it stopped the knaves in Parliament from altering values for political concerns. A distributed system enables a method that will stop such knaves seeking to alter the monetary supply yet not turn them into trusted third parties.

Users in the system are only required to maintain a copy of the block header to which they can compare transactions. At present, the block header is under 50 MB in size. Many image files can exceed such levels. A decade from now, the growth will only be linear. So, we have a system that scales by Moore’s law exponentially yet takes a linear amount of resources. There are a few systems that could not keep block headers in memory today.

Network nodes or miners would provide users with the longest proof-of-work chain. A user could implement a Bayesian system to ensure that they had the longest chain. Rather than checking with one miner, they would query multiple random nodes. In doing so, it is possible to ensure very simply and without much bandwidth that they have the longest path.

Verification is reliable in the system as long as the honest nodes control the network. It is important to note that network miners act within the law. A network node involves investment. Today, even small miners invest hundreds of millions of dollars in their systems. More importantly, miners are geographically located and cannot easily move, making them subject to the provisions of law, where a dishonest miner would be liable to losses. Bitcoin was never designed as a system that acts outside of the real world. In fact, the reason that the word honest is mentioned 15 times in the white paper is that it relates directly to acts such as the U.K.’s Fraud Act 2006.

The result is that once Bitcoin achieves any level of scale, it comes under the purview of law. Game theoretically, the game to a miner inclusion and acting as an attacker is minimised by the losses that miners will face. I had written in an early draft of the white paper that transactions would only be vulnerable to reversal. It is so because Bitcoin is not designed to be a system that acts outside of the controls of law. It is a system that supports honest trading and allows the capture and sequestration of transactions that can be shown to be associated with criminal activity.

An attacker that can overpower the network can work with a network node only for as long as they can continue to overpower the network. Which is something that would be quickly noticed. Existing miners would be able to determine ‘double spends’ within seconds. At worst, an attacking miner who built a chain six blocks deep would on average be determined after an hour or so, when all would be rejected outright. The myth that Bitcoin acts outside the law has been propagated by those seeking to create criminal systems, but it is a false and malicious lie and one that is easily discredited. As governments, regulators, and law enforcement start to wake up and see the true design of Bitcoin, they will start to understand that it is a system that is friendly to law. It assists in the tracing of transactions, and provides a high level of privacy for the small cash like transfers whilst also being able to immutably record money laundering and crimes.

A

Customer SPV Wallet

The SPV user should maintain a copy of the

transaction that they have received. Transactions are minimal in size, and do

not take up much room. When a user is paid, they should maintain a copy of the

transaction that has been sent to them, so that they can both validate it

against the Merkle tree of a particular block and simplify the payment to the

next peer.

If we assume that Alice has been paid using

an input transaction in a block of sufficient depth that is associated with Tx3

in the following image, she can now save such information in the block path to

simplify verification when she spends her money.

Extending the scenario, we can see that

Alice can save each of the input transactions for the money she wishes to spend

on her own computer. They are each treated as digital coins. By signing them or

fulfilling the other conditions of the output script, Alice can now transfer

her coins to a new output in order to pay Bob.

Alice sends Bob a copy of both Tx1 and Tx2,

the inputs to Tx3 that she is spending in the transaction below, in order to

pay Bob. By also sending the Merkle path, Bob can very quickly validate the

hash of each transaction and ensure that it follows to the block header and

validates. Bob can trust the input transactions if they exist in the

blockchain. He can, of course, choose to validate the input transactions again

himself. He has just received a copy of both Tx1 and Tx2 from Alice.

In order to validate a transaction and

ensure it exists within the Merkle path and validates to the block header, Bob

simply needs to take the hash of each transaction that acts as an input to his

payment transaction that Alice is giving him. To do so, Bob calculates the hash

of both transactions:

Hash(Tx1);

and

Hash(Tx2).

With both values, and with the Merkle path

Alice has just supplied, Bob can simply and very quickly calculate the full

blockchain header value and ensure that the path in the blockchain header is

correct. If the hash and Merkle tree that he has in the headers he has saved

match, Bob knows with certainty that Alice has given him a valid transaction.

He knows that the existence of the transaction in the blockchain has been

validated by the Bitcoin miners and that there is now proof-of-work defining

the existence of the transaction in the chain.

The SPV system is shown schematically in

the diagram below:

Customer SPV wallet

Note that Alice does not maintain merely her private keys in the system. She will save the Merkle path and the input transactions that she is seeking to use. Alice does not need to maintain access to the blockchain to be able to spend her money. As Alice knows that she is the only party able to spend her coins, she can even act to make a transaction that is valid while she is still not connected to the blockchain in any way. Alice does not need to worry about the validity of any change transaction or output, because Bob cannot alter them. If Bob seeks to alter the transaction so that the change is not incorporated, the entire transaction will be invalid. The result is that Bob either submits the payment he has received from Alice to the blockchain for settlement, with the change to be paid to Alice, or he does not receive payment, in which case Alice does not need to worry about her change at all.

Note the following features of a customer’s SPV wallet:

1. TXs – Pre-loaded full transaction data containing Alice’s available unspent transaction outputs (UTXOs). Full transaction data alongside a Merkle path constitutes a Merkle proof that the transaction Alice is spending is valid. Hashing the full transaction will give the TXID, which is required as part of the input data for the new transaction.

Note that providing

the TXID alone would be insufficient as Bob must be able to verify that the

TXID is indeed the hash of the transaction. Bob can only do so if Alice provides

him with the full transaction data; hence, she must store it.

If Alice does not store such information, Bob will need to check it on the blockchain, which will add delays to the process. Bob, of course, can charge a fee for non-SPV transactions where he must go to a miner and download the complete transaction, and miners can do the same to merchants who require a speedy response to a selected query.

2. Private/Public keys – The wallet must have access to a set of private keys to sign TX outputs and public keys to specify change addresses when conducting transactions.

3. Merkle paths – The Merkle path of each of the transactions containing the TXs. The Merkle paths will be used by the merchant’s point of sale wallet in verifying that the TXs are valid. Note that the Merkle proof provided by the wallet does not prevent a ‘double spend’ but acts as a fail-fast mechanism against spam attacks.

4. Minimal processing – The SPV wallet is required to sign the unspent transactions in order to spend them. Doing so requires the offline wallet to be able to implement ECDSA signatures, or in other words possess enough processing power required to perform elliptic curve point multiplication and compute hash functions.

5. Block headers (optional) – The customer wallet may wish to include block headers to verify that payments to point of sale SPV wallets have been processed. Doing so would also require storing the TXIDs and Merkle paths after interaction with a point of sale wallet.

Maintaining Privacy; Ensuring Scalability

As the merchant, Bob sends the transactions

to the blockchain, and not Alice; she has more privacy than if she sent it

herself. Bob and Alice are already exchanging, and so Bob knows of Alice (he

may need to send her goods). As Bob sends the transactions, and as he is likely

to be a merchant with many transactions, his IP address is made public, not

Alice’s. Alice does not need to attract attention using Tor; she can exchange

knowing that only Bob sees her exchange (here, Bob and Alice can use an

encrypted channel). So, Alice reveals far less and can maintain her privacy in

the world at large.

Chain analysis and recording IP addresses

will not reveal Alice’s exchange. Bob holds a record, but it is not public.

In coming posts, I will start to detail how

such a solution can be achieved and how it helps scale Bitcoin. In fact, Bitcoin

can neither be peer-to-peer nor scale without the implementation of SPV.

Bob can quickly check the validity of any

coin that Alice is using to pay him. He can check whether it’s in the UTXO set as

an unspent transaction, and he can quickly validate the input location in the

blockchain as Alice has handed him the path. The deeper the coin is, the more

the proof of work is that is needed to change the path and hence the more

secure it is for Bob to accept it. If Alice simply spends her pay and receives

coins after being validated for an hour or so, it is still very secure. Bob does

not need to download the entire blockchain. Even if he ran his own node, it

would gain him nothing. Only miners change the blockchain. As Bob has received

Alice’s input coin, he can check that it is valid and that she has correctly

formulated the output coin to Bob, which is all he needs to validate the payment

itself. Next, if Alice hands the Merkle path associated with her coin to Bob,

she can now be assured that Bob can quickly validate it by hashing the input

transaction and checking its location on the hash headers, by validating the

Merkle path she has given him.

Such was always the methodology I envisioned to exchange transactions on Bitcoin and to allow peers to act without third parties. Without it, by implementing a requirement that all systems run as a full network node, the simplicity of the system is lost, and the system is no longer able to scale. By running SPV, users can quickly and simply validate their own transactions, and they can do so by storing a minimal amount of information.

I shall continue detailing the processes

involved with SPV in following posts, and explain how Bitcoin can be scaled not

to a few individuals but to millions of transactions a second.

---

← Back to archive