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 C7F1C273 for ; Thu, 25 Jun 2015 22:33:53 +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 0A84011F for ; Thu, 25 Jun 2015 22:33:52 +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 t5PMXpYx056380 for ; Thu, 25 Jun 2015 23:33:51 +0100 (BST) Received: from muck (74.113.166.146.rbitech.net [74.113.166.146] (may be forged)) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5PMXhwk045766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 25 Jun 2015 23:33:49 +0100 (BST) Date: Thu, 25 Jun 2015 18:33:44 -0400 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20150625223344.GA2406@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline X-Server-Quench: 403ae392-1b8a-11e5-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktfZ1U0Glt1 UkhIR0JQFw9rAhYE BlAZVgdzdgZYeXh2 e0dmWG9eVENldAg5 Ry4pfTVBPmdkbWcZ Vg5edAtWPgdKfU4Q aVl9SXJfaTQaZ3s1 QkpiMW9teG0HcnkE GghUdg8eGlAhPwZi GlhFVR4PMGYmYwIY DCAHD3MiMXwwHHR6 PVY5XVUJNhIUFmUA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 74.113.166.146/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] BIP65 / CHECKLOCKTIMEVERIFY deployment 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: Thu, 25 Jun 2015 22:33:53 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable BIP66 adoption is quite close to 95% and will likely be enforced for all blocks in a few more days; now is time to think about how CLTV will be deployed, particularly given its benefits to much-needed scalability solutions such as payment channels. While I'm both a fan and co-author of the Version bits BIP(1) proposal, it hasn't been implemented yet, and the implementation will be relatively complex compared to the previous soft-fork mechanism. I think there is good reason to get CLTV deployed sooner, and I don't think we have any lack of consensus on it. The CLTV code itself has been extensively reviewed in the form of the "mempool-only" pull-req, has been included in the Elements sidechain prototype by Mark Friedenbach, has been running in production on Viacoin for six months, and has a few working demos of its functionality implemented. It's also been famously described as "What you thought nLockTime did until you actually tried to use it." To that end I'm proposing that we simply use the existing median block version mechanism previously used for the nVersion=3D2 and nVersion=3D3 soft-forks for CLTV. This mechanism is well-tested and understood, and would allow CLTV to be easily backported to v0.10.x (even 0.9.x) with little risk for rapid deployment. In the event that another soft-fork is proposed prior to BIP65, nVersion=3D4, enforcement, we do have the option of setting in motion yet another soft-fork as the median mechanism only requires forks to be serialized in sequence - it does not prevent multiple soft-forks from being "in-flight" at the same time. Thoughts? If there are no objections I'll go ahead and write that code, using the same thresholds as BIP66. 1) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/m= sg07863.html --=20 'peter'[:-1]@petertodd.org 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24 --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVjIHFXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzQYgf/SPN8V5Ptmv5KQGTo/I4B/fY+ W0R6niWKgxZ1wJ+zFS5yPlEqKXSJIQLRZ7fB1Duol7/dio8SDuY58ZwKDZoAq1Q3 eV/OHaKT65sG19eL3dqnKFLOFtRvLtMwzLeanE/QmDHTultODe7kElTyj9Gp5hPR UisU0PcWoZfVswu4MbTV4KkE71GgXTnK92lNczhdzyfoJjHIOF5fYc04keKE0VmR 2nQX2QGNzIuAAeUPcQOSPLeAS5MhwgVqV/oyHwwiM9po/+BfZBWZvVrHlOgcykTA +mrbWxbu823/4M4zchgesy+0Yhy0hkT7V+s7qXEMA5Vt4YipHA2ErdXF1vMvKA== =0hEE -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb--