It seems that Bitcoin is getting serious about using the individual bits of nVersion for softforks (BIP9). This will severly interfer with the current way merge-mining is handled through nVersion. Thus, I think we should push for a fork that changes the merge-mining format so that it does no longer mess with nVersion, and allows us to keep up with upstream development.
Currently, merge-mined blocks signal this fact through a bit in nVersion, and also set the merge-mining "chain id" in higher bits of this number. I propose the following change (that is a hardfork): Starting with the fork block height (or possibly a certain block time, so that this can be deduced without context as nTime is part of the header already), we change the serialisation format of block headers. nVersion will no longer be "abused" and will just match Bitcoin's version field to 100%, but the initial 80 bytes of the current block header will always be followed by data indicating the merge-mining information - also for non-merge-mined blocks. This additional data could be a new byte that contains the merge-mining information and chain ID. If this byte signals merge-mining, the auxpow follows as before.
I believe it is no issue that this new data is added after the block header and thus no longer (opposed to nVersion) part of the block hash (for instance). The auxpow is only there to "certify" the PoW done on the block, and so I see no reason why this would need to be secured itself by PoW.
Please let me know what you think about this proposal - I think that it should be executed in "due time", say within a few months at the latest (before Bitcoin pushes through with BIP9). I think that I should be able to work on the patch after Christmas, unless there are any issues with my idea.
Changing merge-mining format for BIP9
Changing merge-mining format for BIP9
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
Hmm. I'm not really qualified to talk about the merits of this particular change, but a few things come to mind.
- How are the other merged mining projects handling this? (In particular, Blockstream and P2Pool.) If they already have a solution to this issue, maybe it would be a good opportunity to switch to their merged mining protocol, or at least inform our changes based on what they've done.
- Hardforking before we have a full port of the Namecoin-Qt name management GUI would be problematic, because we currently recommend that end users who want a name management GUI should use 0.3.80. (Maybe we should look seriously at a bounty for porting, with maintenance?)
Re: Changing merge-mining format for BIP9
Good thing you have an eye on thisdomob wrote:It seems that Bitcoin is getting serious about using the individual bits of nVersion for softforks (BIP9). This will severly interfer with the current way merge-mining is handled through nVersion. Thus, I think we should push for a fork that changes the merge-mining format so that it does no longer mess with nVersion, and allows us to keep up with upstream development.
![Smile :)](./images/smilies/icon_e_smile.gif)
Do I see it correctly that BIP9 in Bitcoin will break merge mining with current Namecoin Core and v0.3.81 as we do not currently allow the parent block to be an auxPOW block?
+1 to nTimeCurrently, merge-mined blocks signal this fact through a bit in nVersion, and also set the merge-mining "chain id" in higher bits of this number. I propose the following change (that is a hardfork): Starting with the fork block height (or possibly a certain block time, so that this can be deduced without context as nTime is part of the header already),
Sounds good.we change the serialisation format of block headers. nVersion will no longer be "abused" and will just match Bitcoin's version field to 100%, but the initial 80 bytes of the current block header will always be followed by data indicating the merge-mining information - also for non-merge-mined blocks. This additional data could be a new byte that contains the merge-mining information and chain ID. If this byte signals merge-mining, the auxpow follows as before.
Could messing with the chain ID cause problems? I would feel a bit safer about this if it would also be hashed.I believe it is no issue that this new data is added after the block header and thus no longer (opposed to nVersion) part of the block hash (for instance). The auxpow is only there to "certify" the PoW done on the block, and so I see no reason why this would need to be secured itself by PoW.
That would be greatPlease let me know what you think about this proposal - I think that it should be executed in "due time", say within a few months at the latest (before Bitcoin pushes through with BIP9). I think that I should be able to work on the patch after Christmas, unless there are any issues with my idea.
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Changing merge-mining format for BIP9
From what i can understand bitcoin now will be able to signal multiple softforks simultaneously based on % of hashrate accepting the change or upgrading.
Namecoin on the other hand relies on block-height for the soft/hard forks.
Logic indicates that namecoin can have forks based on changes in bitcoin code that we can do nothing about and namecoin related changes based on namecoin code that for the sake of simplicity should continuing to be based on block-height.
Now, it seems that the new bitcoin code interferes with how Auxpow is indicated.
It seems that a hard fork at a certain height will be inevitable.
As long as you can change the auxpow in a way that can be understood later, it will be fine, you are one of the biggest expert on this. IDK. paging lukejr?
Last, if you announce the imminent demise of v0.3.81 support, people will finally start to look at nameGUI![Wink ;)](./images/smilies/icon_e_wink.gif)
Namecoin on the other hand relies on block-height for the soft/hard forks.
Logic indicates that namecoin can have forks based on changes in bitcoin code that we can do nothing about and namecoin related changes based on namecoin code that for the sake of simplicity should continuing to be based on block-height.
Now, it seems that the new bitcoin code interferes with how Auxpow is indicated.
It seems that a hard fork at a certain height will be inevitable.
As long as you can change the auxpow in a way that can be understood later, it will be fine, you are one of the biggest expert on this. IDK. paging lukejr?
Last, if you announce the imminent demise of v0.3.81 support, people will finally start to look at nameGUI
![Wink ;)](./images/smilies/icon_e_wink.gif)
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Changing merge-mining format for BIP9
As far as I can tell, it has nothing to do with the parent block being an auxPOW block (BIP 9 doesn't propose making Bitcoin blocks use auxPOW). The issue is that BIP 9 will permit use of the nVersion field for purposes that collide with Namecoin's usage.phelix wrote:Good thing you have an eye on thisdomob wrote:It seems that Bitcoin is getting serious about using the individual bits of nVersion for softforks (BIP9). This will severly interfer with the current way merge-mining is handled through nVersion. Thus, I think we should push for a fork that changes the merge-mining format so that it does no longer mess with nVersion, and allows us to keep up with upstream development.
Do I see it correctly that BIP9 in Bitcoin will break merge mining with current Namecoin Core and v0.3.81 as we do not currently allow the parent block to be an auxPOW block?
Generally I would prefer having miners vote for the change via either nVersion or a coinbase string (same as how Bitcoin does it). That way we don't get any surprises due to miners failing to upgrade. Is there a strong reason to deviate from Bitcoin's behavior here? It is noteworthy that Wang Chun from F2Pool suggested that we decrease the threshold for consensus rule forks from 95% to circa 90%.phelix wrote:+1 to nTimeCurrently, merge-mined blocks signal this fact through a bit in nVersion, and also set the merge-mining "chain id" in higher bits of this number. I propose the following change (that is a hardfork): Starting with the fork block height (or possibly a certain block time, so that this can be deduced without context as nTime is part of the header already),
I think I agree with Phelix. If there is no compelling reason to omit the auxpow data from the block hash, I would prefer to keep it hashed as it is now.phelix wrote:Could messing with the chain ID cause problems? I would feel a bit safer about this if it would also be hashed.I believe it is no issue that this new data is added after the block header and thus no longer (opposed to nVersion) part of the block hash (for instance). The auxpow is only there to "certify" the PoW done on the block, and so I see no reason why this would need to be secured itself by PoW.
Re: Changing merge-mining format for BIP9
Exactly this.biolizard89 wrote:As far as I can tell, it has nothing to do with the parent block being an auxPOW block (BIP 9 doesn't propose making Bitcoin blocks use auxPOW). The issue is that BIP 9 will permit use of the nVersion field for purposes that collide with Namecoin's usage.phelix wrote:Good thing you have an eye on thisdomob wrote:It seems that Bitcoin is getting serious about using the individual bits of nVersion for softforks (BIP9). This will severly interfer with the current way merge-mining is handled through nVersion. Thus, I think we should push for a fork that changes the merge-mining format so that it does no longer mess with nVersion, and allows us to keep up with upstream development.
Do I see it correctly that BIP9 in Bitcoin will break merge mining with current Namecoin Core and v0.3.81 as we do not currently allow the parent block to be an auxPOW block?
My reason is simplicity. I don't really believe that the fork will be so complicated to push through that it is justified to implement a complex signalling system. As far as I know, Bitcoin doesn't really have one, either - they never did a well-coordinated hardfork before. There is only the softfork-signalling system based on nVersion.biolizard89 wrote:Generally I would prefer having miners vote for the change via either nVersion or a coinbase string (same as how Bitcoin does it). That way we don't get any surprises due to miners failing to upgrade. Is there a strong reason to deviate from Bitcoin's behavior here? It is noteworthy that Wang Chun from F2Pool suggested that we decrease the threshold for consensus rule forks from 95% to circa 90%.phelix wrote:+1 to nTimeCurrently, merge-mined blocks signal this fact through a bit in nVersion, and also set the merge-mining "chain id" in higher bits of this number. I propose the following change (that is a hardfork): Starting with the fork block height (or possibly a certain block time, so that this can be deduced without context as nTime is part of the header already),
I think changing the hashing of the block header is quite an invasive change and that we should try to avoid it where possible. The chain ID is fixed anyway (and checked against the fixed one when validating a block), so I don't really see where an issue could arise. But of course, if you see a concrete problem, let me know!phelix wrote:I think I agree with Phelix. If there is no compelling reason to omit the auxpow data from the block hash, I would prefer to keep it hashed as it is now.phelix wrote:Could messing with the chain ID cause problems? I would feel a bit safer about this if it would also be hashed.I believe it is no issue that this new data is added after the block header and thus no longer (opposed to nVersion) part of the block hash (for instance). The auxpow is only there to "certify" the PoW done on the block, and so I see no reason why this would need to be secured itself by PoW.
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
There seems to have been a misunderstanding, let me rephrase. If I understand correctly Namecoin does not allow the parent block chain to be merge mined. Might BIP9 Bitcoin block header nVersion data be misinterpreted as auxPOW blocks by the Namecoin client, resulting in rejection?domob wrote:Exactly this.biolizard89 wrote:As far as I can tell, it has nothing to do with the parent block being an auxPOW block (BIP 9 doesn't propose making Bitcoin blocks use auxPOW). The issue is that BIP 9 will permit use of the nVersion field for purposes that collide with Namecoin's usage.phelix wrote: Do I see it correctly that BIP9 in Bitcoin will break merge mining with current Namecoin Core and v0.3.81 as we do not currently allow the parent block to be an auxPOW block?
Re: Changing merge-mining format for BIP9
I see - very good point! Yes, that is possible and another reason for us to fix this as soon as possible.phelix wrote:There seems to have been a misunderstanding, let me rephrase. If I understand correctly Namecoin does not allow the parent block chain to be merge mined. Might BIP9 Bitcoin block header nVersion data be misinterpreted as auxPOW blocks by the Namecoin client, resulting in rejection?
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
Ok. So we might have to hardfork as early as March...domob wrote:I see - very good point! Yes, that is possible and another reason for us to fix this as soon as possible.phelix wrote:There seems to have been a misunderstanding, let me rephrase. If I understand correctly Namecoin does not allow the parent block chain to be merge mined. Might BIP9 Bitcoin block header nVersion data be misinterpreted as auxPOW blocks by the Namecoin client, resulting in rejection?
Is the nonce used at all in Namecoin (auxPOW child) blocks? Maybe it could do the job in combination with the highest bit of nVersion which Bitcoin will not use anytime soon. Or we just test for a valid auxPOW if the header is not valid without.
Re: Changing merge-mining format for BIP9
Hm, yes, the nonce could probably be used - but I see no point, TBH. This may just create a similar problem in the future. I'd like to avoid "abusing" any other data fields; I think we can just do what I suggested, namely adding the auxpow information unconditionally with a change in the block header serialisation. This is basically what you suggest (somewhat, at least).phelix wrote:Ok. So we might have to hardfork as early as March...domob wrote:I see - very good point! Yes, that is possible and another reason for us to fix this as soon as possible.phelix wrote:There seems to have been a misunderstanding, let me rephrase. If I understand correctly Namecoin does not allow the parent block chain to be merge mined. Might BIP9 Bitcoin block header nVersion data be misinterpreted as auxPOW blocks by the Namecoin client, resulting in rejection?
Is the nonce used at all in Namecoin (auxPOW child) blocks? Maybe it could do the job in combination with the highest bit of nVersion which Bitcoin will not use anytime soon. Or we just test for a valid auxPOW if the header is not valid without.
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/