BSV Devcon China: Simplified Payment Verification – Insight and Emphasis on its Overlooked Features

Hello, everyone! It is a great honor to be here in the first Chinese-language Bitcoin SV DevCon My name is Zhang Wei and I am a senior researcher with UK nChain I graduated from Trinity College, Cambridge, where I majored in mathematics I obtained my doctorate from Royal Holloway, University of London, where I majored in cryptography Then I worked with IBM during my postdoctoral research, with a focus on fully homomorphic encryption (FHE) In 2015, I joined Accenture as a programmer and took part in a number of financial trading platform development projects In 2018, I joined nChain’s research team to assist the R&D Director in leading team innovation and disseminating blockchain knowledge, etc The topic of my presentation today is SPV, Simplified Payment Verification Those overlooked key points, including the role that SPV plays in Instant Pay, and the validity of digital signature This presentation mainly targets an audience interested in data applications of payment systems and blockchains All developers are very welcome SPV first appeared in Section 8 of the Bitcoin Whitepaper in 2008 Its full name is Simplified Payment Verification, and SPV is its acronym In my presentation today, I will use the phrase “simplified verification” from time to time instead of “simplified payment verification” because simplified verification can be used in non-payment scenarios Today, my presentation is divided into three parts The first part will mainly review and explain the SPV described in the Whitepaper The second part will chiefly discuss how to achieve Instant Pay by means of SPV The third part will mostly discuss the close relationship between simplified verification and the validity of digital signature Since there is a lot to talk about, let’s get started now The existence of simplified verification is enabled by three pieces of information The first one is the block headers list The second one is the transaction data The last one is the Merkle proof of such transaction data I will explain them in detail one after another The first one, the block headers list First, let’s find out what a block header is A block header is comprised of 6 parts: version, previous block hash, Merkle root, timestamp, difficulty target and nonce We’re not going to explain the definition of each part here, but we’re more concerned about its size Version is 4-byte long Previous block hash is 32-byte long Merkle root is actually a hash value as well, therefore also 32-byte long Timestamp is 4-byte long Difficulty target is 4-byte long, and nonce is 4-byte long, Hence a total length of 80 bytes The size of a block header is invariable, which is very important And we will talk about it again later The block headers list can be regarded as a hash chain, a block header’s hash chain The “previous block hash” of this block header is a hash value for all the information on the previous block header Similarly, the “previous block hash” of the ensuing block header is a hash value for all the information on the current block header Therefore, it is important that we have a block headers list in due order The order is important I’d like to mentioned that Merkle root in a block header Merkle root can be regarded as a fingerprint for all the transactions in a block Merkle tree is constructed like a reversed tree The bottom layer, called leaves, is made up of the ID of each transaction in the said block We can obtain the Merkle root at the very top through layer upon layer of hash This will be used in SPV at all times I also want to mention that it is very difficult to imitate a block header The block header has its own Proof of Work (PoWs) If we want to create a valid block header, there must be a lot of Proof of Work behind it, or PoWs endued with corresponding “difficulty targets” That’s why we believe in all the data in a block header Let’s take a look at next part

Transaction data, the second part of data required for simplified verification First, let’s find out what transaction data is TxID is a hash value of transaction data Here are the Locktime, the Outpoint, and the Unlocking script, which is also known as input script, the Sequence number, and the Locking script, which is also known as output script If you know better names in Chinese to match these names, please let me know Next, we will discuss the third part of data required for SPV, that is Merkle Proof Let’s assume we are interested in this transaction This green dot represents the TxID of this transaction Our aim is to calculate the Merkle root Therefore, we need to know the hash value next to the TxID Once we know the value, we can link them together, and calculate the hash value for the upper layer Likewise, we need to know the hash value of the counterpart on the left hand side, so as to calculate the hash value for the upper layer Lastly, when we know the hash value of the counterpart on the right, we can then calculate the hash value of Merkle root at the very top After we have calculated the Merkle root, we need to compare it with the Merkle root in the block diagram, to see whether they are equal If they are equal, we can say that this transaction is already recorded on the blockchain So what is Merkle Proof exactly? Let’s take a look The transaction’s Merkle Proof is made up of 4 parts The first part is the TxID of the transaction The second part is the hash value of its counterpart in the transaction The third part is the hash value of its counterpart on the upper layer The fourth part is the hash value of its counterpart on the further upper layer A transaction’s Merkle Proof can be seen as the minimum information required to calculate the Merkle root of the Merkle tree, where the transaction is located Let me repeat it A transaction’s Merkle Proof can be seen as the minimum information required to calculate the root of the Merkle tree, where the transaction is located Okay, now we have gone through the three parts of data required for the existence of simplified verification They are the block headers list, the transaction data and the transaction’s Merkle Proof, respectively Next, we will see how simplified verification is applied in a payment scenario First, we have a five-starred seller, Ruby, who sells commodities online She wants to complete online payments by means of SPV First, she needs to get connected with a Bitcoin network and obtain the block headers list via the Bitcoin network, because the block headers list is one of the three parts of data required for SPV She can collect the first part of data through this connecting with the Bitcoin network This part of data needs to be updated in real-time On the other hand, we have a gamer, Ming When shopping online, he comes across a game console presented by our five-starred seller Ruby, falls for it right away and so he decides to buy it Ming initiates a payment transaction to Ruby If you are familiar with BIP270, you will notice that this BIP applies perfectly in this case Ruby may first send a request for payment to Ming, which is a template of payment transaction After completing it, Ming can send the payment transaction back to Ruby, who then successfully collects the second part of data required for simplified verification, that is, the transaction data Finally, Ruby needs one more thing, the Merkle Proof, to start the SPV Ruby sends the payment transaction to the Bitcoin network and then waits patiently Once the payment transaction is recorded in a certain block, Ruby will receive a Merkle Proof from the Bitcoin network,

collecting all the three parts of data, which enable her to start the SPV Let’s take a look at it With the block headers list in hand, the five-starred seller Ruby can start the SPV Ruby can get a Merkle root via the payment transaction and the Merkle proof, and then find a block header in the block headers list hoping that there is a block header containing this Merkle root In this way, SPV is successfully done And Ruby deems the payment successful Now she can send the game console to Ming Let’s do a recap of the process we just talked about So, SPV requires three things The first one is a block headers list The second one is transaction data The third one is a Merkle Proof of the transaction data We mentioned at the beginning that each block header is 80-byte long We have got about 650,000 block headers by far The total size is 52MB, so it’s very small Since it takes about 10 minutes for each block to be generated, the increment in size every year will be about 4.2MB, still a tiny figure Transaction data is typically 400-byte long In the case of typical P2PKH, the minimum size can be 250 bytes or so If a Merkle proof hails from a block containing 4 billion transactions, its size will be about 1MB Of course, the fewer transactions the block contains, the smaller the size of Merkle proof will be The 52MB size of the first block header list is usually stored on the hard drive or RAM, which is a storage space There is no need to store the next two, which have to be transmitted instead So they require transmission But generally speaking, what I want to say is the scalability As we can see, 52MB, 400 bytes, 1MB, and even 1MB are all based on an assumption that there are 4 billion transactions in the block The whole process of SPV and its preconditions are therefore perfectly scalable Of course in this presentation, you might have realized that the entire SPV is very suitable for online shopping But how do we fulfill payment transactions in brick-and-mortar stores? Because there is one step, where Ruby has to wait for the payment transaction to be recorded on the block That could take 10 or even 20 minutes, which is not Instant Pay So, now we will discuss how SPV can make Instant Pay happen First, we can see that we need more information in order to enable Instant Pay In the transaction data here, we’ve got an input transaction The Merkle proof is also a Merkle proof for the input transaction, not for the payment transaction Let’s explain it in detail First, we still have Ruby, but this time she becomes a six-starred seller, because she’s got a brick-and-mortar store now However, she still sells game consoles as before The gamer Ming wants a game console ASAP, so he chooses Instant Pay and provides Ruby with a payment transaction, an input transaction as well as its Merkle proof After verifying these, Ruby decides to give the game console to Ming But how can she be convinced that Ming is not cheating her? Let’s take a look at it in more detail First, let’s see what a payment transaction exactly is In this payment transaction, we see that there is an output Its amount is x And the payee is PK2, public key 2 If Ruby thinks this amount is OK and the public key belongs to him, then the output is fine In this part, Ruby can check it by herself The second part is the input transaction Ruby can check whether this input transaction exists or not

through the Merkle proof, i.e. verify the existence of a transaction, as we said before Ruby can verify its existence via the block headers list she owns, specific contents of the input transaction and the Merkle proof However, one thing here has been overlooked by all of us, which is the digital signature This is one of those key things that are often overlooked and I would like to talk about it today First, I want to say a digital signature is legally valid, which is prescribed in Article 14 of the Digital Signature Act Second, I would like to use a credit card payment for comparison A few years ago, a credit card payment could be made with a handwritten signature The merchant needed you to hand-write a signature Then the merchant could check whether it matched the signature on the back of your credit card If they matched, the payment could be made successfully Therefore, checking the signature in a credit card payment is also a kind of Instant Pay Therefore, we can conclude that if we can verify the validity of a digital signature, we can enable Instant Pay Of course, here we have an assumption that the payee can establish a payer’s identity using a public key I want to say a few things about this assumption First, when you pay using a credit or debit card, your name is written on the card Second, Instant Pay offers great convenience to both the payee and the payer Therefore to some extent, a payer might be willing to provide a public key with his own identity or a public key associated with his identity Third, the payee can offer incentives, such as credit points or others, to encourage the payer to provide a public key, which can prove the payer’s identity Fourth, the association between the public key and the identity can be kept secret Only the payee can verify the association between the payer’s identity and the public key Fifth, when the spending amount exceeds a certain threshold, the law will require the payer to describe the payee’s identity Based on the above arguments, we believe this assumption is reasonable Next, let’s take a look at how to verify a digital signature We need three pieces of information as well The first one is the signatory information The second part is the digital signature The third part is the public key In a payment transaction, we have seen that the digital signature and the public key are both in the unlocking script But what about the signatory information? In fact, the signatory information contains some data in the input transaction That is to say, the signatory information is not contained entirely in the payment transaction This is the second thing that has been overlooked What information derived from the input transaction is contained in the signatory information? It is quite simple, actually It’s the first output amount and the output script of this input transaction Let’s take a look at a complete diagram of the signatory information The long strip shown at the bottom is the signatory information All the data hails from the above two transactions “1” represents the version number of the payment transaction The next few fields in pink all hail from the input in the payment transaction The fields in yellow hail from the first output of the input transaction This output is determined by the input point in the payment transaction The field in blue contains the hash values of all outputs in the payment transaction “0” represents Locktime in the payment transaction And sighashflag determines the input of these 3 hash values We will not elaborate on that today Since this slide contains a lot of information, let’s view the same contents from another perspective I will keep the signatory information unchanged here

Now let’s look at the meaning of each field The first field represents the transaction version The second field contains the hash values of all the input points The payment transaction we’ve discussed has only one input So this is the hash value of InputTransaction_0 The third field represents the hash values of all sequence numbers Since we have only one input point, there is one sequence number Next is the input point corresponding to the signature Therefore, it is InputTransaction_0 The information coming next hails from an output of the input transaction We first need to read the output script, P2PKH, and then calculate its byte length and put it in front Then, we read the value in the locking script and put “W” here The unit used here is Satoshi Next is the sequence number of that input corresponding to the signature Here comes the largest one, containing eight Fs Coming next are the hash values of all the transaction outputs Since we have two transaction outputs and each transaction output is in the format of value plus output script, then we join them together as the input as to hash values Next is Locktime It’s zero here The last one is sighashflag Our description of the sighashflag should be “all” That’s why we use “all”, “all” and “all” here If the sighash here is not the same, these three hash values would be different We will not make further explanation here I will give you some time to digest the contents on this slide Great, you don’t have to remember all the exact contents in the signatory information We only need to remember that it has to be composed of a payment transaction and an input transaction Now let’s take a look at the information provided by the gamer, Ming, to our six-starred seller, Ruby The payment transaction, the input transaction, and the Merkle proof Let’s see whether Ruby can complete the verification of the digital signature To verify the digital signature, we will need the signatory information, the digital signature as well as the public key Ruby has the input transaction, the payment transaction, and the Merkle proof You will find that the verification of digital signature doesn’t actually require a Merkle proof, and it doesn’t even need most contents in the input transaction Is it sufficient to just provide an output of the input transaction and the payment transaction? Let’s see what will happen if Ming only provides these two pieces of information First, we can see that this P2PKH can correspond to the public key in the payment transaction That’s no problem That is to say, this P2PKH actually determines what the public key will be But what about the value? Can the input point of this input transaction determine the value? If Ming alters the value, will Ruby be informed of it? The answer is no That means it is impossible for the input transaction or rather the whole input information to inform Ruby of what exactly this part of information is If Ming provides this part of information in its entirety, it is impossible for Ruby to ensure the accuracy of this part of information Ruby is therefore required to make sure that the value and the script of the input transaction have never been tampered with Now, we have only one solution, which is to provide all the data of the input transaction and also ensure data completeness by means of simplified verification That’s why Ming has to provide Ruby with the whole of the input transaction as well as the Merkle proof of the input transaction This is the third thing that has been overlooked, but I want to talk about, namely, the integrity of an input transaction Before we go back to the story of Ming and Ruby, let’s sort out our logic and train of thought At the beginning, we wanted Instant Pay

Then we believed Instant Pay could happen if we could verify the validity of a digital signature However, we need the signatory information to verify the digital signature, and the signatory information contains the output script and the value of the input transaction We need to ensure the output script and the value have never been tampered with So we need to present the integrity of the input transaction by means of simplified verification For that purpose, we need to enter all the data of the input transaction as well as its Merkle proof Therefore, if Ming provides the input transaction as well as its Merkle proof plus the payment transaction, then Ruby can do all these things and finally be able to verify the digital signature, so as to enable Instant Pay Now let’s take a look at how Ming and Ruby make it happen First, the gamer Ming provides the Merkle proof, the input transaction and the payment transaction Next, the first step for Ruby is to prove the existence and integrity of the input transaction via the Merkle proof The second step for her is to read the output script and the value in the input transaction, to verify the corresponding digital signature in the payment transaction Once the digital signature is verified, Ruby can hand the game console over to the gamer, Ming, thus enabling Instant Pay Let me repeat it Ruby proves the existence and integrity of the input transaction by use of the Merkle proof, and then reads the output script and value in the input transaction to verify the corresponding digital signature in the payment transaction So why is Instant Payment enabled? Because Ruby can verify the digital signature For that purpose, simplified verification is required to ensure the completeness of certain information This is also a very important role played by simplified verification in Instant Pay This is an important point that is often overlooked Okay, let’s move on to next topic First, I want to start with something important The existence of a transaction doesn’t indicate the validity of a digital signature I will explain what it means Let’s assume we have a payment transaction which has been recorded in the block, therefore we have a Merkle proof Can this Merkle proof prove that the digital signature is valid? You might think that since this payment transaction has been recorded on the blockchain, the digital signature must be valid But have you ever thought about which output script this digital signature corresponds to? Let me explain the question The output script determines the input script, i.e. the digital signature and the public key Perhaps, I need to explain it a bit further Let’s look at some examples I’d like to take this opportunity to thank Xiaojie Tao, CTO of Volt, who single-handedly discovered this key point, which is overlooked So thank you, Tao Xiaojie I will explain in detail this key point discovered by him As we said, the output script determines the input script What does that mean exactly? We have this Public Key Hash in the output script, which determines that a certain public key must be used in the input script Therefore, only the owner of the private key corresponding to this public key can affix a digital signature And this OP_CHECKSIG requires that a digital signature must be contained in the input script Basically, these two factors determine that the input script can only be created by the owner of the private key corresponding to this public key However, if we delete the rest of this output script and leave OP_CHECKSIG alone, this input script can actually be created by anyone

Because anyone can generate a private key and calculate the public key before calculating the digital signature In that case, the public key here can be any public key, but due to the existence of OP_CHECKSIG, this digital signature is still a valid one The public key here, however, is of no significance at all Let’s look at another example, if the output script is OP_DROP OP_DROP OP_TURE, that is to say, no matter what the input script is, as long as it provides two pieces of data, the first piece of data will be discarded but the second piece of data will be discarded, too Then “Verification successful” will appear on the stack What does that mean? That any two pieces of data can form a valid input script If someone provides two pieces of data that look like a digital signature and a public key, a transaction with this input script would then be deemed valid and be recorded in the block However, since the output script contains no OP_CHECKSIG, the digital signature in the input script is not necessarily valid To put it simply, when we see a transaction contains a digital signature and a public key, it doesn’t necessarily mean the digital signature in this input script is valid We have to check what the output script is If the output script is OP_DROP OP_DROP OP_TURE, then this digital signature is most probably invalid Thus, the completeness of the output script is very important, because the output script can specify the public key and also the request for a signature That is to say when you check whether a digital signature is valid, you need to check its output script and ensure that this output script does request a digital signature Besides, the public key it specifies is the public key you expect The completeness of the output script can be guaranteed by the integrity of the input transaction And simplified verification can be used to ensure the integrity of the input transaction Let’s sort out our logic and train of thought We can ensure the integrity of the input transaction by means of simplified verification, thus ensuring the completeness of the output script in the input transaction, so that we can ensure the validity of the corresponding digital signature The validity of a digital signature is very important in a lot of data applications Let’s look at one case: Metanet If you are not familiar with it, you can learn more about it on the two URLs below You can also contact my colleague Jack Davies Here, I will not give a detailed introduction of Metanet I just want to say the digital signature and the public key in the input script on Metanet correspond to the Metanet transaction’s upper layer as well as authorization and certification of Metanet data To put it simply, the digital signature and the public key on Metanet are very important Let’s take a look at a Metanet transaction The key point here is this digital signature We must pay attention to the public key PKA in here, and a funding transaction, and lastly, an upper-layer Metanet transaction Let’s take a look For the upper-layer Metanet transaction, what we are interested in is the last output, which is a data output of OP_FALSE OP_RETURN As we can see here, the public key PKA is used in this upper-layer Metanet transaction In addition, we need to take a look at this funding transaction In this transaction, we are interested in one of its outputs The output value here is x, its output script is P2PKH PKA and the public key here is PKA, too

Let’s extract some important information from these 3 transactions and put it on the same slide First, we have an upper-layer Metanet transaction, in which we have defined the public key PKA That means if the Metanet transaction is valid, it must use this PKA and must require a corresponding digital signature This Metanet transaction meets these requirements, because there is a digital signature and its public key is PKA The funding transaction has similar requirements, namely, a digital signature is needed and the corresponding public key will be PKA The difference is that the requirements on the funding transaction are rigid and will be checked by all miners, whereas the requirements on the upper-layer Metanet transaction are flexible and can only be checked by users themselves This is the difference However, if both requirements are met, then the Metanet transaction will have no problem Now the question is: what if we don’t know what the funding transaction is, for example, if the output script of the funding transaction is OP_DROP OP_DROP OP_TURE, miners will not check the digital signature In that case, because this special output script is valid, this Metanet transaction will be recorded on the blockchain When a user sees that this Metanet transaction has been recorded on the blockchain, they will naturally believe that this digital signature is valid However, it has not been checked by miners yet Therefore, a user has to either check the digital signature on his own or request the output script of the funding transaction for verification, to ensure the digital signature is indeed checked by miners To put it simply, whether the digital signature in the input script is valid depends on the corresponding output script rather than on the fact that the Metanet transaction is on the blockchain But if we can ensure that the output script of the funding transaction specifies the corresponding public key and the request for a signature by means of simplified verification, plus the proof that the Metanet transaction has been on the blockchain, we can determine the validity of the Metanet transaction Let me repeat it The validity of the Metanet transaction requires a funding transaction, a Metanet transaction and a Merkle proof There is one thing I must emphasize here, namely that we must provide a funding transaction, otherwise there is no way for us to check the validity of the Metanet transaction In fact, Metanet is no exception Any application that needs to utilize a digital signature in the input script has to take this key point into consideration, which is, the validity of a digital signature requires an input transaction that has not been tampered with And the data integrity of input transaction requires simplified verification That’s why simplified verification is particularly important Lastly, let’s do a summary We have mentioned at the beginning that the SPV described in the Bitcoin whitepaper is mainly used to verify the existence of a transaction We find such a verification method is especially suitable for online shopping, because Ruby can patiently wait for the Merkle proof as to the payment transaction once Ming sends a payment transaction to her After receiving the Merkle proof, Ruby can carry out the SPV to ensure a successful payment The waiting time here is between 10 minutes and 2 hours, which is fine in the case of online shopping However, if Ruby has a brick-and-mortar store, where she wants to enable Instant Pay, she has to check the digital signature in the payment transaction, because the signatory information in this digital signature contains some data in the input transaction Ruby will therefore ask Ming to provide the input transaction She also has to ensure the integrity of the input transaction provided by Ming

has not been tampered with She needs Ming to provide a Merkle proof for this input transaction Ruby can ensure the integrity of the input transaction by means of SPV, especially the completeness of the output script and the value in the input transaction Ruby can verify the digital signature with peace of mind Once the verification is successful, Ruby can send the item over to Ming, thus enabling Instant Pay At last, we have discussed some data applications which have all put the digital signature in the input transaction to some other use he validity of digital signature is very important in these applications Therefore, in order to verify a digital signature, we need an input transaction This is very important We also need Merkle proofs for the input transaction in order to ensure its integrity Lastly, I would like to mention that SPV, or simplified payment verification, can not only verify the existence of a transaction, but can also verify the integrity of the input transaction Here is an important point that has been often overlooked: because the integrity of input transaction is one of the key factors for verifying the validity of a digital signature, I hope all of you will understand the significant role that SPV plays in relation to the validity of a digital signature That brings us to the end of my presentation today Thank you! Please recommend this conference to other people serving the blockchain industry whom you know and stay tuned with the Bitcoin SV Developer Zone on CSDN, at bsv.csdn.net Thank you, bye!