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 09:30:38 +1000 [thread overview]
Message-ID: <aeAfnufGvf1pG85h@erisian.com.au> (raw)
In-Reply-To: <61159968-e2cd-44a6-8171-a815e6055cff@mattcorallo.com>
On Wed, Apr 15, 2026 at 05:50:31PM -0400, Matt Corallo wrote:
> 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.
Well, I imagine you're not lean4 validated, so I guess holding
contradictory views is your right...
> > 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).
> 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, [...]
Making existing UTXOs ("all quantum-vulnerable addresses") spendable
via a previously non-existant quantum safe path is a hard fork. Sorry
if I didn't phrase that clearly enough.
> 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.
At at my last utxo set (height 923,997) there's about 20k BTC ($1.5B)
in utxos between 100k sats ($75) and 300k sats ($225), across about 11M
utxos. There's about 25M utxos with more than 300k sats.
Another advantage of a hard-fork approach is you could relatively easily
include an increased blocksize to mitigate some of the impact of larger
signature sizes.
> > 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.
The 36kB withness size was for the "stateful signature transaction /
normal operation" case (which AIUI should have been perhaps ~500 WU),
not just the fallback. I don't understand it at all, but also haven't
tried decoding the simplicity source code.
I'm personally a bit skeptical of the dedicated opcode approach, given
how fast things move here, both in new improvements being invented and
old ideas getting broken.
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/aeAfnufGvf1pG85h%40erisian.com.au.
next prev parent reply other threads:[~2026-04-15 23:34 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
2026-04-15 23:30 ` Anthony Towns [this message]
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=aeAfnufGvf1pG85h@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