From: Matt Corallo <lf-lists@mattcorallo.com>
To: Anthony Towns <aj@erisian.com.au>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Wed, 15 Apr 2026 17:50:31 -0400 [thread overview]
Message-ID: <61159968-e2cd-44a6-8171-a815e6055cff@mattcorallo.com> (raw)
In-Reply-To: <ad_y3iFzPOGTiVAn@erisian.com.au>
On 4/15/26 4:19 PM, Anthony Towns wrote:
> 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".
I mean I agree with everything you said but I think that's also what I said above. Yes, some people
may never migrate but because many people think the risk is low the cost has to be similarly low.
And then the fact that many users will (rightly or wrongly) be asking about PQC make the wallets
willing to put in the effort (as long as its low!) to get users to shut up.
>> 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.
Oh we're very much on the same page here. Such an outcome sucks but its better than literally
nothing. My point was more that some people do have to migrate because the proof costs to do such a
fork (which is definitely not a hard fork, technically, even if it is maybe in a philosophical sense
and maybe should be for the same reason) will be high enough that transacting in bitcoin might
borderline stall. Also many of these users have a balance in the $100 range, a recovery transaction
fee of $50 is kinda not really useful for them. Maybe we can "just do a commit-reveal scheme" but
there are plenty of practical issues with that too.
> 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).
Not only do I agree with you but I think anything else would be a pretty substantial philosophical
failure for bitcoin!
> 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??).
Yep, all the more reason to add OP_SHRINCS or whatever, which I think all of this discussion largely
assumes.
Matt
--
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/61159968-e2cd-44a6-8171-a815e6055cff%40mattcorallo.com.
next prev parent reply other threads:[~2026-04-15 22:45 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
2026-04-15 21:50 ` Matt Corallo [this message]
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=61159968-e2cd-44a6-8171-a815e6055cff@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=aj@erisian.com.au \
--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