<p>To verify the auxiliary chain, you need to prove that a certain amount of work has been done upon the latest block in that auxiliary chain. As with any form of mining, this involves computing a hash to be below a threshold.</p>

<p>However, it doesn't matter that the pre-image of the hash has a lot of other irrelevant data in it too, so long as it contains the relevant auxiliary-block header in there somewhere. I.e. from a proof-of-work perspective it makes no difference if you calculate this:</p>

<pre><code>while(h &gt; aux-threshold) {
    h = hash(aux-header + nonce)
    nonce++
}
result = nonce    
</code></pre>

<p>versus this:</p>

<pre><code>container = hash(hash(aux-header) + other-data)
while(h &gt; aux-threshold) {
    h = hash(container + nonce)
    nonce++
}
result = nonce
</code></pre>

<p>Both will take the same amount of work and both will prove that the work has been done on <code>aux-header</code>. This is so because <code>container</code> can be proven to contain the aux-header, and since <code>aux-header</code> and <code>other-data</code> are stored in the aux-chain block and the hash can be re-computed at any time.</p>

<p>So, for merged mining, <code>container</code> is actually the hashed header of the parent-chain block and <code>aux-header</code> just needs to be included in the parent block somewhere. It really could be included anywhere so long as the parent block passes the verification process. For example, you could include the aux-chain-header-hash as an address in a multisig transaction, or as a piece of data that gets placed on the stack but never popped off in one of the transactions. Yet, the easiest place to put it is in the txin script of the coinbase transaction. This always contains arbitrary data anyway, and its location at the top of the chain means that <code>other-data</code> can contain the smallest number of merkle branches.</p>

CC BY-SA 3.0
2016-01-23T03:24:59.237Z
why the downvote mystery downvoter?
mulllhausen
CC BY-SA 3.0
2016-01-24T13:41:13.410Z
Please consider using proper capitalization, it makes longer texts much easier to read because sentence beginnings are more visible.
Murch
CC BY-SA 3.0
2015-03-24T02:16:08.660Z
2016-01-24T13:30:38.643Z
2016-01-24T13:30:38.643Z
mulllhausen
<p>You verify the auxiliary chain precisely the same way, except you must also check that the auxiliary chain's header is properly included in the parent's coinbase. From the point of view of the auxiliary chain, you can think of the entire primary chain header as part of a giant nonce.</p>

CC BY-SA 3.0
2015-03-24T01:35:31.670Z
i think its not so useful to think of the primary-chain-header-hash as part of a nonce, since the primary-chain-header-hash must be below the aux-chain threshold, whereas nonces don't have this property of needing to be below a threshold.
mulllhausen
CC BY-SA 3.0
2015-03-24T05:21:11.823Z
@mulllhausen If you define nonce as "value the chain doesn't care about that get hashed to produce a value that must be below the target" then it makes sense to think about all the primary chain stuff as part of the nonce on the auxiliary chain.
David Schwartz
CC BY-SA 3.0
2015-03-25T11:36:41.167Z
but we do care about some of the values in the primary header - for example a correct merkle root is a requirement. i agree that parts of the primary header are equivalent to a nonce - just not the whole thing.
mulllhausen
CC BY-SA 3.0
2015-03-23T15:43:29.343Z
2015-03-24T00:59:38.010Z
2015-03-24T00:59:38.010Z
David Schwartz
<p>When mining Bitcoin, the nonce is included in the header, which is then hashed and checked to see if it is below the target threshold.<br>
Everybody can verify that the header does indeed hash below the threshold. However, in merged mining, <a href="https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase" rel="nofollow">according to the wiki</a>, the hash of the auxiliary chain's header is included in the parent's coinbase txin script without the opportunity to change the nonce in the auxiliary chain. The parent's nonce is incremented as usual but the aux hash remains the same.</p>

<p>How can we then verify the auxiliary chain?</p>

<p>is it because the parent nonce makes its way into the auxiliary chain through the parent header's hash? even so it seems that this would not help for verification because the aux chain's hash no longer need meet any threshold criteria.</p>

<altcoin><merged-mining><block-header>
Nonce in Merged Mining
mulllhausen
# Nonce in Merged Mining

(Asked by: username_0 on 2015-03-23)

When mining Bitcoin, the nonce is included in the header, which is then hashed and checked to see if it is below the target threshold.  
Everybody can verify that the header does indeed hash below the threshold. However, in merged mining, [according to the wiki](https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase), the hash of the auxiliary chain's header is included in the parent's coinbase txin script without the opportunity to change the nonce in the auxiliary chain. The parent's nonce is incremented as usual but the aux hash remains the same.

How can we then verify the auxiliary chain?

is it because the parent nonce makes its way into the auxiliary chain through the parent header's hash? even so it seems that this would not help for verification because the aux chain's hash no longer need meet any threshold criteria.

**Tags:** altcoin, merged-mining, block-header


---

## 2 answers

### Answer by username_0 on 2015-03-24. Score: 3

To verify the auxiliary chain, you need to prove that a certain amount of work has been done upon the latest block in that auxiliary chain. As with any form of mining, this involves computing a hash to be below a threshold.

However, it doesn't matter that the pre-image of the hash has a lot of other irrelevant data in it too, so long as it contains the relevant auxiliary-block header in there somewhere. I.e. from a proof-of-work perspective it makes no difference if you calculate this:

```
while(h > aux-threshold) {
    h = hash(aux-header + nonce)
    nonce++
}
result = nonce    

```

versus this:

```
container = hash(hash(aux-header) + other-data)
while(h > aux-threshold) {
    h = hash(container + nonce)
    nonce++
}
result = nonce

```

Both will take the same amount of work and both will prove that the work has been done on `aux-header`. This is so because `container` can be proven to contain the aux-header, and since `aux-header` and `other-data` are stored in the aux-chain block and the hash can be re-computed at any time.

So, for merged mining, `container` is actually the hashed header of the parent-chain block and `aux-header` just needs to be included in the parent block somewhere. It really could be included anywhere so long as the parent block passes the verification process. For example, you could include the aux-chain-header-hash as an address in a multisig transaction, or as a piece of data that gets placed on the stack but never popped off in one of the transactions. Yet, the easiest place to put it is in the txin script of the coinbase transaction. This always contains arbitrary data anyway, and its location at the top of the chain means that `other-data` can contain the smallest number of merkle branches.

> **Comments:**
> **username_0**: why the downvote mystery downvoter?  
> **username_1**: Please consider using proper capitalization, it makes longer texts much easier to read because sentence beginnings are more visible.  

---

### Answer by username_2 on 2015-03-23. Score: 2

You verify the auxiliary chain precisely the same way, except you must also check that the auxiliary chain's header is properly included in the parent's coinbase. From the point of view of the auxiliary chain, you can think of the entire primary chain header as part of a giant nonce.

> **Comments:**
> **username_0**: i think its not so useful to think of the primary-chain-header-hash as part of a nonce, since the primary-chain-header-hash must be below the aux-chain threshold, whereas nonces don't have this property of needing to be below a threshold.  
> **username_2**: @username_0 If you define nonce as "value the chain doesn't care about that get hashed to produce a value that must be below the target" then it makes sense to think about all the primary chain stuff as part of the nonce on the auxiliary chain.  
> **username_0**: but we do care about some of the values in the primary header - for example a correct merkle root is a requirement. i agree that parts of the primary header are equivalent to a nonce - just not the whole thing.  

---

