jl2012 at xbt.hk [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-20 📝 Original message:Peter Todd via bitcoin-dev ...

📅 Original date posted:2015-08-20
📝 Original message: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?