Difference between revisions of "Simplified Payment Verification"

Latest revision as of 01:01, 14 August 2022

Simplified Payment Verification (SPV) is described in section 8 of the Bitcoin whitepaper. It allows a transaction recipient to prove that the sender has control of the source funds of the payment they are offering without downloading the full Blockchain, by utilising the properties of Merkle proofs. This does not guarantee that the funds have not been previously spent, this assurance is received by submitting the transaction to the Bitcoin miners. However, in such a case the SPV proof acts as strong evidence of fraud backed by legally recognised digital signature technology.

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

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.

As explained in Section 8 of the Bitcoin whitepaper:

" ... [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 branch linking the transaction to the block it's timestamped in ...

And in Section 7:

" ... A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year ..."

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 network for specific transactions relating to them (an extremely difficult 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 confirmed at least 6 times whatever the transaction type, amount or situation.

The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the ledger through the network nodes. An analogy for this is a transaction done using cheque at a much faster speed. The customer hands the the signed cheque (transaction) to the merchant, who then banks or cashes the cheque (settles the transaction on chain). When/if the merchant is satisfied according to the situational 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 decreases exponentially as time goes by). If the transaction is only for a cup of coffee, then the merchant will be exposed to less risk than if the transaction is to buy a car for example, and they would behave differently. If selling a cup of coffee, they can satisfy themselves that the transaction they have received appears to be valid using the SPV process detailed above, and submit the transaction themselves to the network (or even to a trusted miner if using a Merchant API). Given that they will likely receive notification and proof of a fraud attempt within seconds, they will not want to maintain a copy of the entire ledger or even the UTXO set to check against, because the risk they face does not justify the cost. SPV is adequate just as an instant contactless payment without a pin number although arguably the security of SPV is far superior given that discovery of fraud attempts is rapid. Likewise, they will not want to detain their customer while they wait for 6 confirmations - it simply is not necessary - they have received a transaction which appears to be valid, and it has been accepted by the network without a double spend alert. This will probably be enough for them to risk the cost of the coffee.

Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs

A Merkle Tree is a structure used in computer science to validate data - see wikipedia definition for more information.

The Merkle Root in a Bitcoin block is the hash contained in the block header, which is derived from the hashes of all transactions in the block.

A Merkle Path in SPV represents the information which the user needs to calculate the expected value for the Merkle root for a block, from their own transaction hash contained in that block. The Merkle path is used as part of of the Merkle Proof.

A Merkle Proof in SPV proves the existence of a specific transaction in a specific block (without the user needing to examine all the transactions in the Block). It includes the Merkle Root and the Merkle Path.

To create a Merkle proof, a user (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 blocks themselves). I.e. they need their own copy of the block header of each block, that they know to be accurate. Using their own block header chain, together with the transaction (or its hash/id) they want to verify, as well as its Merkle proof (also sometimes referred to as an inclusion proof), a user can verify the transaction was time stamped in a specific block, without examining every transaction in that block.

An article in March 2019 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:

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:

$Transaction_{0}$ - the transaction that contains the UTXO as an output,
The Merkle path of $Transaction_{0}$
The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
$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}$ .

@@ Line 1: / Line 1: @@
-Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify that a transaction is in the [[Block chain]] without downloading the full chain.
+Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a transaction recipient to prove that the sender has control of the source funds of the payment they are offering without downloading the full [[Blockchain]], by utilising the properties of [[Simplified_Payment_Verification #Merkle_Trees.2C_Merkle_Roots.2C_Merkle_Paths_and_Merkle_Proofs|Merkle proofs]]. This does not guarantee that the funds have not been previously spent, this assurance is received by submitting the transaction to the Bitcoin miners. However, in such a case the SPV proof acts as strong evidence of fraud backed by legally recognised digital signature technology.
-To '''create''' a Merkle proof, a user or (or their wallet) simply needs the '''[[Block_hashing_algorithm#Block_Header|block header]]''' for a given block (80 bytes) and the '''Merkle path''' within that block of the transaction they need to validate. Together, these two items will be sufficient to prove that a given transaction exists in the chain at a given block height.
+SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.
-To '''validate''' a proof, a user (or their wallet) only needs the 80 byte header for the block where the transaction appeared.  They don't need all of the transactions within block (which could be very large).  By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.
 ===Advantages===
 The advantages of using SPV are clear in terms of the volume of data required:
-* a wallet only needs around '''50MB to store the block headers for the entire block chain''' (as at January 2020, with 80 bytes per block and around 620,000 blocks in the chain).  This '''grows linearly''' with each block mined (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block, so we can expect it to grow at around 4MB per year.)
+* 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
+* 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 <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.
+* The size of the data required for the '''[[merkle path]]s''' is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.
+As explained in Section 8 of the [[Bitcoin whitepaper]]:
+{{quote|1=''" ... [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 branch linking the transaction to the block it's timestamped in ... }}
+And in Section 7:
+{{quote|1=''" ... A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year ..."''}}
 ===Approach===
-An article in March entitled [https://craigwright.net/blog/bitcoin-blockchain-tech/merkle-trees-and-spv Merkle Trees and SPV] (Craig Wright, 2019) clarified some previous misunderstandings around SPV and transaction verification.  Previously, the custom had been for the person receiving a payment to poll the block chain repeatedly, to confirm that their transaction had reached a certain depth.  Dr Wright stated that this was unnecessary and said as follows:
+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 network for specific transactions relating to them (an extremely difficult 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 [[confirmation|confirmed]] at least 6 times whatever the transaction type, amount or situation.
+The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the ledger through the network nodes. An analogy for this is a transaction done using cheque at a much faster speed. The customer hands the the signed cheque (transaction) to the merchant, who then banks or cashes the cheque (settles the transaction on chain).  When/if the merchant is satisfied according to the situational 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 decreases exponentially as time goes by). If the transaction is only for a cup of coffee, then the merchant will be exposed to less risk than if the transaction is to buy a car for example, and they would behave differently.  If selling a cup of coffee, they can satisfy themselves that the transaction they have received appears to be valid using the SPV process detailed above, and submit the transaction themselves to the network (or even to a trusted miner if using a [[Merchant API]]). Given that they will likely receive notification and proof of a fraud attempt within seconds, they will not want to maintain a copy of the entire ledger or even the [[UTXO]] set to check against, because the risk they face does not justify the cost.  SPV is adequate just as an instant contactless payment without a pin number although arguably the security of SPV is far superior given that discovery of fraud attempts is rapid.  Likewise, they will not want to detain their customer while they wait for 6 confirmations - it simply is not necessary - they have received a transaction which appears to be valid, and it has been accepted by the network without a double spend alert.  This will probably be enough for them to risk the cost of the coffee.
+===Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs===
+A '''Merkle Tree''' is a structure used in computer science to validate data - see [https://en.wikipedia.org/wiki/Merkle_tree wikipedia definition] for more information.
-{{quote|
+The '''Merkle Root''' in a Bitcoin block is the hash contained in the [[Block_hashing_algorithm#Block_Header|block header]], which is derived from the hashes of all transactions in the block.
-In contrast, the present invention requires that the necessary SPV check be performed on a transaction’s inputs '''prior to its broadcast''' [emphasis added].  The shift in emphasis greatly reduces the burden and traffic on the network in dealing with invalid transactions.
-A second important paradigm in the existing [i.e. the prior] SPV system is that an SPV client must '''query full nodes''' [emphasis added] on the network to obtain the Merkle path required for the SPV check ...  SPV checks that '''remove such burden on the network''' [emphasis added], by stipulating the lightweight Bitcoin client where users keep, maintain, or at least have access to their own copies of Merkle paths pertinent to the unspent transaction outputs owned by them, '''allow Bitcoin to scale'''. [emphasis added]
+A '''Merkle Path''' in SPV represents the information which the user needs to calculate the expected value for the Merkle root for a block, from their own transaction hash contained in that block.  The Merkle path is used as part of of the Merkle Proof.
-}}
-The article referenced above included the following diagram which shows how transaction hashes can be related to the Merkle root in a block header:
+A '''Merkle Proof''' in SPV proves the existence of a specific transaction in a specific block (without the user needing to examine all the transactions in the Block).  It includes the Merkle Root and the Merkle Path.
+* To '''create''' a Merkle proof, a user (or their wallet) simply needs the Merkle path of the transaction as well as the [[Block_hashing_algorithm#Block_Header|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 blocks themselves). I.e. they need their own copy of the [[block header]] of each block, that they know to be accurate.  Using their own block header chain, together with the transaction (or its hash/id) they want to verify, as well as its Merkle proof (also sometimes referred to as an inclusion proof), a user can verify the transaction was time stamped in a specific block, without examining every transaction in that block.
+An article in March 2019 entitled [https://craigwright.net/blog/bitcoin-blockchain-tech/merkle-trees-and-spv 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:
 [[File: Merkle_tree2.png|frameless|1000px|alt=Three transactions and the Merkle paths which can be used to relate them to blocks]]
-===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 https://en.wikipedia.org/wiki/Merkle_tree] for more information
 ===SPV Wallet===
-An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct bitcoin transactions and payments.
+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:
@@ Line 39: / Line 51: @@
 # <math>Transaction_1</math> - the transaction that spends the UTXO
 To validate the information, a user computes the Merkle root from the Merkle path of <math>Transaction_0</math>. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that <math>Transaction_0</math> is in the chain.
 === Offline Payment ===
 Note that by storing <math>Transaction_0</math> locally, a user will be able to sign <math>Transaction_1</math> offline, as any signature on <math>Transaction_1</math> requires the scriptPubKey (locking script) part from <math>Transaction_0</math>.

Page Contents

Navigation

Tools