[Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 4452 bytes --]

Summary
-------

The BIP66 soft-fork recently passed the 75% support threshold. This
means that 75% of the hashing power has upgraded to support BIP66; 25%
of the hashing power has not. Once 95% of the hashing power has
upgraded, blocks created by the 5% who have not upgraded will be
rejected.

If you operate a pool, solo-mine, or mine on p2pool you'll very likely
need to upgrade your Bitcoin Core node to support the BIP66 soft-fork,
or your blocks will be rejected. If you only sell your hashing power to
a centralized pool you do not need to do anything.


How does the Bitcoin protocol measure BIP66 support?
----------------------------------------------------

Miners that have upgraded to support BIP66 create blocks with the
version field set to 3; non-upgraded miners set the version to 2.
Bitcoin Core measures BIP66 support by counting how many blocks with
version >= 3 exist in the blockchain within the last 1000 blocks.

If 750 out of the last 1000 blocks support BIP66, blocks with the
version set to >= 3 that do not follow the BIP66 rules are rejected; if
950 out of the last 1000 blocks support BIP66, blocks with version < 3
are rejected.


When will the 95% threshold be reached?
---------------------------------------

It's unknown exactly when the 95% threshold will be reached. The BIP34
soft-fork went from 75% to 95% support in a about two weeks, however
more or less time is possible; it's possible that the 95% threshold will
be reached in just a few days.


How can I monitor BIP66 adoption?
---------------------------------

See Pieter Wuille's graphs:

    http://bitcoin.sipa.be/ver-ever.png
    http://bitcoin.sipa.be/ver-50k.png
    http://bitcoin.sipa.be/ver-10k.png
    http://bitcoin.sipa.be/ver-2k.png

The 'ever' and '50k' graphs show the 75% and 95% thresholds.


What software supports support BIP66?
-------------------------------------

Bitcoin Core releases later than v0.10.0 support BIP66.

In addition, v0.9.5 supports BIP66, however we recommend that you
upgrade to v0.10.2

If you run a pool, you may also need to upgrade your pool software as
well. For instance, eloipool versions prior to May 22nd 2015, git commit
f5f4ea636fb38f38e6d9a04aad1f04427556a4bc, do not support BIP66. (For
Eloipool, cb8a5e8fbb4bfdfe9e35f670082603caff65e1b2 is a clean merge that
should work for any branch more recent than 2013 April 6)

Solo miners and decentralised miners using GBT need to also update their
mining software to a currently supported version of BFGMiner to get
support for v3 blocks. The official BFGMiner binaries include this
update with 5.1.0, 4.10.2, and 3.10.9.


What is BIP66?
--------------

BIP66 - "Strict DER signatures" - is a soft-fork that tightens the rules
for signature verification, specifically the way that signatures are
encoded. The Bitcoin Core implementation currently relies on OpenSSL for
signature validation, which means it implicitly defines Bitcoin's block
validity rules. Unfortunately, OpenSSL is not designed for
consensus-critical behaviour (it does not guarantee bug-for-bug
compatibility between versions), and thus changes to it can - and have -
affected Bitcoin software. (see CVE-2014-8275)

By tightening these rules BIP66 reduces the risk that changes to OpenSSL
will cause forks in the Bitcoin blockchain, as seen previously by the
March 2013 fork. Secondly reducing our dependency on OpenSSL is a step
towards replacing OpenSSL with libsecp256k1, a signature validation
library from Pieter Wuille and Gregory Maxwell, that is designed for
consensus-critical applications, as well as being significantly faster
than OpenSSL.


Is it possible that the BIP66 soft-fork will not happen?
--------------------------------------------------------

In theory yes, though it is unlikely and rejection of BIP66 would be a
very ugly process. Unfortunately the existing soft-fork mechanism
provides no mechanism for a soft-fork to expire, so once set in motion
there is no clean way to stop a soft-fork.

There is a proposal from Wuille/Maxwell/Todd, to reform how soft-forks
are adopted that aims to fix this issue, as well as allow multiple
soft-forks be adopted in parallel:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]