From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3D1y-0005eB-65 for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 00:41:10 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z3D1w-0003Iy-33 for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 00:41:10 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5C0f2oi004288 for ; Fri, 12 Jun 2015 01:41:02 +0100 (BST) Received: from muck ([209.226.201.221]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5C0ewSw032231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 12 Jun 2015 01:41:00 +0100 (BST) Date: Thu, 11 Jun 2015 20:40:58 -0400 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20150612004058.GA14749@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline X-Server-Quench: b2d94a10-109b-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgd1 Kg0XXVBSFQB4AR0L Ah8UUhg8dQVPZnxy Y1hgXnFFXkZ7akN1 RVFVWykDFmc1LwNY UENadQBVPgJLeh1F JAJ9AHoJMGQHe3tg TgV2Zmk8YHBVc3UL B1lVdw9DGU9SQzI1 GAYnHDMiB1ZXDxQ0 MlMiLhZcAksLIw02 MFgsXUNZexkfBwEW A0YFHTdWPVANSmI6 Ch5AFWQfDDZaQCEU KRoyL1dOBTBfOGJD A0xDAw0IQzhYSDFP UioVeAwVUgZB X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 209.226.201.221/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Z3D1w-0003Iy-33 Subject: [Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 00:41:10 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=3D 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 >=3D 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/msg07= 863.html --=20 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVeiqXXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udx3uwf+PCWUm3jRQ+adpv8GOe9gOmJG NAT202XJsYq8744194FKKXn9mGjPV6y9YD/r1a4gzy7yjwk0NhE84+FcNQm/bVtH fpzru5f9ac3jX5VUZebttTbRscK/ADDUEel1EWxT8at/AGArSAKcGFJX6ZVsj45c VXrXxVNGiVE3aJveeENs5YJzhtU07KbCWmdkSr5WnlAOw6cE7O8eV9noOhTfG6FU Ah6FISsyLjT9Sgk7eIUZtwkuAAr56zN3/G676l/6LlXPn0PceVf19pzwcpqtGEHL GHdCoCXwjUeu7+dOhCB6XdSoYJGDg2LUobrPhccqvrI2WkFprhA11HI10DVV9Q== =HjrV -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--