Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4511 bytes --]