MIME-Version: 1.0
In-Reply-To: <CABr1YTf20qzXmaLepnsCjAjwMY6x69C_KXcMgdcwqctWY9+_Gg@mail.gmail.com>
References: <20150625223344.GA2406@muck>
	<CABr1YTf20qzXmaLepnsCjAjwMY6x69C_KXcMgdcwqctWY9+_Gg@mail.gmail.com>
Date: Fri, 26 Jun 2015 01:07:48 +0100
Message-ID: <CAE-z3OWq_8r52yy2-FDGtZUZhRCDQRs8-ACSEKZ=HXj5ZRk-5w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1146922ab874e605196087b9
Subject: Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment
Precedence: list

--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 <elombrozo@gmail.com> 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
>> 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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div></div>It would be =
possible to run a simplified version of the bits proposal, until BIP 66 loc=
ks.=C2=A0 <br><br>It&#39;s obviously not worth it at this point though, tho=
ugh it could be 1-2 weeks more.=C2=A0 <br></div><div><br></div>Version 2 me=
ans neither option<br></div>Version 3 means BIP 66 only<br></div>Version 4 =
means CLTV only<br></div>Version 5 means both<br><br></div>If (Version 3 + =
version 5) &gt; 95%, reject 2 &amp; 4<br>If (Version 4 + version 5) &gt; 95=
%, reject 2 &amp; 3<br><br></div>For 2 options at the same time, this isn&#=
39;t much extra overhead.<br></div><div><div><div><div><br></div></div></di=
v></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo <span dir=3D"ltr">&lt;<a href=
=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Please do=
 it.</p>
<div class=3D"gmail_quote"><div><div class=3D"h5">On Jun 25, 2015 3:33 PM, =
&quot;Peter Todd&quot; &lt;<a href=3D"mailto:pete@petertodd.org" target=3D"=
_blank">pete@petertodd.org</a>&gt; wrote:<br type=3D"attribution"></div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">BIP66 adoption is =
quite close to 95% and will likely be enforced for all<br>
blocks in a few more days; now is time to think about how CLTV will be<br>
deployed, particularly given its benefits to much-needed scalability<br>
solutions such as payment channels.<br>
<br>
While I&#39;m both a fan and co-author of the Version bits BIP(1) proposal,=
<br>
it hasn&#39;t been implemented yet, and the implementation will be<br>
relatively complex compared to the previous soft-fork mechanism. I think<br=
>
there is good reason to get CLTV deployed sooner, and I don&#39;t think we<=
br>
have any lack of consensus on it. The CLTV code itself has been<br>
extensively reviewed in the form of the &quot;mempool-only&quot; pull-req, =
has<br>
been included in the Elements sidechain prototype by Mark Friedenbach,<br>
has been running in production on Viacoin for six months, and has a few<br>
working demos of its functionality implemented. It&#39;s also been famously=
<br>
described as &quot;What you thought nLockTime did until you actually tried =
to<br>
use it.&quot;<br>
<br>
To that end I&#39;m proposing that we simply use the existing median block<=
br>
version mechanism previously used for the nVersion=3D2 and nVersion=3D3<br>
soft-forks for CLTV. This mechanism is well-tested and understood, and<br>
would allow CLTV to be easily backported to v0.10.x (even 0.9.x) with<br>
little risk for rapid deployment. In the event that another soft-fork is<br=
>
proposed prior to BIP65, nVersion=3D4, enforcement, we do have the option<b=
r>
of setting in motion yet another soft-fork as the median mechanism only<br>
requires forks to be serialized in sequence - it does not prevent<br>
multiple soft-forks from being &quot;in-flight&quot; at the same time.<br>
<br>
Thoughts? If there are no objections I&#39;ll go ahead and write that code,=
<br>
using the same thresholds as BIP66.<br>
<br>
1) <a href=3D"https://www.mail-archive.com/bitcoin-development@lists.source=
forge.net/msg07863.html" rel=3D"noreferrer" target=3D"_blank">https://www.m=
ail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html</a>=
<br>
<br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
<br></div></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a1146922ab874e605196087b9--