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.
Published at
2023-06-07 17:36:59Event JSON
{
"id": "993ab33523a02ff9d45cb39eaacece922fdac2a380a8467fec54934daf2b4dd0",
"pubkey": "fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83",
"created_at": 1686159419,
"kind": 1,
"tags": [
[
"e",
"7b6db0ce13f47e3b2db7907716169da0107cc63b6d57e20477da59a8b07dbb21",
"",
"root"
],
[
"e",
"00e82b7c4df2dcbc2cec2aab2cf2ceafeb55e8204e56817830a8d82eafe900ae",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2015-08-19\n📝 Original message:On Wed, Aug 19, 2015 at 2:24 PM, Tier Nolan via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e 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():\n\u003e\u003e\n\u003e\u003e if ((block.nVersion \u0026 0xff) \u003e= 4 \u0026\u0026 CBlockIndex::IsSuperMajority(...)) { //...}\n\u003e\n\u003e What if version number 257 is used in the future? That would appear to be a version 1 block and fail the test.\n\nTo clarify this is the code example for how the same problem occurs\nwith auxpow bits when running a an IsSuperMajority() softfork and how\nit's solved in that instance.\n\nIn our case for Bitcoin Core, option 2 we use nVersion=8, apply a\nbitmask of 0xdffffff8 thus:\n\n if ((block.nVersion \u0026 ~0x20000007) \u003e= 4 \u0026\u0026\nCBlockIndex::IsSuperMajority(...)) { //...}\n\nWith nVersion=8, but using comparison \u003e=4 allows us to recover the\nbit later, assuming we want it (otherwise we use version \u003e=8).\n\nThis should, unless I am missing something, be forward compatible with\nfuture softforks. My understanding was if \"versionbits softfork\" code\nis not ready by the time we're ready for the deployment,\nIsSuperMajority() would be acceptable; and this is how we could deploy\nit in the wake of the XT developers' carelessness.",
"sig": "cc30a524b8103a4d57db4cb54a6ff5e5aa05ab3fc2ed3343ba5beceb5f92f4f825335dc7a3d0ce76b91aa72570a673045f7f1cd4ab8ecde81f854402f1a4e488"
}