Date: Thu, 8 Apr 2021 11:56:05 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Michael Folkson <michaelfolkson@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210408215605.5qdcpwkay6cxyyvr@ganymede>
References: <CAFvNmHR54FCakJtaNvnwc3r6p8qhr+-e1MC2MennWm=tNZ2Unw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="4t3bixrwcgb2dmav"
Content-Disposition: inline
In-Reply-To: <CAFvNmHR54FCakJtaNvnwc3r6p8qhr+-e1MC2MennWm=tNZ2Unw@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
Precedence: list


--4t3bixrwcgb2dmav
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev w=
rote:
> 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.=20

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-56=
281595

[4] https://bitcoinops.org/en/topics/soft-fork-activation/

--4t3bixrwcgb2dmav
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmBve/UACgkQ2dtBqWwi
adOhvQ/8D0/QlXe5IO6I6DHl1xnr2K1yjavcDToyUVsE2b8qXzQWVCZsJQQ8ljHq
tbY3MjuRNRGIGVu2b0onwHT0aBsjq6oD+4SPls4G+3xxaoVxC0XQi5LC5Vhm9VaU
dZOIdfPXuECbH3sukiEXhvrKFRnhC9BLyxiysUJmHdUUfP8hBrDuVKvNqbv9AqUX
tcQAA/wtjkiQCovfGzODmj7nVjiiqFObijMV2OgdA8a4g56+3ggYieg5Bv18AAoh
VQyZ74NK+qccrBvJ9NEhoTI1EUDdK5ACsraE/Ek738OTb42hWB62S1M+/+0e74Xo
wWx4new6V37jvKJCTsSEyqs3X8gekqyJi5k8WbUhQ32S81REifLFB4OaIJrtYuIs
8eV7lCUojp9GVU6uiz5ut9mhU5g9qF4559jZL8KqX2i8bJb8Mq7NKKctH2xDqN01
hLf0lRgWLajtlApWwB7l67y9+s+ReKv3K+Jr01Bt6Dr3dp4mEPMzMFnxM6WcR9uZ
gCK/VEB9jB/KY1VS4JfWZHef4Ej0G+UxYPSLuhNknfkDIiIui4hyu4TPACHtrvkB
Ohp1gTiNFcHC7AJ9iPXgpdVbD08reFHDIyZ2gtPAF8XhIm1eYS2wADZeIZjCY8PN
bQoeMClkyATmOm+/LQy0NB1KW021nXfylMNNFzjvKcXO4jBHl88=
=l0sw
-----END PGP SIGNATURE-----

--4t3bixrwcgb2dmav--