I don't get it. The nonce and chain ID are effectively added together. If I try a different nonce it will just make the same two chains collide in a different slot. It would have made more sense if nonce and chain ID were multiplied, then using different nonces would yield different results.
This doesn't seem to be
entirely true because of the way the result is taken modulo the number of available slots; if that's not a power of two it appears that changing the nonce can rarely cause colliding chains not to collide. It is kind of broken though. (This is also a shame because power-of-two numbers of slots are conceptually simpler.)
If A==B where A=X%Z and B=Y%Z then increasing X and Y by the same amount means you still have A==B. It doesn't matter whether Z is a power of 2. (% is modulo and == is equality)
Another thing is that the number of merkle leaves IS required to be a power of 2. Namecoin block validation checks that the number of merkle leaves is equal to (1 << vChainMerkleBranch.size()). If you are merged mining 3 aux chains, you have to use a dummy slot merkle leaf.
Essentially you want to ensure somebody doesn't attempt to solve multiple blocks at once with the same work. The way vince did this is a bit odd - a better way is to make require proof of work hashes to be unique.
Unless I'm missing something, wouldn't that make double-spending attacks a lot cheaper because you could share the same work on both sides of the double-spend?
It is also important to stop someone from creating X number of blocks on top of each other with a single hash. I guess that's the problem referred to at
https://en.bitcoin.it/wiki/Alternative_Chains#Protecting_against_double_proof.
But I think the double-spending attack you are talking about is even scarier.
Can you stop someone from working on multiple forks with the same hashing power by just requiring aux pows to be unique? To me, namecoin's solution looks much more secure. It's just unfortunate that the formula for merkle indices is broken.
