MIME-Version: 1.0
In-Reply-To: <CADJgMztmgUzy70sJ+_Xj-OFe-kvEi6eSAYoGTb4yg-yGQ9u1dw@mail.gmail.com>
References: <20150819055036.GA19595@muck>
	<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
	<CABm2gDpBLKxKbHyWocOuyfO1VZ45yM7U1t+zVL_13LP9veXmcA@mail.gmail.com>
	<CADJgMztmgUzy70sJ+_Xj-OFe-kvEi6eSAYoGTb4yg-yGQ9u1dw@mail.gmail.com>
Date: Wed, 19 Aug 2015 12:31:58 +0200
Message-ID: <CABm2gDqRycGY2diXoTvL+d5JE0EgccgGdiQdgWj8c_9SMokJEw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to
 XT/Not-BitcoinXT miners
Precedence: list

I don't think just using version=3D4 for cltv and friends would be a
problem if it wasn't for the XT/nonXT issue.

On Wed, Aug 19, 2015 at 12:20 PM, Btc Drak <btcdrak@gmail.com> wrote:
> On Wed, Aug 19, 2015 at 10:34 AM, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Seems like 3 is something we want to do no matter what and therefore
>> is the "most future-proof" solution.
>> I wonder if I can help with that (and I know there's more people that
>> would be interested).
>> Where's the current "non-full" nVersion bits implementation?
>> Why implement a "non-full" version instead of going with the full
>> implementation directly?
>
>
> There is a simple answer to this, convenience: versionbits has not been
> implemented yet, and I believe the BIP is still in review stage. As it se=
ems
> likely the remaining locktime pull requests will be ready by or before th=
e
> next major release, we need a deployment method if versionbits is not rea=
dy
> (which is unlikely because no-one appears to be working on it at the
> moment). Pieter indicated he is OK with another IsSuperMajority() rollout=
 in
> the interim. Personally, I dont think we should let perfection be the ene=
my
> of progress here because at the end of the day, the deployment method is
> less important than the actual featureset being proposed.
>
> That said, the features in the next soft fork proposal are all related an=
d
> best deployed as one featureset softfork, but moving forward, versionbits
> seems essential to be able to roll out multiple features in parallel with=
out
> waiting for activation and enforcement each time.
>
>
>
>
>