Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment

From: Eric Lombrozo <elombrozo@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment
Date: Thu, 25 Jun 2015 16:52:12 -0700	[thread overview]
Message-ID: <CABr1YTf20qzXmaLepnsCjAjwMY6x69C_KXcMgdcwqctWY9+_Gg@mail.gmail.com> (raw)
In-Reply-To: <20150625223344.GA2406@muck>

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

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

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