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?

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev