3

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?

4

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.

  • How does the node know that the header is authentic, the merkle root is authentic & the path transactions/hashes are authentic? – user93353 Jan 7 '17 at 11:37
  • 1
    A 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 Jan 7 '17 at 13:10
0

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.

  • 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 Jan 6 '17 at 14:10
  • 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 Jan 6 '17 at 14:12
  • 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 Jan 6 '17 at 14:21
  • 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 Jan 6 '17 at 14:25
  • 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 Jan 6 '17 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.