path: root/59/72446af0c72388a0a1a94f59fe8f31f05b9d8f

Return-Path: <lf-lists@mattcorallo.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5B481C0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 17:43:35 -0500
Message-Id: <A0DE3A1A-CE90-427E-8D61-9F7DBE800532@mattcorallo.com>
References: <CABm2gDq3dAFmRkH2J7d7PcN0A6-F+ZOT22YsDpiORDARmpvu9g@mail.gmail.com>
In-Reply-To: <CABm2gDq3dAFmRkH2J7d7PcN0A6-F+ZOT22YsDpiORDARmpvu9g@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Mailer: iPhone Mail (17C54)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: 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 <jtimon@jtimon.cc> 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
>> <bitcoin-dev@lists.linuxfoundation.org> 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