Page 1 of 1

Update for BIP65 softfork

Posted: Mon Aug 08, 2016 4:10 pm
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.

Re: Update for BIP65 softfork

Posted: Mon Aug 08, 2016 9:12 pm
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.

Re: Update for BIP65 softfork

Posted: Tue Aug 09, 2016 6:11 pm
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.

Re: Update for BIP65 softfork

Posted: Wed Aug 10, 2016 9:50 pm
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.

Re: Update for BIP65 softfork

Posted: Wed Aug 17, 2016 12:43 pm
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

Re: Update for BIP65 softfork

Posted: Wed Aug 17, 2016 5:47 pm
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?

Re: Update for BIP65 softfork

Posted: Wed Aug 17, 2016 6:55 pm
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?

Re: Update for BIP65 softfork

Posted: Wed Aug 17, 2016 7:01 pm
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.

Re: Update for BIP65 softfork

Posted: Wed Aug 17, 2016 10:03 pm
by johnc
Oh, i see it. https://github.com/namecoin/namecoin-core/pull/67

Ok, waiting for brandonrobertz to check it.

Re: Update for BIP65 softfork

Posted: Sat Aug 20, 2016 7:02 pm
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).