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.