From: Michael Folkson <michaelfolkson@gmail•com>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
Date: Sat, 10 Apr 2021 13:07:40 +0100 [thread overview]
Message-ID: <CAFvNmHQTy+hfJHs7NvoOAOxkX0-dt6N8mg0Hj846KGr2H3mD5w@mail.gmail.com> (raw)
In-Reply-To: <CAFvNmHSd-YJk4Sst4pSxLDfMyLw_4g+76vBfdKOJj9LgdbD-Ew@mail.gmail.com>
In my previous email in response to David Harding I said:
"I think you have consistently said it doesn't matter too much
although you did previously express a preference for block height."
This was based on:
"My preference would be for whatever solution is most preferred by
reviewers." March 7th
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792220340
With a greater number of PR comments preferring block height at this
point I concluded that this equated to a preference for block height.
I'm happy to correct my previous statement having spoken to David.
This did not equate to a preference and David was entirely neutral.
For the sake of the mailing list (even though David didn't do so)
expressing preferences on a PR is absolutely fine. It is fine to say
"This is my preference" without NACKing a PR or NACKing a technical
decision. I (and many others) have done this. Maintainers can look
through the PR, read the rationales for the preferences and still
consider merging the PR. However, well reasoned NACKs (e.g. Concept,
Approach NACKs) make it difficult for maintainers to merge a PR
especially if they are from long term contributors. If you oscillate
from a preference one way to a full on NACK the other way to "Let's
coin flip it" with minimal rationale you are making maintainers' jobs
even more difficult. You are also wasting the time of reviewers who
don't know which PR to review and which PR stands a better chance of
being merged. You are also (unintentionally) increasing the risk of
bugs not being caught because the PR that eventually gets merged
hasn't received the review it could have.
I have been criticized on IRC for the tone of my emails. To be clear I
take Taproot activation seriously, I take the Core review process
seriously and I take keeping the community informed of the likely
timetable seriously. I'm not impressed by people wasting my time and
I'm doubly not impressed by people wasting other Core reviewers' time
and maintainers' time. If that informs my tone so be it. This is not
directed towards David who has worked hard to make progress with
Taproot activation, hasn't wasted anyone's time and I have a huge
amount of respect for.
In terms of the latest state of play with Core, there is an open Core
PR for Speedy Trial (#21377) that appears to be our best chance of
getting activation code merged into Core. The more testing and code
review this Core PR receives the better. If it continues to make
progress the discussion will then need to move onto a timetable.
On Fri, Apr 9, 2021 at 12:19 PM Michael Folkson
<michaelfolkson@gmail•com> wrote:
>
> 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
--
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
prev parent reply other threads:[~2021-04-10 12:07 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
2021-04-09 11:19 ` Michael Folkson
2021-04-10 12:07 ` Michael Folkson [this message]
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=CAFvNmHQTy+hfJHs7NvoOAOxkX0-dt6N8mg0Hj846KGr2H3mD5w@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