diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2020-01-14 19:42:07 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-01-14 19:42:14 +0000 |
| commit | 75d529eada35371adb4e53911183d7a3615e2d8b (patch) | |
| tree | ec7d212176e19c140978eb3fd16073264eaddfb7 | |
| parent | ae2f48dd46823642ad1e03a51ee1d274c6911aa0 (diff) | |
| download | pi-bitcoindev-75d529eada35371adb4e53911183d7a3615e2d8b.tar.gz pi-bitcoindev-75d529eada35371adb4e53911183d7a3615e2d8b.zip | |
Re: [bitcoin-dev] Modern Soft Fork Activation
| -rw-r--r-- | 7c/d215d4a2b67501e0a22fef59e87c4d89e84101 | 338 |
1 files changed, 338 insertions, 0 deletions
diff --git a/7c/d215d4a2b67501e0a22fef59e87c4d89e84101 b/7c/d215d4a2b67501e0a22fef59e87c4d89e84101 new file mode 100644 index 000000000..66faf9f5a --- /dev/null +++ b/7c/d215d4a2b67501e0a22fef59e87c4d89e84101 @@ -0,0 +1,338 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 9644BC077D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Jan 2020 19:42:14 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 7FBBB85A03 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Jan 2020 19:42:14 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from hemlock.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id vtS6KMmtDITi + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Jan 2020 19:42:09 +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 hemlock.osuosl.org (Postfix) with ESMTPS id DAE4E8594B + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Jan 2020 19:42:08 +0000 (UTC) +Received: from [10.233.42.100] (unknown [69.59.18.156]) + by mail.as397444.net (Postfix) with ESMTPSA id 5BD7D16AFBC; + Tue, 14 Jan 2020 19:42:07 +0000 (UTC) +To: Anthony Towns <aj@erisian.com.au>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +References: <20200111144207.5xzspeptstspsbsf@erisian.com.au> +From: Matt Corallo <lf-lists@mattcorallo.com> +Message-ID: <a7fc5d7f-9b11-ed8e-0513-fd863881290e@mattcorallo.com> +Date: Tue, 14 Jan 2020 19:42:07 +0000 +User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 + Thunderbird/60.9.0 +MIME-Version: 1.0 +In-Reply-To: <20200111144207.5xzspeptstspsbsf@erisian.com.au> +Content-Type: text/plain; charset=utf-8 +Content-Language: en-US +Content-Transfer-Encoding: 8bit +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 14 Jan 2020 19:42:14 -0000 + +In general, your thoughts on the theory of how consensus changes should +work I strongly agree with. However, my one significant disagreement is +how practical it is for things to *actually* work that way. While I wish +ecosystem players (both businesses and users) spent their time +interacting with the Bitcoin development community enough that they had +a deep understanding of upcoming protocol change designs, it just isn't +realistic to expect that. Thus, having an "out" to avoid activation +after a release has been cut with fork activation logic is quite a +compelling requirement. + +Thus, part of the goal here is that we ensure we have that "out", and +can observe the response of the ecosystem once the change is "staring +them in the face", as it were. A BIP 9 process is here not only to offer +a compelling activation path, but *also* to allow for observation and +discussion time for any lingering minor objections prior to a BIP 8/flag +day activation. + +As for a "mandatory signaling period" as a part of BIP 8, I find this +idea strange both in that it flies in the face of all recent soft fork +design work, and because it doesn't actually accomplish its stated goal. + +Recent soft-fork design has all been about how to design something with +minimal ecosystem impact. Certainly in the 95% activation case I can't +say I feel strongly, but if you actually *hit* the BIP 8 flag day, +deliberately causing significant network forks for old clients has the +potential to cause real ecosystem risk. While part of the reason for a +24-month time horizon between BIP 8 decision and flag-day activation +endeavors to de-risk the chance that major players are running on +un-upgraded nodes, you cannot ignore the reality of them, both full-, +and SPV-clients. + +On the other hand, in practice, we've seen that version bits are set on +the pool side, and not on the node side, meaning the goal of ensuring +miners have upgraded isn't really accomplished in practice, you just end +up forking the chain for no gain. + +Matt + +On 1/11/20 2:42 PM, Anthony Towns wrote: +> On Fri, Jan 10, 2020 at 09:30:09PM +0000, Matt Corallo via bitcoin-dev wrote: +>> 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). +> +> FWIW etc, but my perspective on this is that the way we want consensus +> changes in Bitcoin to work is: +> +> - decentralised: we want everyone to be able to participate, in +> designing/promoting/reviewing changes, without decision making +> power getting centralised amongst one group or another +> +> - technical: we want changes to be judged on their objective technical +> merits; politics and animal spirits and the like are fine, especially +> for working out what to prioritise, but they shouldn't be part of the +> final yes/no decision on consensus changes +> +> - improvements: changes might not make everyone better off, but we +> don't want changes to screw anyone over either -- pareto +> improvements in economics, "first, do no harm", etc. (if we get this +> right, there's no need to make compromises and bundle multiple +> flawed proposals so that everyone's an equal mix of happy and +> miserable) +> +> In particular, we don't want to misalign skills and responsibilities: it's +> fine for developers to judge if a proposal has bugs or technical problems, +> but we don't want want developers to have to decide if a proposal is +> "sufficiently popular" or "economically sound" and the like, for instance. +> Likewise we don't want to have miners or pool operators have to take +> responsibility for managing the whole economy, rather than just keeping +> their systems running. +> +> So the way I hope this will work out is: +> +> - investors, industry, people in general work out priorities for what's +> valuable to work on; this is an economic/policy/subjective question, +> that everyone can participate in, and everyone can act on -- +> either directly if they're developers who can work on proposals and +> implementations directly, or indirectly by persuading or paying other +> people to work on whatever's important +> +> - developers work on proposals, designing and implementing them to make +> (some subset of) bitcoin users better off, and to not make anyone worse +> off. +> +> - if someone discovers a good technical reason why a proposal does make +> people worse off, we don't try to keep pushing the proposal over the +> top of objections, but go back to the drawing board and try to fix +> the problems +> +> - once we've done as much development as we can, including setting up +> experimental testnet/signet style deployments for testing, we setup a +> deployment. the idea at this point is to make sure the live network +> upgrade works, and to retain the ability to abort if last minute +> problems come up. no doubt some review and testing will be left until +> the last minute and only done here, but *ideally* the focus should be +> on catching errors *well before* this point. +> +> - as a result, the activation strategy mostly needs to be about ensuring +> that the Bitcoin network stays in consensus, rather than checking +> popularity or voting -- the yes/no decisions should have mostly been +> made earlier already. so we have two strategies for locking in the +> upgrade: either 95%+ of hashpower signals that they've upgraded to +> software that will enforce the changes forever more, _or_ after a +> year of trying to deploy, we fail to find any technical problems, +> and then allow an additional 2.5 years to ensure all node software is +> upgraded to enforce the new rules before locking them in. +> +> The strategy behind the last point is that we need to establish that +> there's consensus amongst all of Bitcoin before we commit to a flag day, +> and if we've found some method to establish consensus on that, then we're +> done -- we've already got consensus, we don't need to put a blockchain +> protocol on top of that and signal that we've got consensus. (Activating +> via hashpower still needs signalling, because we need to coordinate on +> *when* sufficient hashpower has upgraded) +> +> This approach is obviously compatible with BIP-148 or BIP-91 style +> forced-signalling UASFs if some upgrade does need to be done urgently +> despite miner opposition; the forced signalling just needs to occur during +> the BIP-9 or BIP-8 phases, and no during the "quiet period". Probably the +> first period of BIP-8 after the quiet period would make the most sense. +> +> But without that, this approach seems very friendly for miners: even +> if they don't upgrade, they won't mine invalid blocks (unless the rules +> activate and someone else deliberately mines an invalid block and they +> build on top of it), and if a change is incompatible with, say 10% +> of hashpower, it won't be forced on them for 3.5 years, by which point +> it's probably a good bet that everyone's upgrading to a new generation +> of mining hardware anyway. But even that's a backstop, because if a +> change *is* incompatible with existing mining hardware, that's an easily +> describable technical problem that should mean we go back to the drawing +> board and fix it, not deploy the change despite the problems. [0] +> +> On Fri, Jan 10, 2020 at 11:21:51PM +0100, Jorge Timón via bitcoin-dev wrote: +>> Regarding bip8-like activation, luke-jr suggested that [..] a +>> consensus rule could require the blocks to signal for activation in +>> the last activation window. +> +> FWIW, that had been my (strong) preference too, but I think I'm now +> convinced it's not needed/useful. +> +>> 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. +> +> The 3.5 year window from BIP-9-starttime to BIP-8-flagday means you'd +> have to be using *very* out of date software to need to autodetect +> unknown upgrades. If an upgrade starts on 2021-01-01 say, it'd be +> supported by 0.21.x, 0.22.0, and 0.23.0 (with bip8 as an opt-in) and +> 0.24.0, 0.25.0, 0.26.0, 0.27.0, and 0.28.0 (with bip8 as always on) +> before flag day activation on 2024-06-01. +> +> 0.21.x to 0.23.x could warn if they see potential early BIP-8 activation +> via versionbits, and also warn if the flag day date is seen saying "flag +> day activation may have happened, please check external sources and +> consider upgrading your node software". +> +> So you'd need to be running 0.20.x, released 4 years prior to the +> activation to be outdated enough to not get warnings, I think. +> +>> 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. +> +> If you're knowingly doing a deliberate minority chain split, you'll +> almost certainly change the PoW function, and trivially get a clean +> split as a result of doing that. +> +> But I think what we want is to move away from consensus decisions being a +> "who has the most money/power/hashpower/nodes/reddit-accounts" contest +> to being a question of "have we dealt with every reasonable technical +> objection?" -- I think that's better for decentralisation in that anyone +> can stop a bad proposal without having to be rich/powerful/persuasive, +> and better for encouraging constructive contributions. +> +> The other side to this is that if it's just a matter of resolving +> technical problems, then it's also straightforward for a small but skilled +> group to get a consensus change through even if the vast majority doesn't +> think it's a priority -- they just need to make a good proposal, make +> sure it doesn't make people worse off, work through all the objections +> people find, and be willing to wait for it to go through reviews and +> upgrade steps which may take extra time if other people don't think it's +> a high priority. But those are all just technical challenges, that can +> be resolved with skill and patience, whoever you might be. So to me, +> that's a win for decentralisation as well. +> +>> 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. +> +> For me, the focus there is on Matt's first point: "avoid activating +> [or merging, or even proposing] in the face of significant, reasonable, +> and directed objection". If you want to stop a change you should have to +> do nothing more than describe the problems with it; and if there aren't +> problems with it, you shouldn't be trying to stop the change. +> +> (A benefit to having the BIP-8 settings defined simultaneously with +> the initial activation attempt is that it means that if the core +> devs/maintainers go crazy with power and try to force/prevent the BIP-8 +> activation despite clear community consensus going the other way, then +> it will be easy to for the client, and set the parameter correctly -- +> literally just a matter of changing a value in chainparams.cpp, unlike the +> difficulties of changing the blocksize from 1MB to 2MB. Other variations +> of this overall approach have the same benefit) +> +> Cheers, +> aj (very grateful to Greg and Matt for explaining a lot of thing +> about this approach and helping resolve my concerns with it) +> +> [0] Trigger warning, PTSD over the 2015-2017 blocksize wars... +> +> The segwit timeline was something like this: +> +> 2015-05 - blocksize debate begins on bitcoin-dev +> 2015-08 - bitcoin xt with bip101 hardfork released +> 2015-09 - scaling bitcoin phase 1 +> 2015-12 - segwit proposal at scaling bitcoin phase 2 +> 2016-01 - segwit testnet launched +> 2016-02 - bitcoin classic with bip109 hardfork released +> 2016-04 - first release (0.12.1) with a bip9 deployment (csv) +> 2016-06 - segwit merged +> 2016-07 - csv activated +> 2016-10 - first release (0.13.1) with segwit activation params +> 2016-11 - segwit activation starttime +> 2017-02 - UASF first proposed +> 2017-03 - antpool to swith to bitcoin unlimited +> 2017-04 - covert ASICBoost vs segwit conflict described +> 2017-05 - NY segwit2x agreement, btc1 with bip102 hardfork started +> 2017-05 - BIP-91 proposed +> 2017-06 - UAHF proposal from bitmain that became BCH +> 2017-07 - BIP-91 lockin +> 2017-08 - BIP-148 activation +> 2017-08 - BCH chainsplit +> 2017-08 - segwit lockin and activation +> 2017-11 - 2x fork called off; btc1 nodes stall; 2x chain stillborn +> 2018-02 - first release (0.16.0) with segwit wallet support +> +> (That's about 33 months in total, compared to the 24 months we've +> already spent since taproot was first described in Jan 2018, or the +> 42 months before flag-day activation in Matt's proposal) +> +> I don't think that timeline is a good example of how things should +> work, and would call out a few mistakes in particular: +> +> * too much urgency to increase the blocksize resulting in rushed +> decision making, especially for the hardfork implementations, but +> also for segwit +> +> * alternative clients attempted to activate forks without +> resolving technical problems (eventually resulting in the btc1 +> client stalling prior to the expected hard fork block, eg) +> +> * a lot of emphasis was on numbers (market share, hashpower, etc) +> rather than technical merits, resulting in a lot of false +> signalling an political meaneuvering +> +> * the incompatibility between ASICBoost and segwit wasn't noticed +> prior to activation, and wasn't fixed when it was noticed +> (certainly you can justify this as a tit-for-tat response to the +> other errors having been made in bad faith, or as not being a real +> problem because everyone claimed that they weren't doing covert +> ASICBoost, but considered on its own I think the incompatibility +> should have been resolved) +> +> * the UASF approach had significant potential technical problems +> (potential for long reorgs, p2p network splits) that weren't +> resolved by the time it became active. happily, this was mitigated +> by hashpower enforcement of BIP-148 rules via BIP-91. neither +> BIP-148 or BIP-91 gained enough consensus to be supported in +> bitcoin core though +> +> I don't personally think we need to fix every problem we had with +> segwit's process -- it eventually mostly worked out okay, after all -- +> but I think Matt's approach has a good chance of fixing a lot of +> them, while still leaving us flexibility to deal with whatever new +> problems we come up with in their place. +> + |