From: Michael Folkson <michaelfolkson@gmail•com>
To: Dave Harding <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Date: Sat, 6 Mar 2021 19:56:02 +0000 [thread overview]
Message-ID: <CAFvNmHQKrw=UsUqNfBy2pO-LyfH=7VwO8z1VaHPvimXGReUyBQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]
Hi Matt
> I'm really unsure that three months is a short enough time window that
there wouldn't be a material effort to split the network with divergent
consensus rules. Instead, a three month window is certainly long enough to
organize and make a lot of noise around such an effort, given BIP 148 was
organized and reached its peak within a similar such window.
I'm not sure either. I can't control anyone other than myself. I think (and
Luke has also stated on IRC) that trying a UASF (LOT=true) during a "Speedy
Trial" deployment would be crazy. I would certainly recommend no one tries
that but I can't stop anyone. I'll repeat that soft forks have and always
will contain some limited chain split risk regardless of activation
mechanism. I think you are well intentioned but I'm not sure if you've
fully grasped that yet. Maybe you have and I'm missing something.
> Worse, because the obvious alternative after a three month activation
failure is a significant delay prior to activation, the vocal UASF minority
may be encouraged to pursue such a route to avoid such a delay.
Again I can only speak for myself but I wouldn't support a UASF until this
"fail fast" Speedy Trial has completed and failed. Luke agrees with that
and other people (eg proofofkeags) on the ##uasf IRC channel have also
supported this "Speedy Trial" proposal. If you want me (or anyone else for
that matter) to guarantee there won't be an attempted UASF during a Speedy
Trial deployment obviously nobody can do that. All I can say is that
personally I won't support one.
> One alternative may be to reduce the signaling windows involved and start
slightly later. Instead of the likelihood of failure growing on the
horizon, simply have two signaling windows (maybe two weeks, maybe a moth
each?). In order to ensure success remains likely, begin them somewhat
later after software release to give pools and miners a chance to configure
their mining software in advance.
The parameters for Speedy Trial are being hammered out on IRC as we speak.
I'd encourage you to engage with those discussions. I'd really like to
avoid a scenario where we have broad consensus on the details of Speedy
Trial and then you come out the woodwork weeks later with either an
alternative proposal or a criticism for how the details of Speedy Trial
were finalized.
I've read your email as you're concerned about a UASF during a Speedy Trial
deployment. Other than that I think (?) you support it and you are free to
join the discussion on IRC if you have particular views on parameters.
Personally I don't think those parameters should be chosen assuming there
will be a UASF during the deployment but you can argue that case on IRC if
you wish. All proposals you have personally put forward suffer from chain
split risk in the face of a competing incompatible activation mechanism.
--
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
[-- Attachment #2: Type: text/html, Size: 3385 bytes --]
next reply other threads:[~2021-03-06 19:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-06 19:56 Michael Folkson [this message]
2021-03-06 21:55 ` Matt Corallo
-- strict thread matches above, loose matches on Subject: below --
2021-03-15 14:06 Michael Folkson
2021-03-06 3:43 David A. Harding
2021-03-06 4:44 ` Jeremy
2021-03-06 6:04 ` Andrew Chow
2021-03-06 14:44 ` Russell O'Connor
2021-03-15 2:51 ` Luke Dashjr
2021-03-15 3:14 ` Andrew Chow
2021-03-06 9:29 ` Anthony Towns
2021-03-06 10:26 ` Eric Voskuil
2021-03-06 18:11 ` Matt Corallo
2021-03-06 20:23 ` David A. Harding
2021-03-06 21:48 ` Matt Corallo
2021-03-06 20:44 ` Ariel Luaces
2021-03-06 20:55 ` Keagan McClelland
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='CAFvNmHQKrw=UsUqNfBy2pO-LyfH=7VwO8z1VaHPvimXGReUyBQ@mail.gmail.com' \
--to=michaelfolkson@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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