From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 15:45:36 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD8zH-00038h-Jg for bitcoindev@gnusha.org; Wed, 15 Apr 2026 15:45:36 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-41701418411sf13932686fac.1 for ; Wed, 15 Apr 2026 15:45:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776293129; cv=pass; d=google.com; s=arc-20240605; b=jlPH0CWS/2U7yUGzFQcXJM5Oc8LqzNEs0Yjd/SBRl1yre8u7QyiOv7dDpvS2p1U4ZV XS9RHbxSPi7DvodBKQgoPjUCgduq2NQynaETPJufFf5DmuirNzrURnhLI489NGBmcTAp nEocou0taO4PegrpKI8JusYCnpGfECNvdzDBQY1tpnvpUFtsyFlIzSDT7OJnYSwOWNNB I57dQXhuraFG+p//obEEEwpKTpuaRaLQf83Zj70ZF2qOmzNBIcarCayNDnTMUO6Eh7xU +QC6ecg1z8MwJyVVqchAj81f2dC0pVFKw/AQxKcijCE6ArzQvJaLv7EK7iI9PDnOcqey zmjA== 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=GX4SgplfSQ7n7Sy4hKfJ8MP8GxyDK/E0culTIq9RRpA=; fh=gyqCPImddn1Fo3qaeQ+qBK93G3+7FqBij78KleSi7vw=; b=N364mZq+3+VO70ijXU2frvY9d/lLuSZben5wOLZGwCkZxAx2wbvWRff4CpPO35OJ2C 36/p3LQZGCbV02SLrS+tZnQISFI1U82mSzAopJgCTOfLI6hHA6ZhvLtUZdI3yMoGWdNI 98aRGj+60nbcHJidweEkJdGleMclkufuOR8v+HHB3usfmQNLvkRlYDIeoRysvTcwbvTa ZhFO/UosL5H43hSVQFRJz9rHVUoCJOQspG/cG9WtlfutWk8Vdnzz9Bkj2cDXU6m9REFW rS1VbWcOK/rCvHFCMMlgB0V+5NRr3DXIXPgM+zbR2MIsytEjzz3NFJORZOiRmO5km7lL FUYg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776288062 header.b=If1m8YcS; dkim=pass header.i=@clients.mail.as397444.net header.s=1776288064 header.b=nOXvNkr+; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::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=1776293129; x=1776897929; 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=GX4SgplfSQ7n7Sy4hKfJ8MP8GxyDK/E0culTIq9RRpA=; b=n15qxIqNDLEJ0h0kXsa/l4wf2ijqG1IIGbndCtWEHZF5QqbcIf+bqjRdLWznXq8A58 jGr5jDNv5e6b1rlqVP8HKSIOlMtgz/i2qp3sdjMvb2xxz901K+fXYEz+JnK6g9BU7miM S3i8A99j+VK6qLmk7FxzdkF6tZ+dlxDlIFDx7au5zwK9E6jIkDmIZV7vIUzWen0V7+QA 1WIeJ+YKxH1JkDClAm+TnUCxypdHIWjxmFTeVRU5D76X88OqRDc30LHjItzY+2gPk4YO pU0Gv9Ddjq89OFuPAb+nxeCTAUZyauJj1IqQ4eXMa1WR+kizz2C8GFq+33pbQN9FXyUS vptg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776293129; x=1776897929; 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=GX4SgplfSQ7n7Sy4hKfJ8MP8GxyDK/E0culTIq9RRpA=; b=TuQ+znIlA7w9VZp3RTM+tOC8V0Oruf5paiYgic0jnLd97sA3ATLHTJ5EI5WwGaThZA KGx/VAoanlwE1I0iNWPrJUq4iV7VcuHRPIfKJTVbA68nQtfBxldEVpBPcuCh6ITBMJLi ikqy355hYs88U+K/r0pJ/36FHTXMTF7DUfKZbwp4zSeyGxwcQamHycnbn3b/bPXBCZnD PcdLHRRS01eqL5awhTDQe7ia8lW8yW+fESt8GrQTPcu4QI9ErISw0UIB8WxajEjf8yOb f43HHwX/fHW6C7ffNSIRTnO5NlMUhP2GOcaYALevI2IHZxxu+wyHfyRay/sSL75HThn2 IxJg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ9BwnPPpjwXONoqeBJcI66PDqiREk0+vbtg+bg9U3pt8ynay3GttMVzEZyrXPrItHSh6YpB67fu2Sx8@gnusha.org X-Gm-Message-State: AOJu0Yy3bKu+YaviXvxq8gUrHdmoeVuKYJOE2b93oOZ9HsE4Gi0/TTrC wJNw2MnL5lIX06XyasFtPIgrscZwDcySb9WiiiU6wMT6A3ElyiCVrBwE X-Received: by 2002:a05:6870:ac87:b0:41b:f2ee:bfec with SMTP id 586e51a60fabf-423e106ceb7mr13841446fac.25.1776293129289; Wed, 15 Apr 2026 15:45:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKvhMxumChclpzypUc1socam8VZK2scc9vL9hauSxXxlg==" Received: by 2002:a05:6870:648c:b0:41c:6ad4:3efb with SMTP id 586e51a60fabf-4280c60891cls158475fac.1.-pod-prod-08-us; Wed, 15 Apr 2026 15:45:23 -0700 (PDT) X-Received: by 2002:a05:6808:c162:b0:46a:c987:ba00 with SMTP id 5614622812f47-4789e7222f1mr13292719b6e.32.1776293123122; Wed, 15 Apr 2026 15:45:23 -0700 (PDT) Received: by 2002:a05:690c:3612:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7b8ade91770ms7b3; Wed, 15 Apr 2026 14:50:34 -0700 (PDT) X-Received: by 2002:a05:690e:190d:b0:650:1d3c:2b08 with SMTP id 956f58d0204a3-65198ab9d5bmr23849468d50.28.1776289834331; Wed, 15 Apr 2026 14:50:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776289834; cv=none; d=google.com; s=arc-20240605; b=dSKnH0N2QABFYeNIuydQOQA4FiwAQ2kGSudSCVtBUr7qPqWwLtLbKuelNRqO0I+B9e SXN5jER36ylEXYO/MkE72mCVxPmVwA3Q005PPH8rNBW718Q/o7Hy3ReNgNA2+/3FqY0I YMJHP3+xMieVvWf167YpdNuDN71mC4vBvcRKCcgZ54r2wr/eFa0MeJz/QOc1/rtyAfNc CCOIJvIPpJTMLXwcN/upTCpZ3dWKw0MIbz5u9LO1M3s94uUsSgngGKQB6UCQ2m9GvhEG 0rTeCGYBvYWTUwOzOsbORIDD2iFp/40tVrBTeb1Kw8DzohtIVfwL8p1/b/ioKWz5ru2H 9YGg== 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=xMY2WJ+8mAHzaqMlcxjliuBguHo6deQ+Y3vBAYugJbI=; fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=; b=KHCzWW6EaMh+rrfyjOD6+DijuHlwTlRHUJjn0Cp+N5iW/WKlqnStnqK1RcGgRs3RzU gCdLcq/dqp+gSXSfxZwXtqzRTIun7hzOdodmkqcgr2L/Jz6L+WnDw1I4SQ5DsUuoFZfA c/wt60lIgYQrJJHtXjl/FTs0mgOi1/y+G6CBTy9bW8Pnp6manAZtmx6gbr5abe97b0uJ ko9TZeS5oo7A2s6KBON++qRbfdQtng2MaTLrPVy5DFM3iu9ZCYRAbwWj4lyTnL3zVy0H l3rBunOqzGIS/75n1v5zSmI/PVg/UEnvx1Gqi5WEleruTInNT6OaoGD9Utygxqve/DGp c3Zw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776288062 header.b=If1m8YcS; dkim=pass header.i=@clients.mail.as397444.net header.s=1776288064 header.b=nOXvNkr+; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::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. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id 956f58d0204a3-652e4534ff3si99588d50.1.2026.04.15.14.50.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 14:50:34 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::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 1wD880-000000061S2-3KwN; Wed, 15 Apr 2026 21:50:32 +0000 Message-ID: <61159968-e2cd-44a6-8171-a815e6055cff@mattcorallo.com> Date: Wed, 15 Apr 2026 17:50:31 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] In defense of a PQ output type To: Anthony Towns Cc: Bitcoin Development Mailing List References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> <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> 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=1776288062 header.b=If1m8YcS; dkim=pass header.i=@clients.mail.as397444.net header.s=1776288064 header.b=nOXvNkr+; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::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 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.