📅 Original date posted:2017-04-04
📝 Original message:On Monday, April 03, 2017 9:06:02 AM Sancho Panza via bitcoin-dev wrote:
> While BIP9 has served the community reasonably well until now, the
> author remarks several shortcomings in its approach:
>
> - it limits itself to backward-compatible changes, precluding its
> applicability to hard forks
BIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it
not being applicable to hardforks. BIP 9 provides a mechanism for having
miners coordinate softforks because they can make the upgrade process smoother
this way. But the same is not true of hardforks: miners are essentially
irrelevant to them, and cannot make the process any smoother. Therefore, BIP 9
and any miner signalling in general is not very useful for deploying these.
> - a fixed 95% threshold is not flexible enough to allow for a 'spectrum
> of contentiousness' to be represented
>
> - the 95% threshold allows small minorities to veto proposed changes,
> lead to stagnation (viz. current standoffs)
Softforks are not required to use BIP 9, and even if they do, they are not
required to use the recommended thresholds.
Basically, the problems you're trying to solve don't exist...
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:59:01
in reply to nevent1q…t3az
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:59:01Event JSON
{
"id": "7b0d475aeec77ad245f438c6fa972bba69980283bae65d77d99b298517a914e8",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160741,
"kind": 1,
"tags": [
[
"e",
"3909d155f1982e3a0b455d11e4ee4341d4be262d42cc407a1e3075f6c71d559b",
"",
"root"
],
[
"e",
"0333f6e28cabb25671ff5819324d7f5e1396392a8cd7b393c07df48bd053d82e",
"",
"reply"
],
[
"p",
"a9caed86d21b3cc6356c289ed2aeb2c219bf1d6b85255c98a935d53b4377ef20"
]
],
"content": "📅 Original date posted:2017-04-04\n📝 Original message:On Monday, April 03, 2017 9:06:02 AM Sancho Panza via bitcoin-dev wrote:\n\u003e While BIP9 has served the community reasonably well until now, the\n\u003e author remarks several shortcomings in its approach:\n\u003e \n\u003e - it limits itself to backward-compatible changes, precluding its\n\u003e applicability to hard forks\n\nBIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it \nnot being applicable to hardforks. BIP 9 provides a mechanism for having \nminers coordinate softforks because they can make the upgrade process smoother \nthis way. But the same is not true of hardforks: miners are essentially \nirrelevant to them, and cannot make the process any smoother. Therefore, BIP 9 \nand any miner signalling in general is not very useful for deploying these.\n\n\u003e - a fixed 95% threshold is not flexible enough to allow for a 'spectrum\n\u003e of contentiousness' to be represented\n\u003e \n\u003e - the 95% threshold allows small minorities to veto proposed changes,\n\u003e lead to stagnation (viz. current standoffs)\n\nSoftforks are not required to use BIP 9, and even if they do, they are not \nrequired to use the recommended thresholds.\n\nBasically, the problems you're trying to solve don't exist...\n\nLuke",
"sig": "a2a86077e719ea71c13a68539ec6ae51c7458dd6831aaa4dfc73462da0e27c6fede60cca84cdb745fad09061580695273de248957968b540c13e239fae1ff1e9"
}