<p>Bitcoin Core, in its BIP37 implementation, will compute the Merkle proofs on the fly. It does not store the blocks' Merkle trees anywhere (only its root is stored).</p>

CC BY-SA 4.0
2020-10-09T05:10:50.010Z
Thank you Pieter. I wanna add someting. merkle roots are used to reduce operations from n to logn . Looks like for full node, operation count is still n. it gets reduced to logn for light nodes since full node only sends a path of merkle tree instead of the whole merkle tree. do you agree to all i've just said ?
Nika Kurashvili
CC BY-SA 4.0
2020-10-09T17:01:38.643Z
any comments about my last reply ? Thanks in advance.
Nika Kurashvili
CC BY-SA 4.0
2020-10-09T17:08:05.323Z
@Nika That's correct, though it's really the only option. BIP37 uses Bloom filters to select which transactions are interesting, which isn't something we can build an index for fast lookup for. As a result, the node answering must go through the entire block anyway to determine even which transactions are interesting to the client. Building the Merkle tree and responding with the paths of matching transaction is a minor cost compared to that.
Pieter Wuille
CC BY-SA 4.0
2020-10-09T02:00:17.963Z
2020-10-09T02:00:17.963Z
Pieter Wuille
<p>I understand what the merkle root is for. And I understand that blocks don't store the merkle tree.</p>
<p><strong>Question 1)</strong> Is there any place that the complete merkle trees get stored? I don't mean the merkle root hashes since I know they are in the block headers.</p>
<p><strong>Question 2)</strong> Let's say a full node starts proving to a light node that a specific transaction is in Block J. How does the full node send the merkle branch to the light node? Does it loop through the transactions again to get the hashes and then sends the interior node hashes of transactions, or do full nodes already have the complete merkle tree (whole tree and each internal hash) stored somewhere?</p>

<bitcoin-core><transaction-verification><merkle-tree><thin-clients><merkleblock>
Do full nodes store the complete merkle tree or do they regenerate it when creating a merkle proof?
Nika Kurashvili
# Do full nodes store the complete merkle tree or do they regenerate it when creating a merkle proof?

(Asked by: username_0 on 2020-10-08)

I understand what the merkle root is for. And I understand that blocks don't store the merkle tree.

**Question 1)** Is there any place that the complete merkle trees get stored? I don't mean the merkle root hashes since I know they are in the block headers.

**Question 2)** Let's say a full node starts proving to a light node that a specific transaction is in Block J. How does the full node send the merkle branch to the light node? Does it loop through the transactions again to get the hashes and then sends the interior node hashes of transactions, or do full nodes already have the complete merkle tree (whole tree and each internal hash) stored somewhere?

**Tags:** bitcoin-core, transaction-verification, merkle-tree, thin-clients, merkleblock


---

## 1 answers

### Answer by username_1 on 2020-10-09. Score: 3 | Accepted answer

Bitcoin Core, in its BIP37 implementation, will compute the Merkle proofs on the fly. It does not store the blocks' Merkle trees anywhere (only its root is stored).

> **Comments:**
> **username_0**: Thank you username_1. I wanna add someting. merkle roots are used to reduce operations from n to logn . Looks like for full node, operation count is still n. it gets reduced to logn for light nodes since full node only sends a path of merkle tree instead of the whole merkle tree. do you agree to all i've just said ?  
> **username_0**: any comments about my last reply ? Thanks in advance.  
> **username_1**: @username_0 That's correct, though it's really the only option. BIP37 uses Bloom filters to select which transactions are interesting, which isn't something we can build an index for fast lookup for. As a result, the node answering must go through the entire block anyway to determine even which transactions are interesting to the client. Building the Merkle tree and responding with the paths of matching transaction is a minor cost compared to that.  

---

