How do you know that Block, the Merket Root & the hashes in the path are authentic?

I went through this Q & A on Merkle Root What is the Merkle root?

And several others on the Merkle Root & the Merkle Tree. I understand what is a Merkle Tree & how you can take use your transaction hash & other hashes in the path to the root to verify if it's consistent.

However, you get the Merkle Root & all of all other path nodes from a node you don't essentially trust, right? So what's the point of this verification? The whole block itself or the Merkle Root or the path hashes may be fake. The only way this verification makes sense is if you already have a later block you trust & the previous hash from that points to this Merkle Root. However, this does not make sense to me - how will you trust that block in the first place?

What am I missing?

user93353

Posted 2017-01-06T11:28:23.567

Reputation: 91

Answers

Forget about the Merkle tree. Assume that instead, the block header would just contain a hash of the concatenation of all transactions.

A lightweight node could then download all headers, verify their proof of work, and make the assumption it has seen the longest chain. It is now convinced it has seen the chain the network accept. This is different from a full node, which does not assume a chain is accepted until it has seen all block data and verified every single transaction.

Now the lightweight client decides to ask peers for the actual block data. When it receives a blocks' transactions, it knows they actually match what the block header committed to, as it can recompute the hash, and compare it to the value in the header.

But what if the lightweight node is not interested in all transactions? BIP37 introduces the concept Bloom filtered blocks, where a lightweight node can reveal what keys/transactions/addresses it is interested in, and the full node it is downloading from will only give the transactions that match the filter.

Unfortunately, if the lightweight node does not download all transactions, there is no way to know whether they match the hash in the header, and as such, the full node could lie, and include transactions that are not actually present in the chain.

Enter the Merkle tree.

Instead of just storing a hash, we store the root of a Merkle tree. The full node can now for each matched transaction include the hash values that transaction's hash is combined with, to prove that the transaction is in fact included in the tree, despite the fact that the lightweight node only knows the root.

Pieter Wuille

Posted 2017-01-06T11:28:23.567

Reputation: 54 032

How does the node know that the header is authentic, the merkle root is authentic & the path transactions/hashes are authentic? – user93353 – 2017-01-07T11:37:25.690

1A lightweight node will always assume that the header chain with the most proof of work is the to be accepted one, it does not validate further (only full nodes do). So once it has the headers, which commit to the transactions, it can cheaply check whether the transactions it receives in fact do belong to the blocks whose headers it already has. The Merkle root does not in any way allow a node to quickly assess validity - it merely allows checking whether transactions belong to blocks for which it already has the headers. – Pieter Wuille – 2017-01-07T13:10:33.190

You only have to trust the genesis block. From there on, you have download all other blocks and verify them. This (among others) includes checking whether the proof of work done fulfills the requirements of the consensus rules.

However, you get the Merkle Root & all of all other path nodes from a node you don't essentially trust, right? So what's the point of this verification? The whole block itself or the Merkle Root or the path hashes may be fake.

A block contains transactions. You check all of these transactions, build the Merkle tree from them, and check whether your Merkle root is the same as the one in the header of the block you received.

UTF-8

Posted 2017-01-06T11:28:23.567

Reputation: 2 941

You only have to trust the genesis block. From there on, you have download all other blocks and verify them. Merkle Hash is used for SPV. I thought the whole point of SPV is that you don't have to download all blocks – user93353 – 2017-01-06T14:10:37.013

A block contains transactions. You check all of these transactions, build the Merkle tree from them, and check whether your Merkle root is the same as the one in the header of the block you received. You do not need to check all transactions to be verify the Merkle tree - that's the point of the Merkle tree. – user93353 – 2017-01-06T14:12:06.833

I didn't know your question is about SPV. Anyways, it goes like this: SPV means that no complete verification since the genesis block is done. Instead, individual transactions are verified at reduced security. For this, only the block containing the transaction is needed. It's not guaranteed that there is a chain from the genesis block to that block but it's very unlikely that someone made a valid block with a lot of work being done just to make that transaction appear in it. – UTF-8 – 2017-01-06T14:21:08.930

To verify the transaction hasn't just been put into the block, an SPV client still needs to verify the Merke root, then hash the block header, and check whether it's small enough. What you described to be the purpose of the Merkle tree, is not correct. The purpose of the Merkle tree is to generate a number of constant length in a way such that it's very hard to find a different list of transactions for which that number (the Merkle root) is the same. A block is only valid if all transactions in it are valid. However, the latter is not verified by SPV clients. – UTF-8 – 2017-01-06T14:25:40.317

To verify the transaction hasn't just been put into the block, an SPV client still needs to verify the Merke root, then hash the block header, and check whether it's small enough - small enough? That makes no sense – user93353 – 2017-01-06T14:47:30.100

The purpose of the Merkle tree is to generate a number of constant length in a way such that it's very hard to find a different list of transactions for which that number (the Merkle root) is the same. - if that were the purpose, then concatenating all the transactions & finding the hash of that would be enough - no need to do the merkle tree – user93353 – 2017-01-06T14:48:21.170

"small enough? That makes no sense" Yes, it does. Please look up what miners try to achieve: They try to find a block whose hash is smaller than a given value. That value is determined every 2016 blocks (a difficulty period). – UTF-8 – 2017-01-06T15:06:05.963

There are various advantages of using a Merkle tree. Because going into the specifics of the vulnerabilities of hash functions and why it makes sense because of that would take way too long, I'll provide you this rather simple reason (and partly because it's about SPV clients): If a SPV client wants to verify a transaction, it only needs the Merkle branch of that transaction, not the entire block. This means the storage space needed and work do be done by a SPV client is much smaller, this way. – UTF-8 – 2017-01-06T15:07:43.173

I added another answer that explains the questions in comments a bit less briefly. – Pieter Wuille – 2017-01-06T15:15:32.970