summaryrefslogtreecommitdiff
path: root/c5/4ed30a075b88a235222f4418b3c470a4237f53
blob: 6274e3722f0d1700b8ad3262d519c3f57e052432 (plain)
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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
Return-Path: <jtimon@jtimon.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E1890C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 14:03:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CCB58402E0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 14:03:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GDRXRyXSSnOe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 14:03:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
 [IPv6:2607:f8b0:4864:20::b2e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7452B402A7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 14:03:27 +0000 (UTC)
Received: by mail-yb1-xb2e.google.com with SMTP id u3so17267800ybh.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 06:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=3BgZ8IPIbszMtJxzq7b0KMbnE16S3/X13+zpUwKF7iQ=;
 b=79rm7PtB3fx05eZII3gckjr3qQKlM4sfZht1cx6gh2MqCAy5f0+fanakO37r+GIRev
 6TkYCyWSMhhuGzzOzDZmPKZ9X8Rhg2NBNLpnKj34u4Pi6qMpw3sM9XYoiK/HXHrbleDQ
 yl/PaiTbyRlgbe8M7/UCx2yVjjtJUau23QXo2a76RhuQutfAOMxqDYx0Cv8N6RbVfDtF
 7DL1zkU1tRoZjhpM9KQt5iDhLTD61AIvj2Wa/daTXYms+dpZ7fSUWSpxMIyDnYqynz2Q
 R9N245xYYcyCS5nXDnpw7f5vW4HduCBZeoUIE3RGFD6gDXxfBz0jCBuQljkG+Jnr1z/9
 L8yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=3BgZ8IPIbszMtJxzq7b0KMbnE16S3/X13+zpUwKF7iQ=;
 b=gkKsmkFT7d4YzcYYP80ceFAiT2eu7ZTgcd3xUAX1c8NdUDK6v+f3MBabwNvlEEoJWE
 Ym57Q8WUX/v4pWdbOMv1vbngqdeKqJESI1SyG7VjaxdxXnHbZQregGnKe4h5ghMEsUsZ
 vd2wUj4NUYlA1Q28rLxdJc8uERqu5QcGZEfloZ1vwdXDjgtWWLdCMJRh1AE8EKEh99Qz
 AGc8r3RDm95Qs+dKiPyPVLCeVWStuqrOxhKnW21DVPweKUtVpapnrwo+rhRbI7veYihX
 XFInr05SfWIUIXm0aRqJDapkdHO6g5iLtYAnxNXp+C0ODYjX7etMgB4PKF6ADH26Vkat
 NSNg==
X-Gm-Message-State: AOAM533GH6OlSVLtO8lGwOxfOAQFNlEkCvkLJ31fMbCZwhQiKhNsmT9U
 80WUekceRSV8mt1v+MQcR1APBiEYNvBkW1u42uGDl6htBAgLQQ==
X-Google-Smtp-Source: ABdhPJytD5t1ac3BzvFLEoqmDU8eFjJdafa4KKkOPR4VxdHn77PqVqqMVZR4En2A9c/5Pd/2yjDcObIwifJEhXmbqfY=
X-Received: by 2002:a25:dc8c:0:b0:628:df7f:424b with SMTP id
 y134-20020a25dc8c000000b00628df7f424bmr8119339ybe.620.1647007406111; Fri, 11
 Mar 2022 06:03:26 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
 <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
In-Reply-To: <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 11 Mar 2022 14:04:29 +0000
Message-ID: <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Mark <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="0000000000006250ec05d9f1cbcd"
X-Mailman-Approved-At: Fri, 11 Mar 2022 16:03:55 +0000
Subject: Re: [bitcoin-dev] Speedy Trial
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: Fri, 11 Mar 2022 14:03:29 -0000

--0000000000006250ec05d9f1cbcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed a=
ll
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>

What accusations of bad faith?
You're accusing me of having prosecution complex.
I'm accusing you of ignoring the "yes-users-veto" faction. But that doesn't
require bad faith, you may simply not understand the "faction".

A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr.  It turns out that, =
at
>>> the time of that proposal, a large amount of hash power simply did not =
have
>>> the firmware required to support signalling.  That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mi=
ning
>>> power offline if it had been deployed.  Imagine if the firmware couldn'=
t be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot.  Firstly, users can
> just not use taproot.  Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking t=
he
> source code.  Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>

Since it's about activation in general and not about taproot specifically,
your third point is the one that applies.
Users could have coordinated to have "activation x" never activated in
their chains if they simply make a rule that activating a given proposal
(with bip8) is forbidden in their chain.
But coordination requires time.
Please, try to imagine an example for an activation that you wouldn't like
yourself. Imagine it gets proposed and you, as a user, want to resist it.


As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed.  Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, the=
n
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>.  I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative.  A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-20=
22.pdf>
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology.  But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowled=
ge
> proof of the chaincode used to derive them.
>

Thank you, perhaps I'm wrong about this and all his concerns were addressed
and all his suggestions heard. I guess I shouldn't have brought that up,
since I cannot talk for Mark.

_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000006250ec05d9f1cbcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Mar 11, 2022, 13:47 Russell O&#39;Con=
nor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"></div><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 11, 2022=
 at 7:18 AM Jorge Tim=C3=B3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" target=
=3D"_blank" rel=3D"noreferrer">jtimon@jtimon.cc</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=
=3D"auto">I talked about this. But the &quot;no-divergent-rules&quot; facti=
on doesn&#39;t like it, so we can pretend we have listened to this &quot;fa=
ction&quot; and addressed all its concerns, I guess.</div><div dir=3D"auto"=
>Or perhaps it&#39;s just &quot;prosectution complex&quot;, but, hey, what =
do I know about psychology? <br></div></div></blockquote><div><br></div><di=
v>Your accusations of bad faith on the part of myself and pretty much every=
one else makes me disinclined to continue this discussion with you.=C2=A0 I=
&#39;ll reply, but if you want me to continue beyond this, then you need to=
 knock it off with the accusations.=C2=A0</div></div></div></blockquote></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">What accusations of bad fa=
ith?</div><div dir=3D"auto">You&#39;re accusing me of having prosecution co=
mplex.</div><div dir=3D"auto">I&#39;m accusing you of ignoring the &quot;ye=
s-users-veto&quot; faction. But that doesn&#39;t require bad faith, you may=
 simply not understand the &quot;faction&quot;.</div><div dir=3D"auto"><br>=
</div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"=
auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"auto"><div dir=3D"auto">A major contender to the Speedy=
 Trial design at the time was to mandate eventual forced signalling, champi=
oned by luke-jr.=C2=A0 It turns out that, at the time of that proposal, a l=
arge amount of hash power simply did not have the firmware required to supp=
ort signalling.=C2=A0 That activation proposal never got broad consensus, a=
nd rightly so, because in retrospect we see that the design might have risk=
ed knocking a significant fraction of mining power offline if it had been d=
eployed.=C2=A0 Imagine if the firmware couldn&#39;t be quickly updated or i=
magine if the problem had been hardware related.</div></div></blockquote></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes, I like this so=
lution too, with a little caveat: an easy mechanism for users to actively o=
ppose a proposal.</div><div dir=3D"auto">Luke alao talked about this.</div>=
<div dir=3D"auto">If users oppose, they should use activation as a trigger =
to fork out of the network by invalidating the block that produces activati=
on.</div><div dir=3D"auto">The bad scenario here is that miners want to dep=
loy something but users don&#39;t want to.</div><div dir=3D"auto">&quot;But=
 that may lead to a fork&quot;. Yeah, I know.</div><div dir=3D"auto">I hope=
 imagining a scenario in which developers propose something that most miner=
s accept but some users reject is not taboo.</div></div></blockquote><div><=
br></div><div>This topic is not taboo.<br></div><div><br></div><div><div>Th=
ere are a couple of ways of opting out of taproot.=C2=A0 Firstly, users can=
 just=20
not use taproot.=C2=A0 Secondly, users can choose to not enforce taproot ei=
ther by running an older version of Bitcoin Core or otherwise forking the s=
ource code.=C2=A0 Thirdly, if some users insist on a chain where taproot is=
 &quot;not activated&quot;, they can always softk-fork in their own rule th=
at disallows
 the version bits that complete the Speedy Trial activation sequence, or al=
ternatively soft-fork in a rule to make spending from (or to) taproot addre=
sses illegal.</div></div></div></div></blockquote></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Since it&#39;s about activation in general and n=
ot about taproot specifically, your third point is the one that applies.</d=
iv><div dir=3D"auto">Users could have coordinated to have &quot;activation =
x&quot; never activated in their chains if they simply make a rule that act=
ivating a given proposal (with bip8) is forbidden in their chain.</div><div=
 dir=3D"auto">But coordination requires time.</div><div dir=3D"auto">Please=
, try to imagine an example for an activation that you wouldn&#39;t like yo=
urself. Imagine it gets proposed and you, as a user, want to resist it.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div class=3D"gma=
il_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"auto"><div dir=3D"auto">As for mark, he wasn&#39;t talking about =
activation, but quantum computing concerns. Perhaps those have been &quot;a=
ddressed&quot;?</div><div dir=3D"auto">I just don&#39;t know where.</div></=
div></blockquote><div><br></div><div>Quantum concerns were discussed.=C2=A0=
 Working from memory, the arguments were (1) If you are worried about your =
funds not being secured by taproot, then don&#39;t use taproot addresses, a=
nd (2) If you are worried about everyone else&#39;s funds not being quantum=
 secure by other people choosing to use taproot, well it is already too lat=
e because over 5M BTC is currently quantum insecure due to pubkey reuse &lt=
;<a href=3D"https://nitter.net/pwuille/status/1108091924404027392" target=
=3D"_blank" rel=3D"noreferrer">https://nitter.net/pwuille/status/1108091924=
404027392</a>&gt;.=C2=A0 I think it is unlikely that a quantum breakthrough=
 will sneak up on us without time to address the issue and, at the very lea=
st, warn people to move their funds off of taproot and other reused address=
es, if not forking in some quantum secure alternative.=C2=A0 A recent paper=
 &lt;<a href=3D"https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/202=
2/01/Webber-2022.pdf" target=3D"_blank" rel=3D"noreferrer">https://www.suss=
ex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf</a>&gt; sug=
gest that millions physical qubits will be needed to break EC in a day with=
 current error correction technology.=C2=A0 But even if taproot were to be =
very suddenly banned, there is still a small possibility for recovery becau=
se one can prove ownership of HD pubkeys by providing a zero-knowledge proo=
f of the chaincode used to derive them.<br></div></div></div></blockquote><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">Thank you, perhaps I&#39=
;m wrong about this and all his concerns were addressed and all his suggest=
ions heard. I guess I shouldn&#39;t have brought that up, since I cannot ta=
lk for Mark.</div><div dir=3D"auto"><br></div><div class=3D"gmail_quote" di=
r=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_quote"><div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000006250ec05d9f1cbcd--