<p>I interpret your question as &quot;why can I trust a Merkle proof?&quot;</p>
<ol>
<li>A cryptographic hash function processes an input and always returns the same output. If you change the input in the slightest, you will get back a completely different result. It is considered computationally infeasible to find other inputs such that they produce a matching output to other inputs. The range of outputs is so humongous that merely knowing a specific output is proof that we knew about the corresponding input.</li>
<li>A block id is produced by hashing the header of a block. The header includes the previous block’s id and the <em>Merkle root</em>. The block hash must fulfill the current difficulty, which means that it must be an extremely unlikely low hash. Because it is so much work to find a valid block, it is hard to produce a block header that commits to other data but has a valid proof-of-work.</li>
<li>Miners decides which transactions they try to include in their block before attempting to find a valid block header. From the list of transaction ids, they build a <a href="https://bitcoin.stackexchange.com/a/38399/5406">Merkle tree</a>. The Merkle tree starts from the transaction ids as the leaves and hashes them together pairwise at each level. Finally we get a Merkle root that compactly commits to the inclusion of all transactions.</li>
<li>Putting it all together, we have a block header that is covered by a proof-of-work that is expensive to fake, which commits to a Merkle root. We have a Merkle root that commits to all transactions, and vice versa, by showing that we know the hashing partners that form a series of hashes that connect a transaction id to the Merkle root, and the chain of block headers that connect the block to the Genesis block, we can provide a credible proof that a transaction is present in a block.</li>
<li>Malicious nodes can lie by omission: &quot;No, I’ve never seen that transaction.&quot; But for honest nodes making a proof is cheap, and when you do get a proof, it is trivial to check whether it is valid and connected to what you think is the best blockchain. If a malicious node tried to lie to you, they would have to perform very expensive proof of work to stand a chance.</li>
</ol>

CC BY-SA 4.0
2024-03-22T14:28:06.783Z
Unfortunatelly, I knew all this. My question is about sending a request to one of the malicious node. If 49% of the nodes are malicious and they collude to start working on a different chain after block number X, and at that moment, I send 1 btc to Bob, bob could see that he got 1 btc because his request went to honest node.so he sends me a bike. Now, he asks again whats his balance and his request goes to colluding node which still has a valid chain but does not contain the 1 btc tx. Even if Bob waits for 6 confirmations, such hard fork of 51-49% still tricked him.
Giorgi Lagidze
CC BY-SA 4.0
2024-03-22T14:28:35.083Z
You can remove what you wrote though. Sorry I was not clear maybe on the question.
Giorgi Lagidze
CC BY-SA 4.0
2024-03-22T14:57:48.727Z
It seems to me that my answer is relevant here: If you are concerned that a large subset of miners are working on an alternative chaintip, the Merkle proof they provide will link a different chain of block headers than the one your lightweight client is following (covered in points 2 and 4). Or is your question "How can a lightweight tell whether the chaintip with the most work is valid?"
Murch
CC BY-SA 4.0
2024-03-22T15:12:34.827Z
The user is an external user, someone who has no knowledge of what rpc is and what "request" is. The user might be using a software or rpc endpoint of the node that is in 49% of my scenario. In this case, user first gets the merkle root of that node's chain's one of the block and ofc, the proof as well will be exactly corresponding to that merkle root, in which case, user will think that he got 1 BTC, but 10 minutes later, the another node(that is in 51%) will return him his balance as 0.
Giorgi Lagidze
CC BY-SA 4.0
2024-03-22T15:13:47.587Z
Please see @PieterWuille’s answer, it seems to be better covering your question.
Murch
CC BY-SA 4.0
2024-03-22T15:16:46.867Z
Yes, I just read his answer and it's exactly what I was looking for.
Giorgi Lagidze
CC BY-SA 4.0
2024-03-22T13:52:13.630Z
2024-03-22T13:52:13.630Z
Murch
<p>A Merkle inclusion proof is a proof that a transaction is included in a block with a particular hash, nothing more. Whoever gave you that proof can lie by omission (claiming no transactions you asked for exist in the given block), but if a proof is given, it can be validated.</p>
<p>As I believe you realize, the proof only covers the inclusion of a transaction in a given block. It doesn't prove anything about that block itself. You must independently acquire information about that block and ascertain it is part of the currently best active chain. <strong>If you just ask some node what their best chain is, they can claim whatever</strong>, and you're trusting that node entirely. That is however not how you're supposed to use such inclusion proofs (unless you have reason to trust them, e.g. because it's your own node, or because it's run by a known entity that you're willing to rely on).</p>
<p>Instead, you (the verifier) would generally run a lightweight network node, which does some part of the network validation. It would connect to multiple other nodes, download the block headers from those nodes, and validate them (just their syntactic correctness and proof-of-work). Among the headers chains you received, you'd pick the most-work valid one, and then verify the Merkle proof against <strong>that</strong>.</p>
<p>There are still ways in which you can be cheated, but it's not as simple as a single node lying to you:</p>
<ul>
<li>Since you are only validating the headers, it is possible that the highest-work headers chain is not actually a valid blockchain (e.g., it could contain unauthorized inflation, theft, or double-spending). Doing so would not convince full nodes, but it can convince lightweight nodes. The theory is that attackers will not try this because it is expensive, hard (needs a majority of the hashrate to keep up), and hopefully a sufficiently important part of the ecosystem would not accept their blocks, thus making the cost of mining wasted. However, this assumption does rely on the presence of enough fully-validating nodes in the network to make the attack uneconomical. If you are concerned about this, your own option is running your own fully-validating node instead of a lightweight one.</li>
<li>If <em>all</em> peers you talk to are attackers (or colluding with an attacker), something referred to as an <em>Eclipse attack</em>, and are thus shielded off from the real best chain, attackers can get away with constructing an alternate minority-hashrate chain, and hiding the real best chain from you. Depending on how long they can keep the Eclipse attack, this may still be extremely expensive.</li>
</ul>
<p>Note that &quot;majority of <strong>nodes</strong>&quot; is never relevant in this analysis. The criteria are whether you have at least <strong>one</strong> honest peer, and whether a majority of the <strong>hashrate</strong> is working with the attacker.</p>

CC BY-SA 4.0
2024-03-22T15:19:14.557Z
Thank you Pieter. That's what I was looking for. Basically,  I can be lied if my request goes to the node that is in 49% - since these nodes are building a different chain(it's still valid), their responses would be different than what 51% of nodes would return. My main concern was that what if I'm a normal user and I just use an endpoint of rpc that goes to one of 49% nodes. In this case, I am tricked. what I gathered from your answer is that I must run a lightweight node and that lightweight node would get the longest chain and I should make a request to my node. All correct ?
Giorgi Lagidze
CC BY-SA 4.0
2024-03-22T15:24:38.740Z
Mostly right. Nodes generally do not expose RPC access to anything but their operator; you *can't* just ask a random node on the network things through RPC, you can only use the P2P protocol with them (which is for communication between nodes). So yes, you'll run your own node (lightweight or not) and it will communicate with other nodes, and then you can request information from your own node yourself. Also note that hashpower and nodes are very different; just because a majority of hashrate is honest does not mean a majority of nodes are.
Pieter Wuille
CC BY-SA 4.0
2024-03-22T15:28:04.060Z
Thanks Pieter. :) Have a great day..
Giorgi Lagidze
CC BY-SA 4.0
2024-03-22T15:05:18.590Z
2024-03-22T15:05:18.590Z
Pieter Wuille
<p>Assume that 51% of nodes are honest and 49% malicious. Fur sure, longest chain would make the chains consistent/same all over the world as 51% can outweigh the 49%, but my question is slightly different.</p>
<p>If I am an external party(just a normal user) and ask whether the specific tx is in the specific block, how can I be sure that this request didn't reach the malicious node ? The solution is for me to get merkle root from a block header, then a node must return to me the proof and then I verify, but, but, but...</p>
<p>my confusion is that I also have to ask for merkle root to the node and how can I be sure that the &quot;asking merkle root&quot; request goes to honest node ? what if it ends up going to the malicious node - since 49% is malicious, it's likely that my request could end up to this malicious node geographically and it could return such a merkle root that the next request of me making for proof also returns appropriate proof to this malicious merkle root. I hope I made sense.</p>

<blockchain><nodes><merkle-tree><majority-attack><sybil-attack>
How can an external party be sure that node's response is valid?
Giorgi Lagidze
# How can an external party be sure that node's response is valid?

(Asked by: username_0 on 2024-03-22)

Assume that 51% of nodes are honest and 49% malicious. Fur sure, longest chain would make the chains consistent/same all over the world as 51% can outweigh the 49%, but my question is slightly different.

If I am an external party(just a normal user) and ask whether the specific tx is in the specific block, how can I be sure that this request didn't reach the malicious node ? The solution is for me to get merkle root from a block header, then a node must return to me the proof and then I verify, but, but, but...

my confusion is that I also have to ask for merkle root to the node and how can I be sure that the "asking merkle root" request goes to honest node ? what if it ends up going to the malicious node - since 49% is malicious, it's likely that my request could end up to this malicious node geographically and it could return such a merkle root that the next request of me making for proof also returns appropriate proof to this malicious merkle root. I hope I made sense.

**Tags:** blockchain, nodes, merkle-tree, majority-attack, sybil-attack


---

## 2 answers

### Answer by username_2 on 2024-03-22. Score: 4 | Accepted answer

A Merkle inclusion proof is a proof that a transaction is included in a block with a particular hash, nothing more. Whoever gave you that proof can lie by omission (claiming no transactions you asked for exist in the given block), but if a proof is given, it can be validated.

As I believe you realize, the proof only covers the inclusion of a transaction in a given block. It doesn't prove anything about that block itself. You must independently acquire information about that block and ascertain it is part of the currently best active chain. **If you just ask some node what their best chain is, they can claim whatever**, and you're trusting that node entirely. That is however not how you're supposed to use such inclusion proofs (unless you have reason to trust them, e.g. because it's your own node, or because it's run by a known entity that you're willing to rely on).

Instead, you (the verifier) would generally run a lightweight network node, which does some part of the network validation. It would connect to multiple other nodes, download the block headers from those nodes, and validate them (just their syntactic correctness and proof-of-work). Among the headers chains you received, you'd pick the most-work valid one, and then verify the Merkle proof against **that**.

There are still ways in which you can be cheated, but it's not as simple as a single node lying to you:

* Since you are only validating the headers, it is possible that the highest-work headers chain is not actually a valid blockchain (e.g., it could contain unauthorized inflation, theft, or double-spending). Doing so would not convince full nodes, but it can convince lightweight nodes. The theory is that attackers will not try this because it is expensive, hard (needs a majority of the hashrate to keep up), and hopefully a sufficiently important part of the ecosystem would not accept their blocks, thus making the cost of mining wasted. However, this assumption does rely on the presence of enough fully-validating nodes in the network to make the attack uneconomical. If you are concerned about this, your own option is running your own fully-validating node instead of a lightweight one.
* If *all* peers you talk to are attackers (or colluding with an attacker), something referred to as an *Eclipse attack*, and are thus shielded off from the real best chain, attackers can get away with constructing an alternate minority-hashrate chain, and hiding the real best chain from you. Depending on how long they can keep the Eclipse attack, this may still be extremely expensive.

Note that "majority of **nodes**" is never relevant in this analysis. The criteria are whether you have at least **one** honest peer, and whether a majority of the **hashrate** is working with the attacker.

> **Comments:**
> **username_0**: Thank you username_2. That's what I was looking for. Basically,  I can be lied if my request goes to the node that is in 49% - since these nodes are building a different chain(it's still valid), their responses would be different than what 51% of nodes would return. My main concern was that what if I'm a normal user and I just use an endpoint of rpc that goes to one of 49% nodes. In this case, I am tricked. what I gathered from your answer is that I must run a lightweight node and that lightweight node would get the longest chain and I should make a request to my node. All correct ?  
> **username_2**: Mostly right. Nodes generally do not expose RPC access to anything but their operator; you *can't* just ask a random node on the network things through RPC, you can only use the P2P protocol with them (which is for communication between nodes). So yes, you'll run your own node (lightweight or not) and it will communicate with other nodes, and then you can request information from your own node yourself. Also note that hashpower and nodes are very different; just because a majority of hashrate is honest does not mean a majority of nodes are.  
> **username_0**: Thanks username_2. :) Have a great day..  

---

### Answer by username_1 on 2024-03-22. Score: 1

I interpret your question as "why can I trust a Merkle proof?"

1. A cryptographic hash function processes an input and always returns the same output. If you change the input in the slightest, you will get back a completely different result. It is considered computationally infeasible to find other inputs such that they produce a matching output to other inputs. The range of outputs is so humongous that merely knowing a specific output is proof that we knew about the corresponding input.
2. A block id is produced by hashing the header of a block. The header includes the previous block’s id and the *Merkle root*. The block hash must fulfill the current difficulty, which means that it must be an extremely unlikely low hash. Because it is so much work to find a valid block, it is hard to produce a block header that commits to other data but has a valid proof-of-work.
3. Miners decides which transactions they try to include in their block before attempting to find a valid block header. From the list of transaction ids, they build a [Merkle tree](https://bitcoin.stackexchange.com/a/38399/5406). The Merkle tree starts from the transaction ids as the leaves and hashes them together pairwise at each level. Finally we get a Merkle root that compactly commits to the inclusion of all transactions.
4. Putting it all together, we have a block header that is covered by a proof-of-work that is expensive to fake, which commits to a Merkle root. We have a Merkle root that commits to all transactions, and vice versa, by showing that we know the hashing partners that form a series of hashes that connect a transaction id to the Merkle root, and the chain of block headers that connect the block to the Genesis block, we can provide a credible proof that a transaction is present in a block.
5. Malicious nodes can lie by omission: "No, I’ve never seen that transaction." But for honest nodes making a proof is cheap, and when you do get a proof, it is trivial to check whether it is valid and connected to what you think is the best blockchain. If a malicious node tried to lie to you, they would have to perform very expensive proof of work to stand a chance.

> **Comments:**
> **username_0**: Unfortunatelly, I knew all this. My question is about sending a request to one of the malicious node. If 49% of the nodes are malicious and they collude to start working on a different chain after block number X, and at that moment, I send 1 btc to Bob, bob could see that he got 1 btc because his request went to honest node.so he sends me a bike. Now, he asks again whats his balance and his request goes to colluding node which still has a valid chain but does not contain the 1 btc tx. Even if Bob waits for 6 confirmations, such hard fork of 51-49% still tricked him.  
> **username_0**: You can remove what you wrote though. Sorry I was not clear maybe on the question.  
> **username_1**: It seems to me that my answer is relevant here: If you are concerned that a large subset of miners are working on an alternative chaintip, the Merkle proof they provide will link a different chain of block headers than the one your lightweight client is following (covered in points 2 and 4). Or is your question "How can a lightweight tell whether the chaintip with the most work is valid?"  
> **username_0**: The user is an external user, someone who has no knowledge of what rpc is and what "request" is. The user might be using a software or rpc endpoint of the node that is in 49% of my scenario. In this case, user first gets the merkle root of that node's chain's one of the block and ofc, the proof as well will be exactly corresponding to that merkle root, in which case, user will think that he got 1 BTC, but 10 minutes later, the another node(that is in 51%) will return him his balance as 0.  
> **username_1**: Please see @username_2’s answer, it seems to be better covering your question.  
> **username_0**: Yes, I just read his answer and it's exactly what I was looking for.  

---

