From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 734569A for ; Wed, 19 Aug 2015 05:50:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149101.authsmtp.com (outmail149101.authsmtp.com [62.13.149.101]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 31835134 for ; Wed, 19 Aug 2015 05:50:50 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7J5on60056338 for ; Wed, 19 Aug 2015 06:50:49 +0100 (BST) Received: from muck ([24.114.40.22]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7J5obJu058591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 19 Aug 2015 06:50:44 +0100 (BST) Date: Tue, 18 Aug 2015 22:50:36 -0700 From: Peter Todd To: Bitcoin Dev Message-ID: <20150819055036.GA19595@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline X-Server-Quench: 3dd8bf27-4636-11e5-9f75-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktca1U/GlJ1 UkhIR0JSEg9tARYF DlAcVgdzdgFYfH5u Z0R9W3hcQ0U0MUEH RxEGbygGYG9lYWFR VkBYd01XJFdCLElH bU17UnALfGQGM399 TgFsYnVpZW8CeXxc G1pQIQkEamI3IHkX fC5FECkkWwUJSj03 KA0jJ1gAVE0WNF4z PVY7UE4ZNBkJQgFD EglRB2dpGx4nQDZu JwJGVkkfFg1hI29Z AxslOAQg X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.40.22/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 05:50:52 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both mine blocks with nVersion=3D0x20000007, which would falsely trigger the previously suggested implementation using the IsSuperMajority() mechanism and nVersion=3D4 blocks. Additionally while the XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's nVersion soft-fork mechanism(3) a key component of it - fork deadlines(3) - is not implemented. XT/Not-Bitcoin-XT behavior -------------------------- Both implementations produce blocks with nVersion=3D0x20000007, or in binary: 0b001...111 Neither implementation supports a fork deadline; both Not-Bitcoin-XT and XT will produce blocks with those bits set indefinitely under any circumstance, with the proviso that while XT has a hashing power majority, blocks it produces might not be part of the Bitcoin blockchain after Jan 11th 2016. (though this can flap back and forth if reorgs happen) Curiously the BIP101 draft was changed(4) at the last minute from using the nVersion bits compliant 0x20000004 block nVersion, to using two more bits unnecessarily. The rational for doing this is unknown; the git commit message associated with the change suggested "compatibility concerns", but what the concerns actually were isn't specified. Equally even though implementing the fork deadline would be very each in the XT implementation, this was not done. (the XT codebase has had almost no peer review) Options for CLTV/CSV/etc. deployment ------------------------------------ 1) Plain IsSuperMajority() with nVersion=3D4 This option can be ruled out immediately due to the high risk of premature triggering, without genuine 95% miner support. 2) nVersion mask, with IsSuperMajority() In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would be masked away, prior to applying standard IsSuperMajority() logic: block.nVersion & ~0x20000007 This means that CLTV/CSV/etc. miners running Bitcoin Core would create blocks with nVersion=3D8, 0b1000. From the perspective of the CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be advertising blocks that do not trigger the soft-fork. For the perpose of soft-fork warnings, the highest known version can remain nVersion=3D8, which is triggered by both XT/Not-Bitcoin-XT blocks as well as a future nVersion bits implementation. Equally, XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an unknown bit set. When nVersion bits is implemented by the Bitcoin protocol, the plan of setting the high bits to 0b001 still works. The three lowest bits will be unusable for some time, but will be eventually recoverable as XT/Not-Bitcoin-XT mining ceases. Equally, further IsSuperMajority() softforks can be accomplished with the same masking technique. This option does complicate the XT-coin protocol implementation in the future. But that's their problem, and anyway, the maintainers (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks and/or appear to be in favor of a more centralized mandatory update schedule.(6) 3) Full nVersion bits implementation The most complex option would be to deploy via full nVersion bits implementation using flag bit #4 to trigger the fork. Compliant miners would advertise 0x20000008 initially, followed by 0x20000000 once the fork had triggered. The lowest three bits would be unusable for forks for some time, although they could be eventually recovered as XT/Not-Bitcoin-XT mining ceases. The main disadvantage of this option is high initial complexity - the reason why IsSuperMajority() was suggested for CLTV/CSV in the first place. That said, much of the code required has been implemented in XT for the BIP101 hard-fork logic, although as mentioned above, the code has had very little peer review. References ---------- 1) https://github.com/bitcoinxt/bitcoinxt 2) https://github.com/xtbit/notbitcoinxt 3) "Version bits proposal", Pieter Wuille, May 26th 2015, Bitcoin-development mailing list, http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.= html, https://gist.github.com/sipa/bf69659f43e763540550 4) https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e478= 8deebfe 5) "On consensus and forks - What is the difference between a hard and soft= fork?", Mike Hearn, Aug 12th 2015, https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7 6) 2013 San Jose Bitcoin conference developer round-table --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --KsGdsel6WgEHnImy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV1BkoXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udze8wf/XBQP1HOKr1qecHxhGt16e/1G RIckZlhgyZReYnor2yoAnemwRN7WVXEbEDwSKqAkfUQ/GQRRxZeHgNLAmi9vdivf U4avuivy6zuDdgBpTkR1lwYIXymFnUklm+QcYy4YHJhuO1Pql9W3BIUKBvCgCKJF ig2zAAYUPvhoqstER8MwNQh9u4AndLS6ZzCXd7ML76KXjOXmdCds+RbaLO78QmXf WmueIxpW3slLM7ipxW5w5Jlyo9GkGDCxuCxnjZL7TRyGqVrq39KzJMcx33yHsPGc xX1gvxyte3WuOGL13PhS9mmnm1fo/ntIBUHQMh6s/r8+vOI9yAaezSIEPiRJlQ== =wLCH -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--