From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Thu, 16 Apr 2026 06:19:42 +1000 [thread overview]
Message-ID: <ad_y3iFzPOGTiVAn@erisian.com.au> (raw)
In-Reply-To: <ba187dd7-6181-43e0-831a-6580d2c93433@mattcorallo.com>
On Tue, Apr 14, 2026 at 04:04:02PM -0400, Matt Corallo wrote:
> I'm gonna top-post because I think we're too far in the weeds and the
> high-level argument is getting lost. No, of course I do not thing that our
> job is to "convince" any quantum skeptics. What is our job is making sure
> the *bitcoin system* is ready in case a CRQC does become a reality. That
> means looking at the system as a whole, not individuals. Notably, this means
> that if the decisions we make result in a bitcoin where some people who are
> super worried about a CRQC have migrated but everyone else hasn't, and a
> CRQC becomes an imminent reality, *we've failed*.
I think those views are contradictory. Preparing for a post-quantum
world is not free: even if you come up with a new address scheme that
imposes zero overhead to make a PQ spending path available, there are
still switching costs associated with moving to that new address scheme,
so the only way you get the people who aren't super worried about CRQC
to migrate beforehand is precisely to "convince" them that the (low)
risk is worth the (low) cost.
If the outcome of not doing something is that you've "failed", then
doing that thing is your "job".
> In such a world, bitcoin
> becomes largely value-less and the paranoid folks who migrated long ago and
> paid for it have accomplished absolutely nothing. I hope we can at least
> agree on this point.
I don't believe that's necessarily true either though.
A path forward in such a scenario (30%-95% of BTC held in CRQC-vulnerable
addresses, CRQC is believed by the public to exist, and willingness to
hold BTC when large portions of supply are CRQC-vulnerable is already low
or dropping fast) could be to create a hard-fork the chain, preserving
the UTXO set, but making all quantum-vulnerable addresses only spendable
via a scheme like roasbeef's recent demo (ie, provide a PQ ZK proof of
a hardened derivation path to the pubkey that links that knowledge to
a new quantum-safe pubkey).
Of course, there are plenty of difficulties with such a path, notably:
* deployment (chain forks have been done before, but they're
not easy)
* post-quantum cryptography implementation (there's a whole host
of new crypto needed, relative to bitcoin today)
* market agreement on *which* new hard fork coin is the winner (if
there's one such fork that gains any traction, there will certainly
be many clones launched at a similar time, some of which may have
meaningful technical/economic differences)
* avoiding capture by a "hardfork core team" via an ongoing sequence
of mandatory hard fork upgrades (traditionally chain splits have
resulted in multiple followup consensus changes, eg to tweak PoW rules)
But if the only alternative is the end of Satoshi's grand experiment,
then it sure seems worth trying.
The "Q-day hard-fork" approach has a few benefits too:
* it's a clean split; people who still don't believe in quantum risk
can ignore it
* if done prematurely, it's equally irrelevant to all other hard forks
* as a hard fork, adding new spending paths to old coins is a viable
option, rather than freezing everything being the only choice
* it's a voluntary, opt-in solution, where everyone gets coins under
both the old and the new rules that they can spend or save as they
see fit
In a scenario like that, the people who migrated long ago benefit by
retaining immediate access to their coins on the hard fork chain with only
minor updates to their systems; the people who didn't, instead need to
retool and perhaps extract private keys in order to generate the ZK proofs
that will allow them to regain access to their funds on the fork chain.
Personally, I'm skeptical that there'll be any agreement on disabling
spending paths without a concrete CRQC to analyse: it seems to me there's
likely significant risk that you'll either freeze spending paths too
early (someone gets lucky and triggers the freezing condition 10 years
early, even though it turns out scaling CRQC is harder than expected)
or too late (eg, after significant funds have already been stolen).
I also don't think there's much point discussing disabling spending paths
when there isn't any other way to spend funds. From what I've seen,
there have been demo Winternitz implementations in bllsh (~4,000 WU)
and GSR (~24,000 WU), and a SHRINCS implementation in Simplicity deployed
on Liquid (~36,000 WU??).
Cheers,
aj
--
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/ad_y3iFzPOGTiVAn%40erisian.com.au.
next prev parent reply other threads:[~2026-04-15 20:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 18:58 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-09 20:31 ` [bitcoindev] " Dplusplus
2026-04-09 21:17 ` [bitcoindev] " Olaoluwa Osuntokun
2026-04-09 22:46 ` Matt Corallo
2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List
2026-04-10 20:33 ` Matt Corallo
2026-04-11 0:20 ` Ethan Heilman
2026-04-11 1:04 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-11 1:25 ` Antoine Riard
2026-04-13 14:21 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-15 19:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-15 19:14 ` Erik Aronesty
2026-04-15 20:16 ` محمد الوصابي
2026-04-13 14:02 ` Matt Corallo
2026-04-14 1:45 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 12:36 ` Thomas Suau
2026-04-14 14:51 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 15:50 ` thomas suau
2026-04-14 19:09 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 15:33 ` Matt Corallo
2026-04-14 18:56 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 20:04 ` Matt Corallo
2026-04-15 11:02 ` Matt Corallo
2026-04-15 14:36 ` Ethan Heilman
2026-04-15 15:17 ` Matt Corallo
2026-04-15 16:01 ` Ethan Heilman
2026-04-15 16:03 ` Matt Corallo
2026-04-15 16:26 ` Ethan Heilman
2026-04-15 16:36 ` Matt Corallo
2026-04-15 20:19 ` Anthony Towns [this message]
2026-04-15 21:50 ` Matt Corallo
2026-04-15 23:30 ` Anthony Towns
2026-04-16 11:15 ` Matt Corallo
2026-04-16 11:19 ` Garlo Nicon
2026-04-15 18:15 ` '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=ad_y3iFzPOGTiVAn@erisian.com.au \
--to=aj@erisian.com.au \
--cc=bitcoindev@googlegroups.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