Changing merge-mining format for BIP9
Re: Changing merge-mining format for BIP9
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/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: Changing merge-mining format for BIP9
Yeah, better we are prepared.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.)
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Changing merge-mining format for BIP9
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.phelix wrote:Yeah, better we are prepared.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.)
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Changing merge-mining format for BIP9
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
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?biolizard89 wrote:What's the status on the BIP 9 compatibility fix? Last commit on unabuse-nversion appears to be 24 days ago.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Changing merge-mining format for BIP9
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.domob wrote: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?biolizard89 wrote: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
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.
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
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.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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: Changing merge-mining format for BIP9
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/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Changing merge-mining format for BIP9
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.domob wrote: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.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.
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!)