MIME-Version: 1.0
References: <CAFvNmHR54FCakJtaNvnwc3r6p8qhr+-e1MC2MennWm=tNZ2Unw@mail.gmail.com>
 <20210408215605.5qdcpwkay6cxyyvr@ganymede>
In-Reply-To: <20210408215605.5qdcpwkay6cxyyvr@ganymede>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Fri, 9 Apr 2021 12:19:02 +0100
Message-ID: <CAFvNmHSd-YJk4Sst4pSxLDfMyLw_4g+76vBfdKOJj9LgdbD-Ew@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
Precedence: list

I have no problem with coin tosses to decide for example shed colors
(an illustrative example discussed by copumpkin, roasbeef on IRC). In
this kind of example everyone should recognize it doesn't matter and
Approach ACK two competing PRs. No one should be NACKing or Approach
NACKing a PR based on shed color. If the maintainers don't care about
the shed color either then they are free to use a coin toss to decide
which PR to merge. In this example there shouldn't be any NACKs,
Approach NACKs or technical opposition from regular Core reviewers.
NACKs are not meant to be used for shed colors.

However, in this example the organizer of the coin toss had previously
NACKed one of the options (block height, though his position seems to
change by the day) and others have NACKed MTP. I think you have
consistently said it doesn't matter too much although you did
previously express a preference for block height.

I don't want to belabor the point but can we avoid even suggesting
using coin tosses on consensus code decisions in future please? It
makes a mockery of those who spent time understanding the technical
considerations and have spent months or years working on soft fork
activations. Even in the shed color example, leave it to the
maintainers to decide whether a coin toss is appropriate rather than
creating a circus around a coin toss in a public meeting where the PR
authors weren't present and no Core maintainers were present.

I understand the frustration and I understand the desire to break
deadlocks. But if the coin toss organizer hadn't previously NACKed one
of the options (block height) we may have avoided getting into this
deadlock in the first place.

Your recent review notes of PR #21377 look great and are proving very
helpful to me as I look at the PR.
https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40

Thanks
Michael

On Thu, Apr 8, 2021 at 10:57 PM David A. Harding <dave@dtrt.org> wrote:
>
> 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/


-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3