public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Yosef" <asix@disroot.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev]  Modern Soft Fork Activation
Date: Mon, 13 Jan 2020 08:34:24 +0000	[thread overview]
Message-ID: <415e793656ab4326b48d9dc050a85eb8@disroot.org> (raw)

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


             reply	other threads:[~2020-01-13  8:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13  8:34 Yosef [this message]
2020-01-14  3:20 ` [bitcoin-dev] Modern Soft Fork Activation 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=415e793656ab4326b48d9dc050a85eb8@disroot.org \
    --to=asix@disroot.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox