From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
Date: Wed, 28 May 2025 14:15:32 -0700 (PDT) [thread overview]
Message-ID: <84ae7e2c-eb71-44fa-b3da-27731802f47an@googlegroups.com> (raw)
In-Reply-To: <7E385C29-F84D-45E1-8314-D735929F9DC1@sprovoost.nl>
[-- Attachment #1.1: Type: text/plain, Size: 2149 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 2509 bytes --]
next prev parent reply other threads:[~2025-05-28 21:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 19:02 [bitcoindev] Against Allowing Quantum Recovery of Bitcoin AstroTown
2025-03-24 11:19 ` Agustin Cruz
2025-05-25 19:03 ` 'conduition' via Bitcoin Development Mailing List
2025-05-25 23:03 ` Dustin Ray
2025-05-26 0:32 ` Agustin Cruz
2025-05-28 1:07 ` waxwing/ AdamISZ
2025-05-28 7:46 ` Sjors Provoost
2025-05-28 21:15 ` waxwing/ AdamISZ [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-03-16 14:15 Jameson Lopp
2025-03-16 18:03 ` Chris Riley
2025-03-16 19:44 ` Nagaev Boris
2025-03-16 21:25 ` Jameson Lopp
2025-03-16 22:56 ` IdeA
2025-03-17 13:28 ` Jameson Lopp
2025-03-17 12:00 ` Matt Corallo
2025-03-18 12:48 ` Sjors Provoost
2025-03-25 1:06 ` Matt Corallo
2025-03-25 8:16 ` Sjors Provoost
2025-03-28 20:00 ` Matt Corallo
2025-03-30 22:23 ` Javier Mateos
2025-04-04 4:49 ` 'Ben Sigman' via Bitcoin Development Mailing List
2025-04-06 14:07 ` Nadav Ivgi
2025-04-30 15:40 ` Michael Tidwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84ae7e2c-eb71-44fa-b3da-27731802f47an@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox