From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] PQC - What is our Goal, Even?
Date: Mon, 20 Apr 2026 18:04:32 +0000 [thread overview]
Message-ID: <qbvf74cnK7N4QsE5kriIhV2yjyDxq8Yuuxli5-cpuilhuGqT1vvjs9EKyXVHL1lv9wPKiFrhdih1x6Hd2q8oL_YKahj5rl2qPCjNYSg6LT0=@protonmail.com> (raw)
In-Reply-To: <CF7A554D-EE6F-4E6B-A670-1D6F72170539@mattcorallo.com>
Matt,
Thanks for this. I agree it's useful to first debate the goals of a first
migration step, and hopefully get broad agreement on a subset thereof.
The goal you propose rules out a PQ-only output as too expensive. I don't think
it is necessarily so, but it's probably fair that a seamless migration is a
requirement to get the vast majority of users upgraded.
Even taking your goal for granted, the devil is in the tradeoffs. As stated
elsewhere i don't think "we" (tm) should position ourselves as arbiter of who
gets to retain ownership of their coins should some users fail to migrate, which
could be necessary if this was the only dimension to optimize for.
I would also be uncomfortable with a migration strategy that could legitimize
future confiscation. We already start seeing attempts at normalizing it by
renaming it to "deprecation". This, in my view, hurts Bitcoin's perceived value
as much as the prospects of a CRQC materializing before it is ready to face it.
I'd like to also propose another goal. I find it extremely frustrating how black
and white thinking creeps into this discussion, whereby some participants treat
the risk of a CRQC as a certainty, not unlike how others deny it is even a risk
worth considering. I think our migration strategy should focus on maintaining
consensus (at least) until there is more certainty on the progress toward a
CRQC, and to not degrade Bitcoin in the event CRQCs do not become a reality
within the next decade or so.
Best,
Antoine Poinsot
On Wednesday, April 15th, 2026 at 12:51 PM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
> 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/CF7A554D-EE6F-4E6B-A670-1D6F72170539%40mattcorallo.com.
>
--
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/qbvf74cnK7N4QsE5kriIhV2yjyDxq8Yuuxli5-cpuilhuGqT1vvjs9EKyXVHL1lv9wPKiFrhdih1x6Hd2q8oL_YKahj5rl2qPCjNYSg6LT0%3D%40protonmail.com.
next prev parent reply other threads:[~2026-04-20 18:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 16:37 Matt Corallo
2026-04-20 1:37 ` [bitcoindev] " Antoine Riard
2026-04-20 18:04 ` 'Antoine Poinsot' via Bitcoin Development Mailing List [this message]
2026-04-15 16:37 [bitcoindev] " Matt Corallo
2026-04-15 18:08 ` Erik Aronesty
2026-04-16 11:17 ` Matt Corallo
2026-04-16 16:28 ` Erik Aronesty
2026-04-16 16:31 ` Erik Aronesty
2026-04-16 17:34 ` 'conduition' via Bitcoin Development Mailing List
2026-04-17 20:44 ` Matt Corallo
2026-04-17 21:28 ` Ethan Heilman
2026-04-18 0:37 ` Matt Corallo
2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
2026-04-18 16:34 ` Erik Aronesty
2026-04-19 0:29 ` Matt Corallo
2026-04-19 12:57 ` Erik Aronesty
2026-04-19 13:36 ` Matt Corallo
2026-04-19 16:27 ` 'conduition' via Bitcoin Development Mailing List
2026-04-19 16:37 ` Matt Corallo
2026-04-19 19:43 ` Matt Corallo
2026-04-20 20:20 ` '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='qbvf74cnK7N4QsE5kriIhV2yjyDxq8Yuuxli5-cpuilhuGqT1vvjs9EKyXVHL1lv9wPKiFrhdih1x6Hd2q8oL_YKahj5rl2qPCjNYSg6LT0=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=lf-lists@mattcorallo.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