diff options
author | Anthony Towns <aj@erisian.com.au> | 2020-01-12 00:42:07 +1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-01-11 14:42:20 +0000 |
commit | b36446b00f69a36c44c2198abac6e96f77d988cb (patch) | |
tree | 6d5903e2731280e13acb1e5757588d3796305837 | |
parent | b454550e197dcad9a71ee23331fb3e1db9632289 (diff) | |
download | pi-bitcoindev-b36446b00f69a36c44c2198abac6e96f77d988cb.tar.gz pi-bitcoindev-b36446b00f69a36c44c2198abac6e96f77d988cb.zip |
Re: [bitcoin-dev] Modern Soft Fork Activation
-rw-r--r-- | f8/220a2869266c89463b3ec8d9e1f9be2ab24372 | 301 |
1 files changed, 301 insertions, 0 deletions
diff --git a/f8/220a2869266c89463b3ec8d9e1f9be2ab24372 b/f8/220a2869266c89463b3ec8d9e1f9be2ab24372 new file mode 100644 index 000000000..b50fe2984 --- /dev/null +++ b/f8/220a2869266c89463b3ec8d9e1f9be2ab24372 @@ -0,0 +1,301 @@ +Return-Path: <aj@erisian.com.au> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 44F77C0881 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 11 Jan 2020 14:42:20 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id 33E6D20343 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 11 Jan 2020 14:42:20 +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 DM1mWN5EjHUT + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 11 Jan 2020 14:42:18 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) + by silver.osuosl.org (Postfix) with ESMTPS id 02E5F20243 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 11 Jan 2020 14:42:18 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) + id 1iqHxs-00042F-73; Sun, 12 Jan 2020 00:42:14 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Sun, 12 Jan 2020 00:42:07 +1000 +Date: Sun, 12 Jan 2020 00:42:07 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20200111144207.5xzspeptstspsbsf@erisian.com.au> +MIME-Version: 1.0 +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +In-Reply-To: <CABm2gDq3dAFmRkH2J7d7PcN0A6-F+ZOT22YsDpiORDARmpvu9g@mail.gmail.com> + <4a132f8a-22e3-8e31-e338-bed9ef46d2ef@mattcorallo.com> +User-Agent: NeoMutt/20170113 (1.7.2) +X-Spam-Score-int: -18 +X-Spam-Bar: - +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: Sat, 11 Jan 2020 14:42:20 -0000 + +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. + + |