<p>Generally, thin-clients at least download, validate, and store the header for each block. Since the Merkle root is part of the header, they already know all the Merkle roots for the whole blockchain. While a block header is insufficient for checking the corresponding block's validity (even the complete block would be insufficient if the validator doesn't know the current UTXO set), just from the header, a thin-client can verify that…</p>
<ul>
<li>the block header is well-formed</li>
<li>the block header provides sufficient proof-of-work to pass the difficulty requirement</li>
<li>the block header commits to the previous block, and inductively connects to the Genesis Block</li>
</ul>
<p>Since each header is only 80 B, the whole header chain is just ~57.5 MB. Thin-clients then gain some confidence in the chain-tip they're following by waiting for additional blocks extending it under the assumption that only the best chain would be acquiring significant additional POW over time.</p>
<p>Now, when a thin-client receives a transaction along with its <a href="https://bitcoin.stackexchange.com/a/50680/5406">Merkle branch</a>, it can check whether it attaches to the header chain by hashing the transaction, combining it with the corresponding hashing partners that were part of the Merkle branch, and whether that ends up matching a Merkle root in one of the block header's it has.</p>

CC BY-SA 4.0
2022-04-12T14:55:09.633Z
> Now, when a thin-client receives a transaction along with its Merkle branch

How is the Merkle branch created? Who creates it?
Finlay Weber
CC BY-SA 4.0
2022-04-12T15:06:27.650Z
@FinlayWeber: Full nodes calculate Merkle branches to prove membership of a transaction when they get a request for a "Merkle block". I've described it further here: https://bitcoin.stackexchange.com/a/50680/5406
Murch
CC BY-SA 4.0
2022-04-12T16:51:03.520Z
Just to make sure I understand. A client, who has the merkle root, and who wants to check if transaction A is in the block, would make a request for "Merkle blocks" needed for it to confirm the inclusion of transaction A in the set of transactions? So basically the full node, not only provide the merkle root, but it can also provide merkle blocks to clients who needs it to perform inclusion verification? Is this right? If so, what do the client need to pass to the full node when making this request?
Finlay Weber
CC BY-SA 4.0
2022-04-12T20:21:03.773Z
The thin client would probably have gotten the block header already previously and thus know the merkle root of the block in advance. After the thin client learns about a transaction it is interested in, it would make a `getdata` request specifying the data type `MSG_MERKLEBLOCK`. The full node would respond with a [`merkleblock`](https://developer.bitcoin.org/reference/p2p_networking.html#merkleblock) message that provides the txid, hashing partners, and header. The full tx is then sent as a `tx` message right after.
Murch
CC BY-SA 4.0
2022-04-13T01:04:43.057Z
Thanks for the answer and clarification!
Finlay Weber
CC BY-SA 4.0
2022-01-05T22:05:15.920Z
2022-04-12T15:06:41.347Z
2022-04-12T15:06:41.347Z
Murch
<p>I understand Merkle roots can be used for Merkle inclusion proofs, where a client/validator can quickly check if a transaction is part of the block without requesting all the transactions in the block.</p>
<p>The question I have is this: for this process of performing the Merkle proof, where does the client performing the proof get the merkle root from? And how is the client guaranteed that the merkle root it is given is the correct one?</p>
<p>I am thinking of a scenario where an attacker could convince a client/validator that a transaction is part of a block by sending it a fraudulent Merkle root and corresponding hashes.</p>
<p>What properties of Merkle trees and how it is used in Merkle inclusion proof in bitcoin prevent this from happening?</p>

<merkle-tree><spv><merkleblock>
What guarantees the validity of merkle root used in the merkle inclusion proof?
Finlay Weber
# What guarantees the validity of merkle root used in the merkle inclusion proof?

(Asked by: username_0 on 2022-01-05)

I understand Merkle roots can be used for Merkle inclusion proofs, where a client/validator can quickly check if a transaction is part of the block without requesting all the transactions in the block.

The question I have is this: for this process of performing the Merkle proof, where does the client performing the proof get the merkle root from? And how is the client guaranteed that the merkle root it is given is the correct one?

I am thinking of a scenario where an attacker could convince a client/validator that a transaction is part of a block by sending it a fraudulent Merkle root and corresponding hashes.

What properties of Merkle trees and how it is used in Merkle inclusion proof in bitcoin prevent this from happening?

**Tags:** merkle-tree, spv, merkleblock


---

## 1 answers

### Answer by username_1 on 2022-01-05. Score: 3 | Accepted answer

Generally, thin-clients at least download, validate, and store the header for each block. Since the Merkle root is part of the header, they already know all the Merkle roots for the whole blockchain. While a block header is insufficient for checking the corresponding block's validity (even the complete block would be insufficient if the validator doesn't know the current UTXO set), just from the header, a thin-client can verify that…

* the block header is well-formed
* the block header provides sufficient proof-of-work to pass the difficulty requirement
* the block header commits to the previous block, and inductively connects to the Genesis Block

Since each header is only 80 B, the whole header chain is just ~57.5 MB. Thin-clients then gain some confidence in the chain-tip they're following by waiting for additional blocks extending it under the assumption that only the best chain would be acquiring significant additional POW over time.

Now, when a thin-client receives a transaction along with its [Merkle branch](https://bitcoin.stackexchange.com/a/50680/5406), it can check whether it attaches to the header chain by hashing the transaction, combining it with the corresponding hashing partners that were part of the Merkle branch, and whether that ends up matching a Merkle root in one of the block header's it has.

> **Comments:**
> **username_0**: > Now, when a thin-client receives a transaction along with its Merkle branch  How is the Merkle branch created? Who creates it?  
> **username_1**: @username_0: Full nodes calculate Merkle branches to prove membership of a transaction when they get a request for a "Merkle block". I've described it further here: https://bitcoin.stackexchange.com/a/50680/5406  
> **username_0**: Just to make sure I understand. A client, who has the merkle root, and who wants to check if transaction A is in the block, would make a request for "Merkle blocks" needed for it to confirm the inclusion of transaction A in the set of transactions? So basically the full node, not only provide the merkle root, but it can also provide merkle blocks to clients who needs it to perform inclusion verification? Is this right? If so, what do the client need to pass to the full node when making this request?  
> **username_1**: The thin client would probably have gotten the block header already previously and thus know the merkle root of the block in advance. After the thin client learns about a transaction it is interested in, it would make a `getdata` request specifying the data type `MSG_MERKLEBLOCK`. The full node would respond with a [`merkleblock`](https://developer.bitcoin.org/reference/p2p_networking.html#merkleblock) message that provides the txid, hashing partners, and header. The full tx is then sent as a `tx` message right after.  
> **username_0**: Thanks for the answer and clarification!  

---

