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 > >