From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 16 Apr 2026 04:44:40 -0700 Received: from mail-ot1-f58.google.com ([209.85.210.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 1wDL9D-0006sM-Q6 for bitcoindev@gnusha.org; Thu, 16 Apr 2026 04:44:40 -0700 Received: by mail-ot1-f58.google.com with SMTP id 46e09a7af769-7dbd60b7ecbsf20428256a34.1 for ; Thu, 16 Apr 2026 04:44:39 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776339873; cv=pass; d=google.com; s=arc-20240605; b=X6IN7STzmc7/8QMsEMVm7FEcftCGp3eiLeUTQaomIu3wogMJxwkQU9QImj84zVmxmL ymbTExcdDbXr+9kr7A4R2Gsux3lfc2I2KqgFYx/m0DP6WJwadQhaeWHic1Oia2lT9BJt p20HqqfZmLjlQWtStFtCG7HJAPCwYnwFNKPQXcqzEsyb56xJRRnC900Y84XboY//ic4L ru+/kkKOaD5C1ui3fcpA3/ZEWEdluBdQWT4z6g0vQwyNPiigYptsUBQnEJRCzPVrqFwz kaZ43qbixwzEokPL4pbzFJ4iKMInDK71NGZ5j+NYWzn9ruDrG76Tt2BGkVbG1X2SvRSI RCDA== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=HMZVnFsx97NiIt6py9Oo37sp873BBfH2SQmzYDHaEiU=; fh=QAlRjLjmGSrErxV5gK0DNh2tpj7AxkeWTKaK1UITY/s=; b=Is35bPQa23/QeZTvbPM2/RitKqR+l5V2O1TR6ES1CLvfw1g4AXN0zzYlYJbQFuDHo6 E0kH9EXJM6RVdMYxcd924/KJ1JZlUfCXHmGTGjakH2+EStele2PLyR5MoVRc1ZMDeUyX AEfhHe3vm/tTTthfZvWz1/tH+fSaxL5IkZXSParb3SHWEFjp2PglY0HtykkwHJMTSk4i tuR/7bhwP3ZLikojuLkE/zdTv0T8bryzmjBNuESEljaMHsBFzhwdpEKVD4y3WmA4j9Ag SW+23HOSwCiKFpLR9C+gdQ2D7xTmEXtm59llBfPhZGOneQkGjcwE4yKAIwOl2XIYyiSF FsTw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=lgb0EOL6; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776339873; x=1776944673; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=HMZVnFsx97NiIt6py9Oo37sp873BBfH2SQmzYDHaEiU=; b=ZLmcOy6Q45uJc3TU5FuATz5J5elCbTdzYNeTW2zojIWwx3/coa/3HhwWcZM+kKUwC5 9qToRcJyZ4djAvmcw7pNjfDdr4ga/xWh4X83tnDXJlO0qBzWx/UjXJwjE9Za4UNDEY5w dVvQo0Bk/m76hO5pU3Jxhn9q70YUFC0Ad/FyrdVRAwPxnSAiTyJaxxBAwY4pEPd04k0r 5LfCOnsBssp3akflmqfLsyZG9FHIkMbN02yRr6Spp2oK+iKSDXMYrXUNgisK4Pd3gPxe 29dF21rNy0OcebcyITJ+UOCQY7FmzhftLf4usaaZFveeQKvYUYG7IYed/+jA1burbGHD bUOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776339873; x=1776944673; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HMZVnFsx97NiIt6py9Oo37sp873BBfH2SQmzYDHaEiU=; b=UkJz2AF30ATocrI110TP/mOhjbbSVdnHCPCTAbGULGtooLed0vN5/r5Dmgk41V+34O f9EAp473qXBuIJ1TsWO7DbgBGPrp5L08JOqrdDETuob02wSRYeqJSDIMFG1e5eCSM0bu Cte5g3x96ofQVdhBka1EOL5RI1xz5uLePfGtPsKk5Yximi+rBPEkmeAWQyHoUYuk/I9m Vryt+2p25xY0jj4sU4qJK3wauzL7Wxxi6lmFugTwVlUm0k9uKU6yX5g6LkYDISq2Osdk FhIVX5MWWjvPrg3PsM5/eg3UdBYBECdMoq0++P0lxFzKVPODbOL2aT7i+5pH2PA+a7rF Z4KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776339873; x=1776944673; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=HMZVnFsx97NiIt6py9Oo37sp873BBfH2SQmzYDHaEiU=; b=XFn+oGuUMp4HKgAxjfmFC3Y7eqrAOdPo0LlgsSpbv/rkf09G0NVkYHGRqFA8D0EXbO PyaUx93Orsv2uftsu9Fx7+EKs7H+4mQCjeQc39Wzvm4GkFii3HkkGIWzS1SPl/TpWp2w 14lMz37VZSSdulrhmmJENwVcB6BQHCGmICI7tg0BMip8ksg/EuOxwmPLGAsuAzn1bl8+ wM9UmNHc68OcA/qCFMoqt134juGeOn0xcQ+KE1006sKjUWfqRKp7FX0yG0t+mYPhgyDZ 7k1/OmR6lOrcm00rAbbMsHq2W9d7/PWY6EAJQ1OttvOEERi4STxVdoKQOyGer+rGyS8N uWjg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ90Qwqn+gCXYeMsj6arF6mgcGGfes8fzHteCzdp87/sTtQ2JvU8Z/KojaGzbWqyRUZvRHmNZLk7uCIj@gnusha.org X-Gm-Message-State: AOJu0YxZk/IfFRP6o1cH1k4wY67khntG9A0DvhfF1bTq8IFJgy+bztCA uWqtiHECuNFHS4g9vpIC9l6g87rsLBays8f9epUuHp6qBO+TPWPNDTOn X-Received: by 2002:a05:6820:2907:b0:683:c005:54fa with SMTP id 006d021491bc7-68be80deb43mr13159184eaf.41.1776339873397; Thu, 16 Apr 2026 04:44:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJEZwZnm2T1/o5rdaCpPfVfS3SFDaEQzaPJOXvAO1qrxQ==" Received: by 2002:a05:6820:1ca1:b0:688:c001:f814 with SMTP id 006d021491bc7-6943c8d6210ls423437eaf.1.-pod-prod-08-us; Thu, 16 Apr 2026 04:44:28 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ8NN4idmYVCsu3VC4wk6COfMlcwMkG85BoNnfQrCAE2S+5l1vDZNpOP86thSIa9w7eShLNBVtDsdMN1@googlegroups.com X-Received: by 2002:a05:6808:4f20:b0:467:1212:46eb with SMTP id 5614622812f47-4789f109a3dmr15934993b6e.35.1776339867986; Thu, 16 Apr 2026 04:44:27 -0700 (PDT) Received: by 2002:a05:6504:1381:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-2f7410d1ab5msc7a; Thu, 16 Apr 2026 04:19:15 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ8LrrMFdWE2zozQHP3Agbnq02RBX1pAM3Mw9n4Kqog6tiq1S1B3lcsKL9xPG0qCHa4KnWhiR2GSV/0M@googlegroups.com X-Received: by 2002:a05:6512:1192:b0:5a4:299:285b with SMTP id 2adb3069b0e04-5a40df7f715mr1249638e87.12.1776338353479; Thu, 16 Apr 2026 04:19:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776338353; cv=pass; d=google.com; s=arc-20240605; b=KR7HsaG63pSgM6yMouw0y3gLpMB6PUnS1MtF2YsSfX8AqYZZLkWupxYmCZ/UKkpr+a lNzU+8Zi4EfrhJ35VV73l2MnYutRkf7HUBDrpXTVdEevCSO12hOaxHUZ+yedSfOghfmY veqMnx7MyW2Lt8RtOG1w5i6BUj95Vv+v4UFO2Qn5c295UKQu2vuZP6WIlyWA9CeVOpEw pPF8uEM/LUU0Vsw0O8O5z5QK52n0EYciuBeqC8gbYyLazDu63fSpyA7MwidKpnckDsq1 3+vBSitwnDD/EcB5V2vXPQVVsX/M9izKmNNUwQRwxXROB0+TPiiCZQGmUDnm4NIx9Z0r 8+UA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=bg2b8328IZcCcimZqp/C0MhQLZEMXTx5TCpY2GFmNa0=; fh=SXm212CzJKfPzBVZG8SpkCkcDUb0L3TpGtAmC4thjPg=; b=eoDoRcCwVXquLLHUH+gae6YItbh8XWl7AUEnOPjqZ675ALyCEPe3CawS+r9q4PiYyZ 5yYsMioONPpwjQG7wzW/oIWiJxVFF5WIY7Rfsoy0RhwQUHd4At4KGaIYX60xW5/p/x9J dOtHRP9UYv5dgkP0/pp8rUCtFhsZ1yfdKPpko9YMOkM48LBLcOvR93RHg2t8S1ZIRx46 aZbx+KB9NF4Pt3ojNzRIx0ER16SHLbCI2I4qQEOnl2snGIIO6fl1t8a//CzNaTnV3cS5 ka6mhIdgq96Hhoo2jo7LeqLeMPGj+5ug9fpG9nRp7gSR5Hq2+Vdsh4gWs3lYBgu8Fmiq aEbg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=lgb0EOL6; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com. [2a00:1450:4864:20::52d]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5a4138722ccsi2511e87.2.2026.04.16.04.19.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2026 04:19:13 -0700 (PDT) Received-SPF: pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) client-ip=2a00:1450:4864:20::52d; Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-66d65646c65so1157262a12.1 for ; Thu, 16 Apr 2026 04:19:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776338353; cv=none; d=google.com; s=arc-20240605; b=RJidhoX/zC1KloDJ/4VP0LojCt+ZD9zVtkIKjsMXrioXcogx+qd7UBvOLU1dN1iFGk erLDN5gVeAxNQwt1DTGU6I//S+40BMreqHp5iJqFHYDDMO40fXqBYJyDBNgsaNg5z/yG ShOVzWWKbkygLoBHMGwQc+hmoZzLuwUz95npfB+lV75B4ZBl4BWoz1nD8k55rOBS2UQ3 W8FjDhTb8xMW6NI8Eub7k9LxzmyLovp5SNxgtM+TI7SSOs4ORNzsBxqAUbl92+Lo9H04 Kkpi1kDR1SgmTCi51/v+Hqif3DCgsaRiKDm1hWVx/QjfkdiLkFTDzkrHdwOAj62etcU5 /2Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=bg2b8328IZcCcimZqp/C0MhQLZEMXTx5TCpY2GFmNa0=; fh=SXm212CzJKfPzBVZG8SpkCkcDUb0L3TpGtAmC4thjPg=; b=jvzaiSn3ecqane8pSZC0GeX7fercFjELKmVI4mteClArz6f2xNC49XDCxFehgh0A2X jJ4hbKUviwO7CVUxL3aCA4O18fOFcVETyVFlFYSsT2RFA0gOlWO3nTRE19T/6y4oZQAp mjxipWeJyUu8QUQg+8xlrVcsg4UNhDTYGiToA4FaFcn6X4jZgCO4sdRrDJqGdldN4sxV CeccRyb5fX7lCsT3lZGasofS/ByFq1Qwif3NVsWADNHvFRjIT+WtNEQVki3xw41sSW2Z KxfE8LGOn0S0LlhpLniJjWMV3moI5EEKH3f5mfHVaP8rkAm8Vv+lWRebBvV1/Gqajjij nXFA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ/8Q4/Cz+kFAQL5M2A21+RqZfaXRJnOoBz+tgH669Ka3XqPPw0AQz/x3U2KR/eKr2ox8JP0l8R3iOrj@googlegroups.com X-Gm-Gg: AeBDievfMtZUqW+Y3sEl/PUCPV/7g6+TIKAyvVR7r3IRg5CMCHBEuN2yZk/PiFmHOLM pH24agZlDv/zOXaO7/agCRMmnX7HIB10zwyADWH2nmKUPYzKckn5deSemIaSPXNeR3N0PGATKCL zU1pnpSb6x4TfzeTocpinodf8Xd02DzApSc/jCT2sfswZ+JoV7GTdPr+IMq6mJwBtn7Qpw6QZrQ uthly4SvBN1c3/u8+SmDhs0KVu/aT9ubwE90lydgA5yu1yopIbsjlCTsNc2/Z8Ad+WHWpmyUY1e XFDDfTP3/not/zWg X-Received: by 2002:a05:6402:46c5:b0:66e:6f38:47ef with SMTP id 4fb4d7f45d1cf-6728ee0957cmr532288a12.8.1776338352313; Thu, 16 Apr 2026 04:19:12 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Garlo Nicon Date: Thu, 16 Apr 2026 13:19:00 +0200 X-Gm-Features: AQROBzAi-N7N37mwqlbju39GfyZmPyMoDS0gqF45inUFj5n1UAyI5DoTTjw-5kk Message-ID: Subject: Re: [bitcoindev] In defense of a PQ output type To: Anthony Towns Cc: Matt Corallo , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000007d98cc064f920027" X-Original-Sender: garlonicon@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=lgb0EOL6; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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.5 (/) --0000000000007d98cc064f920027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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. It is a soft-fork, if you need both: the old signature from secp256k1, and the new one. Then, producing the first part can be as trivial, as if old coins would sit on OP_TRUE, and the second part actually decides, where the coins should go. And then, as usual, old nodes can receive only the secp256k1 part, while new nodes can receive everything. Just like the whole Segwit works like OP_TRUE for all pre-Segwit nodes. > 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 think it is better to make it sigops-based. For each and every OP_CHECKSIG call, or its equivalent, you need a new signature, in a separate space, counted separately, and never shared with the old nodes. Then, you can fairly compare different quantum proposals, regardless of their signature sizes. Because why old nodes should even process quantum signatures in the first place? They don't have the code to validate it anyway, and they will treat it as OP_TRUE, or something similar. Which means, that if you have 80k sigops limit, then the new maximum size for "quantum signature stack" would be 80k, multiplied by the size of the new signature, depending on the chosen algorithm. czw., 16 kwi 2026 o 01:34 Anthony Towns napisa=C5=82(a)= : > 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 t= he > > > > 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 makin= g > 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 CRQ= C > > > 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 willingnes= s > > > 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.c= om.au > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAN7kyNi1QD%2B1TJsCaCSrtumOZpEPqV0aV3Hqb6feeY49q9XMxQ%40mail.gmail.com. --0000000000007d98cc064f920027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Making existing UTXOs ("all quantum-vulnerable a= ddresses") spendable via a previously non-existant quantum safe path i= s a hard fork. Sorry if I didn't phrase that clearly enough.

It= is a soft-fork, if you need both: the old signature from secp256k1, and th= e new one. Then, producing the first part can be as trivial, as if old coin= s would sit on OP_TRUE, and the second part actually decides, where the coi= ns should go.

And then, as usual, old nodes can receive only the sec= p256k1 part, while new nodes can receive everything. Just like the whole Se= gwit works like OP_TRUE for all pre-Segwit nodes.

> Another advan= tage of a hard-fork approach is you could relatively easily include an incr= eased blocksize to mitigate some of the impact of larger signature sizes.
I think it is better to make it sigops-based. For each and every OP_C= HECKSIG call, or its equivalent, you need a new signature, in a separate sp= ace, counted separately, and never shared with the old nodes. Then, you can= fairly compare different quantum proposals, regardless of their signature = sizes. Because why old nodes should even process quantum signatures in the = first place? They don't have the code to validate it anyway, and they w= ill treat it as OP_TRUE, or something similar.

Which means, that if = you have 80k sigops limit, then the new maximum size for "quantum sign= ature stack" would be 80k, multiplied by the size of the new signature= , depending on the chosen algorithm.

czw., 16 kwi 2026= o 01:34=C2=A0Anthony Towns <aj@eri= sian.com.au> napisa=C5=82(a):
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 r= eality. That
> > > means looking at the system as a whole, not individuals. Not= ably, 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 h= asn't, and a
> > > CRQC becomes an imminent reality, *we've failed*.
> >
> > I think those views are contradictory. Preparing for a post-quant= um
> > 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 a= bout CRQC
> > to migrate beforehand is precisely to "convince" them t= hat the (low)
> > risk is worth the (low) cost.
> >
> > If the outcome of not doing something is that you've "fa= iled", then
> > doing that thing is your "job".
>
> I mean I agree with everything you said but I think that's also wh= at 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
> >=C2=A0 =C2=A0(30%-95% of BTC held in CRQC-vulnerable
> >=C2=A0 =C2=A0 addresses, CRQC is believed by the public to exist, = and willingness
> >=C2=A0 =C2=A0 to hold BTC when large portions of supply are CRQC-v= ulnerable is
> >=C2=A0 =C2=A0 already low or dropping fast)
> > could be to create a hard-fork the chain,
> >=C2=A0 =C2=A0 preserving the UTXO set, but
> >=C2=A0 =C2=A0 making all quantum-vulnerable addresses only spendab= le
> >=C2=A0 =C2=A0 via a scheme like roasbeef's recent demo
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(ie, provide a PQ ZK proof of a hardene= d derivation path
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the pubkey that links that knowledg= e to a new
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 quantum-safe pubkey).

> Oh we're very much on the same page here. Such an outcome sucks bu= t its
> better than literally nothing. My point was more that some people do h= ave 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") spenda= ble
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 disablin= g spending paths
> > when there isn't any other way to spend funds. From what I= 9;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),<= br> 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<= br> 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aeAfnufGvf1pG85h%40eri= sian.com.au.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAN7kyNi1QD%2B1TJsCaCSrtumOZpEPqV0aV3Hqb6feeY49q9XMxQ%40ma= il.gmail.com.
--0000000000007d98cc064f920027--