In bitcoin, miners hash the header twice with the SHA256 function. This header consists of the fields listed below, as described by this question.

  • version
  • previousHashBlock
  • merkleRoot
  • time
  • difficulty
  • nonce

This header data only applies to one chain. I don't get how we can mine on two different chains, as their merkleRoot and their previousHashBlock are totally different? We obviously can't have the same transactions on both merkle trees since we are talking about two different cryptocurrency chains with different transactions. So how do some pools manage to do that?

The question "How does merged mining work?" explains the broad concept of merged mining, but I'm looking for specific technical details. A byte-by-byte description of how merged mining works would be very helpful.

There's actually a very good detailed specification on the bitcoin.it site.

Essentially, what it comes down to is that there's some data inserted into the coinbase transaction of the parent chain. So, assuming, for example, that Bitcoin is the parent chain and Namecoin the child chain, anyone merge-mining would be using a coinbase transaction in Bitcoin that has a particular script that looks like this:

  • 4 bytes magic (0xfa, 0xbe)
  • 32 bytes hash of auxPOW header
  • 4 bytes merkle size
  • 4 bytes merkle nonce

For now, note that the 32 byte hash of the auxPOW header is the important thing. We'll get to explaining what that is later.

The actual block submitted to Namecoin is actually slightly different. It has a few extra fields like:

  • Bitcoin's coinbase txn
  • merkle branch (essentially an SPV proof) of the coinbase txn being in Bitcoin's block
  • Namecoin's previous block hash

This block is called the AuxPOW block and is actually what gets submitted to the Namecoin block chain. Now, what's to stop anyone finding a block on Bitcoin and submitting the block to Namecoin by adding this extra data? This is where the hash of the AuxPOW in the coinbase transaction of Bitcoin is important.

The AuxPOW hash can be computed ahead of time and must be included in the coinbase transaction of Bitcoin in order for Namecoin to accept it. Thus, anyone merge-mining must be aware of the Namecoin blockchain as they're looking for Bitcoin blocks. Otherwise, Namecoin doesn't accept blocks that just have data added afterwards. The Proof-of-work on Bitcoin already has previous Namecoin block information in the coinbase transaction, tying the two chains together.

merkle size and merkle nonce are 1 and 0 if you're merge mining only 1 other chain. These two variables were set up so that you could merge-mine more than 1 other child blockchain, but it's actually broken. There's a workaround described here.

  • It takes 44 bytes of data of the coinbase' input script, which is limited to 100 bytes. So at most you can only merged mine 2 coins with Bitcoin? OP_RETUN could be used for more, theoretically, even though standardness currently limits it to 40 bytes (Miners can disregard this fact in their coinbase transaction). – StephenM347 Feb 3 '15 at 13:51
  • Could you explain in more detail what the merkle size and merkle nonce are, and why they have to be included in the coinbase's scriptSig? – StephenM347 Feb 3 '15 at 13:54
  • I've added another paragraph to address both concerns, essentially. It doesn't help much due to the fact that it's actually a bit broken. – Jimmy Song Feb 3 '15 at 14:06
  • Also there are other coins being merged mined at the moment as child's of namecoin. – a supporter Mar 5 '15 at 19:12

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.