From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C3FDFC000A for ; Thu, 8 Apr 2021 21:57:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id AC6446067E for ; Thu, 8 Apr 2021 21:57:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 3.935 X-Spam-Level: *** X-Spam-Status: No, score=3.935 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpmHx-KJxxWb for ; Thu, 8 Apr 2021 21:57:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from newmail.dtrt.org (newmail.dtrt.org [IPv6:2600:3c03::f03c:91ff:fe7b:78d1]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5C165605D6 for ; Thu, 8 Apr 2021 21:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org; s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4qhYNQz4xbRSwuPOb6wTvIbHvltO1gLinz33bIZZq10=; b=a1LDBfRnrFfiINv293dPhmdjg4 DYCbL6LhV4qPooQD5Uc1hRg2zWMz0lRgqrOQCYoYHBnyKeHnENFL9mui1xv8n9YCJ1bK+26P4M2v7 jMwdutkkM1lKg+1yvItisAwmprXYdvmT2gZHTueGuo5oUO+zh4DeP21u5KD4ccz0wjsQ=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1lUceZ-0002q4-V5; Thu, 08 Apr 2021 11:57:31 -1000 Date: Thu, 8 Apr 2021 11:56:05 -1000 From: "David A. Harding" To: Michael Folkson , Bitcoin Protocol Discussion Message-ID: <20210408215605.5qdcpwkay6cxyyvr@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4t3bixrwcgb2dmav" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 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: Thu, 08 Apr 2021 21:57:35 -0000 --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 " [...] 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--