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?
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.