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 11E77273 for ; Thu, 25 Jun 2015 23:52:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DC9E7C for ; Thu, 25 Jun 2015 23:52:15 +0000 (UTC) Received: by lbbpo10 with SMTP id po10so54813509lbb.3 for ; Thu, 25 Jun 2015 16:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z8QpoZZrfPDOovpDruue2zz+zOoVJNMiajqPbJ9JEzw=; b=frH9NEtQ5nGdA2W6Wz0TW/k5TVC82uCF6daSHaWquAQfb1NYJA5XXkAsOAHTjWAU5u MUgNialKg8JCZNWnfDs/dRxr7M+YOqPQ/S10yHdFKyLGpG95IiG66XFq2v2Fa3V+A+oP tgM1i0EZZH+IGTtTdlL2qFEAKBjv41198zJpdsFGI2ueXBBr2PZKGFadTp0R+7Y3r15O gl59SEcAfiC1VX10xIB2J2M5RotnwQsJng+ydFKIQRfhHBBXqRUct7Ad72unE40Exj6N A9rEDtDHyIBWFtdJJsm/1SJHOwajBB8pELo8Yc3oCBaWOT2XtdIzL900OFD8dw3KAA1o T9aw== MIME-Version: 1.0 X-Received: by 10.152.4.163 with SMTP id l3mr14494471lal.35.1435276333138; Thu, 25 Jun 2015 16:52:13 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Thu, 25 Jun 2015 16:52:12 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Thu, 25 Jun 2015 16:52:12 -0700 (PDT) In-Reply-To: <20150625223344.GA2406@muck> References: <20150625223344.GA2406@muck> Date: Thu, 25 Jun 2015 16:52:12 -0700 Message-ID: From: Eric Lombrozo To: Peter Todd Content-Type: multipart/alternative; boundary=089e013d100cfdcb2e0519604f30 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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@lists.linuxfoundation.org Subject: Re: [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 23:52:16 -0000 --089e013d100cfdcb2e0519604f30 Content-Type: text/plain; charset=UTF-8 Please do it. On Jun 25, 2015 3:33 PM, "Peter Todd" wrote: > 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=2 and nVersion=3 > 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=4, 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/msg07863.html > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e013d100cfdcb2e0519604f30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Please do it.

On Jun 25, 2015 3:33 PM, "Peter Todd" = <pete@petertodd.org> wrote:=
BIP66 adoption is q= uite 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<= br> 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<= br> 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.m= ail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html=

--
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e013d100cfdcb2e0519604f30--