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 C26A38ED for ; Wed, 19 Aug 2015 21:03:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 15C61217 for ; Wed, 19 Aug 2015 21:03:22 +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 t7JL3JP2078751; Wed, 19 Aug 2015 22:03:19 +0100 (BST) Received: from muck (S0106e03f49079160.ok.shawcable.net [174.4.1.120]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7JL3FS3008612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2015 22:03:18 +0100 (BST) Date: Wed, 19 Aug 2015 14:03:14 -0700 From: Peter Todd To: Mark Friedenbach Message-ID: <20150819210314.GA31482@muck> References: <20150819055036.GA19595@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: X-Server-Quench: b7a4f02c-46b5-11e5-9f75-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwsUGUATAgsB AmMbWVZeUF57WGs7 ag1VcwFDY1RPXQV1 VUBOXVMcUAISfR93 ZR0eUhF0dgcIeXp4 ZkQsDHcKWBJ6dxVg RkgGEHAHZDJldWlJ V0VFdwNWdQpKLx5G bwR8GhFYa3VsNCMk FAgyOXU9MCtqYA9x fj9KBmksBksXFXh0 Sx0aGTI+GEADW204 KBo9K1IRBk8NM0I0 KhMtRF9QLxhwQj1i WGdKHGpzJkUKQCst PT8SWE8YHSdGKT8G X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.4.1.120/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 Cc: Bitcoin Dev Subject: Re: [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 21:03:24 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 19, 2015 at 09:32:49AM -0700, Mark Friedenbach via bitcoin-dev = wrote: > I think you misunderstand my suggestion Tier. I am suggesting the same as > BtcDrak, I think: >=20 > Modify IsSuperMajority to take an (optional) mask field. Bits set in that > mask are zero'd for the purpose of the IsSuperMajority calculation. For > this vote we mask bits 0x20000007. >=20 > Thus to signal support for CLTV/CSV/etc. (on Core, XT, or not-XT), you set > bit 4. On Core this would mean a minimum version of 0x8, on XT/not-XT a > minimum version of 0x20000008. >=20 > However the vote is still over whether to enforce BIP 65, 68, etc. for > blocks with nVersion>=3D4. So when this all clears up we haven't needless= ly > wasted an additional bit. Ah, I see your point now re: wasting bits; my post was a bit incorrect on that point. So a subtle thing with the IsSuperMajority() mechanism, and the nVersion bits proposal alternative, is one of the main objectives of the latter proposal proposal is to allow forks to *fail* to be adopted cleanly. To illustrate the problem, consider a hypothetical CLTV soft-fork, implemented with IsSuperMajority() nVersion >=3D 4. We release Bitcoin Core with that code, call it Bitcoin Core v0.12.0, however some substantial fraction of the mining community refuses to upgrade, believing CLTV to be a bad idea. This forms the community into Bitcoin Core and Bitcoin Not-CLTV camps. The Not-CLTV camp then wants to do a new soft-fork upgrade, say for CHECKSIG2 What now? If CHECKSIG2 is implemented via IsSuperMajority, nVersion >=3D 5, that'll falsely trigger Core nodes to think the upgrade has gone though. You could safely define >=3D 5 semantics to be "OP_CLTV is now disabled", but that's pretty ugly and unnecessarily uses up a NOP. You can avoid this problem by assigning one bit out of nVersion for every soft-fork, but then you can only do ~29 more soft-forks - ugly! Come to think of it, if you're Really Sure=E2=84=A2 the soft-fork will be adopted, you can recycle those bits by using the following rule: if (IsFlagBitMaskSuperMajority(1 << 4, pindex->pprev) || block.nMedianT= ime > CLTV_SOFTFORK_DEADLINE) { flags |=3D SCRIPT_VERIFY_CLTV; } IsFlagBitMaskSuperMajority() is a masked version of the existing IsSuperMajority() logic. CLTV_SOFTFORK_DEADLINE would be set some reasonable amount of time in the future, perhaps 3 years. This would probably be ok for non-controversial forks - implementing DERSIG this way would have been fine - and an unlimited number of soft-forks can be done this way safely. (even in parallel) However, this idea still causes problems if forks ever fail to get adoption, something the nVersion bits proposal handles cleanly, albeit at the cost of a significantly more complex implementation. With a sufficiently far off fork deadline in practice that may not be a big issue - nearly everyone would have upgraded their software anyway - but it's still technically creating hard-fork scenarios with respect to older software whenever forks fail to get adoption. --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV1O8PXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxTcQf/deLEWwYkPVXXs+fd4B5VNQ4j hf+s8KrdOB5aynMVz0z7S3PSIPAJHuI5UpmhMxkX1M8ymX2o0GjXyL/J+4V3VCFq czQ3k0lwP2eRoSJ1iQGUWUP26YLm6PmFxDpkOQ9AIkFfmptCQPBuGxhrbTSmXTO1 G/bTAI78HO0+F8P2S9jQevOPlevX7RRxJ5ZhwGekgMBFs5xAMjnqBGsHL3D8Icku 21a8IbVXY5MxOMXPDy1/fte4tM92ch/84G96Ewx6EDJiz0MndG0D0nl4us7lnzaq 7LeZOzSiHtgwlLrwe+76sFhK8XOQm+v3Fg2hCan5T8SUIt2VffWl4IEk1efjdQ== =iPyr -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ--