Delivery-date: Wed, 28 May 2025 14:54:33 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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 />&gt; 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&quot; 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--