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
|
Delivery-date: Wed, 28 May 2025 14:54:33 -0700
Received: from mail-yb1-f186.google.com ([209.85.219.186])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDI23FE35EIBBDMM33AQMGQETM5FWWI@googlegroups.com>)
id 1uKOjH-0001aJ-Vz
for bitcoindev@gnusha.org; Wed, 28 May 2025 14:54:32 -0700
Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e7d88956a25sf40182276.3
for <bitcoindev@gnusha.org>; Wed, 28 May 2025 14:54:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1748469265; x=1749074065; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=P9wQ7exgL0M1bFWknNyaF5lUnOAoDGchTzuEI285ef0=;
b=pzYC1P710bgkEuABBHcW74SwBw9Pe7TcHbXY4zH9h4r8rxtbSflMW887dsK7qG6rnA
jJAnjxYgnKoRED5C6miFdvfZZlysnmp6Fo9mSx659qaglxQf0eF73/9TgXaN++fRKzAt
fvf5ji7zo+AwfV9xhSTD+L46vhvH1zRBZkMaBL2Jq5tH9Va7I8o+hXJSgRndMqR2TWf8
WMeFKhfDlP6G+2cTGTeNx3cw/3MqrfgH+Fcgf+zTkzGJ15OutRdEWV3wz/T62d7tNKpt
PHO7jo3j0vZh4ps/DPfv2GacJvm9wZACgLHFCbuBl46okrDghQVjzkt3etAbXv5tGsni
i+Vg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748469265; x=1749074065; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=P9wQ7exgL0M1bFWknNyaF5lUnOAoDGchTzuEI285ef0=;
b=Cd6D9BqktRkzNr+Sj9V/iNsR8VrbKCgHs/E5ox0izSXDPB/JXUHr/nr9TfnZrNdUDG
1wra4z1Q+E2JBz+Ta7Ew0KuOZlBpI1kfQ5zaCf/Xc6Uox1GSZyQQOpqAxFpJxBHhZC6T
19JHLYmoToUK3rSRnhFczl2yj/KnGiUZftovQXQtR1cJX3ARUqmCSWEM/z156DNQNJhv
Jll+1NjsSRXgjcmY1fUWveJGuorRVM5g6BsU3Mz/kn2R4XgGS57VgEjxVR+rLykOFrOB
0ncu5qRGyedq50NkNBKGC0WFtiukF2PpNyoSOMx1XOfnRVgfB3PofevnlU6sdq6s17Oo
JAVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748469265; x=1749074065;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=P9wQ7exgL0M1bFWknNyaF5lUnOAoDGchTzuEI285ef0=;
b=meMMBQ4wiwY3LiuPXwqcYVHeXgVyReD0pYDLjcyOjkKeBAYiDArTiMl+tQAvrrhptA
EQy3q2yXTHG2xdGhtitCQYVk8rRhHEUm9iDjjanUKyjeU956h9pWhV0HcyI+JqyA6dBz
Y/RnCsqjH3TMBo4b3LaO2nCSRYVEBPgfIWs4pzaQD6LJ8enqLDW42NpXlvXMcmCSoYcz
/jXMFC3nZbyD31BqWgQAS39YxdonJOUoSqs9FMhyqrVpfukus+SaLKkjVRi0lffkaP/I
bQo4zZoi1CI54o4QOmCWzu8tKWJdpXeoPfcLraU0Uhb1VcFcEH1yHJ9o5i9wXq6SA4bq
yGCQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUkfWvZqA+MBXDqnkxB2qWw6VNg1LlcsFJfP6/y26PPy91igJZaQ1kJC88/5HOu9oRqoAi4eSH6rtOe@gnusha.org
X-Gm-Message-State: AOJu0YymYU+n1lTaPPik6cCNMTh1WFPRL/NS9wZ+45RSZYXEoKKRCVpG
/PZmbymWEDx0E0n8eqNUs6/1l8yTgR5MfCeOJwePKK6fWCdM8bnVO6t2
X-Google-Smtp-Source: AGHT+IE16sZC+LJRqd9zCCMeucRRoiILaDetP2Y2OIN2fUU9te+ng0OO6I+WzIFPT7Dxxxi4M5Dndg==
X-Received: by 2002:a05:6902:1021:b0:e7d:7e15:2f8b with SMTP id 3f1490d57ef6-e7ec8860a10mr2615768276.7.1748469265476;
Wed, 28 May 2025 14:54:25 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZedwst4pJ+CXIgextaOf5HYT7yWh4hCF6EKSO5Uu+sEMg==
Received: by 2002:a25:b115:0:b0:e7e:17d7:a664 with SMTP id 3f1490d57ef6-e7f6f7f5da3ls270102276.2.-pod-prod-02-us;
Wed, 28 May 2025 14:54:21 -0700 (PDT)
X-Received: by 2002:a05:690c:6504:b0:70f:6ec6:62b3 with SMTP id 00721157ae682-70f6ec666e5mr52435667b3.26.1748469261497;
Wed, 28 May 2025 14:54:21 -0700 (PDT)
Received: by 2002:a81:c949:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-70ca9c0bd38ms7b3;
Wed, 28 May 2025 14:15:33 -0700 (PDT)
X-Received: by 2002:a05:690c:6d13:b0:6f9:56d1:a8bd with SMTP id 00721157ae682-70e2dabfaf8mr252321577b3.33.1748466932560;
Wed, 28 May 2025 14:15:32 -0700 (PDT)
Date: Wed, 28 May 2025 14:15:32 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <84ae7e2c-eb71-44fa-b3da-27731802f47an@googlegroups.com>
In-Reply-To: <7E385C29-F84D-45E1-8314-D735929F9DC1@sprovoost.nl>
References: <E8269A1A-1899-46D2-A7CD-4D9D2B732364@astrotown.de>
<CAJDmzYxw+mXQKjS+h+r6mCoe1rwWUpa_yZDwmwx6U_eO5JhZLg@mail.gmail.com>
<zyx7G6H1TyB2sWVEKAfIYmCCvfXniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuHMjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXLmiCJOY=@proton.me>
<CAC3UE4+DR=DQqtT+X0SYvH1XCVnmatD7frcHC5dtdVAef39UnQ@mail.gmail.com>
<CAJDmzYycnXODG_e9ATqTkooUu3C-RS703P1-RQLW5CdcCehsqg@mail.gmail.com>
<c568cc33-abba-4010-ac65-42c84dae6eb8n@googlegroups.com>
<7E385C29-F84D-45E1-8314-D735929F9DC1@sprovoost.nl>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_14278_854258312.1748466932153"
X-Original-Sender: ekaggata@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_14278_854258312.1748466932153
Content-Type: multipart/alternative;
boundary="----=_Part_14279_294058494.1748466932153"
------=_Part_14279_294058494.1748466932153
Content-Type: text/plain; charset="UTF-8"
Sorry looks like I forgot to crosspost this reply to list:
Hi Sjors, list:
> I brought this up [0], but it was later pointed out to me that it doesn't
work
Oh yes, doh. That's most unfortunate. While this is getting silly, I can't
help wondering what happens, in the presence of an ECDLP breaker, to a
botched version of taproot that requires script-path spending and doesn't
allow key-path.
It's interesting, imagine: honest keyholder creates Q = P_N + H(P_N||S)G
where P_N means NUMS internal key. ECDLP breaker can just find DL of Q but
if we disallow key-path spend they have to open a hash commitment to a
tweak as per usual taproot rules.
So they need: Q = P_2 +H(P_2||S_2)G now, they know the full private key x_N
+ H(P_N||S) for Q (and they may or may not know S, or be able to guess it,
to get all the variables in that expression), but it seems to not help them
given the commitment to P_2 in the hash, requiring them to choose P_2
before the hash.
They could of course do it with P_N itself, if that were allowed, hence the
"disable NUMS" might make sense, in this scenario. Can't say I'm 100% sure
of myself here, but it looks like that works.
Even if I'm right, it's not so interesting; we already are assuming that a
quantum attacker can't break hashes, that's behind a lot of the discussion
here, so of course it would make sense if we broke taproot to require it
only to use hashes (script path only), then it might come back to the same
security situation (which of course, is not actual security, since keys are
always revealed in spending). Or maybe we should start to think of really,
really worst case scenarios: what if a new quantum algorithm actually does
efficiently find SHA2 preimages? :)
Thanks, AdamISZ/waxwing
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/84ae7e2c-eb71-44fa-b3da-27731802f47an%40googlegroups.com.
------=_Part_14279_294058494.1748466932153
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sorry looks like I forgot to crosspost this reply to list:<br /><br />Hi Sj=
ors, list:<br /><br />> I brought this up [0], but it was later pointed =
out to me that it doesn't work<br />=C2=A0<br /><br />Oh yes, doh. That's m=
ost unfortunate. While this is getting silly, I can't help wondering what h=
appens, in the presence of an ECDLP breaker, to a botched version of taproo=
t that requires script-path spending and doesn't allow key-path.<br /><br /=
>It's interesting, imagine: honest keyholder creates Q =3D P_N + H(P_N||S)G=
where P_N means NUMS internal key. ECDLP breaker can just find DL of Q but=
if we disallow key-path spend they have to open a hash commitment to a twe=
ak as per usual taproot rules.<br /><br />So they need: Q =3D P_2 +H(P_2||S=
_2)G now, they know the full private key x_N + H(P_N||S) for Q (and they ma=
y or may not know S, or be able to guess it, to get all the variables in th=
at expression), but it seems to not help them given the commitment to P_2 i=
n the hash, requiring them to choose P_2 before the hash.<br /><br />They c=
ould of course do it with P_N itself, if that were allowed, hence the "disa=
ble NUMS" might make sense, in this scenario. Can't say I'm 100% sure of my=
self here, but it looks like that works.<br /><br />Even if I'm right, it's=
not so interesting; we already are assuming that a quantum attacker can't =
break hashes, that's behind a lot of the discussion here, so of course it w=
ould make sense if we broke taproot to require it only to use hashes (scrip=
t path only), then it might come back to the same security situation (which=
of course, is not actual security, since keys are always revealed in spend=
ing). Or maybe we should start to think of really, really worst case scenar=
ios: what if a new quantum algorithm actually does efficiently find SHA2 pr=
eimages? :)<br /><br />Thanks, AdamISZ/waxwing<br /><br /><div><br /></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/84ae7e2c-eb71-44fa-b3da-27731802f47an%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/84ae7e2c-eb71-44fa-b3da-27731802f47an%40googlegroups.com</a>.<br />
------=_Part_14279_294058494.1748466932153--
------=_Part_14278_854258312.1748466932153--
|
