<p>There's actually a very good detailed specification on the <a href="https://en.bitcoin.it/wiki/Merged_mining_specification" rel="nofollow">bitcoin.it site</a>.</p>

<p>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:</p>

<ul>
<li>4 bytes magic (0xfa, 0xbe)</li>
<li>32 bytes hash of auxPOW header</li>
<li>4 bytes merkle size</li>
<li>4 bytes merkle nonce</li>
</ul>

<p>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.</p>

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

<ul>
<li>Bitcoin's coinbase txn</li>
<li>merkle branch (essentially an SPV proof) of the coinbase txn being in Bitcoin's block</li>
<li>Namecoin's previous block hash</li>
</ul>

<p>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.</p>

<p>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.</p>

<p>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 <a href="https://en.bitcoin.it/wiki/Merged_mining_specification#Aux_work_merkle_tree" rel="nofollow">here</a>.</p>

CC BY-SA 3.0
2015-02-03T13:51:50.823Z
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).
morsecoder
CC BY-SA 3.0
2015-02-03T13:54:47.173Z
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?
morsecoder
CC BY-SA 3.0
2015-02-03T14:06:48.683Z
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
CC BY-SA 3.0
2015-03-05T19:12:26.560Z
Also there are other coins being merged mined at the moment as child's of namecoin.
a supporter
CC BY-SA 3.0
2015-02-03T02:17:29.350Z
2015-02-03T14:06:17.373Z
2015-02-03T14:06:17.373Z
Jimmy Song
<p>In bitcoin, miners hash the header twice with the SHA256 function. This header consists of the fields listed below, as described by <a href="https://bitcoin.stackexchange.com/questions/35699/what-is-a-block/35700#35700">this question</a>. </p>

<ul>
<li><code>version</code></li>
<li><code>previousHashBlock</code></li>
<li><code>merkleRoot</code></li>
<li><code>time</code></li>
<li><code>difficulty</code></li>
<li><code>nonce</code></li>
</ul>

<p>This header data only applies to one chain. I don't get how we can mine on two different chains, as their <code>merkleRoot</code> and their <code>previousHashBlock</code> 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?</p>

<p>The question <a href="https://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work">"How does merged mining work?"</a> 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. </p>

<blockchain><block><merged-mining>
How does merged mining work on a technical level?
abeikverdi
# How does merged mining work on a technical level?

(Asked by: username_0 on 2015-02-02)

In bitcoin, miners hash the header twice with the SHA256 function. This header consists of the fields listed below, as described by [this question](https://bitcoin.stackexchange.com/questions/35699/what-is-a-block/35700#35700).

* `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?"](https://bitcoin.stackexchange.com/questions/273/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.

**Tags:** blockchain, block, merged-mining


---

## 1 answers

### Answer by username_1 on 2015-02-03. Score: 6

There's actually a very good detailed specification on the [bitcoin.it site](https://en.bitcoin.it/wiki/Merged_mining_specification).

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](https://en.bitcoin.it/wiki/Merged_mining_specification#Aux_work_merkle_tree).

> **Comments:**
> **username_2**: 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).  
> **username_2**: 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?  
> **username_1**: 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.  
> **username_3**: Also there are other coins being merged mined at the moment as child's of namecoin.  

---

