diff options
| author | David A. Harding <dave@dtrt.org> | 2021-04-08 11:56:05 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-04-08 21:57:35 +0000 |
| commit | 0da4d08b0378e74c44eb611b2ef7bffb30f751e9 (patch) | |
| tree | ee3d29211038c374717a0e880056dfda43046769 | |
| parent | fb453b51684858c38b941d56c5844b1b5e13e9b4 (diff) | |
| download | pi-bitcoindev-0da4d08b0378e74c44eb611b2ef7bffb30f751e9.tar.gz pi-bitcoindev-0da4d08b0378e74c44eb611b2ef7bffb30f751e9.zip | |
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
| -rw-r--r-- | 8a/93141f4b5be68a74328d8c578be3849ceff4b4 | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/8a/93141f4b5be68a74328d8c578be3849ceff4b4 b/8a/93141f4b5be68a74328d8c578be3849ceff4b4 new file mode 100644 index 000000000..df058cafa --- /dev/null +++ b/8a/93141f4b5be68a74328d8c578be3849ceff4b4 @@ -0,0 +1,192 @@ +Return-Path: <dave@dtrt.org> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C3FDFC000A + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <dave@dtrt.org>) + 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" <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 +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 "<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-- + |