From: Rusty Russell <rusty@rustcorp.com.au>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>,
	Peter Todd <pete@petertodd.org>
In-Reply-To: <20150929200302.GA5051@amethyst.visucore.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<20150929200302.GA5051@amethyst.visucore.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Wed, 30 Sep 2015 13:35:42 +0930
Message-ID: <87wpv8ft61.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

"Wladimir J. van der Laan via bitcoin-dev"
<bitcoin-dev@lists.linuxfoundation.org> writes:
> On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:
>
>> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> There appears to be common agreement on that.
>
> The only source of some controversy is how to deploy: versionbits versus
> IsSuperMajority. I think the versionbits proposal should first have code
> out there for longer before we consider it for concrete softforks. Haste-ing
> along versionbits because CLTV is wanted would be risky.

Agreed.  Unfortunately, a simple "block version >= 4" check is
insufficient, due to XT which sets version bits 001....111.

Given that, I suggest using the simple test:

        if (pstart->nVersion & 0x8)
            ++nFound;

Which means:
1) XT won't trigger it.
2) It won't trigger XT.
3) You can simply set block nVersion to 8 for now.
4) We can still use versionbits in parallel later.

Cheers,
Rusty.