<p>Basically the idea is that you assemble a Namecoin block and hash it, and then insert that hash into a Bitcoin block.  Now when you solve the Bitcoin block at a difficulty level greater to or equal to the Namecoin difficulty level, it will be proof that that amount of work has been done for the Namecoin block.   The Namecoin protocol has been altered to accept a Bitcoin block (solved at or above the Namecoin difficulty level) containing a hash of a Namecoin block as proof of work for the Namecoin block.  The Bitcoin block will only be acceptable to the Bitcoin network if it is at the difficulty of the Bitcoin network.</p>

<p>The Bitcoin block chain gets a single extra hash when a merged mining block is accepted, and the Namecoin block chain gets a little bit more (because it includes the Bitcoin block) when a merged mining block is accepted. However, because of the Merkle Tree, the entire Bitcoin block doesn’t need to be included in the Namecoin tree, just the top level hashes (so the extra bloat to the Namecoin chain is not a big problem).</p>

<p>Since you make more money mining both Namecoins and Bitcoins miners will eventually all do merged mining, and the difficulty level for all block chains will eventually be the same.</p>

<p>Furthermore, the economic incentive to mine will be the combined economic incentive of all networks, making all networks more secure.  Of course this allows competing networks (with different inflation rates) to quickly become secure.  This subjects Bitcoin to more competition.  </p>

<p>Ultimately the value of Bitcoin is a reflection of the need for Bitcoins to make exchanges.  The more people using Bitcoin to make purchases, the more demand there is for Bitcoins, and the higher the price of Bitcoins goes.  (Speculation also raises the price, but long term speculation is essentially a bet that the transactional demand for Bitcoin will increase in the future.)  The higher the price, the higher the incentive to mine.</p>

<p>At any given time there is a certain amount of demand for a Bitcoin like currency to make transactions.  That need doesn’t increase with more competition.  That means that the transactional demand for Bitcoin is really the same as the transactional demand for all substantially similar forms of payment.  As more currencies are competing to fill the same demand they actually reduce the demand for the other currencies as they become more widely used.</p>

<p>This means that ultimately, to the extent that currencies are interchangeable to end users, merged mining does not increase the overall security of the networks.  The demand for currencies drives the price (and thus the value of the reward).  Increased demand for any given currency results in decreased demand for others, lowering the incentive to mine for the other currencies.  The total incentive is a function of total demand for all Bitcoin like currencies.</p>

<p>Except now competing currencies can market themselves as “as secure as Bitcoin but with lower transaction fees.”  In other words there is a race to the bottom among competing currencies to offer the lowest transaction fees, because lowering the transaction fee doesn’t hurt the security of the network in comparison to the other merged mining networks.  Users, following their own self interest, will adopt the currency with the lowest transaction fees as long as it has the same security of the competitors.</p>

<p>This will increase the price of the currency with the lowest transaction fee (because demand for the currency is higher), and decrease the price of the currencies with higher transactions fees (because demand for those currencies is dropping as it is being filled by demand for the competing currency).  Because the currencies with the higher transaction fees were the ones generating the incentive to mine, overall incentive to mine will diminish.  As long as a currency’s mining is merged with the freeloading currency, it will be powerless to increase incentives by imposing mandatory transaction fees.</p>

<p>The result will be a decrease in mining incentive, a decrease in mining, and ultimately all networks that allow merged mining will become insecure.</p>

CC BY-SA 3.0
2012-12-07T13:30:27.570Z
Issac, I'm also interested in where the hash goes and if any examples exist on Blockchain .info.  Thanks @ThePiachu
makerofthings7
CC BY-SA 3.0
2011-09-28T17:05:22.537Z
One slight correction--not all Bitcoin-like currencies will serve the same demand, and Namecoin is an excellent example of that.  Demand for Namecoin is highly based on its alternative DNS system, which Bitcoin does not provide.
eMansipater
CC BY-SA 3.0
2011-09-28T19:03:17.237Z
Very true.  To the extent that different Bitcoin-like currencies are serving truly different demands, merged mining might increase the overall security.  But, to the extent that merged mining enables a transaction fee race to the bottom for each different type of currency, it will destroy overall security of the block chain.  (Perhaps there is a way to control which currencies can piggy back on Bitcoin mining?  If so, Bitcoin could only invite currencies that contributed some minimum incentive for miners.)
Isaac Kriegman
CC BY-SA 3.0
2012-04-06T13:11:15.920Z
"Basically the idea is that you assemble a Namecoin block and hash it, and then insert that hash into a Bitcoin block." - where does one insert the Namecoin block hash exactly?
ThePiachu
CC BY-SA 3.0
2011-09-28T14:39:46.660Z
2012-04-06T04:35:01.447Z
2012-04-06T04:35:01.447Z
Isaac Kriegman
<p>Satoshi himself seems to be the inventor of merged mining. In his words (<a href="https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696" rel="noreferrer">bitcointalk.org</a>):</p>
<blockquote>
<p>I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.</p>
<p>The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.</p>
<p>I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.</p>
<p>Instead of fragmentation, networks share and augment each other's total CPU power.  This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one.  Instead, all networks in the world would share combined CPU power, increasing the total strength.  It would make it easier for small networks to get started by tapping into a ready base of miners.</p>
</blockquote>

CC BY-SA 3.0
2016-05-12T23:26:12.487Z
2016-05-12T23:26:12.487Z
2020-06-16T11:10:03.350Z
nickler
<p>one thing to remember in merged mining is that the block hash of the auxiliary chain (eg namecoin) <strong>does not</strong> need to be below the aux-chain threshold. rather, it is the block hash of the parent (eg bitcoin) which must be below the aux-chain (namecoin) threshold. for example, check out what happened to namecoin <a href="http://explorer.namecoin.info/b/19200" rel="nofollow">when merged mining was introduced in block 19200</a>:</p>

<pre><code>nmc block height: 19199
nmc block hash: 000000000000b19f0ad5cd46859fe8c9662e8828d8a75ff6da73167ac09a9036

nmc block height: 19200
nmc block hash: d8a7c3e01e1e95bcee015e6fcc7583a2ca60b79e5a3aa0a171eddd344ada903d
</code></pre>

<p>this did not happen because of a difficulty change in namecoin, and it also <strong>did not</strong> happen because the namecoin difficulty became irrelevant due to merged mining. rather it happened because the criteria for evaluating valid blocks changed due to merged mining.</p>

<p>extra fields were added to the namecoin header and these enable us to verify that the block validates to be below the namecoin threshold. specifically, the parent chain's <em>block hash</em> is now included in the namecoin block header. it is this block hash which is mined in the parent chain and so we can simply observe this block hash and grab any result that is lower than the namecoin threshold.</p>

<p>the reason this parent chain block hash is at all relevant to the auxiliary chain is simply because the block hash of the auxiliary chain is included in the coinbase txin script in the parent chain. this coinbase txin can take any arbitrary value - it need not produce a valid <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow">script</a>. so it is a good place to put the parent chain block hash.</p>

<p>so, working backwards, to validate a merge-mined block we need to:</p>

<ol>
<li>verify that the aux chain block hash (before adding the parent chain data) exists in the coinbase txin script</li>
<li>verify that the coinbase tx exists in the parent's merkle tree</li>
<li>verify that the parent's merkle root exists in the parent's block hash</li>
<li>verify that the parent's block hash is lower than the aux-chain's threshold</li>
</ol>

<p>and since each of these steps involves a one-way hash function of the data in the previous step, then completion of each step verifies all of the previous steps.</p>

CC BY-SA 3.0
2015-03-23T15:43:12.733Z
2015-03-24T01:30:13.160Z
2015-03-24T01:30:13.160Z
mulllhausen
<p><a href="https://github.com/namecoin/wiki/blob/master/Merged-Mining.mediawiki" rel="noreferrer">Merged mining</a> allows a miner to mine for more than one block chain at the same time. The benefit is that every hash the miner does contributes to the total hash rate of both (all) currencies, and as a result they are all more secure.</p>

<p>Starting with a high-level explanation: The miner (or mining controller in the case of pooled mining) actually builds a block for both hash chains in such a way that the same hash calculation secures both blocks. Work units based on this block are then assigned to miners. If a miner solves a block (at the difficulty level of either or both block chains) the block is re-assembled with the completed proof of work and submitted to the correct block chain (or both blocks are separately reassembled and each submitted to the corresponding network if it met both of their difficulty requirements).</p>

<p>The only confusing detail is how the same hash can secure both block chains. I'll use the example of Bitcoin and Namecoin, where Namecoin supports merged mining and Bitcoin doesn't:</p>

<p>First, the miner must assemble a transaction set for both block chains. He then assembles the final Namecoin block and hashes it. He then creates a transaction containing this hash that is valid in the Bitcoin chain and inserts it in the Bitcoin transaction set at the tip of the tree. He then assembles the final Bitcoin header with this transaction in it and sends out the work units.</p>

<p>If a miner solves the hash at the Bitcoin difficulty level, the Bitcoin block is assembled and sent to the Bitcoin network. The Namecoin hash does nothing and the Bitcoin network ignores it.</p>

<p>If a miner solves the hash at the Namecoin difficulty level, the Namecoin block is assembled. It includes the Namecoin transaction set, the Namecoin block header, the Bitcoin block header, and the hash of the rest of the transactions in the Bitcoin block. This entire "mess" is then submitted to the Namecoin system. The Namecoin system, supporting merged mining, accepts this as proof of work because it contains work that must have been done after the block header and Namecoin transaction set was built. (Because you can't build the Bitcoin transaction set containing that hash, and therefore the Bitcoin header that secures it, without that information. So it proves the work was done.)</p>

<p>Note that a miner can solve both chains simultaneously, and they will if they solve at the higher difficulty. One block can "win" in the public chain and not the other. They are fully independent -- only the mining is merged.</p>

<p>Three key points to remember:</p>

<ol>
<li>The Bitcoin chain doesn't get junked up with Namecoin stuff due to merged mining. At most, one tiny hash is inserted in the transaction tree.</li>
<li>The two hash chains remain fully independent. The "Bitcoin stuff" that goes in the Namecoin tree is basically ignored and only used to validate the proof of work. (It will bloat the Namecoin chain a bit as it means some blocks will have an extra header and an extra hash.)</li>
<li>Lastly, no special support is needed from Bitcoin.</li>
</ol>

<p>The benefit for Namecoin is obvious. A lot of Bitcoin miners will probably do merged mining, since it costs them basically nothing and gives them a greater return than mining Bitcoins alone. As a result, their block generation timing will be more predictable and their transactions more secure against a 51% attack.</p>

CC BY-SA 3.0
2013-05-15T08:06:47.540Z
So the key to understanding this is that Namecoin has explicit support for merged mining. With two chains not supporting it, this would be impossible. That was what I was struggling with, thanks! BTW, a reference where Namecoin's merged mining support is documented would be great!
Steven Roose
CC BY-SA 3.0
2015-01-29T20:05:56.333Z
Where do the Namecoin transactions appear in the Bitcoin block? Are they contained in the coinbase of the miner's subsidy transaction? Can you point to Tx on the blockchain and identify it as a Namecoin block hash?
pinhead
CC BY-SA 3.0
2015-01-29T20:41:00.510Z
@pinhead They don't. Only the hash of the Namecoin block appears in the Bitcoin block.
David Schwartz
CC BY-SA 3.0
2015-01-29T21:32:12.873Z
@DavidSchwartz OK, but WHERE is the namecoin block hash inserted in the bitcoin block? In a transaction? In the coinbase? In some other data field?
pinhead
CC BY-SA 3.0
2015-01-29T22:03:23.557Z
@pinhead It goes in the ScriptSig of the coinbase transaction. The spec is [here](https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase).
David Schwartz
CC BY-SA 3.0
2017-01-30T16:48:09.750Z
Why block generation timing will be more predictable and can prevent 51% attack when merge-mining ? thanks.
hqt
CC BY-SA 3.0
2017-01-30T16:50:10.223Z
another problem. for example at some point, namecoin is harder to solve than bitcoin. so if a miner decide to solve both namecoin and bitcoin, they will have less probability to solve a bitcoin block than some miners just only solve bitcoin.
hqt
CC BY-SA 3.0
2017-01-30T18:15:39.137Z
@hqt That makes no sense. That you are also trying to mine some other kind of block has no effect on the probability that you will mine a bitcoin block -- that probability is determined entirely by the bitcoin difficulty.
David Schwartz
CC BY-SA 3.0
2017-01-31T04:08:44.287Z
@DavidSchwartz yes. it's true now. But I mention in the future, when solving a namecoin problem may be harder than solving a bitcoin problem (in other word, nonce of namecoin is larger than bitcoin), so any miners solve both currencies with have less probability to win a bitcoin block than only-bitcoin miner. (unlikely this will be happen, I just mention about its technical aspect)
hqt
CC BY-SA 3.0
2017-01-31T04:10:52.403Z
about my first question. I don't understand why block generation timing will be more predictable and can prevent 51% attack when merge-mining ? Can you explain for me clearer this point, thanks.
hqt
CC BY-SA 3.0
2017-01-31T04:35:02.020Z
@hqt Without merged mining, people will only mine a coin when the value of the coin exceeds the cost of the power to mine. With merged mining, there is no additional cost to mine the coin and people will mine it so long as it's not worthless. This makes the hashing power both greater and more predictable.
David Schwartz
CC BY-SA 3.0
2017-01-31T05:20:58.640Z
@hqt The probability that you will mine a block depends solely on the difficulty. Merged mining has no effect on the difficulty, so your odds of mining either block are the same as if you weren't merged mining. Each hash is like two lottery tickets instead of one.
David Schwartz
CC BY-SA 3.0
2017-01-31T06:12:28.183Z
For example. the difficult of named coin is 10. and the difficult of bitcoin is only 8. So the miner will use difficult 10 for both bitcoin and name coin. Compare to miner that only mines bitcoin, he/she will only solve bitcoin with difficultity is 8. In this case, merge mining decreases probability to winning the race.
hqt
CC BY-SA 3.0
2017-01-31T07:59:38.397Z
@hqt Why would he do something obviously that dumb? For each hash, he'll check if it mines a bitcoin block and if it mines a namecoin block. If it mines a bitcoin block, it will mine a namecoin block. If it falls between the two difficulties, it will only mine a namecoin block. Why would he throw away a valid namecoin block just because it doesn't meet the difficulty for a bitcoin block?
David Schwartz
CC BY-SA 3.0
2017-01-31T10:17:21.367Z
"Why would he throw away a valid namecoin block just because it doesn't meet the difficulty for a bitcoin block?" I don't understand this point. Because you are merge-mining on bitcoin-blockchain, if you don't meet the difficult for a bitcoin block, how can other miners accept your block chain ?
hqt
CC BY-SA 3.0
2017-01-31T10:18:21.037Z
@hqt Other bitcoin miners won't, but other namecoin miners will since it meets the namecoin difficulty. When you merge mine, every hash is an attempt to form two (or more) valid blocks for two (or more) different block chains.
David Schwartz
CC BY-SA 3.0
2017-01-31T10:29:44.590Z
@DavidSchwartz ah thanks so much. I miss this important piece of information. That namecoin blockchain will maintain its own blockchain.
hqt
CC BY-SA 3.0
2017-02-22T12:01:09.283Z
Didn't read all of it, but check [Blockstack paper, § 3.5](https://www.usenix.org/conference/atc16/technical-sessions/presentation/ali): *"One of our key findings is that merged mining is currently failing in practice: the leading merged-mined blockchain, Namecoin, is vulnerable to the 51% attack. Moreover, merged-mining provided a false sense of security. F2Pool controls 30-35% computing power of Bitcoin, but over 60% of Namecoin’s computing power through merged mining, leaving Namecoin vulnerable to a 51% attack."*
Daniel
CC BY-SA 4.0
2019-04-03T15:12:51.397Z
Yes, merge mining does the opposite of prevent a 51% attack by removing the economic losses in case of a failure. https://bitcoinmagazine.com/articles/side-chains-challenges-potential/
user5389726598465
CC BY-SA 3.0
2011-11-02T21:37:45.023Z
"He then creates a transaction containing this hash that is valid in the Bitcoin chain and inserts it in the Bitcoin transaction set at the tip of the tree." - just to be clear, one creates a bogus transaction for 0BTC that has the exact same hash as Namecoin block and enters it as the last transaction in the merkle tree that is hashed? Doesn't generating the bogus transaction require a lot of resources if it has to match the hash exactly? It it is just inserted without being generated, doesn't this make the block invalid, as it contains an invalid transaction?
ThePiachu
CC BY-SA 3.0
2011-11-02T22:07:20.213Z
@ThePiachu: It doesn't have to "match" the hash, it just has to *contain* the hash.
David Schwartz
CC BY-SA 4.0
2011-08-31T12:28:14.097Z
2018-08-29T04:36:40.620Z
2018-08-29T04:36:40.620Z
David Schwartz
<p>How does the implementation of merged mining affect the global hash rate of alt chains?</p>

<p>Does one solution fit all?  Does one solution fit some?  Does the rate of "solutions that will fit" decrease the more forks that it is tested against?</p>

<p>An explanation of how merged mining actually works would be excellent.</p>

CC BY-SA 3.0
2011-08-31T12:53:56.630Z
I think the answer you accepted is not a strict answer to your question as it appears in the title, but rather to "How does merged mining works". Can you edit your title to reflect this?
ripper234
<hashpower><merged-mining>
How does merged mining work?
MaxSan
# How does merged mining work?

(Asked by: username_0 on 2011-08-31)

How does the implementation of merged mining affect the global hash rate of alt chains?

Does one solution fit all? Does one solution fit some? Does the rate of "solutions that will fit" decrease the more forks that it is tested against?

An explanation of how merged mining actually works would be excellent.

**Tags:** hashpower, merged-mining

> **Comments:**
> **username_1**: I think the answer you accepted is not a strict answer to your question as it appears in the title, but rather to "How does merged mining works". Can you edit your title to reflect this?  

---

## 4 answers

### Answer by username_8 on 2011-08-31. Score: 101 | Accepted answer

[Merged mining](https://github.com/namecoin/wiki/blob/master/Merged-Mining.mediawiki) allows a miner to mine for more than one block chain at the same time. The benefit is that every hash the miner does contributes to the total hash rate of both (all) currencies, and as a result they are all more secure.

Starting with a high-level explanation: The miner (or mining controller in the case of pooled mining) actually builds a block for both hash chains in such a way that the same hash calculation secures both blocks. Work units based on this block are then assigned to miners. If a miner solves a block (at the difficulty level of either or both block chains) the block is re-assembled with the completed proof of work and submitted to the correct block chain (or both blocks are separately reassembled and each submitted to the corresponding network if it met both of their difficulty requirements).

The only confusing detail is how the same hash can secure both block chains. I'll use the example of Bitcoin and Namecoin, where Namecoin supports merged mining and Bitcoin doesn't:

First, the miner must assemble a transaction set for both block chains. He then assembles the final Namecoin block and hashes it. He then creates a transaction containing this hash that is valid in the Bitcoin chain and inserts it in the Bitcoin transaction set at the tip of the tree. He then assembles the final Bitcoin header with this transaction in it and sends out the work units.

If a miner solves the hash at the Bitcoin difficulty level, the Bitcoin block is assembled and sent to the Bitcoin network. The Namecoin hash does nothing and the Bitcoin network ignores it.

If a miner solves the hash at the Namecoin difficulty level, the Namecoin block is assembled. It includes the Namecoin transaction set, the Namecoin block header, the Bitcoin block header, and the hash of the rest of the transactions in the Bitcoin block. This entire "mess" is then submitted to the Namecoin system. The Namecoin system, supporting merged mining, accepts this as proof of work because it contains work that must have been done after the block header and Namecoin transaction set was built. (Because you can't build the Bitcoin transaction set containing that hash, and therefore the Bitcoin header that secures it, without that information. So it proves the work was done.)

Note that a miner can solve both chains simultaneously, and they will if they solve at the higher difficulty. One block can "win" in the public chain and not the other. They are fully independent -- only the mining is merged.

Three key points to remember:

1. The Bitcoin chain doesn't get junked up with Namecoin stuff due to merged mining. At most, one tiny hash is inserted in the transaction tree.
2. The two hash chains remain fully independent. The "Bitcoin stuff" that goes in the Namecoin tree is basically ignored and only used to validate the proof of work. (It will bloat the Namecoin chain a bit as it means some blocks will have an extra header and an extra hash.)
3. Lastly, no special support is needed from Bitcoin.

The benefit for Namecoin is obvious. A lot of Bitcoin miners will probably do merged mining, since it costs them basically nothing and gives them a greater return than mining Bitcoins alone. As a result, their block generation timing will be more predictable and their transactions more secure against a 51% attack.

> **Comments:**
> **username_5**: "He then creates a transaction containing this hash that is valid in the Bitcoin chain and inserts it in the Bitcoin transaction set at the tip of the tree." - just to be clear, one creates a bogus transaction for 0BTC that has the exact same hash as Namecoin block and enters it as the last transaction in the merkle tree that is hashed? Doesn't generating the bogus transaction require a lot of resources if it has to match the hash exactly? It it is just inserted without being generated, doesn't this make the block invalid, as it contains an invalid transaction?  
> **username_8**: @username_5: It doesn't have to "match" the hash, it just has to *contain* the hash.  
> **username_9**: So the key to understanding this is that Namecoin has explicit support for merged mining. With two chains not supporting it, this would be impossible. That was what I was struggling with, thanks! BTW, a reference where Namecoin's merged mining support is documented would be great!  
> **username_10**: Where do the Namecoin transactions appear in the Bitcoin block? Are they contained in the coinbase of the miner's subsidy transaction? Can you point to Tx on the blockchain and identify it as a Namecoin block hash?  
> **username_8**: @username_10 They don't. Only the hash of the Namecoin block appears in the Bitcoin block.  
> **username_10**: @username_8 OK, but WHERE is the namecoin block hash inserted in the bitcoin block? In a transaction? In the coinbase? In some other data field?  
> **username_8**: @username_10 It goes in the ScriptSig of the coinbase transaction. The spec is [here](https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase).  
> **username_11**: Why block generation timing will be more predictable and can prevent 51% attack when merge-mining ? thanks.  
> **username_11**: another problem. for example at some point, namecoin is harder to solve than bitcoin. so if a miner decide to solve both namecoin and bitcoin, they will have less probability to solve a bitcoin block than some miners just only solve bitcoin.  
> **username_8**: @username_11 That makes no sense. That you are also trying to mine some other kind of block has no effect on the probability that you will mine a bitcoin block -- that probability is determined entirely by the bitcoin difficulty.  
> **username_11**: @username_8 yes. it's true now. But I mention in the future, when solving a namecoin problem may be harder than solving a bitcoin problem (in other word, nonce of namecoin is larger than bitcoin), so any miners solve both currencies with have less probability to win a bitcoin block than only-bitcoin miner. (unlikely this will be happen, I just mention about its technical aspect)  
> **username_11**: about my first question. I don't understand why block generation timing will be more predictable and can prevent 51% attack when merge-mining ? Can you explain for me clearer this point, thanks.  
> **username_8**: @username_11 Without merged mining, people will only mine a coin when the value of the coin exceeds the cost of the power to mine. With merged mining, there is no additional cost to mine the coin and people will mine it so long as it's not worthless. This makes the hashing power both greater and more predictable.  
> **username_8**: @username_11 The probability that you will mine a block depends solely on the difficulty. Merged mining has no effect on the difficulty, so your odds of mining either block are the same as if you weren't merged mining. Each hash is like two lottery tickets instead of one.  
> **username_11**: For example. the difficult of named coin is 10. and the difficult of bitcoin is only 8. So the miner will use difficult 10 for both bitcoin and name coin. Compare to miner that only mines bitcoin, he/she will only solve bitcoin with difficultity is 8. In this case, merge mining decreases probability to winning the race.  
> **username_8**: @username_11 Why would he do something obviously that dumb? For each hash, he'll check if it mines a bitcoin block and if it mines a namecoin block. If it mines a bitcoin block, it will mine a namecoin block. If it falls between the two difficulties, it will only mine a namecoin block. Why would he throw away a valid namecoin block just because it doesn't meet the difficulty for a bitcoin block?  
> **username_11**: "Why would he throw away a valid namecoin block just because it doesn't meet the difficulty for a bitcoin block?" I don't understand this point. Because you are merge-mining on bitcoin-blockchain, if you don't meet the difficult for a bitcoin block, how can other miners accept your block chain ?  
> **username_8**: @username_11 Other bitcoin miners won't, but other namecoin miners will since it meets the namecoin difficulty. When you merge mine, every hash is an attempt to form two (or more) valid blocks for two (or more) different block chains.  
> **username_11**: @username_8 ah thanks so much. I miss this important piece of information. That namecoin blockchain will maintain its own blockchain.  
> **username_12**: Didn't read all of it, but check [Blockstack paper, § 3.5](https://www.usenix.org/conference/atc16/technical-sessions/presentation/ali): *"One of our key findings is that merged mining is currently failing in practice: the leading merged-mined blockchain, Namecoin, is vulnerable to the 51% attack. Moreover, merged-mining provided a false sense of security. F2Pool controls 30-35% computing power of Bitcoin, but over 60% of Namecoin’s computing power through merged mining, leaving Namecoin vulnerable to a 51% attack."*  
> **username_13**: Yes, merge mining does the opposite of prevent a 51% attack by removing the economic losses in case of a failure. https://bitcoinmagazine.com/articles/side-chains-challenges-potential/  

---

### Answer by username_2 on 2011-09-28. Score: 37

Basically the idea is that you assemble a Namecoin block and hash it, and then insert that hash into a Bitcoin block. Now when you solve the Bitcoin block at a difficulty level greater to or equal to the Namecoin difficulty level, it will be proof that that amount of work has been done for the Namecoin block. The Namecoin protocol has been altered to accept a Bitcoin block (solved at or above the Namecoin difficulty level) containing a hash of a Namecoin block as proof of work for the Namecoin block. The Bitcoin block will only be acceptable to the Bitcoin network if it is at the difficulty of the Bitcoin network.

The Bitcoin block chain gets a single extra hash when a merged mining block is accepted, and the Namecoin block chain gets a little bit more (because it includes the Bitcoin block) when a merged mining block is accepted. However, because of the Merkle Tree, the entire Bitcoin block doesn’t need to be included in the Namecoin tree, just the top level hashes (so the extra bloat to the Namecoin chain is not a big problem).

Since you make more money mining both Namecoins and Bitcoins miners will eventually all do merged mining, and the difficulty level for all block chains will eventually be the same.

Furthermore, the economic incentive to mine will be the combined economic incentive of all networks, making all networks more secure. Of course this allows competing networks (with different inflation rates) to quickly become secure. This subjects Bitcoin to more competition.

Ultimately the value of Bitcoin is a reflection of the need for Bitcoins to make exchanges. The more people using Bitcoin to make purchases, the more demand there is for Bitcoins, and the higher the price of Bitcoins goes. (Speculation also raises the price, but long term speculation is essentially a bet that the transactional demand for Bitcoin will increase in the future.) The higher the price, the higher the incentive to mine.

At any given time there is a certain amount of demand for a Bitcoin like currency to make transactions. That need doesn’t increase with more competition. That means that the transactional demand for Bitcoin is really the same as the transactional demand for all substantially similar forms of payment. As more currencies are competing to fill the same demand they actually reduce the demand for the other currencies as they become more widely used.

This means that ultimately, to the extent that currencies are interchangeable to end users, merged mining does not increase the overall security of the networks. The demand for currencies drives the price (and thus the value of the reward). Increased demand for any given currency results in decreased demand for others, lowering the incentive to mine for the other currencies. The total incentive is a function of total demand for all Bitcoin like currencies.

Except now competing currencies can market themselves as “as secure as Bitcoin but with lower transaction fees.” In other words there is a race to the bottom among competing currencies to offer the lowest transaction fees, because lowering the transaction fee doesn’t hurt the security of the network in comparison to the other merged mining networks. Users, following their own self interest, will adopt the currency with the lowest transaction fees as long as it has the same security of the competitors.

This will increase the price of the currency with the lowest transaction fee (because demand for the currency is higher), and decrease the price of the currencies with higher transactions fees (because demand for those currencies is dropping as it is being filled by demand for the competing currency). Because the currencies with the higher transaction fees were the ones generating the incentive to mine, overall incentive to mine will diminish. As long as a currency’s mining is merged with the freeloading currency, it will be powerless to increase incentives by imposing mandatory transaction fees.

The result will be a decrease in mining incentive, a decrease in mining, and ultimately all networks that allow merged mining will become insecure.

> **Comments:**
> **username_4**: One slight correction--not all Bitcoin-like currencies will serve the same demand, and Namecoin is an excellent example of that.  Demand for Namecoin is highly based on its alternative DNS system, which Bitcoin does not provide.  
> **username_2**: Very true.  To the extent that different Bitcoin-like currencies are serving truly different demands, merged mining might increase the overall security.  But, to the extent that merged mining enables a transaction fee race to the bottom for each different type of currency, it will destroy overall security of the block chain.  (Perhaps there is a way to control which currencies can piggy back on Bitcoin mining?  If so, Bitcoin could only invite currencies that contributed some minimum incentive for miners.)  
> **username_5**: "Basically the idea is that you assemble a Namecoin block and hash it, and then insert that hash into a Bitcoin block." - where does one insert the Namecoin block hash exactly?  
> **username_3**: Issac, I'm also interested in where the hash goes and if any examples exist on Blockchain .info.  Thanks @username_5  

---

### Answer by username_6 on 2016-05-12. Score: 8

Satoshi himself seems to be the inventor of merged mining. In his words ([bitcointalk.org](https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696)):

> I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
>
> The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
>
> I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
>
> Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.


---

### Answer by username_7 on 2015-03-23. Score: 3

one thing to remember in merged mining is that the block hash of the auxiliary chain (eg namecoin) **does not** need to be below the aux-chain threshold. rather, it is the block hash of the parent (eg bitcoin) which must be below the aux-chain (namecoin) threshold. for example, check out what happened to namecoin [when merged mining was introduced in block 19200](http://explorer.namecoin.info/b/19200):

```
nmc block height: 19199
nmc block hash: 000000000000b19f0ad5cd46859fe8c9662e8828d8a75ff6da73167ac09a9036

nmc block height: 19200
nmc block hash: d8a7c3e01e1e95bcee015e6fcc7583a2ca60b79e5a3aa0a171eddd344ada903d

```

this did not happen because of a difficulty change in namecoin, and it also **did not** happen because the namecoin difficulty became irrelevant due to merged mining. rather it happened because the criteria for evaluating valid blocks changed due to merged mining.

extra fields were added to the namecoin header and these enable us to verify that the block validates to be below the namecoin threshold. specifically, the parent chain's *block hash* is now included in the namecoin block header. it is this block hash which is mined in the parent chain and so we can simply observe this block hash and grab any result that is lower than the namecoin threshold.

the reason this parent chain block hash is at all relevant to the auxiliary chain is simply because the block hash of the auxiliary chain is included in the coinbase txin script in the parent chain. this coinbase txin can take any arbitrary value - it need not produce a valid [script](https://en.bitcoin.it/wiki/Script). so it is a good place to put the parent chain block hash.

so, working backwards, to validate a merge-mined block we need to:

1. verify that the aux chain block hash (before adding the parent chain data) exists in the coinbase txin script
2. verify that the coinbase tx exists in the parent's merkle tree
3. verify that the parent's merkle root exists in the parent's block hash
4. verify that the parent's block hash is lower than the aux-chain's threshold

and since each of these steps involves a one-way hash function of the data in the previous step, then completion of each step verifies all of the previous steps.


---

