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

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,