<p><a href="https://i.sstatic.net/HrKX0.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/HrKX0.png" alt="Bitcoin Block Data" /></a><br />
<sup><a href="https://i.sstatic.net/HrKX0.png" rel="nofollow noreferrer">[Illustration by Matthäus Wander (Wikimedia)]</a></sup></p>
<p>The block header is an 80-byte data structure that has two elements relevant for this question. Firstly, the header commits to the previous block per the previous block's hash. These links form a chain ensuring that there can only be one block at each height and forcing a potential attacker to commit to a specific point at which their chaintip forks off from the best chain. Secondly, the header includes the merkle root of the transaction list. This data structure is not &quot;space-consuming&quot;. None of the intermediate hashes are ever stored or transmitted. Nodes can quickly regenerate the tree from the list of transactions to verify that they result in the correct merkle root and vice versa, the merkle root is a sufficient commitment to prove the existence of a transaction per a <a href="https://bitcoin.stackexchange.com/a/69514/5406">merkle branch</a>.</p>
<p>While you note that the merkle tree allows for efficient proofs (which I'm sure users running thin clients on mobile devices appreciate), it also provides a structure to prove the presence of transactions in the blockchain in the first place! Without such a commitment structure, you might not have any proof that a transaction was included in the block, or perhaps needed to transfer the whole block every time to convince peers that a transaction exists.</p>
<p>The block header is covered by the proof-of-work—its eighty bytes must hash to a value that is less than the target (i.e. pass the difficulty requirement). Even if an SPV node only has the headers, it can easily verify that the block headers a) form a chain, and b) pass the difficulty requirement—by performing a single SHA-256d hash. On the other hand, producing a block header that passes the difficulty requirement currently requires about 130.5×10<sup>21</sup> hashes. So, the argument is a) a well-connected SPV client with multiple full node peers should eventually hear about the best chain, and b) it would be extremely expensive to produce a fake header that isn't trivially exposed.</p>
<p>A full node cannot provide an outright fake chain, because if any byte in the header were changed, the header's hash would no longer fulfill the difficulty requirement. Since it takes an immense amount of work to create a valid block header, it's impractical for any node to provide a &quot;fake header chain&quot;—the receiver just has to check that the new block ties to the predecessors and do a single hash to verify that the header doesn't pass the difficulty requirement. Giving unconnected blocks won't work because the thin client can merely go back and check whether they connect to the Genesis block. So, &quot;to fake a chain&quot; the attacker actually has to put in the work to find headers that passes this simplest scrutiny. This is generally too expensive unless the attacker can expect to make millions. But if millions are on the line, you'll probably be running a full node and do some additional due diligence anyway.</p>
<p>It follows that a node can only lie by omission to SPV client, by not telling it about the best chain or not telling it about transactions. That's why SPV clients connect to multiple nodes and ask each for their best header chain. Once the SPV client has all headers, the existence of transactions then can easily be shown via a merkle proofs. Or better yet, by more modern SPV clients download the headers and the compact client-side block filters for each block. The compact client-side block filters allow them to search whether a block contains anything of interest to them, and when they notice something relevant, they'll just get that one block and parse it themselves.</p>
<p>So, SPV clients are susceptible to not having all information. They could also fall for an invalid block with a header that passes the difficulty requirement, since they don't check the whole block, but such a block would be expensive to fake.</p>

CC BY-SA 4.0
2022-06-14T03:15:37.023Z
Thanks Murch, I think I need to clarify my question a bit. As the SPV connects to the full node, even the headers it got are from the full node, the full node can theoretically manipulate whatever it returns, including forging a whole valid chain headers. So my point is if a SPV connects to a full node, there's a assumption that the SPV trusts the full node, and if it trusts the full node, it needn't ask the full node for proof. Am I right?
cifer
CC BY-SA 4.0
2022-06-14T03:27:22.777Z
so I think the crux of the merkle proof scenerio is that the SPV client must have already had the root hash from a trusted party, then it gets proofs from the payer or other nodes. But seems few article mentions this point
cifer
CC BY-SA 4.0
2022-06-14T12:46:16.373Z
SPV nodes will connect to multiple full nodes and ask each for their best header chain. The previous block's hash and the Merkle root are part of the blockheader. The  proof-of-work protects the header from being changed. A full node cannot forge the chain without invalidating the headers, because changing any single byte in the headers will cause them not to pass the difficulty requirement.
Murch
CC BY-SA 4.0
2022-06-14T15:00:35.190Z
I've elaborated a bit how everything fits together.
Murch
CC BY-SA 4.0
2022-06-13T21:34:26.610Z
2022-06-14T15:00:20.500Z
2022-06-14T15:00:20.500Z
Murch
<p>I know exactly what merkle tree is, and I know it is used to verify a transaction is in a block with just a hundred of bytes flowing through my network cable (btw do I really lack that megabytes bandwidth?). I also know that a full node holds all block data, but a SPV client holds only the headers.</p>
<p>While all of the above couldn't convince me, why do we on earth need the space-consuming merkle tree structure, and the merkle proof authentication mechanism? Yes, the full node just needs to send a log<sub>2</sub>N path to the SPV client, thus saves a lot network traffic, the SPV client holds the header so it has the merkle root, then it verifies, done.</p>
<p>But, all of these are assuming that the full node is not faking. If it fakes, then all of this is meaningless, you may say the hash algorithm prevent the full node from faking, SPV client has the merkle root, it's impossible for the full node to forge the transaction. Okay, then, where did the SPV client's merkle root get from? Also the full node right?</p>
<p>If the full node fakes, how could we believe the proof it provides? Why does the SPV not just send the transaction hash to the full node and let the full node return a true/false?</p>

<security><transaction-verification><merkle-tree><trust>
The true reason bitcoin needs merkle proof for SPV wallet?
cifer
# The true reason bitcoin needs merkle proof for SPV wallet?

(Asked by: username_0 on 2022-06-13)

I know exactly what merkle tree is, and I know it is used to verify a transaction is in a block with just a hundred of bytes flowing through my network cable (btw do I really lack that megabytes bandwidth?). I also know that a full node holds all block data, but a SPV client holds only the headers.

While all of the above couldn't convince me, why do we on earth need the space-consuming merkle tree structure, and the merkle proof authentication mechanism? Yes, the full node just needs to send a log2N path to the SPV client, thus saves a lot network traffic, the SPV client holds the header so it has the merkle root, then it verifies, done.

But, all of these are assuming that the full node is not faking. If it fakes, then all of this is meaningless, you may say the hash algorithm prevent the full node from faking, SPV client has the merkle root, it's impossible for the full node to forge the transaction. Okay, then, where did the SPV client's merkle root get from? Also the full node right?

If the full node fakes, how could we believe the proof it provides? Why does the SPV not just send the transaction hash to the full node and let the full node return a true/false?

**Tags:** security, transaction-verification, merkle-tree, trust


---

## 1 answers

### Answer by username_1 on 2022-06-13. Score: 3

[![Bitcoin Block Data](https://i.sstatic.net/HrKX0.png)](https://i.sstatic.net/HrKX0.png)  
[[Illustration by Matthäus Wander (Wikimedia)]](https://i.sstatic.net/HrKX0.png)

The block header is an 80-byte data structure that has two elements relevant for this question. Firstly, the header commits to the previous block per the previous block's hash. These links form a chain ensuring that there can only be one block at each height and forcing a potential attacker to commit to a specific point at which their chaintip forks off from the best chain. Secondly, the header includes the merkle root of the transaction list. This data structure is not "space-consuming". None of the intermediate hashes are ever stored or transmitted. Nodes can quickly regenerate the tree from the list of transactions to verify that they result in the correct merkle root and vice versa, the merkle root is a sufficient commitment to prove the existence of a transaction per a [merkle branch](https://bitcoin.stackexchange.com/a/69514/5406).

While you note that the merkle tree allows for efficient proofs (which I'm sure users running thin clients on mobile devices appreciate), it also provides a structure to prove the presence of transactions in the blockchain in the first place! Without such a commitment structure, you might not have any proof that a transaction was included in the block, or perhaps needed to transfer the whole block every time to convince peers that a transaction exists.

The block header is covered by the proof-of-work—its eighty bytes must hash to a value that is less than the target (i.e. pass the difficulty requirement). Even if an SPV node only has the headers, it can easily verify that the block headers a) form a chain, and b) pass the difficulty requirement—by performing a single SHA-256d hash. On the other hand, producing a block header that passes the difficulty requirement currently requires about 130.5×1021 hashes. So, the argument is a) a well-connected SPV client with multiple full node peers should eventually hear about the best chain, and b) it would be extremely expensive to produce a fake header that isn't trivially exposed.

A full node cannot provide an outright fake chain, because if any byte in the header were changed, the header's hash would no longer fulfill the difficulty requirement. Since it takes an immense amount of work to create a valid block header, it's impractical for any node to provide a "fake header chain"—the receiver just has to check that the new block ties to the predecessors and do a single hash to verify that the header doesn't pass the difficulty requirement. Giving unconnected blocks won't work because the thin client can merely go back and check whether they connect to the Genesis block. So, "to fake a chain" the attacker actually has to put in the work to find headers that passes this simplest scrutiny. This is generally too expensive unless the attacker can expect to make millions. But if millions are on the line, you'll probably be running a full node and do some additional due diligence anyway.

It follows that a node can only lie by omission to SPV client, by not telling it about the best chain or not telling it about transactions. That's why SPV clients connect to multiple nodes and ask each for their best header chain. Once the SPV client has all headers, the existence of transactions then can easily be shown via a merkle proofs. Or better yet, by more modern SPV clients download the headers and the compact client-side block filters for each block. The compact client-side block filters allow them to search whether a block contains anything of interest to them, and when they notice something relevant, they'll just get that one block and parse it themselves.

So, SPV clients are susceptible to not having all information. They could also fall for an invalid block with a header that passes the difficulty requirement, since they don't check the whole block, but such a block would be expensive to fake.

> **Comments:**
> **username_0**: Thanks username_1, I think I need to clarify my question a bit. As the SPV connects to the full node, even the headers it got are from the full node, the full node can theoretically manipulate whatever it returns, including forging a whole valid chain headers. So my point is if a SPV connects to a full node, there's a assumption that the SPV trusts the full node, and if it trusts the full node, it needn't ask the full node for proof. Am I right?  
> **username_0**: so I think the crux of the merkle proof scenerio is that the SPV client must have already had the root hash from a trusted party, then it gets proofs from the payer or other nodes. But seems few article mentions this point  
> **username_1**: SPV nodes will connect to multiple full nodes and ask each for their best header chain. The previous block's hash and the Merkle root are part of the blockheader. The  proof-of-work protects the header from being changed. A full node cannot forge the chain without invalidating the headers, because changing any single byte in the headers will cause them not to pass the difficulty requirement.  
> **username_1**: I've elaborated a bit how everything fits together.  

---

