Changing merge-mining format for BIP9

[phelix]

ok, then I guess one minimal solution would be:

0. all blocks must be merge mined
1. auxPOW nonce must always be chainID
2. parent nonce must never be chainID

[domob]

ok, then I guess one minimal solution would be:

0. all blocks must be merge mined
1. auxPOW nonce must always be chainID
2. parent nonce must never be chainID

Yes, this is what I'm thinking about. Except that 2) is not necessary, because 0) already ensures that PoW cannot be reused - at least, I think so. Do I miss anything? Restricting the allowed nonce could lead to confusion with miners, even though the chance of actually hitting exactly the forbidden nonce while mining is negligible.

[phelix]

ok, then I guess one minimal solution would be:

0. all blocks must be merge mined
1. auxPOW nonce must always be chainID
2. parent nonce must never be chainID

Yes, this is what I'm thinking about. Except that 2) is not necessary, because 0) already ensures that PoW cannot be reused - at least, I think so. Do I miss anything? Restricting the allowed nonce could lead to confusion with miners, even though the chance of actually hitting exactly the forbidden nonce while mining is negligible.

Yeah, probably you are right.

So we have 0.) to distinguish between parent and auxPOW blocks and 1.) to distinguish between different auxPOW chains/chain variants (which is only necessary for spv chain fragments or Huntercoin).

[domob]

ok, then I guess one minimal solution would be:

0. all blocks must be merge mined
1. auxPOW nonce must always be chainID
2. parent nonce must never be chainID

Yes, this is what I'm thinking about. Except that 2) is not necessary, because 0) already ensures that PoW cannot be reused - at least, I think so. Do I miss anything? Restricting the allowed nonce could lead to confusion with miners, even though the chance of actually hitting exactly the forbidden nonce while mining is negligible.

Yeah, probably you are right.

So we have 0.) to distinguish between parent and auxPOW blocks and 1.) to distinguish between different auxPOW chains/chain variants (which is only necessary for spv chain fragments or Huntercoin).

Exactly, these two changes are what I was thinking about as well. If there are no objections / issues uncovered in the near future, I'll start working on a patch. This probably requires a bit of refactoring, but is otherwise straight-forward (I guess).

[biolizard89]

Should I ping Luke-Jr and see what he thinks about this topic? He's always given us good advice, and he's knowledgeable about merged mining.

[phelix]

Should I ping Luke-Jr and see what he thinks about this topic? He's always given us good advice, and he's knowledgeable about merged mining.

Sure can't hurt.

[phelix]

Created a separate thread for MM2: https://forum.namecoin.info/viewtopic.php?p=16183

Should we call the (intermediate) solution above MM1b?

[domob]

One more thing: I initially thought that we could still allow ordinary mining for testnet and regtest mode (where it does not matter that you may get two blocks at once by merge-mining with Namecoin itself). But I think this makes things more complicated, thus I suggest that we remove ordinary PoW completely.

For this, I will change the "generate" and "setgenerate" mining commands to automatically create a minimal auxpow in the background. I also plan to remove "getblocktemplate", as it seems to make no sense for a merge-mined coin. Is that ok for everyone?

[phelix]

One more thing: I initially thought that we could still allow ordinary mining for testnet and regtest mode (where it does not matter that you may get two blocks at once by merge-mining with Namecoin itself). But I think this makes things more complicated, thus I suggest that we remove ordinary PoW completely.

yep

For this, I will change the "generate" and "setgenerate" mining commands to automatically create a minimal auxpow in the background. I also plan to remove "getblocktemplate", as it seems to make no sense for a merge-mined coin. Is that ok for everyone?

ACK

[phelix]

sipa: ok, i think bip9 is moved a bit back in priority

So we probably will have more time for the hardfork.

http://bitcoinstats.com/irc/bitcoin-dev ... 52193219.0