Page 4 of 5

Re: Changing merge-mining format for BIP9

Posted: Wed Jan 20, 2016 7:22 pm
by domob
Sounds good, but I still suggest we keep onto it. I've already done some parts of the patch, by refactoring the code a bit and making "generate" and "setgenerate" produce merge-mined blocks. So far, these are non-forking, though. (And not pushed to master, just in a branch of my repo.)

Re: Changing merge-mining format for BIP9

Posted: Fri Jan 22, 2016 9:09 am
by phelix
domob wrote:Sounds good, but I still suggest we keep onto it. I've already done some parts of the patch, by refactoring the code a bit and making "generate" and "setgenerate" produce merge-mined blocks. So far, these are non-forking, though. (And not pushed to master, just in a branch of my repo.)
Yeah, better we are prepared. :)

Re: Changing merge-mining format for BIP9

Posted: Sun Jan 24, 2016 1:16 pm
by biolizard89
phelix wrote:
domob wrote:Sounds good, but I still suggest we keep onto it. I've already done some parts of the patch, by refactoring the code a bit and making "generate" and "setgenerate" produce merge-mined blocks. So far, these are non-forking, though. (And not pushed to master, just in a branch of my repo.)
Yeah, better we are prepared. :)
Agreed. My understanding is that Bitcoin Core intends to maintain branches with various scalability fixes, so that they can be merged on short notice without needing engineering effort at that time. I think we should do the same; a branch should be maintained with the BIP 9 fix so that we can merge it when we get news of Bitcoin's plans.

Re: Changing merge-mining format for BIP9

Posted: Fri Feb 12, 2016 2:51 am
by biolizard89
What's the status on the BIP 9 compatibility fix? Last commit on unabuse-nversion appears to be 24 days ago.

Re: Changing merge-mining format for BIP9

Posted: Fri Feb 12, 2016 6:37 pm
by domob
biolizard89 wrote:What's the status on the BIP 9 compatibility fix? Last commit on unabuse-nversion appears to be 24 days ago.
I'm quite busy at the moment, but I just yesterday rebased the branch to the latest head. I'm thinking about pull requesting the current code as it is now, which is fully functional and non-forking at the moment (it builds up a basis for the forking change). This should simplify things for the further implementation - any thoughts?

Re: Changing merge-mining format for BIP9

Posted: Sat Feb 13, 2016 7:51 am
by biolizard89
domob wrote:
biolizard89 wrote:What's the status on the BIP 9 compatibility fix? Last commit on unabuse-nversion appears to be 24 days ago.
I'm quite busy at the moment, but I just yesterday rebased the branch to the latest head. I'm thinking about pull requesting the current code as it is now, which is fully functional and non-forking at the moment (it builds up a basis for the forking change). This should simplify things for the further implementation - any thoughts?
I'm not qualified to audit the changes that have been made so far, but if it's non-forking and it simplifies things later, I have no objection.

Re: Changing merge-mining format for BIP9

Posted: Wed Mar 09, 2016 3:42 am
by johnc
So this page talks about the change in BIP9

https://bitcoincore.org/en/meetings/2016/03/03/

it's a nice read, my opinion is that maybe the code that change the merged mining process could be added with similar rules. Just test them on testnet, add them to BIP9. Once most testnet users update we can check the effects. Yes you could deploy 0.12 but then you need another release. Instead you could add this merged mining changes to start being deployed automatically after nmc bip9 consensus is reached.

Re: Changing merge-mining format for BIP9

Posted: Wed Mar 09, 2016 6:46 pm
by domob
johnc wrote:it's a nice read, my opinion is that maybe the code that change the merged mining process could be added with similar rules. Just test them on testnet, add them to BIP9. Once most testnet users update we can check the effects. Yes you could deploy 0.12 but then you need another release. Instead you could add this merged mining changes to start being deployed automatically after nmc bip9 consensus is reached.
I strongly prefer to have the fork based on block time and nothing else, in particular no complicated mechanism that relies on block context. That way, given just a block header (but no other information), you know whether it should follow the "new" or "old" format and thus easily process it. While it would be possible to add a logic like BIP9, I don't think this is worth the added complexity. Recall that we are basically changing the block format here (including the serialisation logic, since after the fork it depends no longer on nVersion whether or not an auxpow struct is expected after the pure header) - this is something very low-level, and thus I think it is best if the decision can be made directly without any context. I don't think a complicated logic as in Bitcoin is necessary for us.

Re: Changing merge-mining format for BIP9

Posted: Sun Mar 13, 2016 5:52 pm
by domob
I've now started to implement the actual fork logic on https://github.com/domob1812/namecore/tree/hardfork. The first commit there adds the fork discussed here, but still missing proper testing code.

Re: Changing merge-mining format for BIP9

Posted: Mon Mar 14, 2016 7:47 pm
by biolizard89
domob wrote:
johnc wrote:it's a nice read, my opinion is that maybe the code that change the merged mining process could be added with similar rules. Just test them on testnet, add them to BIP9. Once most testnet users update we can check the effects. Yes you could deploy 0.12 but then you need another release. Instead you could add this merged mining changes to start being deployed automatically after nmc bip9 consensus is reached.
I strongly prefer to have the fork based on block time and nothing else, in particular no complicated mechanism that relies on block context. That way, given just a block header (but no other information), you know whether it should follow the "new" or "old" format and thus easily process it. While it would be possible to add a logic like BIP9, I don't think this is worth the added complexity. Recall that we are basically changing the block format here (including the serialisation logic, since after the fork it depends no longer on nVersion whether or not an auxpow struct is expected after the pure header) - this is something very low-level, and thus I think it is best if the decision can be made directly without any context. I don't think a complicated logic as in Bitcoin is necessary for us.
Also worth pointing out that, if I understand BIP 9 correctly, we can't activate this hardfork via BIP 9, because activating BIP 9 itself requires setting the top 3 bits of nVersion to values that produce an incorrect chain ID. Basically, it is an absolute requirement that the AuxPoW hardfork occur *before* any BIP 9 compliant blocks are mined on the Namecoin chain.

Maybe I'm misunderstanding, but I'm pretty sure I talked to Luke-Jr about this and the conclusion was that this would be a problem. (If I'm wrong, then it's my fault, don't blame Luke!)