MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 20 Aug 2015 13:32:02 -0400
From: jl2012@xbt.hk
To: Peter Todd <pete@petertodd.org>
In-Reply-To: <20150819055036.GA19595@muck>
References: <20150819055036.GA19595@muck>
Message-ID: <c20a83f511d7023f9cdd2df4713cddf9@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
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

Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:

> 
> 
> 2) nVersion mask, with IsSuperMajority()
> 
> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
> be masked away, prior to applying standard IsSuperMajority() logic:
> 
>     block.nVersion & ~0x20000007
> 
> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
> blocks with nVersion=8, 0b1000. From the perspective of the
> CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners would 
> be
> advertising blocks that do not trigger the soft-fork.
> 
> For the perpose of soft-fork warnings, the highest known version can
> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
> as well as a future nVersion bits implementation. Equally,
> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
> unknown bit set.
> 
> When nVersion bits is implemented by the Bitcoin protocol, the plan of
> setting the high bits to 0b001 still works. The three lowest bits will
> be unusable for some time, but will be eventually recoverable as
> XT/Not-Bitcoin-XT mining ceases.
> 
> Equally, further IsSuperMajority() softforks can be accomplished with
> the same masking technique.
> 
> This option does complicate the XT-coin protocol implementation in the
> future. But that's their problem, and anyway, the maintainers
> (Hearn/Andresen) has strenuously argued(5) against the use of 
> soft-forks
> and/or appear to be in favor of a more centralized mandatory update
> schedule.(6)
> 

If you are going to mask bits, would you consider to mask all bits 
except the 4th bit? So other fork proposals may use other bits for 
voting concurrently.

And as I understand, the masking is applied only during the voting 
stage? After the softfork is fully enforced with 95% support, the 
nVersion will be simply >=8, without any masking?