<p>The mempool and the Merkle root have nothing to do with one another.</p>
<p>Blocks consist of a set of transactions chosen by the miner (probably from <em>their</em> mempool, but it doesn't really matter - the composition of blocks is miners' perogative). That block consists of a list of transactions, and a block header that contains among other things a Merkle root committing to <em>those</em> transactions.</p>
<p>When blocks get propagated, nodes verify <em>its</em> Merkle root against <em>its</em> set of transactions. The receiver's mempool is entirely irrelevant in this process of deciding whether or not the received block is valid. Once a new block is accepted, transactions in the receiver's mempool which were included in the block (or conflict with transactions in the block) are removed.</p>
<p>Now, some block relay protocols (notably, BIP152 &quot;compact blocks&quot;) take advance of the fact that receivers typically have most if not all transactions in a block already. BIP152 in particular just sends a short hash of each block transaction rather than the full contents immediately, letting the receiver request missing transactions if any. But none of this has anything to do with the block's Merkle root - that's an aspect of <em>validating</em> the block once it is received (and reconstructed). Compact blocks is a means of <em>transmitting</em> the block before validation happens.</p>

CC BY-SA 4.0
2022-12-11T03:38:46.450Z
2022-12-11T03:38:46.450Z
Pieter Wuille
<p>Before compact blocks (<a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a>), a new block received by a node would contain all its transactions in full. Validating the merkle root in the block header would then not involve the node's mempool at all, it would simply build a merkle tree from the received transactions and verify the merkle roots match. Of course, this meant that (nearly) all transactions were relayed over the network twice, with large bandwith spikes on each new block.</p>
<p>Since the introduction of compact blocks, your node instead only receives a list of short transaction IDs and a few transactions the peer thinks you might not have (most notably the coinbase transaction), looks up these transactions in its mempool, optionally asks the peer for any missing transactions, and then it can verify the merkle root as before.</p>

CC BY-SA 4.0
2022-12-11T02:14:01.337Z
Ah I see, so the node first checks for its mempool transactions, sends its mempool to peers to check if they are missing transactions and then calculates the merkle root with the rest of the transactions. Thank you!
CJ-Programmer
CC BY-SA 4.0
2022-12-11T02:16:21.157Z
One more thing, when a miner is choosing what transactions to use in its block, does they send those transactions to the node, who then validate if they correspond with their full list of transactions and then calculate the merkle root?
CJ-Programmer
CC BY-SA 4.0
2022-12-11T14:42:31.210Z
Not exactly sure what you mean by "sends its mempool to peers". The receiving node only asks its peer for transactions whose IDs were in the compact block but which weren't in its mempool.
Vojtěch Strnad
CC BY-SA 4.0
2022-12-11T14:48:00.757Z
For the miner question, you might benefit from reading the answers to [What exactly is Mining?](https://bitcoin.stackexchange.com/q/148/121614).
Vojtěch Strnad
CC BY-SA 4.0
2022-12-11T01:01:31.820Z
2022-12-11T01:01:31.820Z
Vojtěch Strnad
<p>How is the merkle root verified if the mempools are different? I already understand how its calculated. If a node has a mempool of transactions, and a miner has only some of those transactions and maybe some different ones, how can the node verify that the hash of the miners block which includes all the parameters and the merkle root is correct. As I understand, in order for a node to verify a block, they must first verify the validity of the paramaters in the block header. Thanks in advance!</p>

<full-node><mempool><merkle-tree>
How is the merkle root verified if the mempools may be different?
CJ-Programmer
# How is the merkle root verified if the mempools may be different?

(Asked by: username_0 on 2022-12-11)

How is the merkle root verified if the mempools are different? I already understand how its calculated. If a node has a mempool of transactions, and a miner has only some of those transactions and maybe some different ones, how can the node verify that the hash of the miners block which includes all the parameters and the merkle root is correct. As I understand, in order for a node to verify a block, they must first verify the validity of the paramaters in the block header. Thanks in advance!

**Tags:** full-node, mempool, merkle-tree


---

## 2 answers

### Answer by username_1 on 2022-12-11. Score: 3

The mempool and the Merkle root have nothing to do with one another.

Blocks consist of a set of transactions chosen by the miner (probably from *their* mempool, but it doesn't really matter - the composition of blocks is miners' perogative). That block consists of a list of transactions, and a block header that contains among other things a Merkle root committing to *those* transactions.

When blocks get propagated, nodes verify *its* Merkle root against *its* set of transactions. The receiver's mempool is entirely irrelevant in this process of deciding whether or not the received block is valid. Once a new block is accepted, transactions in the receiver's mempool which were included in the block (or conflict with transactions in the block) are removed.

Now, some block relay protocols (notably, BIP152 "compact blocks") take advance of the fact that receivers typically have most if not all transactions in a block already. BIP152 in particular just sends a short hash of each block transaction rather than the full contents immediately, letting the receiver request missing transactions if any. But none of this has anything to do with the block's Merkle root - that's an aspect of *validating* the block once it is received (and reconstructed). Compact blocks is a means of *transmitting* the block before validation happens.


---

### Answer by username_2 on 2022-12-11. Score: 2

Before compact blocks ([BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)), a new block received by a node would contain all its transactions in full. Validating the merkle root in the block header would then not involve the node's mempool at all, it would simply build a merkle tree from the received transactions and verify the merkle roots match. Of course, this meant that (nearly) all transactions were relayed over the network twice, with large bandwith spikes on each new block.

Since the introduction of compact blocks, your node instead only receives a list of short transaction IDs and a few transactions the peer thinks you might not have (most notably the coinbase transaction), looks up these transactions in its mempool, optionally asks the peer for any missing transactions, and then it can verify the merkle root as before.

> **Comments:**
> **username_0**: Ah I see, so the node first checks for its mempool transactions, sends its mempool to peers to check if they are missing transactions and then calculates the merkle root with the rest of the transactions. Thank you!  
> **username_0**: One more thing, when a miner is choosing what transactions to use in its block, does they send those transactions to the node, who then validate if they correspond with their full list of transactions and then calculate the merkle root?  
> **username_2**: Not exactly sure what you mean by "sends its mempool to peers". The receiving node only asks its peer for transactions whose IDs were in the compact block but which weren't in its mempool.  
> **username_2**: For the miner question, you might benefit from reading the answers to [What exactly is Mining?](https://bitcoin.stackexchange.com/q/148/121614).  

---

