Changing merge-mining format for BIP9

domob
Posts: 1083
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Changing merge-mining format for BIP9

Post by domob » Wed Jan 20, 2016 7:22 pm

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.)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1625
Joined: Thu Aug 18, 2011 6:59 am

Re: Changing merge-mining format for BIP9

Post by phelix » Fri Jan 22, 2016 9:09 am

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. :)
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1932
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Changing merge-mining format for BIP9

Post by biolizard89 » Sun Jan 24, 2016 1:16 pm

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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 1932
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Changing merge-mining format for BIP9

Post by biolizard89 » Fri Feb 12, 2016 2:51 am

What's the status on the BIP 9 compatibility fix? Last commit on unabuse-nversion appears to be 24 days ago.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1083
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Changing merge-mining format for BIP9

Post by domob » Fri Feb 12, 2016 6:37 pm

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?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

biolizard89
Posts: 1932
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Changing merge-mining format for BIP9

Post by biolizard89 » Sat Feb 13, 2016 7:51 am

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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

johnc
Posts: 89
Joined: Sun Dec 28, 2014 10:03 am

Re: Changing merge-mining format for BIP9

Post by johnc » Wed Mar 09, 2016 3:42 am

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.

domob
Posts: 1083
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Changing merge-mining format for BIP9

Post by domob » Wed Mar 09, 2016 6:46 pm

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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

domob
Posts: 1083
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Changing merge-mining format for BIP9

Post by domob » Sun Mar 13, 2016 5:52 pm

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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

biolizard89
Posts: 1932
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Changing merge-mining format for BIP9

Post by biolizard89 » Mon Mar 14, 2016 7:47 pm

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!)
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply