From: "David A. Harding" <dave@dtrt•org>
To: Michael Folkson <michaelfolkson@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
Date: Thu, 8 Apr 2021 11:56:05 -1000 [thread overview]
Message-ID: <20210408215605.5qdcpwkay6cxyyvr@ganymede> (raw)
In-Reply-To: <CAFvNmHR54FCakJtaNvnwc3r6p8qhr+-e1MC2MennWm=tNZ2Unw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5015 bytes --]
On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> So the latest circus act is apparently a technical decision made by a
> coin toss [organized by] Jeremy Rubin
Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
and is the same method I've been using in Bitcoin-related discussions
for over seven years[3] to help people transition from ancillary arguments
back to working on the things they really think are important.
I proposed the coin toss because I understood that both the MTP and the
height approaches required tradeoffs that were, to a certain degree,
unresolvable to the best of our current knowledge. MTP is harder to
analyze for unexpected edge cases; heights would create extra work for
seasoned developers working on post-taproot soft forks. MTP would
require developers of currently-planned UASF software either do extra
work or wait to release their software; heights don't guarantee a
minimum amount of time for a large number of economic full nodes to
upgrade.
Different people gave different weights to the different tradeoffs. In
cases like this where there's no known way to eliminate the tradeoffs
and no way to objectively rank them, I think it's better to begin
working on something concrete than it is to try to persuade everyone to
adopt the same subjective ranking of the tradeoffs---or, as the IETF
published in RFC7282:
"There are times where the result of [an informal open-ended
conversation] is a pretty even split. In practical terms, that
means it doesn't matter where the chair starts the discussion. And
in fact, we've had working groups where a coin flip decided which
proposal to start with. That doesn't mean that the coin flip
determined the outcome; if a fatal technical flaw was found in the
solution that won the coin flip, it is still incumbent upon the
group to address the issue raised or abandon that solution and find
another. Rough consensus on the technical points, in the end, is
always required. Any way to find a place to start, be it the hum or
the coin flip, is only getting to the beginning of the discussion,
not the end."
As Jeremy wrote, in this occassion, we didn't actually need the coin
toss. The authors of the two PRs we were considering found a compromise
solution that seems to be good enough for both of them and which so far
seems to be good enough for the handful of people who agreed to the coin
toss (plus, it seems, several others who didn't agree to the toss).
In short, I think the coin toss was a good attempt. Although we didn't
use its results this time, I think it's something we should keep in our
toolkit for the future when a group of people want to coordinate their
work on getting *a* solution released, even in cases where they don't
necessarily start out in agreement about which solution is best.
> I dread to think what individuals and businesses all over the world
> who have plans to utilize and build on Taproot are making of all of
> this.
Geeks arguing over minutia is a well established stereotype. That we've
conformed to that stereotype in this case is not great---but I don't
think it does us any significant reputational harm. I hope those
individuals and businesses awaiting taproot are discerning enough to
realize that the method we use to activate taproot has nothing to do
with taproot itself. I hope they realize that it remains the case that
there is nearly universal support for taproot from every entity that has
so far commented on it.
Hopefully we've made progress on Speedy Trial this week, that progress
will continue and we'll be able to release activation-ready software
soon, miners will be willing to signal for taproot, and we'll soon be
able to end this chapter in Bitcoin's storied history of soft fork
activations.[4] (But I look forward to continued discussion about
better activation mechanisms for the future---if taproot locks in
quickly, I'd love to see human consensus form around a follow-up
deployment even before taproot reaches activation.)
Respectfully,
-Dave
[1] http://gnusha.org/taproot-activation/2021-04-04.log "<harding> [...]
If that's not our goal and we just want to give miners a chance to
activate taproot as soon as possible (which was certainly my original
objective in supporting ST), I'm personally happy with either MTP or
heights, and I'd be willing to join others in putting my effort behind
just one of them based on fair random chance."
[2] http://gnusha.org/taproot-activation/2021-04-04.log "18:09 <
harding> e.g.: bitcoin-cli getblockhash 123456 | cut -b64 | grep -q
'[02468ace]' && echo MTP || echo height"
[3] E.g.,
https://github.com/bitcoin-dot-org/Bitcoin.org/pull/589#discussion_r18314009
and https://github.com/bitcoin-dot-org/Bitcoin.org/pull/566#issuecomment-56281595
[4] https://bitcoinops.org/en/topics/soft-fork-activation/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-04-08 21:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 11:40 Michael Folkson
2021-04-08 14:30 ` Andrew Poelstra
2021-04-08 15:18 ` Matt Corallo
2021-04-08 21:56 ` David A. Harding [this message]
2021-04-09 11:19 ` Michael Folkson
2021-04-10 12:07 ` Michael Folkson
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=20210408215605.5qdcpwkay6cxyyvr@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@gmail$(echo .)com \
/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