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 D6F5218D7 for ; Mon, 28 Sep 2015 13:21:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149077.authsmtp.com (outmail149077.authsmtp.com [62.13.149.77]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id F0AE1208 for ; Mon, 28 Sep 2015 13:21:33 +0000 (UTC) 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 t8SDLWdg033945; Mon, 28 Sep 2015 14:21:32 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SDLRmZ004542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 14:21:30 +0100 (BST) Date: Mon, 28 Sep 2015 09:21:27 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20150928132127.GA4829@savin.petertodd.org> References: <20150927185031.GA20599@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: d4f8658d-65e3-11e5-b399-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAoUC1AEAgsB AmMbWlBeUlx7WmM7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRRi cmJ8D3NydwFDfHw+ ZERjWXIVCEAsfUB4 ShpJE2hTZnphaTUa TRJbfgpJcANIexZF O1F6ACIKLwdSbGoL FQ4vNDcwO3BTJTpg CiUAMR0JCUoGBjo7 VlgoPA1xQAUuZwgY DDgBAX0gPWM8DGgI EHUQEDp/ X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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: Mon, 28 Sep 2015 13:21:34 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote: > There is *no* consensus on using a soft fork to deploy this feature. It > will result in the same problems as all the other soft forks - SPV wallets > will become less reliable during the rollout period. I am against that, as > it's entirely avoidable. >=20 > Make it a hard fork and my objection will be dropped. >=20 > Until then, as there is no consensus, you need to do one of two things: >=20 > 1) Drop the "everyone must agree to make changes" idea that people here > like to peddle, and do it loudly, so everyone in the community is correct= ly > informed >=20 > 2) Do nothing Hmm? You didn't quote any of my email, so I'll remind you what I did say we had consensus about: 2) We have consensus on the semantics of the CLTV opcode and 3) We have consensus that Bitcoin should adopt CLTV The broad peer review and discussion that got #6124 merged is a clear sign that we expect CLTV to be eventually adopted. __The question isn't if CLTV should be added to the Bitcoin protocol, but rather when.__ (emphasis mine) Both those statements of consensus are *not* about how CLTV is to be deployed. I did discuss deployment later: 6) We have the __necessary consensus__ to deploy CLTV via IsSuperMajori= ty() The various "nVersion bits" proposals - which I am a co-author of - have the primary advantage of being able to cleanly deal with the case where a soft-fork fails to get adopted. However, we do have broad consensus, including across all sides of the blocksize debate, that CLTV should be adopted. __The risk of CLTV failing to get miner adoption, and thus blocking other soft-forks, is very low.__ I probably could have worded this section a bit more clearly; when I say "necessary consensus" I'm referring to the consensus required for a soft-fork deployment. At minimum a simple majority of hashing power - your approval isn't required. For a safe soft-fork, we'd like a super majority of miners to be on board. For a IsSuperMajority() soft-fork - as opposed to nVersion bits - we also need the probability of the soft-fork being rejected to be very low. To achieve that, having consensus that CLTV is a good idea is the best situation to be in. But that's not to say that a few dissenting voices should be seen as a blocker to progress - rather is just makes the deployment a bit more risky, being a sign that the consensus may change in the future, with the soft-fork being later rejected. For example strong objections by a respected Bitcoin developer who has made significant contributions to the consensus codebase and protocol development would be a strong sign that a IsSuperMajority() soft-fork might fail, and deployment via nVersion bits is probably a better approach. Fortunately we're not in that situation. Hard-forks are a very different situation, with significantly more need for very broad consensus, but that's been well discussed elsewhere. I have three questions to you: 1) Do you agree that CLTV should be added to the Bitcoin protocol? Ignoring the question how exactly it is added, hard-fork or soft-fork. 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it is added to Bitcoin Core? If you refuse to do this the risk of the soft-fork is increased a bit, although miner support for XT has remained extremely low, and the 95% switch-over threshold has a significant margin for error. (there's a 75% threshold to consider as well, however as XT has adopted my pull-req #5000 - Discourage NOPs reserved for soft-fork upgrades - those miners will only produce valid blocks under CLTV rules) 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to detect advertised soft-forks and correctly handle them? Notably, if you do this your objections against soft-forks will be met, as the behavior of a SPV client with soft-fork detection during a soft-fork will be identical to that client during a hard-fork. In particular, the SPV client will correct reject invalid blocks, and continue to follow only the longest valid chain. (modulo unadvertised forks of course, an inherently unavoidable problem with the SPV security model) Secondly, that code should also detect forks it doesn't know about - as is done in Bitcoin Core already - and warn the user. --=20 'peter'[:-1]@petertodd.org 00000000000000000d74f5def1087f3ec1571cb468e471e71f96063253988c78 --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWCT7SXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMzI0MjBhZDI5ODdhZGM5NTRkZjg1NWY5YWUxMGNmNjA4 ZTkxMWI0MzFmNjQwZTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsiwQgAhR00ccLDjUQECJIzUkHL4PSj HzO8D9h1MEZp/os8kGBAhSflVy+5FafPL+EoW8XswyshqHAj0uMdhFbSIkQXc3j4 HhW75YcmubxvM9AhZmlAxS5Ly73l8GrxyWLbH9FhFVKup7fppq5OrkFYANxINjft Aq0w1bcJKbp12nuWFPGAMl9nYLwQ2A2RRU8cTJng/NM3kr8tB/duPkXaS3prFpwf 88+sNkO2uz4w94qRw4wR/lb6evfGJ06Pz4MDKg89LyE7teHVw+1ixL8xE0QuQXqO k5tYS5YEd/aOWqHqUN5oS7H4+9JS3HxsQxsAul4D/hAR75sekTegDoMcy+goZg== =gD1y -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--