path: root/7c/d215d4a2b67501e0a22fef59e87c4d89e84101

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.
>