<p dir="ltr">Please do it.</p>
<div class="gmail_quote">On Jun 25, 2015 3:33 PM, "Peter Todd" <<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>> 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'm both a fan and co-author of the Version bits BIP(1) proposal,<br>
it hasn'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'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 "mempool-only" 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's also been famously<br>
described as "What you thought nLockTime did until you actually tried to<br>
use it."<br>
<br>
To that end I'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 "in-flight" at the same time.<br>
<br>
Thoughts? If there are no objections I'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>
'peter'[:-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>