MIME-Version: 1.0
References: <CABm2gDq3dAFmRkH2J7d7PcN0A6-F+ZOT22YsDpiORDARmpvu9g@mail.gmail.com>
 <A0DE3A1A-CE90-427E-8D61-9F7DBE800532@mattcorallo.com>
In-Reply-To: <A0DE3A1A-CE90-427E-8D61-9F7DBE800532@mattcorallo.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sat, 11 Jan 2020 00:07:00 +0100
Message-ID: <CABm2gDoCR9JJ=FS1wCy0D3qtFR4=TTMJEDBXNJCo6JG29=Q85Q@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
Precedence: list

I see how your approach doesn't lose goal 3 while "mine" does.
Regarding goal 4, I don't think any of the approaches loses it. "Use
hashpower enforcement to de-risk the upgrade process, wherever
possible".
Well, in the case of activation while there's "many" non upgrade
miners, they simply can't help to reduce upgrade risks unless they
upgrade. It doesn't matter if the activation is silent or with
mandatory signaling. Am I missing something?

>  in order to nudge miners

That's not the goal at all. All my arguments have been focused on
users, not miners.

> If you want to fork yourself off the network, you can do it in easier way=
s,

Well, it's not that you want to fork yourself off the network, is that
you don't want change X. Ideally change X wouldn't be activated, but
if it is, you prefer to be in a chain without change X.
Let's say we're using your system to deploy change X you oppose for
legitimate reasons.
What easier thing would you do as a user to resist change X with all
other users who also oppose it?

If there are simpler and better ways to do this, great. It's just
something to think about.


On Fri, Jan 10, 2020 at 11:43 PM Matt Corallo <lf-lists@mattcorallo.com> wr=
ote:
>
> 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 po=
or trade off. I=E2=80=99ll note that your point 2 here seems a bit disconne=
cted to me. If you want to fork yourself off the network, you can do it in =
easier ways, and if miners want to maliciously censors transactions to the =
detriment of users, rejecting a version bit doesn=E2=80=99t really help avo=
id that.
>
> Your point about upgrade warnings is well-made, but I=E2=80=99m dubious o=
f it=E2=80=99s value over the network chaos many large forks might otherwis=
e cause.
>
> Matt
>
> > On Jan 10, 2020, at 17:22, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> >
> > =EF=BB=BFWell, bip9 doesn't only fall apart in case of unreasonable obj=
ection,
> > 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.
> >
> > 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:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >> On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> There are a series of soft-fork designs which have recently been makin=
g
> >> 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.
> >>
> >> 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:
> >>
> >> 1) Avoid activating in the face of significant, reasonable, and direct=
ed
> >> 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 mu=
st
> >> 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 jum=
p
> >> to point out).
> >>
> >> 2) Avoid activating within a timeframe which does not make high
> >> node-level-adoption likely. As with all "node" arguments, I'll note th=
at
> >> 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.
> >>
> >> 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 upgrad=
ed
> >> and are capable of enforcing the new rules. Further, this is why recen=
t
> >> 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).
> >>
> >> 4) Use hashpower enforcement to de-risk the upgrade process, wherever
> >> possible. As a corollary of the above, one of the primary reasons we u=
se
> >> soft forks is that hashpower-based enforcement of rules is an elegant
> >> way to prevent network splits during the node upgrade process. While i=
t
> >> does not make sense to invest material value in systems protected by n=
ew
> >> rules until a significant majority of "economic nodes" is enforcing sa=
id
> >> rules, hashpower lets us neatly bridge the gap in time between
> >> activation and then. By having a supermajority of miners enforce the n=
ew
> >> 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.
> >>
> >> 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 t=
he
> >> 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 t=
o
> >> enable political football and compromise.
> >>
> >> 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 communit=
y
> >> 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 har=
d.
> >>
> >> BIP 8 has been proposed as an alternative, largely in response to issu=
es
> >> with #5. However, a naive deployment of it, rather obviously, complete=
ly
> >> 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 practic=
e
> >> 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 fulfi=
ll
> >> #3 and #4, but only by exploiting the "needlessly" and "wherever
> >> possible" loopholes.
> >>
> >> 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 loo=
ks
> >> 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.
> >>
> >> Thus, to strike a balance between the drawbacks of BIP 8 and BIP 9, th=
e
> >> Great Consensus Cleanup softfork proposal included this text in the
> >> discussion section (with the spec describing a BIP 9 deployment):
> >>
> >>> In spite of some suggestion that other activation methods be used, BI=
P
> >>> 9 is proposed as ensuring miners have upgraded to enforce new rules i=
s
> >>> 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 retur=
n
> >>> 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.
> >>
> >> 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 unreasonabl=
e
> >> 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, i=
t
> >> only slows down the process, it doesn't necessarily stop it. In the ca=
se
> >> 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 outreac=
h
> >> and discussion, there is something about a change with a timeframe tha=
t
> >> forces people to more carefully consider it.
> >>
> >> 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:
> >>
> >> 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).
> >>
> >> 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 regr=
et
> >> as Bitcoin continues to grow.
> >>
> >> Matt
> >>
> >> 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
>