From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Boris Nagaev <bnagaev@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
Date: Sun, 13 Jul 2025 19:28:49 +0000 [thread overview]
Message-ID: <qiwLbcmBGlNhbgEb-1WMrZdOS-JQpYVyxfAxcKYmkLSwcwvAKI9faDZigqE94yaPV9-snFurf5X9OXlgXqOGgyJSGJ11AhgrYXgVBjhflw0=@wuille.net> (raw)
In-Reply-To: <9644c572-8cb9-4ce5-8d3c-a01602dc0e1dn@googlegroups.com>
On Sunday, July 13th, 2025 at 2:01 PM, Boris Nagaev <bnagaev@gmail•com> wrote:
> On Sunday, July 13, 2025 at 1:09:01 PM UTC-3 Ethan Heilman wrote:
>
>
> > That is, quantum vulnerable outputs, in the presence of a quantum computer, have already had their value destroyed. They no longer function as property, but instead function as an inflationary reward for owning a quantum computer. Freezing them simply reflects this reality and protects quantum resistant coins from the inflation caused by quantum attacks.
>
>
> The key issue is that we don't know whether the quantum threat will materialize. It's an open question. Jameson's proposal requires taking action before such a threat actually exists. But without knowing if or when it will happen, it's hard to justify such a significant change.
I want to make a perhaps controversial nuance here.
I believe the the main quantum-related threat to bitcoin, at least in the medium term, is not the actual materialization of a cryptographically-relevant quantum computer (CRQC), but **the belief** whether one may exist soon after. I don't mean to imply that such a machine won't ever appear, but I believe the fear that one may exist will likely have a more meaningful impact, and come much earlier.
Furthermore, I don't think the availability of quantum-safe output types will be sufficient to mitigate this fear-threat, because I don't see how the mere existence of quantum-safe outputs will be sufficient to incentivize the vast majority of coin holders to move their coins. Some may not believe a CRQC will ever exist. Some may have use cases that are incompatible with them (e.g. nothing BIP32-like for them, no key aggregation/thresholds, or they're too large for certain use cases). Some may simply not bother to implement whatever is required, because they're busy building altcoin infrastructure[1] that's more profitable (there are still major ecosystem players that cannot even *send* to taproot outputs...). And all of that is ignoring coins which have simply been lost, which will definitely not move.
All of that together means that the mere existence of quantum-safe outputs will not be sufficient to largely remove the presence of CRQC-vulnerable coins from the system. And without that, the fear of the existence of a CRQC may remain an existential threat due to the sell pressure it may cause. Even those who have moved their coins to quantum-safe outputs may worry about an exchange-rate crash caused by a QRQC operator selling stolen coins, which may fuel even more sell pressure.
It's quite possible I'm wrong here, about sentiment, or about what happens in what order. But I think it's worth considering. And if so, then I think the conclusion is that the actual mitigation to (the fear of) a quantum threat is (the prospect of) freezing CRQC-vulnerable coins. Everything else, up to and including investigating, proposing, activating, and advocating for usage, of quantum-safe outputs, is just be preparatory. Those would be necessary first steps of course, but absent a subsequent prospect of actually disabling quantum-vulnerable outputs, they may be irrelevant in the grand scheme of things.
To be clear, I am not advocating for any specific cause of action here. Not on BIPs, timelines, approach, or even whether something should be done at all. However, I do consider it naive to say that simply making post-quantum output types available is a solution.
[1] https://rusty.ozlabs.org/2020/05/27/bitcoin-exchanges-are-now-the-enemy.html
Cheers,
--
Pieter
--
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/qiwLbcmBGlNhbgEb-1WMrZdOS-JQpYVyxfAxcKYmkLSwcwvAKI9faDZigqE94yaPV9-snFurf5X9OXlgXqOGgyJSGJ11AhgrYXgVBjhflw0%3D%40wuille.net.
next prev parent reply other threads:[~2025-07-13 20:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 19:02 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-26 15:40 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2025-06-07 13:28 ` waxwing/ AdamISZ
2025-06-08 14:04 ` Jameson Lopp
2025-07-13 1:39 ` Boris Nagaev
2025-07-13 12:34 ` Jameson Lopp
2025-07-13 14:20 ` Boris Nagaev
2025-07-13 16:01 ` Ethan Heilman
2025-07-13 17:51 ` Boris Nagaev
2025-07-13 19:28 ` Pieter Wuille [this message]
2025-07-13 21:26 ` Jameson Lopp
2025-05-28 1:07 ` waxwing/ AdamISZ
2025-05-28 7:46 ` Sjors Provoost
2025-05-28 21:15 ` waxwing/ AdamISZ
-- 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='qiwLbcmBGlNhbgEb-1WMrZdOS-JQpYVyxfAxcKYmkLSwcwvAKI9faDZigqE94yaPV9-snFurf5X9OXlgXqOGgyJSGJ11AhgrYXgVBjhflw0=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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