From: Matt Corallo <lf-lists@mattcorallo•com>
To: Sjors Provoost <sjors@sprovoost•nl>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Jameson Lopp <jameson.lopp@gmail•com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
Date: Mon, 24 Mar 2025 21:06:01 -0400 [thread overview]
Message-ID: <912fd35e-02f5-49b5-b373-ca02806d952f@mattcorallo.com> (raw)
In-Reply-To: <ED96C777-5BBD-4ACE-8821-A53FDE8FA128@sprovoost.nl>
On 3/18/25 8:48 AM, Sjors Provoost wrote:
>
>> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <lf-lists@mattcorallo•com> het volgende geschreven:
>>
>> I think this is a strong motivation to do "simple PQC" today - while we don't need to decide on the tough question of seizing non-PQC coins today, we want to have the option to do so in the future.
>>
>> In order for that option to be practical, wallets need to be embedding PQC public keys in their outputs probably at least a decade before the seizure occurs, with any additional time giving us an important safety margin.
>
> I don't think that in practice we can deploy a PCQ scheme without at the same time making a decision with regards to burn vs free-for-all. The best we can do is to have all that stuff well researched and tested long before on a signet.
As Jameson describes, I don't think there's a decision to be made here. If, at some point, a QC
becomes undeniable reality (or near-term reality), *not* doing a freeze fork is to allow Bitcoin to
simply die. The only thing we can do is set ourselves up for success such that that freeze freezes
the minimum possible number coins.
> Let's say the burn consensus rule is that no pk(), bare multisig, pkh()*, wpkhk() output can be spent, in addition to any tr() key path.
> To be triggered at some point far enough in the future that people can migrate, but not too late. Let's ignore for now that this will be very hard to agree on, because people will disagree on the nature and timing of the threat until it's undeniable.
>
> In principe a PQC (Post-quantum cryptography) tap leaf scheme could be proposed in a BIP and activated in a soft-fork, without having to decide on the burn issue. Any time your wallet needs to generate a new address, it could add such a tap leaf just in case.
> But this adds a bunch of complexity to wallets, makes descriptor backups longer, etc. So adoption might be minimal. And since no sane person spends from the PQC path, we'd have no idea how much adoption there is.
Indeed, adoption is a challenge. This is true for any PQ scheme, however. Still, I'm dubious that
simply no wallets would actually do that - there is material dramaz over PQ Bitcoin these days, and
for (somewhat) good reason. Those selecting a wallet for short-term use of course have no need to do
this, but those selecting a long-term storage wallet might see PQC as a feature they want, and
select a wallet accordingly.
> More importantly, the activation of a PQC tapleaf soft fork would not be sufficient to permanently migrate coins. That's because in a free-for-all quantum scenario it's the wrong approach. The quantum attacker would just spend from your key path.
As noted above I don't buy that this is a possible outcome.
> In that scenario you'd need to use a NUMS point for the key path. Or maybe that's unsafe, in which case we'd need a new Taproot version without key path support (or BIP360). That's also not a difficult soft fork, but now again you have something that only a small set of users will want to use.
A NUMS point does not suffice unless we explicitly soft-fork out spending from that NUMS point
(which is, of course, doable).
> This new address type is only suitable for very long term storage since it's more expensive to use in a pre-quantum world (using the a regular Schnorr signature in a script path).
>
> So now we'd have two soft forks that ~nobody uses, because it's a bunch of extra wallet complexity and you don't know if you should use the tapleaf or the taproot-without-keypath address for your cold storage.
>
> I doubt that soft forks which nobody intends to use will be activated anytime soon.
There is nontrivial demand (again, for (somewhat) good reason) for PQC on bitcoin today. Suggesting
that no one intends to use such a thing I find incredibly dubious.
Matt
--
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/912fd35e-02f5-49b5-b373-ca02806d952f%40mattcorallo.com.
next prev parent reply other threads:[~2025-03-25 8:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2025-03-25 8:16 ` Sjors Provoost
2025-03-28 20:00 ` Matt Corallo
2025-03-30 22:23 ` Javier Mateos
2025-03-22 19:02 AstroTown
2025-03-24 11:19 ` Agustin Cruz
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=912fd35e-02f5-49b5-b373-ca02806d952f@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=jameson.lopp@gmail$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/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