MIME-Version: 1.0
In-Reply-To: <CAE-z3OVAJcnFn21F9QTGCf=NZrLQ9hAtj_tqSCboQGCfFSvq=Q@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>
	<CABm2gDqRycGY2diXoTvL+d5JE0EgccgGdiQdgWj8c_9SMokJEw@mail.gmail.com>
	<CADJgMztysqVya1nnRatyav5rqcpEZ81CmXxW0ZqwJoLN7W2=hg@mail.gmail.com>
	<CAE-z3OVAJcnFn21F9QTGCf=NZrLQ9hAtj_tqSCboQGCfFSvq=Q@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Wed, 19 Aug 2015 18:25:20 +0100
Message-ID: <CADJgMzsvAfJnW1DDD6t3qkBcQRLb4HMqG27k51LhXJqxC6-z4g@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to
 XT/Not-BitcoinXT miners
Precedence: list

On Wed, Aug 19, 2015 at 2:24 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>> What problem am I missing if we just mask of the offending bits. For my =
own project which uses auxpow (and thus has weird nVersion), I also used th=
e bitmasking method to get rid of auxpow version bits before making the sta=
ndard integer comparisons to deploy BIP66 using IsSuperMajority():
>>
>>     if ((block.nVersion & 0xff) >=3D 4 && CBlockIndex::IsSuperMajority(.=
..)) { //...}
>
> What if version number 257 is used in the future?  That would appear to b=
e a version 1 block and fail the test.

To clarify this is the code example for how the same problem occurs
with auxpow bits when running a an IsSuperMajority() softfork and how
it's solved in that instance.

In our case for Bitcoin Core, option 2 we use nVersion=3D8, apply a
bitmask of 0xdffffff8 thus:

    if ((block.nVersion & ~0x20000007) >=3D 4 &&
CBlockIndex::IsSuperMajority(...)) { //...}

With nVersion=3D8, but using comparison >=3D4 allows us to recover the
bit later, assuming we want it (otherwise we use version >=3D8).

This should, unless I am missing something, be forward compatible with
future softforks. My understanding was if "versionbits softfork" code
is not ready by the time we're ready for the deployment,
IsSuperMajority() would be acceptable; and this is how we could deploy
it in the wake of the XT developers' carelessness.