Delivery-date: Tue, 25 Mar 2025 01:53:21 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99;
Message-ID: <912fd35e-02f5-49b5-b373-ca02806d952f@mattcorallo.com>
Date: Mon, 24 Mar 2025 21:06:01 -0400
MIME-Version: 1.0
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
To: Sjors Provoost <sjors@sprovoost.nl>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Jameson Lopp <jameson.lopp@gmail.com>
References: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com>
 <43afd5bb-244e-4698-ba3d-139efa2c2058@mattcorallo.com>
 <ED96C777-5BBD-4ACE-8821-A53FDE8FA128@sprovoost.nl>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <ED96C777-5BBD-4ACE-8821-A53FDE8FA128@sprovoost.nl>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com



On 3/18/25 8:48 AM, Sjors Provoost wrote:
>=20
>> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <lf-lists@mattcorallo.com> h=
et 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 P=
QC public keys in their outputs probably at least a decade before the seizu=
re occurs, with any additional time giving us an important safety margin.
>=20
> 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=20
becomes undeniable reality (or near-term reality), *not* doing a freeze for=
k is to allow Bitcoin to=20
simply die. The only thing we can do is set ourselves up for success such t=
hat that freeze freezes=20
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 mi=
grate, but not too late. Let's ignore for now that this will be very hard t=
o agree on, because people will disagree on the nature and timing of the th=
reat until it's undeniable.
>=20
> In principe a PQC (Post-quantum cryptography) tap leaf scheme could be pr=
oposed in a BIP and activated in a soft-fork, without having to decide on t=
he burn issue. Any time your wallet needs to generate a new address, it cou=
ld 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. S=
till, I'm dubious that=20
simply no wallets would actually do that - there is material dramaz over PQ=
 Bitcoin these days, and=20
for (somewhat) good reason. Those selecting a wallet for short-term use of =
course have no need to do=20
this, but those selecting a long-term storage wallet might see PQC as a fea=
ture they want, and=20
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 q=
uantum scenario it's the wrong approach. The quantum attacker would just sp=
end 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 mayb=
e 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 ag=
ain 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 f=
rom that NUMS point=20
(which is, of course, doable).

> This new address type is only suitable for very long term storage since i=
t's more expensive to use in a pre-quantum world (using the a regular Schno=
rr signature in a script path).
>=20
> So now we'd have two soft forks that ~nobody uses, because it's a bunch o=
f extra wallet complexity and you don't know if you should use the tapleaf =
or the taproot-without-keypath address for your cold storage.
>=20
> I doubt that soft forks which nobody intends to use will be activated any=
time soon.

There is nontrivial demand (again, for (somewhat) good reason) for PQC on b=
itcoin today. Suggesting=20
that no one intends to use such a thing I find incredibly dubious.

Matt

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
912fd35e-02f5-49b5-b373-ca02806d952f%40mattcorallo.com.