The BSV Academy’s free introduction to Bitcoin Theory course covers the design of Bitcoin as a system as prescribed by Satoshi Nakamoto. This course is open to anyone who is interested in Bitcoin and is the beginner course in this series. Some technical experience would be helpful to complete the course, however, it is open to anyone regardless of experience.
The course goes through the Bitcoin white paper section by section elaborating on the concepts contained within each. This section focuses on Simplified Payment Verification (SPV) and explains why it is possible to verify payments without running a full network node.
To make it as effortless as possible for you to have access to this educational material, we are publishing the entire course here on our blog. Stay tuned for a section-by-section release, and remember that you are still welcome to enrol in the BSV Academy to gain a certificate of completion to add to your resume.
Simplified Payment Verification (SPV)
It is possible to verify payments without running a full network node. A user 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 branch linking the transaction to the block it's timestamped in.
He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
Learn how SPV helps to scale Bitcoin
Full network nodes
It is possible to verify payments without running a full network node.
- Satoshi Nakamoto, Bitcoin Whitepaper
In the context of this statement, a ‘Full Network Node’ is considered a node which performs all of the tasks outlined in Section 5 of the whitepaper, which are:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a difficult proof-of-work for its block.
- When a node finds a proof-of-work, it broadcasts the block to all nodes.
- Nodes accept the block only if all transactions in it are valid and not already spent.
- Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
It is clear from this that nodes are systems that are specifically designed to certify the records being timestamped on the ledger.
Anything else that connects to the network is a peer of a different type, and those peers can verify transactions that took place on the network without needing a full copy of the ledger or the need to build blocks or vote with hash power. This capability comes about through Simplified Payment Verification, or SPV*.
*Simple Payment Verification (SPV), is a system outlined in the Bitcoin Whitepaper that enables clients like wallets to verify that a transaction has been included in a block and therefore a payment has been made and accepted by the network.
This is possible because the Merkle tree structure stores the transactions in each block. The structure of a Merkle tree means that we only need to know the merkle root/top hash and a small branch of the tree to verify if a transaction is part of the tree, that is, if it’s been included into a Bitcoin block.
This is done by taking the nodes that are in the path that connects the Merkle root with one of the bottom transactions and bundling them together to create a proof.
Running a node requires downloading the entire blockchain, but a Bitcoin user can use SPV proofs and only needs to know the header of each block which includes the Merkle root, in order to verify any transaction in that block, so we only have to store 80 bytes per block, instead of the entire block required for nodes.
Merkle branches
A user 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 branch linking the transaction to the block it's time stamped in. - Satoshi Nakamoto, Bitcoin Whitepaper
In a similar fashion to how nodes can store a pruned selection of transactions in their copy of the blockchain, a user can store only a highly curated section of transactions using much the same technique, except instead of starting with the full copy of the blockchain and selectively removing transactions, the user starts with a copy of the block header list which can be easily verified through proof-of-work, and selectively adds only the transactions which they directly are interested in.
Going back to the analogy of a family tree, this is the ability of someone with the details of an original parent and the middle generations of the family tree can prove that they are linked to the subject. When handling these transactions, they can be a very small number as would be required by a user of a wallet or app, or a larger set comprising millions of transactions, but which is a minority subset of the overall ledger.
Looking at our family tree example, each original parent needs only to keep the path back to the subject’s identity. The family path can be requested from archive systems which keep the full family tree.
Each transaction can be proven to exist within a real block on the block chain through the Merkle Branches which connect the hash of its transaction ID all the way back up to the Merkle Root which is contained within the block header. If the transaction can be proven to exist in a block, it can be shown that a node accepted it as a valid transaction written to the ledger and time stamped with other nodes agreeing by building further on top of the block the transaction was contained in.
Transaction acceptance
Each transaction can be proven to exist within a validated block through the Merkle branches that connect the Merkle tree all the way through to the transaction ID contained within the block header. If the transaction can be proven to exist in the block, then it has been written to the ledger and timestamped as a valid transaction by the network.
Each transaction can be proven to exist within a validated block through the block header that connects the hash of its child branch all the way through to the parent branch contained within the Merkle tree. If the transaction can be proven to exist in the block, then it has been written to the ledger and timestamped as a valid transaction by the network.
Each transaction can be proven to exist within a validated block through the transaction ID that is connected to the Merkle root all the way through to the Merkle tree contained within the block header. If the transaction can be proven to exist in the block, then it has been written to the ledger and timestamped as a valid transaction by the network.
Each transaction can be proven to exist within a validated block through the Merkle branches that connect the hash of the transaction all the way through to the Merkle root contained within the block header. If the transaction can be proven to exist in the block, then it has been written to the ledger and timestamped as a valid transaction by the network.
Verification during attack situations
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. - Satoshi Nakamoto, Bitcoin Whitepaper
If the network is overpowered by an attacker who is extending the longest chain of proof-of-work upon an invalid block (either a block that contains an invalid transaction or which doesn’t comply with some other aspect of the network’s rules) user wallets will be unable to determine that the longest chain is not the longest valid chain of proof-of-work.
In this instance, it would be possible for the attacker to present information about an invalid transaction that would imply that it had been accepted into the longest chain of proof-of-work and built upon by the majority of network CPUs.
Maintaining an attack
While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. - Satoshi Nakamoto, Bitcoin Whitepaper
This strategy and the illusion of the invalid transactions appearing valid can only be maintained for as long as the attacking node can afford to maintain a majority of the network hash. As soon as the honest chain of blocks overtakes the dishonest chain, user systems will reject the invalid chain and jump across to the now longer valid chain, rendering the attacker’s transactions void and destroying the investment in the proof-of-work used to build the chain.
A dishonest attack of this form is enormously costly and must be conducted in a way that is fully visible to the public, making it extremely risky for the operators of dishonest nodes to participate in such attacks on the network’s validity. This high economic cost of attacking the network is part of the security model of Bitcoin and serves to strengthen the system against dishonest players.
Invalid block relay system
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alert transactions to confirm the inconsistency. - Satoshi Nakamoto, Bitcoin Whitepaper
This proposed solution would be to set up a system to alert user wallets who requested the longest chain of proof-of-work from the network that the longest chain they could download was in-fact a rejected dishonest attack chain. This gives them details of the earliest block in the invalid chain, details of the detected invalid transactions, and the details of the longest valid chain including the valid versions of any double spends inserted into the malicious chain.
This is a theoretical system to protect against a very theoretical but possible attack. User wallets using SPV to track valid transactions within a known set of keys can be tricked into following an invalid chain of proof-of-work, even for a short period of time.
Businesses running nodes
Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification. - Satoshi Nakamoto, Bitcoin Whitepaper
A business that is making or receiving very large numbers of transactions may elect to operate their own node, participating in the process of receiving and validating all transactions on the network and vying for user hash power to be allocated to their node in order to win blocks.
This would allow a business to follow the longest valid chain very closely and to have full visibility of any attempted attack on the network, and any double spending that might be directed at them or any other businesses for whom they monitor accounts.
This opens up new business opportunities for major online payment processors to operate network systems and to enhance their own operational security at the same time.
