<p>A Merkle tree is calculated by concatenating the two children of a node and hashing the result. We repeat this on each pair of nodes on the same level until we are left with a single node that we call the Merkle Root.</p>
<p><a href="https://i.sstatic.net/345ZR.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/345ZR.png" alt="A merkle tree with four leaves detailing how each branch is combined to reach the root" /></a><br />
<sup>via <a href="https://github.com/bitcoinbook/bitcoinbook/blob/14a25a6fd9e97002c57a46f1fe9faf48cd5d6e46/ch07.asciidoc#merkle-trees" rel="nofollow noreferrer">Mastering Bitcoin Ch7</a></sup></p>
<p>As seen in our example Merkle tree with four transactions <code>{Tx A, Tx B, Tx C, Tx D}</code>, e.g. the right node on the second level H<sub>CD</sub> is calculated by concatenating H<sub>C</sub> and H<sub>D</sub> and hashing that (although the graphic uses a plus to express the concatenation):</p>
<blockquote>
<p>H<sub>CD</sub> = Hash(H<sub>C</sub> || H<sub>D</sub>)</p>
</blockquote>
<p>The coinbase transaction is required to be the first transaction in a block. In this example, <code>Tx A</code> is our coinbase transaction. The other transactions <code>{Tx B, Tx C, Tx D}</code> would have been picked by the mining pool leaving the miner only the ability to change <code>Tx A</code>. To calculate a valid Merkle root, the miner only needs to recalculate the left flank of the tree. They need to be informed about H<sub>B</sub> in order to calculate H<sub>AB</sub> and informed about H<sub>CD</sub> in order to calculate the Merkle root H<sub>ABCD</sub>. This allows the mining pool to communicate the remaining content of the block in compressed form by only providing <em>log(n)</em> hashing partners instead of the whole remaining list of <em>n-1</em> transactions in the block template. Granted, the mining pool could have picked an invalid set of transactions and the miner would be unable to catch that. However, that would be against the interest of the mining pool as the work of the miner would be useless.</p>
<p>It is therefore perfectly fine for the miner to pick the coinbase transaction last and recalculate only the left flank of the Merkle tree. In fact, there is another reason why the coinbase transaction <em>must</em> be picked after all other transactions in the template. If there is at least one segwit transaction included in the block, the coinbase transaction must include a <em>witness commitment</em> as a nulldata output (or OP_RETURN output). This output stores the Merkle root of the witness txids of all transactions in the block (with a placeholder for the coinbase transaction as it cannot know its own witness txid to commit to itself in its own output). This commitment can only be calculated after all other transactions have been picked. Therefore, it is not just possible, but always required that the coinbase transaction be picked last when constructing a block template.</p>

CC BY-SA 4.0
2022-12-31T18:32:32.367Z
thank you very much. It actually make sense now.
chronus
CC BY-SA 4.0
2022-12-30T17:16:02.683Z
2022-12-30T18:51:45.420Z
2022-12-30T18:51:45.420Z
Murch
<p>I'm a beginner is this field. Can someone explain to me how mining pool provided merkle branches are valid?
Normally, when we make the root, it starts from top to bottom, a single change in order can lead to a different hash.</p>
<p>But in pools miner get merkle branches, with coinbasetx left for the miner to tweak.
Is this process correct?
Usually coinbasetx should be calculated first, shouldn't this lead to different root, or may be I'm wrong, can someone explain?</p>

<mining-pools><mining-theory><merkle-tree>
Are pool provided merkle branches trustable?
chronus
# Are pool provided merkle branches trustable?

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

I'm a beginner is this field. Can someone explain to me how mining pool provided merkle branches are valid?
Normally, when we make the root, it starts from top to bottom, a single change in order can lead to a different hash.

But in pools miner get merkle branches, with coinbasetx left for the miner to tweak.
Is this process correct?
Usually coinbasetx should be calculated first, shouldn't this lead to different root, or may be I'm wrong, can someone explain?

**Tags:** mining-pools, mining-theory, merkle-tree


---

## 1 answers

### Answer by username_1 on 2022-12-30. Score: 2 | Accepted answer

A Merkle tree is calculated by concatenating the two children of a node and hashing the result. We repeat this on each pair of nodes on the same level until we are left with a single node that we call the Merkle Root.

[![A merkle tree with four leaves detailing how each branch is combined to reach the root](https://i.sstatic.net/345ZR.png)](https://i.sstatic.net/345ZR.png)  
via [Mastering Bitcoin Ch7](https://github.com/bitcoinbook/bitcoinbook/blob/14a25a6fd9e97002c57a46f1fe9faf48cd5d6e46/ch07.asciidoc#merkle-trees)

As seen in our example Merkle tree with four transactions `{Tx A, Tx B, Tx C, Tx D}`, e.g. the right node on the second level HCD is calculated by concatenating HC and HD and hashing that (although the graphic uses a plus to express the concatenation):

> HCD = Hash(HC || HD)

The coinbase transaction is required to be the first transaction in a block. In this example, `Tx A` is our coinbase transaction. The other transactions `{Tx B, Tx C, Tx D}` would have been picked by the mining pool leaving the miner only the ability to change `Tx A`. To calculate a valid Merkle root, the miner only needs to recalculate the left flank of the tree. They need to be informed about HB in order to calculate HAB and informed about HCD in order to calculate the Merkle root HABCD. This allows the mining pool to communicate the remaining content of the block in compressed form by only providing *log(n)* hashing partners instead of the whole remaining list of *n-1* transactions in the block template. Granted, the mining pool could have picked an invalid set of transactions and the miner would be unable to catch that. However, that would be against the interest of the mining pool as the work of the miner would be useless.

It is therefore perfectly fine for the miner to pick the coinbase transaction last and recalculate only the left flank of the Merkle tree. In fact, there is another reason why the coinbase transaction *must* be picked after all other transactions in the template. If there is at least one segwit transaction included in the block, the coinbase transaction must include a *witness commitment* as a nulldata output (or OP\_RETURN output). This output stores the Merkle root of the witness txids of all transactions in the block (with a placeholder for the coinbase transaction as it cannot know its own witness txid to commit to itself in its own output). This commitment can only be calculated after all other transactions have been picked. Therefore, it is not just possible, but always required that the coinbase transaction be picked last when constructing a block template.

> **Comments:**
> **username_0**: thank you very much. It actually make sense now.  

---

