vinced wrote:nodemaster wrote:
Luke-Jr wrote:Why is it so hard to simply disallow a master-chain block from "vouching for" more than one block in each aux chain? :/
Mhmm, If I understand it correctly this might be undesirable because it might be (and is common) that you solve several AUX chain blocks and have one master-block vouching for them, right? This problem would only be solved if the difficulty of both blockchains draw levels.
This was solved in the current code by requiring each chain to appear in a specific (pseudo-random) spot in the aux chain merkle tree, based on the chain ID. So for a specific chain ID, you would only be able to "solve" one aux chain block per parent block.
It's good to see you all evaluating the details of the implementation and I appreciate the feedback. The more eyes on this the better.
There is a more flexible solution to the problem.
The problem is that, with MM as first implemented, a miner could cheat the proof-of-work system by putting more than one Namecoin block header into one Bitcoin block. This "cheating" would not cause a problem if the Namecoin blocks all had the same previous-block hash: one or another would win the race, as happens when competing blocks enter the network. The problem would arise if a linked series of Namecoin blocks all existed in one Bitcoin block's aux Merkle trees. The miner could work on them all at once, getting more from his hashes than difficulty warrants.
Vince's solution is to constrain the paths by which Namecoin blocks may be embedded in Bitcoin blocks. This works, but it complicates the picture for miners and chain designers in a future with many merged-mining chains.
A better solution for new chains is to prevent the existence of linked series of aux chain blocks which lack proof of work. You might do that by requiring each aux chain block to refer (perhaps via its own coinbase or a new header field) to the "solution" (target-meeting hash of parent chain block) as well as the hash of the previous block in the aux chain. In Bitcoin, these two are the same, namely hashPrevBlock. Force blocks to refer not just to the previous block in the chain but to the proof of work on that block. A series of aux blocks all being worked on would not make sense, because the second block in the series would have to reference the first block's solution, so the first block would have to have been solved.