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 BCBF8AE7 for ; Fri, 26 Jun 2015 00:07:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9F19140 for ; Fri, 26 Jun 2015 00:07:48 +0000 (UTC) Received: by qkbp125 with SMTP id p125so47235055qkb.2 for ; Thu, 25 Jun 2015 17:07:48 -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:cc :content-type; bh=Vx3xr+fZsIrg/7auKrLufLh/ZLSCjCblr3Ym57ptR7Q=; b=tx0ekBL1CB0616pHU5UPHWHB/LQogoAOedVIGpHaz9i1nn2hbutoh85ICP0I+/H6f/ 7K+uXZUmcqtQywCKFqr4yQMcWFV+eU5LGmo2KPsKelDwR24xjj51QN5M9OazqqJwybAD mXLnCI2ba8b1/ME9QqlQt1ust1UKZsYXOtt/Qj8rgAXpA2tQnez8aW5iBZqDKCIa2Yjx y7hAsrIon+gctu6u+bc0ut6Dbj7KFpyOdW23445rSPhiaMfP2QXQ3aMmeYcFN8DqZeRY NfqJYIKV3+y4agDYwK5h8eVDPAM7QodASIRZqMzi2zuBgg8aStXcHsZV+vlwXUazrVN5 NDxA== MIME-Version: 1.0 X-Received: by 10.55.16.83 with SMTP id a80mr85442748qkh.63.1435277268119; Thu, 25 Jun 2015 17:07:48 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Thu, 25 Jun 2015 17:07:48 -0700 (PDT) In-Reply-To: References: <20150625223344.GA2406@muck> Date: Fri, 26 Jun 2015 01:07:48 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1146922ab874e605196087b9 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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: Fri, 26 Jun 2015 00:07:49 -0000 --001a1146922ab874e605196087b9 Content-Type: text/plain; charset=UTF-8 It would be possible to run a simplified version of the bits proposal, until BIP 66 locks. It's obviously not worth it at this point though, though it could be 1-2 weeks more. Version 2 means neither option Version 3 means BIP 66 only Version 4 means CLTV only Version 5 means both If (Version 3 + version 5) > 95%, reject 2 & 4 If (Version 4 + version 5) > 95%, reject 2 & 3 For 2 options at the same time, this isn't much extra overhead. On Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo wrote: > 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 >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1146922ab874e605196087b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be = possible to run a simplified version of the bits proposal, until BIP 66 loc= ks.=C2=A0

It's obviously not worth it at this point though, tho= ugh it could be 1-2 weeks more.=C2=A0

Version 2 me= ans neither option
Version 3 means BIP 66 only
Version 4 = means CLTV only
Version 5 means both

If (Version 3 + = version 5) > 95%, reject 2 & 4
If (Version 4 + version 5) > 95= %, reject 2 & 3

For 2 options at the same time, this isn&#= 39;t much extra overhead.


On = Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo <elombrozo@gmail.com&g= t; wrote:

Please do= it.

On Jun 25, 2015 3:33 PM, = "Peter Todd" <pete@petertodd.org> 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<= 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


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


--001a1146922ab874e605196087b9--