That would be great in an ideal situation. As it happened, getting BIP66 enforced on a majority of hashpower as fast as possible was the priority, since that protects end users who wait for a few confirmations. I asked F2Pool to provide a pull request with the exact changes they're making; we haven't yet received that pull request yet. I apologize for the lack of organization here.DrHaribo wrote:Wouldn't it be better if the github repo was changed so we all enforce BIP66 at the same time?
We're making unnecessary forks this way.
Any progress on a pull request or data on how close we are to everyone (and not just F2pool) enforcing BIP66?biolizard89 wrote: That would be great in an ideal situation. As it happened, getting BIP66 enforced on a majority of hashpower as fast as possible was the priority, since that protects end users who wait for a few confirmations. I asked F2Pool to provide a pull request with the exact changes they're making; we haven't yet received that pull request yet. I apologize for the lack of organization here.
We just got another v3 block built on top of a v1 block. Others have mined blocks on top of ours, one v1 and three v3.
That's six blocks including the initial v1 block. I guess all those will be orphaned as soon as F2pool catches up and their fork becomes the longest.
Not having much luck here.
Here are the details on the change for any miners who want to help.
This should be safe for either 32-bit or 64-bit builds. If you apply this change, make sure to change it back after this is over.[15:27:59] <wangchun> Jeremy_Rand: simply change line consensus.nMajorityRejectBlockOutdated = 950 to 800 in src/chainparams.cpp should be ok, but after a week or two it should be changed back.
Thank you! We will get through this.DrHaribo wrote:I have modified the nMajorityRejectBlockOutdated on my nodes. I suggest more do the same so this can be over with as quickly as possible.
If you are able to easily build Namecoin Core from source (either 32-bit or 64-bit is fine) with the change that I quoted earlier, and are willing to undo the change in your client in a couple weeks, that will help. If you're not able to easily do that, then stay on what you're on now -- but be aware that you will mine a few orphan blocks over the next 5 days or so. In about 5 days things should settle down (when the chain is 95% BIP66). Under no circumstances should you build 64-bit without the change I quoted earlier, until about 5 days have passed (at which point it will be safe to use unmodified 64-bit).mmpool wrote:What exactly needs to be done? What should pools be running? I'm running the 32 bit binary posted earlier - is that sufficient? More communication from the namecoin project would be helpful.
Updated OP. Previous version:
phelix wrote:Due to a bug in OpenSSL Linux and Mac 64bit Namecoin Classic (v0.3.80 and earlier) and Namecoin Core clients accept a wider range of cryptographic signature formats than other builds. This brings us into the dangerous situation of potentially forking the network.
A majority of Namecoin hashrate is going to begin enforcing BIP66 circa Monday (2015-08-03). This means that all mining pools who don't want their blocks rejected after Monday MUST upgrade to Namecoin Core. Either 32-bit or 64-bit will be fine after BIP66 begins enforcement. (Before that point, we still recommend 32-bit). We apologize for the short notice here.
Namecoin Core Repo
Inofficial Windows binary
Do not trust transactions until further notice. Do not purchase new names until further notice. If you have a name that is expiring very soon assume that transactions may be delayed unexpectedly, so renewing those names before the last minute is advisable.
If all goes well things will be mostly working again from Tuesday on (2015-08-04) but you will need to wait for six confirmations (more for important transactions).
(edited as per Biolizard89's suggestions)