Namecoin Core softfork heights

Namecoin, NMControl
Post Reply
domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Namecoin Core softfork heights

Post by domob »

Upstream Bitcoin recently replaced the pre-BIP9 softfork logic with hardcoded heights when the three forks (BIP34, BIP65 and BIP66) activated. Does anyone know what the correct heights are for Namecoin (both main and testnet), so I can set them while merging? (Just in case someone already has it, I'm too lazy right now to write a blockchain scraper script for that and don't think this is necessary, see below.)

Otherwise, I think we can just set the heights to some more-or-less but not too recent block - all that matters is that the height is too far in the past for an actual chain reorg to take place, and that the full blockchain is valid later according to the rules we set. Does anyone see problems if I set the heights in this way to some block from, say, the beginning of the year?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: Namecoin Core softfork heights

Post by domob »

I'm leaning towards specifying the heights as block 130k on testnet and 250k on mainnet (but am still testing if that's actually fine). I'll also add checkpoints at them. If there are no objections until tomorrow evening (CEST), I'll finish the merge and push with that change.

EDIT: Actually, it seems that BIP65 (version=4) is not yet even activated on mainnet - so we can't lock that in, obviously.... I'll think about how to proceed here best. What about locking in the others (BIP34 and BIP66) that are already active with the fixed height, and leaving the activation of BIP65 for the future scheduled fork? There's no hurry in getting it activated, similarly to we still need to activate BIP16 and BIP31.

EDIT 2: Also that is not a good idea. I think we should get BIP65 fully activated on the network as soon as possible (I've posted announcements) and then cleanly set the height. Until then, I will merge upstream patches to a "dev" branch.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

cassini
Posts: 336
Joined: Sun May 26, 2013 6:36 pm

Re: Namecoin Core softfork heights

Post by cassini »

domob wrote:EDIT 2: Also that is not a good idea. I think we should get BIP65 fully activated on the network as soon as possible
ACK, with the exception that I'd like to replace "as soon as" with "as soon as we've informed the users of 0.3.80 and older clients, including NMC exchanges admins".
For details see my comment in the Mining section, https://forum.namecoin.info/viewtopic.p ... 769#p16769

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

Re: Namecoin Core softfork heights

Post by domob »

cassini wrote:
domob wrote:EDIT 2: Also that is not a good idea. I think we should get BIP65 fully activated on the network as soon as possible
ACK, with the exception that I'd like to replace "as soon as" with "as soon as we've informed the users of 0.3.80 and older clients, including NMC exchanges admins".
For details see my comment in the Mining section, https://forum.namecoin.info/viewtopic.p ... 769#p16769
Sounds good - but you should it make clear in the warning that this is not anything we directly control, so at least those users should try to update as soon as possible as we cannot guarantee any fixed "deadline" for when miners upgrade. It seems to be in miners' best interest as well to upgrade as soon as possible (at least if they control less than 5% of the hash rate).
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

cassini
Posts: 336
Joined: Sun May 26, 2013 6:36 pm

Re: Namecoin Core softfork heights

Post by cassini »

domob wrote:but you should it make clear in the warning that this is not anything we directly control,
ok, good point.
domob wrote:so at least those users should try to update as soon as possible as we cannot guarantee any fixed "deadline" for when miners upgrade. It seems to be in miners' best interest as well to upgrade as soon as possible (at least if they control less than 5% of the hash rate).
Also good ideas.

Post Reply