Reply to topic  [ 10 posts ] 
Update for BIP65 softfork 
Author Message

Posts: 1083
Reply with quote
Post Update for BIP65 softfork
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/


Mon Aug 08, 2016 4:10 pm
Profile WWW

Posts: 324
Reply with quote
Post Re: Update for BIP65 softfork
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.


Mon Aug 08, 2016 9:12 pm
Profile

Posts: 1083
Reply with quote
Post Re: Update for BIP65 softfork
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/


Tue Aug 09, 2016 6:11 pm
Profile WWW

Posts: 324
Reply with quote
Post Re: Update for BIP65 softfork
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.


Wed Aug 10, 2016 9:50 pm
Profile

Posts: 1919
os: linux
Reply with quote
Post Re: Update for BIP65 softfork
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


Wed Aug 17, 2016 12:43 pm
Profile

Posts: 1083
Reply with quote
Post Re: Update for BIP65 softfork
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/


Wed Aug 17, 2016 5:47 pm
Profile WWW

Posts: 89
Reply with quote
Post Re: Update for BIP65 softfork
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.



Wed Aug 17, 2016 6:55 pm
Profile

Posts: 1919
os: linux
Reply with quote
Post Re: Update for BIP65 softfork
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


Wed Aug 17, 2016 7:01 pm
Profile

Posts: 89
Reply with quote
Post Re: Update for BIP65 softfork
Oh, i see it. https://github.com/namecoin/namecoin-core/pull/67

Ok, waiting for brandonrobertz to check it.


Wed Aug 17, 2016 10:03 pm
Profile

Posts: 1083
Reply with quote
Post Re: Update for BIP65 softfork
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/


Sat Aug 20, 2016 7:02 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.