public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev]  Modern Soft Fork Activation
@ 2020-01-13  8:34 Yosef
  2020-01-14  3:20 ` Anthony Towns
  0 siblings, 1 reply; 13+ messages in thread
From: Yosef @ 2020-01-13  8:34 UTC (permalink / raw)
  To: bitcoin-dev

tl;dr How about 80% ?

The fallback to BIP-8 makes sense, but it's not a graceful one and we absolutely prefer BIP-9 to succeed. A failure to reach 95% readiness signalling means 2.5 years delay, 3.5 years in total, not yet counting.

95% can prove difficult to achieve. Some % of negligent miners that forget to upgrade is expected. Completing that to 5% is not too difficult for a small malicious minority trying to delay the activation. This is the issue Matt's goal #5 aims to prevent, and while the fallback to BIP-8 helps, BIP-9’s 95% requirement makes it worse by allowing quite a neglected minority to force a dramatic delay. Also note how in such case it would have been better to skip BIP-9 altogether and maybe save 1.5 years.

Matt mentions the 95% requirement under goal #3 "Don't (needlessly) lose hashpower to un-upgraded miners". If that is the trade-off, I'd say 2.5 years delay is worse than a momentary loss of hashrate. The protocol is quiet resilient to hashrate fluctuations and, as others mentioned, at that point miners don’t just signal, but lose coins if they don't upgrade, so the hashpower loss is expected to shortly correct. This also means goal #4 is not really effected.

On Sat Jan 11 14:42:07 UTC 2020, Anthony Towns wrote:

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

I agree, and believe the outreach and review process around taproot are maybe the best we had so far. Notably goal #1 should be mostly satisfied already at merge time, so risking 3.5 years delay after that, seems excessive.

BIP-91 “Reduced threshold Segwit MASF” was deployed by miners specifically to reduce the 95% requirement down to 80% during the segwit drama. While hopefully taproot won’t produce any such excitements, the events around segwit activation and the weird “hash wars” meme that later followed – might encourage some to try similar games again.

The difference between `5% minus apathetic-miners` and `20% minus apathetic-miners` is dramatic and can make such attempts an order of magnitude more difficult.

The taproot process is looking great so far, I feel it will be a mistake to put it on a route that can easily extend to so many years. I suggest keeping Matt’s proposal as is but decrease BIP-9’s 95% threshold down to around 80%.

Yosef


^ permalink raw reply	[flat|nested] 13+ messages in thread
* [bitcoin-dev] Modern Soft Fork Activation
@ 2020-01-10 21:30 Matt Corallo
  2020-01-10 22:21 ` Jorge Timón
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Matt Corallo @ 2020-01-10 21:30 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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.

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

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.

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

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.

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.

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.

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.

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.

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):

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

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.

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 regret
as Bitcoin continues to grow.

Matt

Thanks also to AJ for feedback on an earlier version of this rant.


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-01-16  3:46 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-13  8:34 [bitcoin-dev] Modern Soft Fork Activation Yosef
2020-01-14  3:20 ` Anthony Towns
  -- strict thread matches above, loose matches on Subject: below --
2020-01-10 21:30 Matt Corallo
2020-01-10 22:21 ` Jorge Timón
2020-01-10 22:43   ` Matt Corallo
2020-01-10 23:07     ` Jorge Timón
2020-01-10 23:37 ` Luke Dashjr
2020-01-11  0:54   ` Jeremy
2020-01-14 19:22   ` Matt Corallo
2020-01-11 14:42 ` Anthony Towns
2020-01-12  5:58   ` Luke Dashjr
2020-01-14 19:42   ` Matt Corallo
2020-01-16  3:46     ` Anthony Towns

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox