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: Thu, 16 Apr 2026 07:15:49 -0400 [thread overview]
Message-ID: <32cb27ea-d935-4bf3-9296-c08c8651daf9@mattcorallo.com> (raw)
In-Reply-To: <aeAfnufGvf1pG85h@erisian.com.au>
On 4/15/26 7:30 PM, Anthony Towns wrote:
> 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...
Could you be more clear? I don't see a particularly contradictory view here.
>>> 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.
Right but you could also make it an additional requirement rather than an entirely new spend path.
In fact that's likely how you want to do it for simplicity anyway - run the normal scripts with EC
and whatever and accumulate a list of pubkeys used in checksigs and then require an additional
(segwit style storage) zk proof for each pubkey (or, really, a batched one). Again whether or not
this *should* be a soft fork I leave as an exercise to the reader.
>> 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.
segwit-style additional data also avoids this issue. Might also even require miners to batch the
proofs into one ZKP, though the additional CPU cost to miners may be unpaletable.
>>> 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.
IIUC the stateful version of shrincs is in the 300-500 byte range, depending on particular parameters.
> 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.
It might well make sense to do some kind of more generic hashtree opcode to allow for whatever
particular hash-based signature construction someone might come up with in the future, indeed.
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/32cb27ea-d935-4bf3-9296-c08c8651daf9%40mattcorallo.com.
next prev parent reply other threads:[~2026-04-16 11:44 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
2026-04-16 11:15 ` Matt Corallo [this message]
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=32cb27ea-d935-4bf3-9296-c08c8651daf9@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