📅 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?
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 15:48:32
in reply to nevent1q…aupt
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 15:48:32Event JSON
{
"id": "d5f617832f47e2e5f340885ee7d028c664324a3608795f9115790c419fe09450",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686152912,
"kind": 1,
"tags": [
[
"e",
"33b40cb3a6ef196ed3b584cc0c215cff95814683d4b226bd9e9b25b98d4c9443",
"",
"root"
],
[
"e",
"d0a0addeabed06492483e4ae2d8bf870f40cef1ff524f0dc0e2a6d6210bf85f2",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-08-20\n📝 Original message:Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:\n\n\u003e \n\u003e \n\u003e 2) nVersion mask, with IsSuperMajority()\n\u003e \n\u003e In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would\n\u003e be masked away, prior to applying standard IsSuperMajority() logic:\n\u003e \n\u003e block.nVersion \u0026 ~0x20000007\n\u003e \n\u003e This means that CLTV/CSV/etc. miners running Bitcoin Core would create\n\u003e blocks with nVersion=8, 0b1000. From the perspective of the\n\u003e CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would \n\u003e be\n\u003e advertising blocks that do not trigger the soft-fork.\n\u003e \n\u003e For the perpose of soft-fork warnings, the highest known version can\n\u003e remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks\n\u003e as well as a future nVersion bits implementation. Equally,\n\u003e XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an\n\u003e unknown bit set.\n\u003e \n\u003e When nVersion bits is implemented by the Bitcoin protocol, the plan of\n\u003e setting the high bits to 0b001 still works. The three lowest bits will\n\u003e be unusable for some time, but will be eventually recoverable as\n\u003e XT/Not-Bitcoin-XT mining ceases.\n\u003e \n\u003e Equally, further IsSuperMajority() softforks can be accomplished with\n\u003e the same masking technique.\n\u003e \n\u003e This option does complicate the XT-coin protocol implementation in the\n\u003e future. But that's their problem, and anyway, the maintainers\n\u003e (Hearn/Andresen) has strenuously argued(5) against the use of \n\u003e soft-forks\n\u003e and/or appear to be in favor of a more centralized mandatory update\n\u003e schedule.(6)\n\u003e \n\nIf you are going to mask bits, would you consider to mask all bits \nexcept the 4th bit? So other fork proposals may use other bits for \nvoting concurrently.\n\nAnd as I understand, the masking is applied only during the voting \nstage? After the softfork is fully enforced with 95% support, the \nnVersion will be simply \u003e=8, without any masking?",
"sig": "3cbdb70a260063fc21f44d9194df99dbc6f938642090fade19192f3c2b7a5e4871149f560845f42556943adbbee8607e36dfdadccb2c7e79c9c97f8f1b41d6b8"
}