📅 Original date posted:2015-09-29
📝 Original message:On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> Pieter and Eric pointed out that the current BIP has miners
> turning off the bit as soon as it's locked in (75% testnet / 95%
> mainnet). It's better for them to keep setting the bit until activation
> (2016 blocks later), so network adoption is visible.
>
> I'm not proposing another suggestion, though I note it for future:
> miners keep setting the bit for another 2016 blocks after activation,
> and have a consensus rule that rejects blocks without the bit. That
> would "force" upgrades on those last miners. I feel we should see how
> this works first.
Actually getting rid of the immediate bit forcing was something I
considered to be an advantage of versionbits over prior work.
Consider, where possible we carve soft fork features out from
non-standard behavior. Why do we do this? Primarily so that
non-upgraded miners are not mining invalid transactions which
immediately cause short lived forks once the soft-fork activates.
(Secondarily to protect wallets from unconfirmed TX that won't ever
confirm).
The version forcing, however, guarantees existence of the same forks
that the usage of non-standard prevented!
I can, however, argue it the other way (and probably have in the
past): The bit is easily checked by thin clients, so thin clients
could use it to reject potentially ill-fated blocks from non-upgraded
miners post switch (which otherwise they couldn't reject without
inspecting the whole thing). This is an improvement over not forcing
the bit, and it's why I was previously in favor of the way the
versions were enforced. But, experience has played out other ways,
and thin clients have not done anything useful with the version
numbers.
A middle ground might be to require setting the bit for a period of
time after rule enforcing begins, but don't enforce the bit, just
enforce validity of the block under new rules. Thus a thin client
could treat these blocks with increased skepticism.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:41:52
in reply to nevent1q…s0lw
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:41:52Event JSON
{
"id": "de20e8cc65f5d9d05dc044e50ce59f6a0d885dbac0a409e6513fc9dc1713cb64",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686159712,
"kind": 1,
"tags": [
[
"e",
"0c83326327ba604c52d5c697e5274340531ee31502bd7fd83d6a7ba4ea83b7af",
"",
"root"
],
[
"e",
"680b4835c8bf21838824df8bfd3565e49ea63e8b9297a7188dfc914c0cb621ba",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-29\n📝 Original message:On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e Hi all,\n\u003e\n\u003e Pieter and Eric pointed out that the current BIP has miners\n\u003e turning off the bit as soon as it's locked in (75% testnet / 95%\n\u003e mainnet). It's better for them to keep setting the bit until activation\n\u003e (2016 blocks later), so network adoption is visible.\n\u003e\n\u003e I'm not proposing another suggestion, though I note it for future:\n\u003e miners keep setting the bit for another 2016 blocks after activation,\n\u003e and have a consensus rule that rejects blocks without the bit. That\n\u003e would \"force\" upgrades on those last miners. I feel we should see how\n\u003e this works first.\n\n\nActually getting rid of the immediate bit forcing was something I\nconsidered to be an advantage of versionbits over prior work.\n\nConsider, where possible we carve soft fork features out from\nnon-standard behavior. Why do we do this? Primarily so that\nnon-upgraded miners are not mining invalid transactions which\nimmediately cause short lived forks once the soft-fork activates.\n(Secondarily to protect wallets from unconfirmed TX that won't ever\nconfirm).\n\nThe version forcing, however, guarantees existence of the same forks\nthat the usage of non-standard prevented!\n\nI can, however, argue it the other way (and probably have in the\npast): The bit is easily checked by thin clients, so thin clients\ncould use it to reject potentially ill-fated blocks from non-upgraded\nminers post switch (which otherwise they couldn't reject without\ninspecting the whole thing). This is an improvement over not forcing\nthe bit, and it's why I was previously in favor of the way the\nversions were enforced. But, experience has played out other ways,\nand thin clients have not done anything useful with the version\nnumbers.\n\nA middle ground might be to require setting the bit for a period of\ntime after rule enforcing begins, but don't enforce the bit, just\nenforce validity of the block under new rules. Thus a thin client\ncould treat these blocks with increased skepticism.",
"sig": "150d473afe5e9924490c000cfed76b41114bc356f59767a2687aaa627a3a30f01edecfad4ccadc7fbdf2a5f71e44a0ad4b510ab93d4eaf8e5fce8c565aa1cc9e"
}