📅 Original date posted:2020-01-10
📝 Original message:Well, bip9 doesn't only fall apart in case of unreasonable objection,
it also fails simply with miners' apathy.
Anyway, your proposed plan should take care of that case too, I think.
Overall sounds good to me.
Regarding bip8-like activation, luke-jr suggested that instead of
simply activating on date x if failed to do so by miners' signaling, a
consensus rule could require the blocks to signal for activation in
the last activation window.
I see 2 main advantages for this:
1) Outdated nodes can implement warnings (like in bip9) and they can
see those warnings even if it's activated in the last activation
window. Of course this can become counterproductive if miners' squat
signaling bits for asicboost again.
2) It is easier for users to actively resist a given change they
oppose. Instead of requiring signaling, their nodes can be set to
ignore chains that activate it. This will result in a fork, but if
different groups of users want different things, this is arguably the
best behaviour: a "clean" split.
I assume many people won't like this, but I really think we should
consider how users should ideally resist an unwanted change, even if
the proponents had the best intentions in mind, there may be
legitimate reasons to resist it that they may not have considered.
On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> There are a series of soft-fork designs which have recently been making
> good progress towards implementation and future adoption. However, for
> various reasons, activation methods therefor have gotten limited
> discussion. I'd like to reopen that discussion here.
>
> It is likely worth revisiting the goals both for soft forks and their
> activation methods to start. I'm probably missing some, but some basic
> requirements:
>
> 1) Avoid activating in the face of significant, reasonable, and directed
> objection. Period. If someone has a well-accepted, reasonable use of
> Bitcoin that is working today, have no reason to believe wouldn't work
> long into the future without a change, and which would be made
> impossible or significantly more difficult by a change, that change must
> not happen. I certainly hope there is no objection on this point (see
> the last point for an important caveat that I'm sure everyone will jump
> to point out).
>
> 2) Avoid activating within a timeframe which does not make high
> node-level-adoption likely. As with all "node" arguments, I'll note that
> I mean "economically-used" nodes, not the thousand or so spy nodes on
> Google Cloud and AWS. Rule changes don't make sense without nodes
> enforcing them, whether they happen to be a soft fork, hard fork, or a
> blue fork, so activating in a reduced timeframe that doesn't allow for
> large-scale node adoption doesn't have any value, and may cause other
> unintended side effects.
>
> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> Bitcoin's security comes from miners, reducing the hashpower of the
> network as a side effect of a rule change is a needless reduction in a
> key security parameter of the network. This is why, in recent history,
> soft forks required 95% of hashpower to indicate that they have upgraded
> and are capable of enforcing the new rules. Further, this is why recent
> soft forks have not included changes which would result in a standard
> Bitcoin Core instance mining invalid-by-new-rules changes (by relying on
> the standardness behavior of Bitcoin Core).
>
> 4) Use hashpower enforcement to de-risk the upgrade process, wherever
> possible. As a corollary of the above, one of the primary reasons we use
> soft forks is that hashpower-based enforcement of rules is an elegant
> way to prevent network splits during the node upgrade process. While it
> does not make sense to invest material value in systems protected by new
> rules until a significant majority of "economic nodes" is enforcing said
> rules, hashpower lets us neatly bridge the gap in time between
> activation and then. By having a supermajority of miners enforce the new
> rules, attempts at violating the new rules does not result in a
> significant network split, disrupting existing users of the system. If
> we aren't going to take advantage of this, we should do a hard fork
> instead, with the necessarily slow timescale that entails.
>
> 5) Follow the will of the community, irrespective of individuals or
> unreasoned objection, but without ever overruling any reasonable
> objection. Recent history also includes "objection" to soft forks in the
> form of "this is bad because it doesn't fix a different problem I want
> fixed ASAP". I don't think anyone would argue this qualifies as a
> reasonable objection to a change, and we should be in a place, as a
> community (never as developers or purely one group), to ignore such
> objections and make forward progress in spite of them. We don't make
> good engineering decisions by "bundling" unrelated features together to
> enable political football and compromise.
>
> I think BIP 9 (plus a well-crafted softfork) pretty effectively checks
> the boxes for #2-4 here, and when done carefully with lots of community
> engagement and measurement, can effectively fulfill #1 as well. #5 is,
> as I'm sure everyone is aware, where it starts to fall down pretty hard.
>
> BIP 8 has been proposed as an alternative, largely in response to issues
> with #5. However, a naive deployment of it, rather obviously, completely
> fails #1, #3, and #4, and, in my view, fails #5 as well by both giving
> an impression of, setting a precedent of, and possibly even in practice
> increasing the ability of developers to decide the consensus rules of
> the system. A BIP 8 deployment that more accurately measures community
> support as a prerequisite could arguably fulfill #1 and #5, though I'm
> unaware of any concrete proposals on how to accomplish that. Arguably, a
> significantly longer activation window could also allow BIP 8 to fulfill
> #3 and #4, but only by exploiting the "needlessly" and "wherever
> possible" loopholes.
>
> You may note that, from the point of view of achieving the critical
> goals here, BIP 8 is only different from a flag-day activation in that,
> if it takes the "happy-path" of activating before the flag day, it looks
> like BIP 9, but isn't guaranteed to. It additionally has the
> "nice-to-have" property that activation can occur before the flag-day in
> the case of faster miner adoption, though there is a limit of how fast
> is useful due to node adoption.
>
> Thus, to strike a balance between the drawbacks of BIP 8 and BIP 9, the
> Great Consensus Cleanup softfork proposal included this text in the
> discussion section (with the spec describing a BIP 9 deployment):
>
> > In spite of some suggestion that other activation methods be used, BIP
> > 9 is proposed as ensuring miners have upgraded to enforce new rules is
> > an important part of minimizing disruption. While previous BIP 9 soft-
> > forks have resulted in political contention, this comparatively-
> > unimportant soft-fork provides a good opportunity to attempt to return
> > to utilizing BIP 9 to ensure miner upgrade prior to activation, which
> > the authors believe is a critical goal. However, if there is broad
> > agreement to activate these rules when the BIP 9 expiry time is
> > reached, and miners have not yet signaled sufficient level of
> > readiness, a later flag-day activation may be merited. For this
> > reason, implementations may wish to provide a compatibility option
> > which allows flag-day enforcement of these rules without an update.
>
> Ultimately, through admittedly rather limited discussion, I still like
> this model (though I cannot claim it as my own, the original proposal
> came from Greg Maxwell). BIP 9 only falls apart in case of unreasonable
> objection, which, naturally, should carry a high bar to ignore, given we
> have to have some level of agreement that it is, in fact, unreasonable
> (or untargeted). While I admit this is a possibility, I both find it
> less likely than in previous soft-forks, and even if it is the case, it
> only slows down the process, it doesn't necessarily stop it. In the case
> that it does fail, BIP 9 process, in fact, provides a good learning
> opportunity as to the level of community readiness and desire for a
> given change. While we can (and should, and are) learning a lot about
> community readiness for, and acceptability of a change through outreach
> and discussion, there is something about a change with a timeframe that
> forces people to more carefully consider it.
>
> Thus, as something a bit more concrete, I think an activation method
> which sets the right precedent and appropriately considers the above
> goals, would be:
>
> 1) a standard BIP 9 deployment with a one-year time horizon for
> activation with 95% miner readiness,
> 2) in the case that no activation occurs within a year, a six month
> quieting period during which the community can analyze and discussion
> the reasons for no activation and,
> 3) in the case that it makes sense, a simple command-line/bitcoin.conf
> parameter which was supported since the original deployment release
> would enable users to opt into a BIP 8 deployment with a 24-month
> time-horizon for flag-day activation (as well as a new Bitcoin Core
> release enabling the flag universally).
>
> This provides a very long time horizon for more standard activation,
> while still ensuring the goals in #5 are met, even if, in those cases,
> the time horizon needs to be significantly extended to meet the goals of
> #3. Developing Bitcoin is not a race. If we have to, waiting 42 months
> ensures we're not setting a negative precedent that we'll come to regret
> as Bitcoin continues to grow.
>
> Matt
>
> Thanks also to AJ for feedback on an earlier version of this rant.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 18:22:14
in reply to nevent1q…3ydz
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 18:22:14Event JSON
{
"id": "e2907437ad40197a17cf87f702ca161bfcbe16659e241db84fb766173fdc404b",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686162134,
"kind": 1,
"tags": [
[
"e",
"841b1723b46d2192c57b523c3e08b52e866795609acdd0d30e830bbd3f4a039e",
"",
"root"
],
[
"e",
"5d7ef237815bb3a84f72c173a94febbd99367e11abee993df85365512816f9d6",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2020-01-10\n📝 Original message:Well, bip9 doesn't only fall apart in case of unreasonable objection,\nit also fails simply with miners' apathy.\nAnyway, your proposed plan should take care of that case too, I think.\nOverall sounds good to me.\n\nRegarding bip8-like activation, luke-jr suggested that instead of\nsimply activating on date x if failed to do so by miners' signaling, a\nconsensus rule could require the blocks to signal for activation in\nthe last activation window.\nI see 2 main advantages for this:\n\n1) Outdated nodes can implement warnings (like in bip9) and they can\nsee those warnings even if it's activated in the last activation\nwindow. Of course this can become counterproductive if miners' squat\nsignaling bits for asicboost again.\n\n2) It is easier for users to actively resist a given change they\noppose. Instead of requiring signaling, their nodes can be set to\nignore chains that activate it. This will result in a fork, but if\ndifferent groups of users want different things, this is arguably the\nbest behaviour: a \"clean\" split.\n\nI assume many people won't like this, but I really think we should\nconsider how users should ideally resist an unwanted change, even if\nthe proponents had the best intentions in mind, there may be\nlegitimate reasons to resist it that they may not have considered.\n\nOn Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e There are a series of soft-fork designs which have recently been making\n\u003e good progress towards implementation and future adoption. However, for\n\u003e various reasons, activation methods therefor have gotten limited\n\u003e discussion. I'd like to reopen that discussion here.\n\u003e\n\u003e It is likely worth revisiting the goals both for soft forks and their\n\u003e activation methods to start. I'm probably missing some, but some basic\n\u003e requirements:\n\u003e\n\u003e 1) Avoid activating in the face of significant, reasonable, and directed\n\u003e objection. Period. If someone has a well-accepted, reasonable use of\n\u003e Bitcoin that is working today, have no reason to believe wouldn't work\n\u003e long into the future without a change, and which would be made\n\u003e impossible or significantly more difficult by a change, that change must\n\u003e not happen. I certainly hope there is no objection on this point (see\n\u003e the last point for an important caveat that I'm sure everyone will jump\n\u003e to point out).\n\u003e\n\u003e 2) Avoid activating within a timeframe which does not make high\n\u003e node-level-adoption likely. As with all \"node\" arguments, I'll note that\n\u003e I mean \"economically-used\" nodes, not the thousand or so spy nodes on\n\u003e Google Cloud and AWS. Rule changes don't make sense without nodes\n\u003e enforcing them, whether they happen to be a soft fork, hard fork, or a\n\u003e blue fork, so activating in a reduced timeframe that doesn't allow for\n\u003e large-scale node adoption doesn't have any value, and may cause other\n\u003e unintended side effects.\n\u003e\n\u003e 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of\n\u003e Bitcoin's security comes from miners, reducing the hashpower of the\n\u003e network as a side effect of a rule change is a needless reduction in a\n\u003e key security parameter of the network. This is why, in recent history,\n\u003e soft forks required 95% of hashpower to indicate that they have upgraded\n\u003e and are capable of enforcing the new rules. Further, this is why recent\n\u003e soft forks have not included changes which would result in a standard\n\u003e Bitcoin Core instance mining invalid-by-new-rules changes (by relying on\n\u003e the standardness behavior of Bitcoin Core).\n\u003e\n\u003e 4) Use hashpower enforcement to de-risk the upgrade process, wherever\n\u003e possible. As a corollary of the above, one of the primary reasons we use\n\u003e soft forks is that hashpower-based enforcement of rules is an elegant\n\u003e way to prevent network splits during the node upgrade process. While it\n\u003e does not make sense to invest material value in systems protected by new\n\u003e rules until a significant majority of \"economic nodes\" is enforcing said\n\u003e rules, hashpower lets us neatly bridge the gap in time between\n\u003e activation and then. By having a supermajority of miners enforce the new\n\u003e rules, attempts at violating the new rules does not result in a\n\u003e significant network split, disrupting existing users of the system. If\n\u003e we aren't going to take advantage of this, we should do a hard fork\n\u003e instead, with the necessarily slow timescale that entails.\n\u003e\n\u003e 5) Follow the will of the community, irrespective of individuals or\n\u003e unreasoned objection, but without ever overruling any reasonable\n\u003e objection. Recent history also includes \"objection\" to soft forks in the\n\u003e form of \"this is bad because it doesn't fix a different problem I want\n\u003e fixed ASAP\". I don't think anyone would argue this qualifies as a\n\u003e reasonable objection to a change, and we should be in a place, as a\n\u003e community (never as developers or purely one group), to ignore such\n\u003e objections and make forward progress in spite of them. We don't make\n\u003e good engineering decisions by \"bundling\" unrelated features together to\n\u003e enable political football and compromise.\n\u003e\n\u003e I think BIP 9 (plus a well-crafted softfork) pretty effectively checks\n\u003e the boxes for #2-4 here, and when done carefully with lots of community\n\u003e engagement and measurement, can effectively fulfill #1 as well. #5 is,\n\u003e as I'm sure everyone is aware, where it starts to fall down pretty hard.\n\u003e\n\u003e BIP 8 has been proposed as an alternative, largely in response to issues\n\u003e with #5. However, a naive deployment of it, rather obviously, completely\n\u003e fails #1, #3, and #4, and, in my view, fails #5 as well by both giving\n\u003e an impression of, setting a precedent of, and possibly even in practice\n\u003e increasing the ability of developers to decide the consensus rules of\n\u003e the system. A BIP 8 deployment that more accurately measures community\n\u003e support as a prerequisite could arguably fulfill #1 and #5, though I'm\n\u003e unaware of any concrete proposals on how to accomplish that. Arguably, a\n\u003e significantly longer activation window could also allow BIP 8 to fulfill\n\u003e #3 and #4, but only by exploiting the \"needlessly\" and \"wherever\n\u003e possible\" loopholes.\n\u003e\n\u003e You may note that, from the point of view of achieving the critical\n\u003e goals here, BIP 8 is only different from a flag-day activation in that,\n\u003e if it takes the \"happy-path\" of activating before the flag day, it looks\n\u003e like BIP 9, but isn't guaranteed to. It additionally has the\n\u003e \"nice-to-have\" property that activation can occur before the flag-day in\n\u003e the case of faster miner adoption, though there is a limit of how fast\n\u003e is useful due to node adoption.\n\u003e\n\u003e Thus, to strike a balance between the drawbacks of BIP 8 and BIP 9, the\n\u003e Great Consensus Cleanup softfork proposal included this text in the\n\u003e discussion section (with the spec describing a BIP 9 deployment):\n\u003e\n\u003e \u003e In spite of some suggestion that other activation methods be used, BIP\n\u003e \u003e 9 is proposed as ensuring miners have upgraded to enforce new rules is\n\u003e \u003e an important part of minimizing disruption. While previous BIP 9 soft-\n\u003e \u003e forks have resulted in political contention, this comparatively-\n\u003e \u003e unimportant soft-fork provides a good opportunity to attempt to return\n\u003e \u003e to utilizing BIP 9 to ensure miner upgrade prior to activation, which\n\u003e \u003e the authors believe is a critical goal. However, if there is broad\n\u003e \u003e agreement to activate these rules when the BIP 9 expiry time is\n\u003e \u003e reached, and miners have not yet signaled sufficient level of\n\u003e \u003e readiness, a later flag-day activation may be merited. For this\n\u003e \u003e reason, implementations may wish to provide a compatibility option\n\u003e \u003e which allows flag-day enforcement of these rules without an update.\n\u003e\n\u003e Ultimately, through admittedly rather limited discussion, I still like\n\u003e this model (though I cannot claim it as my own, the original proposal\n\u003e came from Greg Maxwell). BIP 9 only falls apart in case of unreasonable\n\u003e objection, which, naturally, should carry a high bar to ignore, given we\n\u003e have to have some level of agreement that it is, in fact, unreasonable\n\u003e (or untargeted). While I admit this is a possibility, I both find it\n\u003e less likely than in previous soft-forks, and even if it is the case, it\n\u003e only slows down the process, it doesn't necessarily stop it. In the case\n\u003e that it does fail, BIP 9 process, in fact, provides a good learning\n\u003e opportunity as to the level of community readiness and desire for a\n\u003e given change. While we can (and should, and are) learning a lot about\n\u003e community readiness for, and acceptability of a change through outreach\n\u003e and discussion, there is something about a change with a timeframe that\n\u003e forces people to more carefully consider it.\n\u003e\n\u003e Thus, as something a bit more concrete, I think an activation method\n\u003e which sets the right precedent and appropriately considers the above\n\u003e goals, would be:\n\u003e\n\u003e 1) a standard BIP 9 deployment with a one-year time horizon for\n\u003e activation with 95% miner readiness,\n\u003e 2) in the case that no activation occurs within a year, a six month\n\u003e quieting period during which the community can analyze and discussion\n\u003e the reasons for no activation and,\n\u003e 3) in the case that it makes sense, a simple command-line/bitcoin.conf\n\u003e parameter which was supported since the original deployment release\n\u003e would enable users to opt into a BIP 8 deployment with a 24-month\n\u003e time-horizon for flag-day activation (as well as a new Bitcoin Core\n\u003e release enabling the flag universally).\n\u003e\n\u003e This provides a very long time horizon for more standard activation,\n\u003e while still ensuring the goals in #5 are met, even if, in those cases,\n\u003e the time horizon needs to be significantly extended to meet the goals of\n\u003e #3. Developing Bitcoin is not a race. If we have to, waiting 42 months\n\u003e ensures we're not setting a negative precedent that we'll come to regret\n\u003e as Bitcoin continues to grow.\n\u003e\n\u003e Matt\n\u003e\n\u003e Thanks also to AJ for feedback on an earlier version of this rant.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "e057a738113f99f3bb392b70d2c537d65ba787250571b76056d320786c2db8aef8a500c87c9cfb0d678be226f52fdde51dd5c835a3c9fa219b54952fba31bbbe"
}