1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
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--
|
