Btc Drak [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:On Wed, Aug 19, 2015 at ...

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 2:24 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev <bitcoin-dev at lists.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 the bitmasking method to get rid of auxpow version bits before making the standard integer comparisons to deploy BIP66 using IsSuperMajority():
>>
>> if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...)) { //...}
>
> What if version number 257 is used in the future? That would appear to be 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=8, apply a
bitmask of 0xdffffff8 thus:

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

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

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.