From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 16 Apr 2026 04:44:14 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wDL8n-0006s2-Iv for bitcoindev@gnusha.org; Thu, 16 Apr 2026 04:44:14 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-40eee5d10c5sf5903902fac.0 for ; Thu, 16 Apr 2026 04:44:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776339847; cv=pass; d=google.com; s=arc-20240605; b=dytXi0KCpjQUtFKpCGKjq6D26eZizI7wwqiFzOhLP852ARpEONJAAcM7Mo70zLr8aC PCP+IZS1dYUNOAdMmurChqqVEikxc7PYj2l9qoV+oXC8OjQCno36xSfaYJyO/H316GpP eOKanWZ2cOnleCuZad26EA/MbJ6DZvMKF5Qwqb4KSXQ+/7qh5w7WXu6f6Z+/g6g8YBXw bRDLTucRUxYr2wjjKfHI2EjlMK2LXjHhxMGF4T+t7TwAob1zwS85ksVfdCENE2/NLGgj GS1v5tgW/fw1HN0CkdXsDa0AseAlRw1dymScReTvRURiga703DUoJ0slIhFaygUeAKCF MjSQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=wQy0z2Ltt+OoTf7E9D6vgSSJZclzGCY0wjs1C5pv8ac=; fh=Wo/DXkFVN9H2te8K+3QDM6i9qz5+IDObVFRlMWoSKHY=; b=O8UeyV+kQ6n7A6Z6jvEkIscV14Ns4EVNAra/9+QVyzluwSqkw3CoGzmJUseuFyJlT9 F6npJgObJZM2R6BdkHoMcgs+DuJgy9zEncgl12cVzVcKUI+vUrl2+pCkGRwAZZgytgXi nmUrpOIlhZ8k7L171EMy+R9jyGxSYS5aiV9QqlNmw5/lL2FTzsB3nohph7dJyyau5WtF 0A+KHyAYkGmbDUKeCzh/lkRR64wa95wJFVh2b5Q5vY29+7FKlXITrypdQTIA+bu2vKFO hhsIlpD5VrZsehK1mEPIcwGmeA3y4tK88V8V1eYpMtCgN43hfsQIKA8zQwgevDy/TWdi n8/A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776336062 header.b=PCixH9Ge; dkim=pass header.i=@clients.mail.as397444.net header.s=1776336064 header.b=doUspzhl; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776339847; x=1776944647; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:cc :to:subject:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=wQy0z2Ltt+OoTf7E9D6vgSSJZclzGCY0wjs1C5pv8ac=; b=NRosZt/73BraX4pbSP7lAaHCATua00tBxTjofNUjaXke1PkUMBNEV0/6/gokkBOVvo sV35rOAc0sMeG4AAlKVMqGkiB65bJKyJ6NG0ZZRzy+Mg0N4fnue3zOYW85WTVYZW4r9V RvMiCn1qLNWXxBKd4akpW2ompHkwoh3Bcs10lZjTxyH4SsR8qmVsTtu5or9N+9Sn8Kw/ 1ONbkpeGz0wV8NdonycWuIkQGNaT/QCNMk/WUFZN6gA0q5gSRV+Pr+S7tnyoTbQdwNux C1lGG3TKucxtAYm2q8ZEZkC724+HBtK7B3lXK2w9xd7Kb5pIxPSDxAumX4q95T6kyJJj cGlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776339847; x=1776944647; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:cc :to:subject:mime-version:date:message-id:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=wQy0z2Ltt+OoTf7E9D6vgSSJZclzGCY0wjs1C5pv8ac=; b=j/tn/p5WdVQE/MS7JkqCqMK3zPvGKUCN1hRF8iSe9SWfL+5V15BlH3eFr8x7iuvX7c sVI4aGEVKcuccV+xM+JEMcAErsl6ioFyaEruz4Xmcy+CUblVlg8nZVNmvMNh3s/aljA/ hqUxzW2YD75brk7vTGIMu5+LHo7fDWlM1MFyfOXoAsUac4A9AsYngWINimZsJzuLO0Kl 3Ke+gAWGecPfpr6sPfIN5Qzw1Lxd57gIBfnTRfD1Ap6MJ+iKzZtKSnqsWGXnTxEPvZTS 0P8euIJvHIVyblBJej+lCblEjgI0sMshS3xvzdtRU4FIYgqf99gyl9phcq0y0MLMbVF1 kSTQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/RKovbw8g7EBnfPt9fhyxXrzn/k1pM5kqVUijB3b7FVlz+jLWkWDalVH6ic10WEaCOcOW6faPr84vi@gnusha.org X-Gm-Message-State: AOJu0Yxy+FlwgtEqcpCaL9etkI6JxEfU3NcLgyU3cBwku34cjTXx19Cz mmjngVuuIL84Ptue7toIj94f8+JYaIfMUelEs+66/NPLUC79Cnpa7+pZ X-Received: by 2002:a05:6870:2405:b0:423:b5a9:888d with SMTP id 586e51a60fabf-423e1182bd5mr14820936fac.37.1776339846894; Thu, 16 Apr 2026 04:44:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJm1lTyFebf0Fdc/1nAE0kwUPEXukSu3cSl0DXozMcOLA==" Received: by 2002:a05:6870:9f0e:b0:41c:583a:b5c with SMTP id 586e51a60fabf-4280c55901fls423075fac.2.-pod-prod-07-us; Thu, 16 Apr 2026 04:44:01 -0700 (PDT) X-Received: by 2002:a05:6808:1b10:b0:467:1da9:2b0f with SMTP id 5614622812f47-478a0f1d539mr11803254b6e.34.1776339840935; Thu, 16 Apr 2026 04:44:00 -0700 (PDT) Received: by 2002:a05:620a:4045:b0:8d6:1bc4:a7bc with SMTP id af79cd13be357-8e65762f909ms85a; Thu, 16 Apr 2026 04:15:53 -0700 (PDT) X-Received: by 2002:a05:6102:4b81:b0:605:5d09:8631 with SMTP id ada2fe7eead31-60a010583b2mr12616634137.29.1776338153035; Thu, 16 Apr 2026 04:15:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776338152; cv=none; d=google.com; s=arc-20240605; b=XaYa5TrEAhLcUhDFQyh3eJ+LxoUT5hUgKzPSycD8ZEE6Gb8I+k/D17nT1MIhi1EWU3 YXtbGi+bt1Epgz8WrPyCFXX/PvJXzV6jD+2QkpAwCV/uPNzGYIh+Yjz6XqezHjFnvkda AxtxsnDfJerCgHwcw6TLSDHHfXrJqIqG1TMGwQNRS/leazcqpLFi/XnT8tMiAK3rnAEE e8flfA9ATT+R+UtNfU/s+S/W/vxZ9Vq+hbRGMFc4bK+z2ahiCLkKiVyknVbqG4uf7fuG AqL1kKADqphiKmpGGpYB5wjZ7GRMfFcQzM3K4KxoQb+lrKGISVr0OeeWdRTmmA6aav6H rnGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=fKJzS5kH9sbu1YStchi9hjJnLtP/cwEHjN48vXNnoxE=; fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=; b=TLp8MEz8v48EmgFxNoGBjSpyt3qCI0YkPF2fvbdXvu4bnmJwGtSIB/v1DFUviwJ14w ihLxTADMcYfGUIClUqRKI6wdNeL7ontMIqAOuH4tbKEbB979w6hQVe4IhG/WVyaXra5Q 3OZaLro13JE3+YiC5IXC+cUbBvJGlwS7HSXMra1neid7hkB06QVNYu/UcWq8j8LSjzaO 6qFAZYXxlG8N4e3FO6z1vJUdm8JQ35hjg0ROo5pniJOmzD5I/jJstloUE7e7C3FQY+cL Vo4Ie1FE6xitC/gDdZV05FJn4HV6Wk2nXfE/GW9RIS3Wl4rkR5lfz4T3v8eMcF5So9Rl qdvg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776336062 header.b=PCixH9Ge; dkim=pass header.i=@clients.mail.as397444.net header.s=1776336064 header.b=doUspzhl; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8ae6c980234si1456996d6.2.2026.04.16.04.15.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 04:15:52 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wDKhK-000000067ml-3rr0; Thu, 16 Apr 2026 11:15:51 +0000 Message-ID: <32cb27ea-d935-4bf3-9296-c08c8651daf9@mattcorallo.com> Date: Thu, 16 Apr 2026 07:15:49 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] In defense of a PQ output type To: Anthony Towns Cc: Bitcoin Development Mailing List References: <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> <765490aa-5df3-4619-86cc-17570b6d3e99@mattcorallo.com> <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com> <42806684-3cc4-42e2-8052-43288a93e91e@mattcorallo.com> <61159968-e2cd-44a6-8171-a815e6055cff@mattcorallo.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776336062 header.b=PCixH9Ge; dkim=pass header.i=@clients.mail.as397444.net header.s=1776336064 header.b=doUspzhl; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) 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.