Update for BIP65 softfork

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

Update for BIP65 softfork

Post by domob »

Quick heads up to any miners: Softfork voting on BIP65 (version=4 blocks) is in the "enforce" state now - 88% of the hashrate indicates readiness. At 95%, any blocks found by not-yet-upgraded miners will be invalidated - so try to update as soon as possible to a current version.

If you do not want to try out the "bleeding edge", you can use the current release candidate tagged as "nc0.12.0rc2": https://github.com/namecoin/namecoin-co ... c0.12.0rc2 It is signed by my GPG key as well. If you want to use somewhat fresher code, you can follow the 0.13 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: Update for BIP65 softfork

Post by cassini »

Before I post these warnings in the bitcointalk thread I want to make sure I'm not missing anything. Comments welcome:


This also affects users of the Namecoin-Qt 0.3.80 client and older. As soon as we hit the 95% threshold a substantial number of transactions issued by a 0.3.80 client or older will be rejected forever
("Low S values in signatures" problem, see https://github.com/bitcoin/bips/blob/ma ... signatures ).

This in turn means that we should also inform all the NMC-trading exchanges.
If an exchange runs an old client their customers won't be able to reliably withdraw NMCs after the 95% event.

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

Re: Update for BIP65 softfork

Post by domob »

cassini wrote:Before I post these warnings in the bitcointalk thread I want to make sure I'm not missing anything. Comments welcome:

This also affects users of the Namecoin-Qt 0.3.80 client and older. As soon as we hit the 95% threshold a substantial number of transactions issued by a 0.3.80 client or older will be rejected forever
("Low S values in signatures" problem, see https://github.com/bitcoin/bips/blob/ma ... signatures ).

This in turn means that we should also inform all the NMC-trading exchanges.
If an exchange runs an old client their customers won't be able to reliably withdraw NMCs after the 95% event.
I'm not sure - we currently already enforce version=3 / BIP66. I'm not exactly sure when the S-values restriction was introduced, but do you think that the version=3 miners still support those tx while an upgrade would reject them? In that case, it seems reasonable to post such a warning as well.
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: Update for BIP65 softfork

Post by cassini »

domob wrote:but do you think that the version=3 miners still support those tx while an upgrade would reject them?
I've done quite a number of tests using an old 0.3.51 client recently. Precisely half of the transactions were included in the next block, whereas the other half had to wait for a block mined by a v3 mining pool (Slush, Eligius, ghash.io). I should try the same using a Namecoin-Qt 0.3.80.

By the way, pools already on v4 as follows:
F2Pool, BTCC, ViaBTC, Bitminter, multipool.us, myBTCcoin/nodeStratum, yaamp/NiceHash, mmpool.

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

Re: Update for BIP65 softfork

Post by biolizard89 »

cassini wrote:
domob wrote:but do you think that the version=3 miners still support those tx while an upgrade would reject them?
I've done quite a number of tests using an old 0.3.51 client recently. Precisely half of the transactions were included in the next block, whereas the other half had to wait for a block mined by a v3 mining pool (Slush, Eligius, ghash.io). I should try the same using a Namecoin-Qt 0.3.80.

By the way, pools already on v4 as follows:
F2Pool, BTCC, ViaBTC, Bitminter, multipool.us, myBTCcoin/nodeStratum, yaamp/NiceHash, mmpool.
AFAICT the block version shouldn't affect whether high-S signatures are valid. However, Bitcoin Core 0.11.1 and higher consider transactions with such signatures non-standard [1], meaning that they are by default not relayed or mined. My guess is that Slush, Eligius, and GHash.IO haven't upgraded their Namecoin Core clients since the OpenSSL Consensus Bug was fixed circa July 2015; Bitcoin 0.11.1 was released in October 2015. (I'm not certain when that change was made to Bitcoin master branch, but it was probably after July 2015.)

So, it looks to me that the change isn't related to v4 blocks, it just so happens that the older Namecoin Core clients run by those 3 pools don't mine v4 blocks and also don't consider high-S signatures as non-standard.

It looks to me like this might cause problems for non-exchange users of 0.3.80. In particular, users of Namecoin-Qt 0.3.80 might have trouble renewing their names. I suppose they could use the deletetransaction RPC call to try again until it goes through, but that's a significant usability issue.

@domob, is it feasible to temporarily revert 71cc9d9fe829efd9c9b012c4cd1ece1d988b4869 for Namecoin Core master, 0.13, and 0.12 branches, and re-enable that commit once AAA has been deployed? I realize that doing this will expose Namecoin Core users to increased risk of malleability attacks by non-miner adversaries, but I don't see this as a huge problem -- GUI users being unable to renew names easily is a much worse nuisance than malleability attacks are. If we do this, we should also request that at least one significant mining pool upgrade to a Git version that has it reverted. (My guess is that F2Pool would be willing to do so. Eligius has expressed a reluctance to upgrade their Namecoin Core often, as they consider it a bother to do so.)

Cheers.

[1] https://bitcoin.org/en/release/v0.11.1
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: Update for BIP65 softfork

Post by domob »

This makes sense. We can certainly disable the S-malleability fix, but I'm not sure if that's really what we should do. The Qt pull request has been pending for a really long time now, and from what I understand, it mostly works. Is there anything strongly blocking just merging that and getting everyone upgraded?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: Update for BIP65 softfork

Post by johnc »

Were the nametab problems fixed?

If someone could post here the binaries with the latest nametab merged for testing that will be great.

On the beta download page i only see a build that still had issues updating the names with the GUI.

@brandonroberts: is it ready?
Last edited by johnc on Thu Aug 18, 2016 1:19 am, edited 1 time in total.

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

Re: Update for BIP65 softfork

Post by biolizard89 »

domob wrote:This makes sense. We can certainly disable the S-malleability fix, but I'm not sure if that's really what we should do. The Qt pull request has been pending for a really long time now, and from what I understand, it mostly works. Is there anything strongly blocking just merging that and getting everyone upgraded?
I've only had one issue with the latest name tab PR, but it's a significant one. It doesn't prompt the user for a psssword to unlock the wallet when issuing a name_firstupdate, which means that name registrations fail when the wallet is encrypted. Worse, when this failure occurs, even if name_firstupdate is called manually later via CLI when the wallet is unlocked, the queued name_firstupdate made by the GUI stays in the wallet forever, which causes an error to show in debug.log every time a block is received, forever.

This is probably fairly easy to fix, but until it is fixed, the PR is definitely not mergeable.
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: Update for BIP65 softfork

Post by johnc »

Oh, i see it. https://github.com/namecoin/namecoin-core/pull/67

Ok, waiting for brandonrobertz to check it.

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

Re: Update for BIP65 softfork

Post by domob »

biolizard89 wrote: @domob, is it feasible to temporarily revert 71cc9d9fe829efd9c9b012c4cd1ece1d988b4869 for Namecoin Core master, 0.13, and 0.12 branches, and re-enable that commit once AAA has been deployed? I realize that doing this will expose Namecoin Core users to increased risk of malleability attacks by non-miner adversaries, but I don't see this as a huge problem -- GUI users being unable to renew names easily is a much worse nuisance than malleability attacks are. If we do this, we should also request that at least one significant mining pool upgrade to a Git version that has it reverted. (My guess is that F2Pool would be willing to do so. Eligius has expressed a reluctance to upgrade their Namecoin Core often, as they consider it a bother to do so.)
See https://github.com/namecoin/namecoin-core/pull/100. I've thought a bit about it and now agree that we should probably temporarily do this until we are ready to switch to the new "dev" branch (after BIP65 is active).
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

Post Reply