hashman wrote:
How can a bitcoin miner include NMC transactions in a block (including 50 NMC for himself) and still have a block which is a solution to the BTC block validity constraints?
First the miner includes all transactions, then he hashes with a nounce to try to win difficulty.
The exact details have to do with a merkle tree and you can find them in the wiki if you don't want to read the code.
But think of it like if with the same nounce you could try to hash both blocks with no extra effort.
If you "win" the bittcoin block and bitcoin has a difficulty greater or equal than namecoin's, you will also win namecoin block.
If you "win" the namecoin block but the difficulty is not enough to also win in bitcoin, you broadcast the nmc wining block. And start mining with the same bitcoin block and the next nmc block.
hashman wrote:
If that were the case, then the difficulty of both networks will both go up, and we are back where we started in terms of mining profitability. Right?
You can expect that competition will lower profitability, yes. Some people expect the value of bitcoin to drop instead of a higher temporal profitability, but I'm not one of them.
hashman wrote:
Not really a bug per se, referring to potential for bugs (added complexity) when there isn't much to gain in security.
In the merged mining proposal as i understand it proof of "having done hashes" is being accepted as proof of work on the network. Consider that I could easily come up with plenty of strings that hash to some value under the difficulty. For example I could even use previous blocks or find many strings that have the required hashes and save them for use later. This doesn't work as an attack in satoshi's block chain concept because each new block must contain certain things e.g. the hash of the last one. The security provided by proof-of-work is not due to the proof of hashing but also what has been hashed. For merged mining the contents of what has been hashed have lowered in relevance to the network. Isn't this a decrease in the security per hash that will offset any increase in total hashrate?
Not sure about the technical details, please anyone correct me if I'm wrong.
What you hash normally is the hash of the block + the hash of the nounce. But you're not repeatedly hashing the the block, only new nounces.
Your "ticket" to gain difficulty would be:
Ticket = Hash(btc_block, nounce)
With merged mining you use the hash of the namecoin block as "part of your nounce".
Ticket = Hash( Hash(btc_block, Hash(nmc_block) ), nounce)
But Hash(btc_block, Hash(nmc_block) ) is "constant", so you're still hashing a nounce with each try.
And the result is quivalent to
Ticket = Hash( Hash(btc_block, Hash(nmc_block, nounce) ))
So you can just report to the bitcoin network that your nounce has been Hash(nmc_block) + nounce.
To the namecoin you have to report Hash(nmc_block) and nounce separately and the new code will know how to treat it.
I made up the algebra, sorry if it's not very formal.