From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EB022C000A for ; Sat, 10 Apr 2021 12:07:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CDA5083C27 for ; Sat, 10 Apr 2021 12:07:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uARnW--nZ9P for ; Sat, 10 Apr 2021 12:07:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by smtp1.osuosl.org (Postfix) with ESMTPS id 94BCB83C24 for ; Sat, 10 Apr 2021 12:07:52 +0000 (UTC) Received: by mail-ot1-x32a.google.com with SMTP id v24-20020a9d69d80000b02901b9aec33371so8305830oto.2 for ; Sat, 10 Apr 2021 05:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mt5jqiUHy1I1r1kMYPGo0rSy/ubNKhMeY3R24hi6Qw8=; b=o3NlhlNOP7lL1Lw5K+AOJcPAjXcM5rtRYKjRPVDqS4LzRim7LOLXYE9GdLVEHmsh7q yPUqxSlApIRZhBkDEmdFI53VOxs8+X7scmrn01jjbNalXZS5nyv0aBBxIYSy7Vg/TptA Lp2XJXTfHAXt7Q7A3Vy5Zfz9WYiK5yxPJE604bq4D4PRPpoYX/GhIAmXP+vOdUHwSbhf d5S7ADZt6+8RDRR8KfA69HEiMF21UUc8Z9r04Y4Jg3eeWG3RF/EUrxaK4iqr59oi2wOz XYmTJbcbrx1OuUmennwM6GHAV3qPPhntbcCJ1oAS8qs6+kR58CF+nh0WX0BGg06UfyGP J6wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mt5jqiUHy1I1r1kMYPGo0rSy/ubNKhMeY3R24hi6Qw8=; b=SyfL8EUT7oMmBYEdqsMc5dn11sLs/ouvPHxIh/B+exz0zc+smNNkwZ8V4EfdERuoF6 tLOOliBzXaef7xCIu+n5lW7N4oPyxNCTjHzR2VgbIwy1Td18+up1J5sHTVJ/TqJiNsMf McskBCaUCn0Zx+g5GBlzY0O+tJwAgP027X382PDYWb6XPT+QH3SOMUiAIXjByxQQyFP2 OBIzDYnm8VM3l9sglxOmmzal45sEdpune0Tr/RVSvqZs/3xt7InLn1Sel9NbdpzfDjjS l3Js/gW8Q/792I7gaz+No9xi4RRA7UKXCmAuD0k0WFBedFdstVZ4sJDc7OLaLA6egAKC LD4Q== X-Gm-Message-State: AOAM5301Jj468QvqWMJfLzmm5V0cQ8tqZHGBk/lzJdR1PDc67UTlmoIU AozWX7eLTn0pLh4ZP3TEvvnhSbZw/9gPFVtNZAU= X-Google-Smtp-Source: ABdhPJypPFwTQs8MIrB9D/m1aO6kjOvVhplXAYBH/KCCChB6BVKAIjtjgOOeAzkqkdnhlf/DAwl2IQNh839XAtavA9Y= X-Received: by 2002:a9d:12d3:: with SMTP id g77mr989000otg.290.1618056471311; Sat, 10 Apr 2021 05:07:51 -0700 (PDT) MIME-Version: 1.0 References: <20210408215605.5qdcpwkay6cxyyvr@ganymede> In-Reply-To: From: Michael Folkson Date: Sat, 10 Apr 2021 13:07:40 +0100 Message-ID: To: "David A. Harding" Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 10 Apr 2021 14:13:09 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 12:07:54 -0000 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 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 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 " [...] > > 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