From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: PQC - What is our Goal, Even?
Date: Sun, 19 Apr 2026 18:37:24 -0700 (PDT) [thread overview]
Message-ID: <a146e52b-aac8-4fb9-8bcf-4cc9e58176a0n@googlegroups.com> (raw)
In-Reply-To: <CF7A554D-EE6F-4E6B-A670-1D6F72170539@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 10308 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 10934 bytes --]
next prev parent reply other threads:[~2026-04-20 1:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 16:37 [bitcoindev] " Matt Corallo
2026-04-20 1:37 ` Antoine Riard [this message]
2026-04-20 18:04 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
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=a146e52b-aac8-4fb9-8bcf-4cc9e58176a0n@googlegroups.com \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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