From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5B481C0881 for ; Fri, 10 Jan 2020 22:43:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 444352034B for ; Fri, 10 Jan 2020 22:43:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAmdBOsmdnxO for ; Fri, 10 Jan 2020 22:43:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by silver.osuosl.org (Postfix) with ESMTPS id D4141220A2 for ; Fri, 10 Jan 2020 22:43:38 +0000 (UTC) Received: from [69.59.18.158] (unknown [69.59.18.158]) by mail.as397444.net (Postfix) with ESMTPSA id BC290165982; Fri, 10 Jan 2020 22:43:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Fri, 10 Jan 2020 17:43:35 -0500 Message-Id: References: In-Reply-To: To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Mailer: iPhone Mail (17C54) Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Modern Soft Fork Activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 22:43:41 -0000 I went back and forth with a few folks on this one. I think the fact that we= lose goals 3/4 very explicitly in order to nudge miners seems like a poor t= rade off. I=E2=80=99ll note that your point 2 here seems a bit disconnected t= o me. If you want to fork yourself off the network, you can do it in easier w= ays, and if miners want to maliciously censors transactions to the detriment= of users, rejecting a version bit doesn=E2=80=99t really help avoid that. Your point about upgrade warnings is well-made, but I=E2=80=99m dubious of i= t=E2=80=99s value over the network chaos many large forks might otherwise ca= use. Matt > On Jan 10, 2020, at 17:22, Jorge Tim=C3=B3n wrote: >=20 > =EF=BB=BFWell, bip9 doesn't only fall apart in case of unreasonable object= ion, > 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. >=20 > 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: >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev >> wrote: >>=20 >> 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. >>=20 >> 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: >>=20 >> 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). >>=20 >> 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. >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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): >>=20 >>> 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. >>=20 >> 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. >>=20 >> 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: >>=20 >> 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). >>=20 >> 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. >>=20 >> Matt >>=20 >> Thanks also to AJ for feedback on an earlier version of this rant. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev