Hi,

> [1] Of course I believe that the lost coin pool is large enough that the Bitcoin community will, almost
> without question, fork to disable insecure spend paths and burn some coins in the process, but reducing
> the number of coins burned to the absolute minimum is of course best for everyone.

I think at this stage the bitcoin community is something like tens of millions of human beings spread
all over the world and coming from a multitude of horizons. I would take the bet that if you go to ask
them one by one they have would have no real idea about quantum risks, and about the "freeze or not
freeze" controversy they would at best shrug at you. So using "totalizing" socioligcal abstractions
like the "Bitcoin community" and rough guessing Pythia of Delphi-like what this "community" wishes
can only look a bit presumptuous to me...

The whole sale pitch of bitcoin for almost two decades, the one that people have argued at meetups,
conferences, online forums, in the media, in documentaries, on IRC, twitch, even in long-form blog
post [0] has been unconfiscatable and censorship-resistant money. Now, we would take the exact opposite
viewpoint and go to evangelize that *actually* your coins could be now massively confiscated or their
spend usage be censored at the protocol-level...All in the name of loosely defined reasons and risks...?
Sadly, I'm not smart enough to get it here.

Cutting through cheap rhetoric, the way the original post is framed can only lead to confusion and misunderstanding.
By saying first the goal should be to increase the number of coins which are going to be reasonably secure
by the time of a CQRC exists, if it exist one day, period, and then immediately it goes to reformulate the
goal as diminishing the likeliness there is a wish among some community stakeholders to freeze non-upgraded
coins to finally say that the goal should be to prioritize the migrations of the structures of wallet the less
likely to migrate.

It's all very confusing and at the end a reader cannot say if the thesis defended is:
- a) to prioritize consensus upgrades to allow coins owners to migrate their stacks to PQ safe schemes
- b) to prioritize the discussion on "freeze or not freeze", its legitimacy or not among protocol experts
- c) to prioritize the migration of wallet structures / services that might be slow to upgrade to PQ safe schemes

About a), it sounds to me reasonable to care about the CQRC risk. After all, the latest Nobel prize
in physics was awarded for works on the foundations of quantum computing. It might turn all like the
ether in the history of physics (i.e vaporware), though so far we're far to have reached a scientific
consensus on the subject [1]. While adding PQ safe schemes at the consensus level is obviously coming with
a price in term of implementation complexity, it's at least something tangible one can argue for or against.
We can then go to discuss all the varieties with EC-and-PQ safe schemes [2], though notably going to
argue on EC-and-PQ one has to assume that EC spend paths are never completely disabled.

About b), in my humble opinion, any argumentation that some coins must be "freeze" on the "price" is a chimera.
As far as I know, none of the bitcoin "technical experts" supporting a "freeze" is sitting on the board of
the FED, the ECB, the PBOC or the BOJ, so there is no way trying to make hand wawy estimation on a given price
level as there is no leverage on the demand (or the mere global offer of fiat money for a fixed amount of bitcoin).

Speaking about technical risks on the long-term viability of the network, realistically I don't see them. Of course,
one deep pocketed attacker could leverage the gains from CQRC exploitation to mount some categories of attacks against
L2s [3], though motivated attackers can already gather the bitcoin amount sufficient to launch that kind of attacks.
And I don't see attacks they could trigger on the base-layer, where they would hold a significant asymmetrical advantage.
If some are upset by the "no freeze" position, they're always free to go to launch their native PQ safe chain.

About c) it's not very our responsibility that some platforms and services are more focus to chase the latest
token mirages or whatever the ico of the day. All we can do is offering convenient PQ safe cryptograpghic schemes
and interface at the consensus levels, the earlier we can reasonably deliver on, all consensus caveats apply and
go to do the reasonable work of technical advocacy to explain how such schemes are working, somehow. If they're
too busy to care about upgrading their technical stack despite the numerous warnings on the subject, let's them
burn. We're not religious missionaries and it's not our role to go to morally reform their high time preferences
economical incentives.

Now, I do not wish to sound too much dismissive for the services operators and plateforms that have massive
amounts of coins to manage, and for which the quantum risk and any price fluctuation could be a real worry.
My answer to this worry is you're free to go to buy paper insurance coverage in the odds tof massive CQRC
exploitations happening 10 or 20 years down the road. Top insurance companies in the world are already able
to insure one hundreds in the year earthquake or flood, political risks and civil unrests so it should be
okay for them to go to insure a one hundred year quantum risk affecting centralized services...[4]

If we take the CQRC threat seriously, at least deserving some mitigation work, personally I prefer to scratch
my head on isogenies and lattices for practical schemes, rather than wasting ourselvces with the "freeze" non-sense.
The Poinsot take in the other thread calling to disentangle the two topics sounds a reasonable and balance viewpoint
to me.

At least that's my humble 2 sats.

Best,
Antoine
OTS hash: 0b266a6f42311bc42c701073e243f69a2ae8ce2ac9b895efcf49f0dd36ec1a07

[0] https://bluematt.bitcoin.ninja/page9/
[1] A contrario, no scientific yet has got a Noble Prize for demonstrating the impossibility of a QC
[2] In the case there is a cryptanalytic wreckage of the PQ safe but not the EC one
[3] https://ariard.github.io/sigsoverflow.html
[4] And if you prefer the more cypherpunk way, it's likely you can achieve the same with some bitvm constructions,
if it holds it's expressivity and security guarantees

Le Wednesday, April 15, 2026 à 5:51:57 PM UTC+1, Matt Corallo a écrit :
Its become obvious in recent discussions that a large part of the PQC discussion has people coming at it from very different fundamental goals, and as a result the conversations often talk past each other without making real progress. So instead of doing that more I'd like to write down what I think the actual, short-term goal *is*, what it it is not.

Fundamentally, it seems to me the most reasonable goal is that we should be seeking to increase the number of coins which are reasonably likely to be secured by the time a CRQC exists. Put another way, we should be seeking to minimize the chance that the Bitcoin community feels the need to fork to burn coins by reducing the number of coins which can be stolen to the minimum number [1].

This naturally means focusing on the wallets which are the *least likely* to migrate or otherwise get themselves in a safe spot. Focusing on those who are the most likely to migrate does almost nothing to move the needle on the total number of coins protected, nor, thus, on the probability of a future Bitcoin community feeling the need to burn coins. Sadly, this probably means the "top wallets" that are generally terrible at adopting Bitcoin standards. Wallets which are the top listing on app stores like (currently in the top few in my app store): Bitcoin.com, Trust Wallet, Coinbase Wallet, Blockchain.com, etc. These wallets generally use a single static address (because anything else confuses their users and they get additional support tickets for it!) and put very little time into Bitcoin, focusing instead on other tokens and integrations.

A few non-goals:

* To ensure that advanced setups have the absolute best in post-quantum security. I don't see how this moves the needle on the above goal, and in fact in many cases detracts from the above goal. Of course if we can accomplish this without detracting from the top-line goal above, great.

* To ensure we have the best possible design for the signature scheme bitcoin will be using in a world where a CRQC exists and we've gotten past the mess. We'll almost certainly know a lot more about the security of various schemes and have more options for how to approach the problem by the point we're dealing with the mess of a CRQC being imminent, so it seems like a fools errand to try to predict what we should build for this. But even if we know no more then than we do today, likely ending up with hash-based signatures as the scheme everyone uses, we'll almost certainly be having conversations about additional witness discounts or increased block sizes to compensate for the sudden increase in transaction sizes. Maybe we would decide against such an increase, but there's no question such a conversation would happen and it would be premature to have it today.

Matt

[1] Of course I believe that the lost coin pool is large enough that the Bitcoin community will, almost without question, fork to disable insecure spend paths and burn some coins in the process, but reducing the number of coins burned to the absolute minimum is of course best for everyone.

--
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/a146e52b-aac8-4fb9-8bcf-4cc9e58176a0n%40googlegroups.com.