<p>I discovered the answer in a blog:</p>
<blockquote>
<p>it is necessary to make sure that a miner cannot mine on different
branches of the same child blockchain, as this conflicts with the
rules of the underlying Nakamoto consensus mechanism and would make
double spending attacks possible. Hence, each cryptocurrency must
specify a unique ID, which can be used to derive the leaf of the
Merkle tree where the respective block hash must be located.</p>
</blockquote>
<p>Source: <a href="https://alexeizamyatin.medium.com/a-technical-deep-dive-into-merged-mining-5b67706e1a19" rel="nofollow noreferrer">https://alexeizamyatin.medium.com/a-technical-deep-dive-into-merged-mining-5b67706e1a19</a></p>

CC BY-SA 4.0
2021-03-04T19:22:24.147Z
2021-03-04T19:22:24.147Z
Brannon
<p>I'm considering adding merge mining support to coin x. Its parent chain will be coin b. In looking at the spec (<a href="https://en.bitcoin.it/wiki/Merged_mining_specification" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Merged_mining_specification</a>) and Dogecoin/Namecoin sources, I see that there is support for multiple merge-mined coins in a single coinbase payload. That's fine. I also see that I'm given a Merkle tree so that I can verify that my coin x's header's hash was in b's block. That's fine. Given that, what I don't understand is why I would care about x's slot in the Merkle tree in the specific case where multiple coins are being merge-mined. Why would I need to specify a chain_id? Why would I care if my data came back in a different slot than what I requested? Why even request a specific slot? In the Dogecoin codebase it verifies via getExpectedIndex (see <a href="https://github.com/dogecoin/dogecoin/blob/0b46a40ed125d7bf4b5a485b91350bc8bdc48fc8/src/auxpow.cpp#L153" rel="nofollow noreferrer">https://github.com/dogecoin/dogecoin/blob/0b46a40ed125d7bf4b5a485b91350bc8bdc48fc8/src/auxpow.cpp#L153</a> ). How does that add to the security of this? Why not let the block creator put the merge-mined coins into a Merkle tree however it sees fit?</p>

<merged-mining>
what's the purpose of the chain_id in merge mining?
Brannon
# what's the purpose of the chain_id in merge mining?

(Asked by: username_0 on 2021-03-04)

I'm considering adding merge mining support to coin x. Its parent chain will be coin b. In looking at the spec (<https://en.bitcoin.it/wiki/Merged_mining_specification>) and Dogecoin/Namecoin sources, I see that there is support for multiple merge-mined coins in a single coinbase payload. That's fine. I also see that I'm given a Merkle tree so that I can verify that my coin x's header's hash was in b's block. That's fine. Given that, what I don't understand is why I would care about x's slot in the Merkle tree in the specific case where multiple coins are being merge-mined. Why would I need to specify a chain\_id? Why would I care if my data came back in a different slot than what I requested? Why even request a specific slot? In the Dogecoin codebase it verifies via getExpectedIndex (see <https://github.com/dogecoin/dogecoin/blob/0b46a40ed125d7bf4b5a485b91350bc8bdc48fc8/src/auxpow.cpp#L153> ). How does that add to the security of this? Why not let the block creator put the merge-mined coins into a Merkle tree however it sees fit?

**Tags:** merged-mining


---

## 1 answers

### Answer by username_0 on 2021-03-04. Score: 0 | Accepted answer

I discovered the answer in a blog:

> it is necessary to make sure that a miner cannot mine on different
> branches of the same child blockchain, as this conflicts with the
> rules of the underlying Nakamoto consensus mechanism and would make
> double spending attacks possible. Hence, each cryptocurrency must
> specify a unique ID, which can be used to derive the leaf of the
> Merkle tree where the respective block hash must be located.

Source: <https://alexeizamyatin.medium.com/a-technical-deep-dive-into-merged-mining-5b67706e1a19>


---

