<p dir="ltr">Please do it.</p>
<div class="gmail_quote">On Jun 25, 2015 3:33 PM, &quot;Peter Todd&quot; &lt;<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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=2 and nVersion=3<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=4, enforcement, we do have the option<br>
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="https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html</a><br>
<br>
--<br>
&#39;peter&#39;[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>