Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin

From: Matt Corallo <[email-masked]>
Date: Mon, 24 Mar 2025 21:06:01 -0400

On 3/18/25 8:48 AM, Sjors Provoost wrote:
> 
>> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <[email-masked]> 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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/912fd35e-02f5-49b5-b373-ca02806d952f%40mattcorallo.com.