summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnthony Towns <aj@erisian.com.au>2020-01-12 00:42:07 +1000
committerbitcoindev <bitcoindev@gnusha.org>2020-01-11 14:42:20 +0000
commitb36446b00f69a36c44c2198abac6e96f77d988cb (patch)
tree6d5903e2731280e13acb1e5757588d3796305837
parentb454550e197dcad9a71ee23331fb3e1db9632289 (diff)
downloadpi-bitcoindev-b36446b00f69a36c44c2198abac6e96f77d988cb.tar.gz
pi-bitcoindev-b36446b00f69a36c44c2198abac6e96f77d988cb.zip
Re: [bitcoin-dev] Modern Soft Fork Activation
-rw-r--r--f8/220a2869266c89463b3ec8d9e1f9be2ab24372301
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.
+
+