Posted: 25 August 2020
Author: Zhang Wei / Wei Zhang
Source: https: //medium.com/nchain/simplified-payment-verification-48ac60f1b26c
The concept of Simple Payment Verification (SPV) can be traced back to the Bitcoin white paper published in 2008. It verifies whether a transaction is recorded in a block in a scalable and efficient way. However, there are some subtle but important aspects of SPV that are often overlooked. This article will explore the role of SPV in instant payments, data ownership, and legal compliance.
Proof of Publication in a block
Chapter 8 of the Bitcoin white paper introduces that SPV is a verification process for whether a certain payment has been accepted by the Bitcoin network. Assuming that the verifier has access to the block header list, as well as the data of a bitcoin transaction and the Merkle Proof of the transaction, and the Merkle root is deduced from this Merkle Proof to appear in a certain block header, then this can prove the transaction It has indeed been included in the block corresponding to the block header. This verification is considered "simple" because only three pieces of information are required for the entire process:
- Block header list (as of now, this list is only 52MB);
- The complete data of a transaction (for a simple transaction (footnote 1) that is paid to the public key hash P2PKH, this data is less than 400 bytes);
- A Merkle Proof (even if a block includes 1 billion transactions, this Merkle Proof is only 928 bytes)
Imagine a merchant Bob who maintains and updates a block header list in real time. When he receives a payment transaction from his customer Alice, he can immediately verify whether the transaction has been recorded in a certain block after obtaining the Merkle Proof of the transaction. If the BIP-270 process is implemented, Bob himself (or the recipient) should be responsible for sending the payment transaction to the Bitcoin network and obtaining the Merkle Proof. In the case of an SPV client, this process is very effective, because the merchant itself has the above three kinds of information required for simple payment verification.
For Bob, the cost of running this system is much lower than the cost of maintaining a complete blockchain. This SPV verification mechanism has natural lightweight characteristics in terms of storage and bandwidth requirements, so it is not difficult to see that it can be easily expanded.
Instant Payments
This may be against common sense, but SPV can indeed be used in payment scenarios that take effect immediately. In this case, [1] Customer Alice needs to provide two transactions and a Merkle Proof to the merchant Bob: one is the transaction for this payment; the other is the transaction output spent by the payment transaction, and the transaction where the output is located Will be referred to as "pre-order transaction"; here Merkle Proof is "pre-order transaction". (Note: The number of "pre-order transactions" here should actually depend on how many different transactions all the inputs of this payment transaction come from, but for simplicity in this example, we assume that the input value of Alice's payment this time comes from one Pre-order transaction.)
Please note that there is no Merkle Proof in Alice's payment transaction at this time.
One of the motivations for the Simple Payment Verification (SPV) of the previous transaction is to add a fast failure mechanism, that is, Bob can quickly detect invalid payment transactions before sending the transaction to the Bitcoin node. This is because if the previous transaction proves to actually exist on the global ledger, then this confirms that Alice did have the funds needed for the payment at some point in the past.
In fact, simple payment verification has a more fundamental motivation-to verify the integrity of the transaction: to ensure that the data of the previous transaction provided by the customer has not been tampered with. Before explaining this in detail, we want to make a reasonable assumption: digital signatures are legally binding. Please note that this has been the case in the UK since 2000.
Digital signature validity
Suppose Alice wants to buy a game console from Bob, and she sends a payment transaction to Bob.
Picture: This payment transaction
When viewing this payment transaction, Bob can determine that it spent an output of the previous transaction (TX_previous) and assign x to him according to his payment requirements. In order to determine the validity of this transaction, he can send this transaction to the Bitcoin node to wait for feedback, but it will take a while. In order to better serve customers, Bob noticed that there is a digital signature (Sig_A, PK_A) in this payment transaction. If he can verify that the digital signature is valid and make sure it comes from Alice, he can complete the transaction happily Sale. Because of Alice's digital signature, Alice will bear legal responsibility for her actions. By analogy, we can think of people who need to sign to confirm the payment when paying with a credit card. The way to verify the signature at this time is to check whether the payer’s signature is the same as the signature on the back of the card. When buying a high-value product, you may also need to use a photo ID to assist in verification.
An implicit assumption here is that Bob can associate Alice's identity with the public key. This assumption may not be true under certain circumstances, such as when the transaction value is quite low. However, considering the benefits of effective instant payment and the needs of auditing and taxation, we can make this assumption reasonable and reasonable by means of integrity plans, certified public keys (footnote 2) or any other incentive system or mandatory requirements of laws and regulations. Realization. Perhaps soon there will be regulations that require the payer to provide verifiable identification when the purchase amount exceeds a certain amount.
Generally speaking, three [2] messages are required to verify a digital signature:
- digital signature
- Public key
- Signed message
We can see that Bob already has the first two pieces of information, but the required message not only depends on the payment transaction, but also involves the previous transaction TX_previous.
Picture: Pre-order transaction TX_previous
This signed message contains the first output of the previous transaction, namely the output value (Value) and the locking script (Locking script), which are referenced in the input of the payment transaction. Some people would say that Alice can additionally provide only w and OP_DUP OP_HASH160 <H(PK_A)> OP_EQUALVERIFY OP_CHECKSIG to verify the digital signature for Bob, but Alice cannot prove the integrity of the data extracted from the previous transaction (it has not been tampered with) unless she Can provide a complete pre-order transaction and Merkle Proof of this transaction. Merkle Proof as a proof of transaction integrity can tell Bob the following two points:
- The locked script is indeed a digital signature for a specific public key (such as a P2PKH script);
- The locking script has not been modified.
The importance of confirming the integrity of previous transactions is often underestimated. A lock script such as OP_DROP OP_DROP OP_TRUE in the pre-order transaction will allow Alice to place any pair of strings that look like a signature and a public key in the unlock script. If Bob only has the information of this payment transaction, he cannot judge the validity of the signature and the legality of the public key. In addition, because he doesn't know what the locking script in the previous transaction is, this means that Bob cannot be sure that the Bitcoin node will verify this signature. There is no OP_CHECKSIG in the lock script of the above example, so there will be no step to verify the signature when the script is executed.
Please note that many data applications (such as Metanet applications) rely on the validity of the signature and public key in the transaction unlock script to indicate data ownership or access rights. The validity of the transaction does not mean the validity of the signature, unless a pre-order transaction is provided, and its locking script indicates that a signature with a specific public key is required (footnote 3). If Bob only requires the lock script and output value, then Alice may generate any new pair of private and public keys, and create a pseudo P2PKH lock script corresponding to the public key to hide his identity or impersonate others. Next, she can sign the message so that when Bob verifies the payment transaction and the forged lock script, the resulting signature will be valid. Therefore, it is very important for Bob to perform simple payment verification on the previous transaction to check the integrity of the transaction before signature verification.
By successfully verifying the digital signature of the public key related to Alice's identity in the message, Bob is sure that Alice does have the legal control of (amount) w Bitcoin, and she approves the transfer of x Bitcoin to herself through the digital signature. In this case, Bob is willing to complete the transaction because he knows that if Alice makes a double spend, she will bear the legal responsibility. This is how SPV can effectively achieve instant payment.
to sum up
When the digital signature and public key in the unlocking script need to be specially used in certain scenarios, the integrity of the previous transaction, or more accurately, the integrity of the locking script in the previous transaction, becomes extremely important. The integrity proof ensures that the digital signature and specific public key in the unlocking script will be effectively verified in the Bitcoin network. As mentioned above, this proof of integrity can be achieved by simple payment verification of the previous transaction.
In the above example, the signature and public key (associated with Alice's identity) are regarded as proof that Alice agrees to pay Bob for the purchase of goods in Bitcoin, so Bob needs to ensure that the signature is valid and that it is indeed from Alice. This concept also applies to data ownership or data certification in transactions, such as Metanet applications or notarizing a document in the OP_RETURN payload through a transaction.
Finally, we want to emphasize that SPV can be used not only to prove the existence of a published transaction, but also to prove the integrity of the transaction, and the integrity of the transaction means the integrity of any data in the transaction.
Footnotes:
[1] If only the transaction ID is provided to verify its existence, then the verifier needs to know the depth of the Merkle tree or the original transaction from which the transaction ID is derived to confirm the existence of this transaction. This is to ensure that the transaction ID is indeed a leaf on the Merkle tree, not an internal node. Any information may require the verifier to store or access some additional information.
[2] In order to avoid reusing the authenticated identity key, Alice can derive a key pair from her identity key after Bob verifies her identity: for example, by using the BIP32 unhardened key path, or The derivation is based on the Diffie-Hellman key exchange between Alice and Bob. This is to ensure that Bob can verify the correspondence between the public key used in the payment and the authenticated public key of the identity.
[3] We thank Tao Xiaojie, CTO of Volt, who independently discovered the importance of pre-order transactions in verifying Metanet transactions (reference article: https://www.yuque.com/docs/share/0b224413-7987- 4ebf-b0e3-6b268ae18f27) and prompted us to write this article.
Bitcoin SV is the only blockchain that follows the protocol in the white paper "Bitcoin: Peer-to-Peer Electronic Cash System" published by Satoshi Nakamoto in 2008.