<p><em>TL;DR: A Merkle branch provides costly-to-fake indicator that a transaction is actually part of the blockchain. The cost of forging a Merkle branch is sufficiently high to deter some attacks on low-value transactions, but trivial to validate by the thin client.</em></p>
<p>Full nodes and thin clients are distinguished by whether they independently process the whole blockchain. While full nodes verify the complete blockchain from the Genesis block to the chain-tip, thin clients usually keep only copies of transactions they are interested in, and sometimes the headers of the blockchain. Hereby, the headers of the blockchain are already a huge security boost, because the block headers by themselves already are subject to a number of consensus rules including the difficulty requirement. Creating fake block headers that pass even a cursory validation is very costly.</p>
<p>One of the fields included in the 80-byte block header is the Merkle root. The Merkle root is a cryptographic commitment to all transactions included in the block. So, providing the Merkle branch that connects the transaction's leaf to the root is a strong indicator that the transaction existed in a block. Especially, if the block is checked to pass the difficulty requirement which is computationally expensive to find. If the thin client tracks the chain of block headers, the headers tie together by linking to their predecessors, which means that an attacker not only needs to find a block with sufficient proof-of-work, but also do so in a limited time.</p>
<p>If the transaction were not in a block, it would be computationally infeasible to find hashing partners that tie the transaction's hash to a specific Merkle root. Unfortunately, the thin client could still be lied to; either with the claim that the transaction is not included in a block (it's impossible to proof absence except by parsing all blocks), or if the transaction was part of a stale chain-tip that got superseded by a chain-tip where the transaction was not included. Thin clients usually protect against these by asking multiple peers for information, and by waiting for multiple confirmations to make attacks more costly.</p>

CC BY-SA 4.0
2020-09-21T21:12:30.267Z
My question still stays the following: Why would thin client need to know if xxx transaction is found in yyyth block ? I'd much appreciate if you could bring a scenario with names so i can easily understand. Thank you
Nika Kurashvili
CC BY-SA 4.0
2020-09-21T21:16:23.897Z
Let me turn the question around: how would someone prove that your transaction is included in the blockchain without showing you where it is included? Also, thin clients want to know when the transaction got confirmed, so that they can know when they got paid.
Murch
CC BY-SA 4.0
2020-09-21T20:59:06.370Z
2020-09-21T20:59:06.370Z
Murch
<blockquote>
<p>Why would a thin node want to know information like this ?</p>
</blockquote>
<p>They quite possibly don't care about exactly which block the transaction was included in, but they most certainly care about knowing the transaction <em>was included in the blockchain at all</em>. It just so happens that there is no easy way to prove the latter without proving which block it is included in.</p>
<p>To illustrate a more concrete interaction (as used in BIP37, but other protocols like Electrum's client-server protocol are similar). F = full node (the server), L = light client. This is obviously not an actual protocol dump, but conceptually it's close.</p>
<blockquote>
<p>L: Hi F, I'm a light client and am interested in transactions involving addresses A, B, and C. [filteradd]</p>
<p>F: Okay. [<em>nothing</em>]</p>
<p>L: I have synchronized blocks up to block hash H. [getheaders]</p>
<p>F: Oh dear, you're behind, there is also block I and J. Here are their headers! [headers]</p>
<p>L: Those headers look great, and their proof of work is valid. So eh... does I contain any transactions I care about? [getdata with MSG_FILTERED_BLOCK]</p>
<p>F: Nope. [empty merkleblock]</p>
<p>L: Okay... what about block J [getdata with MSG_FILTERED_BLOCK]</p>
<p>F: Oh yes, here is transaction T that involves one of your addresses! [merkleblock]</p>
<p>L: That looks like a transaction that indeed pays me... but can you prove it's actually been included in the chain? You know, I don't trust you really and you could be giving me an invalid transaction, or one that spends money that has already moved in the chain. [<em>nothing</em>]</p>
<p>F: Fine, here is a Merkle path that proves T is in fact included in block J. [part of the earlier merkleblock message, actually].</p>
</blockquote>
<p>So the point is that without the proof, F could be claiming that L got paid, while the transaction is invalid. Having it included in the chain makes that very expensive, assuming other nodes in the network actually enforce validity of transactions in the chain.</p>
<p>There is a caveat of course. There is no way that F can prove to L that block I <em>didn't</em> include any interesting transactions. The solution to that is either trusting the server, or trying multiple - neither is very satisfying.</p>

CC BY-SA 4.0
2020-09-22T08:30:32.907Z
So, it seems like that thin nodes at first have the transactionId. then they ask this to full nodes. full nodes search the transactionId in the entire blockchain presumably. if found, they say: yes, we got it, but light node doesn't believe it and that's where full node gives the path of the merkle root  of the block it found to the thin node to check it out.. correct ?
Nika Kurashvili
CC BY-SA 4.0
2020-09-22T14:16:54.530Z
The full node does not have to search the full blockchain. The thin client first only has the addresses they're interested in. The thin client only learns about the transaction from the full node when the full node looks at a specific block with the filter provided by the thin client.
Murch
CC BY-SA 4.0
2020-09-25T18:07:56.173Z
Hi @Murch, sorry for the late follow up. Just to sum up. A light node has addresses of the users. It at first doesn't have transactions. Now it gives the addresses to full nodes and want to get transactions.  A full node gives transactions to a thin node and thin node shows that on UI website. but problem is how a thin node can trust full node in this case and that's why merkle roots are for. I guess, that's what a thin node is interested and not if the transaction is included in the block or not, but at the end of the day, both options intersect and they mean the same thing. am I right?thanks
Nika Kurashvili
CC BY-SA 4.0
2020-09-26T01:05:52.337Z
Right, the thin client is mostly interested to be sure that he got paid, and the certainty of having been paid increases with confirmations. A confirmation is achieved when the transaction is included in a block. The easiest way to show evidence it is in some block is by showing in which block exactly. This in turn tells the thin client how many blocks were found since then, and the additional confirmations will make the thin client more confident it isn't being tricked.
Murch
CC BY-SA 4.0
2020-09-22T02:07:01.873Z
2020-09-22T13:38:21.033Z
2020-09-22T13:38:21.033Z
Pieter Wuille
<p>I understand what a merkle root is and how merkle proofs work.</p>
<p>It's all about thin nodes checking whether a specific transaction ID is in a specific block. So, thin node says: I have a transaction ID - 12345 and I want to know if this transaction is present in  259,291th block.</p>
<p>Why would a thin node want to know information like this ?</p>

<confirmations><spv><thin-clients><merkleblock>
Why does a thin node need to know if a transaction is present in specific block's merkle tree?
Nika Kurashvili
# Why does a thin node need to know if a transaction is present in specific block's merkle tree?

(Asked by: username_0 on 2020-09-21)

I understand what a merkle root is and how merkle proofs work.

It's all about thin nodes checking whether a specific transaction ID is in a specific block. So, thin node says: I have a transaction ID - 12345 and I want to know if this transaction is present in 259,291th block.

Why would a thin node want to know information like this ?

**Tags:** confirmations, spv, thin-clients, merkleblock


---

## 2 answers

### Answer by username_2 on 2020-09-22. Score: 4 | Accepted answer

> Why would a thin node want to know information like this ?

They quite possibly don't care about exactly which block the transaction was included in, but they most certainly care about knowing the transaction *was included in the blockchain at all*. It just so happens that there is no easy way to prove the latter without proving which block it is included in.

To illustrate a more concrete interaction (as used in BIP37, but other protocols like Electrum's client-server protocol are similar). F = full node (the server), L = light client. This is obviously not an actual protocol dump, but conceptually it's close.

> L: Hi F, I'm a light client and am interested in transactions involving addresses A, B, and C. [filteradd]
>
> F: Okay. [*nothing*]
>
> L: I have synchronized blocks up to block hash H. [getheaders]
>
> F: Oh dear, you're behind, there is also block I and J. Here are their headers! [headers]
>
> L: Those headers look great, and their proof of work is valid. So eh... does I contain any transactions I care about? [getdata with MSG\_FILTERED\_BLOCK]
>
> F: Nope. [empty merkleblock]
>
> L: Okay... what about block J [getdata with MSG\_FILTERED\_BLOCK]
>
> F: Oh yes, here is transaction T that involves one of your addresses! [merkleblock]
>
> L: That looks like a transaction that indeed pays me... but can you prove it's actually been included in the chain? You know, I don't trust you really and you could be giving me an invalid transaction, or one that spends money that has already moved in the chain. [*nothing*]
>
> F: Fine, here is a Merkle path that proves T is in fact included in block J. [part of the earlier merkleblock message, actually].

So the point is that without the proof, F could be claiming that L got paid, while the transaction is invalid. Having it included in the chain makes that very expensive, assuming other nodes in the network actually enforce validity of transactions in the chain.

There is a caveat of course. There is no way that F can prove to L that block I *didn't* include any interesting transactions. The solution to that is either trusting the server, or trying multiple - neither is very satisfying.

> **Comments:**
> **username_0**: So, it seems like that thin nodes at first have the transactionId. then they ask this to full nodes. full nodes search the transactionId in the entire blockchain presumably. if found, they say: yes, we got it, but light node doesn't believe it and that's where full node gives the path of the merkle root  of the block it found to the thin node to check it out.. correct ?  
> **username_1**: The full node does not have to search the full blockchain. The thin client first only has the addresses they're interested in. The thin client only learns about the transaction from the full node when the full node looks at a specific block with the filter provided by the thin client.  
> **username_0**: Hi @username_1, sorry for the late follow up. Just to sum up. A light node has addresses of the users. It at first doesn't have transactions. Now it gives the addresses to full nodes and want to get transactions.  A full node gives transactions to a thin node and thin node shows that on UI website. but problem is how a thin node can trust full node in this case and that's why merkle roots are for. I guess, that's what a thin node is interested and not if the transaction is included in the block or not, but at the end of the day, both options intersect and they mean the same thing. am I right?thanks  
> **username_1**: Right, the thin client is mostly interested to be sure that he got paid, and the certainty of having been paid increases with confirmations. A confirmation is achieved when the transaction is included in a block. The easiest way to show evidence it is in some block is by showing in which block exactly. This in turn tells the thin client how many blocks were found since then, and the additional confirmations will make the thin client more confident it isn't being tricked.  

---

### Answer by username_1 on 2020-09-21. Score: 1

*TL;DR: A Merkle branch provides costly-to-fake indicator that a transaction is actually part of the blockchain. The cost of forging a Merkle branch is sufficiently high to deter some attacks on low-value transactions, but trivial to validate by the thin client.*

Full nodes and thin clients are distinguished by whether they independently process the whole blockchain. While full nodes verify the complete blockchain from the Genesis block to the chain-tip, thin clients usually keep only copies of transactions they are interested in, and sometimes the headers of the blockchain. Hereby, the headers of the blockchain are already a huge security boost, because the block headers by themselves already are subject to a number of consensus rules including the difficulty requirement. Creating fake block headers that pass even a cursory validation is very costly.

One of the fields included in the 80-byte block header is the Merkle root. The Merkle root is a cryptographic commitment to all transactions included in the block. So, providing the Merkle branch that connects the transaction's leaf to the root is a strong indicator that the transaction existed in a block. Especially, if the block is checked to pass the difficulty requirement which is computationally expensive to find. If the thin client tracks the chain of block headers, the headers tie together by linking to their predecessors, which means that an attacker not only needs to find a block with sufficient proof-of-work, but also do so in a limited time.

If the transaction were not in a block, it would be computationally infeasible to find hashing partners that tie the transaction's hash to a specific Merkle root. Unfortunately, the thin client could still be lied to; either with the claim that the transaction is not included in a block (it's impossible to proof absence except by parsing all blocks), or if the transaction was part of a stale chain-tip that got superseded by a chain-tip where the transaction was not included. Thin clients usually protect against these by asking multiple peers for information, and by waiting for multiple confirmations to make attacks more costly.

> **Comments:**
> **username_0**: My question still stays the following: Why would thin client need to know if xxx transaction is found in yyyth block ? I'd much appreciate if you could bring a scenario with names so i can easily understand. Thank you  
> **username_1**: Let me turn the question around: how would someone prove that your transaction is included in the blockchain without showing you where it is included? Also, thin clients want to know when the transaction got confirmed, so that they can know when they got paid.  

---

