How to use the Merck tree to prove whether a transaction exists in the SPV

SPV is the abbreviation of "Simplified Payment Verification" (Simple payment verification). The paper briefly mentions this concept, pointing out that the payment can be verified without running a full node, and the user simply needs to save all the block headers. The user cannot verify the transaction, but if he can find a match from somewhere in the blockchain, he will know that the network has approved the transaction and how many confirmations it has received from the network.

According to Satoshi's original text, there is a detail to note that the SPV refers to "payment verification" rather than "transaction validation". There is a big difference between the two types of validation.
Transaction validation is very complex and involves verifying that there are enough balances available to spend, whether there are double flowers, if scripts can be passed, and so on, usually done by miners running full nodes.
"Payment verification" is relatively simple, only to determine whether the transaction used to "pay" has been verified, and how much of the calculation of the amount of protection (number of confirmed).

Consider a situation in which a receives a notification from B that he has given a certain amount of money from a XXX account. In the central way, no one can prove the reliability of B. Receiving this notice, how can a judge what B says is true?

In the bitcoin system, this notification is implemented in a fixed-format "transaction" that includes B's remittance account check, B's signature, the amount remitted to a and the address of a.

If a wants to personally verify the transaction, first, a must traverse the blockchain ledger and position it on the account of B to see if there is enough money on the account check given by B; Next, a will traverse all subsequent ledgers to see if B has already paid for the cash on this account check (whether there is a double flower deception) And then validate the script to determine whether B has the control of the account. This process requires that a must have a complete blockchain.

However, if a only wants to know if the payment has been verified (if the shipment is verified), he can rely on the Bitcoin system for quick verification. That is, check whether the transaction in which the payment occurred has been included in the blockchain and how many confirmations have been received.

Principle: The block header has three key fields, one is Prev_block_hash (the hash value of the previous chunk, which ensures the transaction order recorded by the blockchain), bits (the difficulty of calculating the current chunk), and the third is merkle_root_ Hash (using the Merkle tree algorithm to ensure the authenticity of all transactions included with the chunk).

When verifying that a transaction is real, in theory, the user can verify it in the following ways:

(To simplify the model, we assume that the Tx_hash is used to locate the block.) This method has the risk of being "trading malleable", which can be positioned according to the Output_point in practical applications. ）

0. Obtain and save all block headers of the longest chain from the network to local;
1. Calculate the hash value of the transaction Tx_hash;
2. Locate the block containing the Tx_hash to verify that the block header is contained in the longest known chain;
3. Obtain the hash value needed to build the Merkle tree from the chunk;
4. Calculate Merkle_root_hash based on these hash values;
5. If the calculated result is equal to the Merkle_root_hash in the block header, the transaction is real.
6. Based on the location of the block header, determine how many confirmations the transaction has received.

Advantages: Significant savings in storage space. Reduce the burden on end users. Regardless of the future volume, the size of the block header remains unchanged, with only 80 bytes. Output 52,560 blocks per hour at 6 block speeds. When only the block header is saved, the new storage requirement is approximately 4 megabytes per year, and the cumulative storage requirement is only 400 trillion after 100 years, even if the user is using the lowest-end device and is fully capable of loading under normal conditions.

Question: How can I navigate to the block of the exchange through Tx_hash? Lack of support for this in previous bitcoin agreements

Need to note is the 3rd, but also the author in the actual development process encountered doubts, in fact, the 3rd there is an interactive process.

The client generally connects to a full node, the following diagram is an example:

Assuming you need to verify DATA01, then I need to get Node12, node22,node32 hash, which must be obtained through the interaction with the full node, and after that, you can build the tree to the root based on the build rules, and then compare to determine whether a transaction exists.