From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Jun 2026 17:41:04 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1waNI4-0001N3-Bb for bitcoindev@gnusha.org; Thu, 18 Jun 2026 17:41:03 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-43cce364a75sf2468275fac.2 for ; Thu, 18 Jun 2026 17:40:59 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781829654; cv=pass; d=google.com; s=arc-20240605; b=NrLiC0VO47fl16KApEIZ1NCHjml0oefOl3SmwrwU85elObiydOOwt7W0CDiHFNMbn6 xI5WR4Py46VKS1Q3VGV+zfmGjIRR1u8hiQlpGtfw3uJLHl9qvLYj7a9ZJXpeR1n4yxkd nVBmx4H1o8+SGBXrmNKqExAhoVVmYlOSzrHNxBzXrThdvQULMLBlAelnQKREGSqc3naa LMcznWJMoEjDEpAPSCNM2E8hlc7NZexxUUcCiQsfC6XlK+B8ReZXP6xoToZ8NwDxomTt 2KhKm+wpZcYnmN1J4YEGs0MigX6LRamB8gNTzhqoOSKQxEhsvnP3+KRPf2Nzy2A+9J55 CWhg== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=geSsbTLxMHI/NHJlZP8EZ4Th9jEiLM0HhslKm6F6I0w=; fh=BVWuPZMXhL+LLQvmN9cyEoQN1yD6pYffkTm3bH7Jq5Y=; b=dlT8MHbGo1U4oC1GPKRkQ/3c193PM/YNsvzUu/2Lw5HrE6Vk/VUIY4s8X+krh4OS3+ fnusVI8dfNxTjZwaxUrP50Q17nOLFXel7NYEDQs2d4zQ4q+v+E6wKysuASWS7QKGMKsM 6WeyeB9CuZFr6pNtL6TjZwxuNz3xqPe2Dg+RDR7OuxlisNN/88XxZWrPtF17disbmSxO m1n6iXGryKaqBUKBuR1JXRFQ6PqiGfO6p9643ixmPHlnRkjvczaG9Zu0LpETqvjDkxpr tkvhx99WCGPZnrJdGvsSSmjtx+trEnKwIdSiCnKPC1oTQOnN9fVtGG1cmNXxoiSEeACU nFYw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="BeyHUVm/"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781829654; x=1782434454; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=geSsbTLxMHI/NHJlZP8EZ4Th9jEiLM0HhslKm6F6I0w=; b=SG8zPWiMRO2o5+iuUHyOE2ckK4LjCVsW7zy4aPYNg0Iowpz81dSSh8I+8iu8vFxJqq PY5NYWoBLRTA0fsycTtoIySZvyfxEiy3iLAKBcacn6uCjg9IhR7cBVq8162Ab2SWqw57 pb7h8Edzb/jJWgLMNZRPi72oVQ2ljHFDG9rAqbYVpcxmIdaXvmmbxzmLinJxmPHFucg4 0RI7lR7Ce5uuFqbYvUHuWXmxd4rFNNSnJu1X2NYoDQaaT3efPcu7SU6yGEnY4wAwKtCZ BAEKzj3Xw1SaevMTifxMu9IdWt3EjF/cSpI4w90+OXcTbMeg/x3uDuYddK7rkRoCgVmn aUig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781829654; x=1782434454; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=geSsbTLxMHI/NHJlZP8EZ4Th9jEiLM0HhslKm6F6I0w=; b=em1LOCi51EY+MbPNYVXOGuKKDbhSuvbRSg6dQbas00BFBnSkY5Z49AWJusjwe+xovT 1tJOyi6EZ9vzrA3Y9TTi5WkI+ZUZHSXjH1uy50bb/htEZLW32Ue7W0xOInqqiFrWcgoC prcFwCijPYTkqfXgk4qX4k3rcOiUk79cstgHIId1M+ePZ3/fNjUTWbNrxv4NsdqmaTlJ oVZMbGyS7kDnD0VXu517PV3hbfaaO1HOJsQiP2q2YiBoW6q4XRBroMtGz2hJ5LOPCf11 qYle51kLKM3hDExPRx4vUhQxErMs2lxwdUSgL0qQnpio924HvNzE9jQTo+xa4w90HlnG bz0A== X-Forwarded-Encrypted: i=2; AFNElJ8zLicnXr9c7xQfb8QqF0gK2TpiIXcKdHpKgPM8SOmtieU5MDzZtfU+quSmbFlS8L75Xbi69V7+N/X5@gnusha.org X-Gm-Message-State: AOJu0Yxos2NMkXK+Tsc4bIRqQxVPgHrFCPEHHA+YIv6R96YqDQ47bAgV M7Rm1govEvH9AfwIiv2NkHFC2TTZc3BJwUYcte2sPJk0ybG6e3+epJ/u X-Received: by 2002:a05:6871:294:b0:42f:aec9:9d92 with SMTP id 586e51a60fabf-44716d5b3b8mr115689fac.29.1781829653571; Thu, 18 Jun 2026 17:40:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfz2C3xvbOPtW5Ioh6xbpnwFHAxpu168SJX8/4pUyijOg==" Received: by 2002:a05:6870:d14c:b0:43b:781c:b5e with SMTP id 586e51a60fabf-446dfac0270ls1063412fac.1.-pod-prod-03-us; Thu, 18 Jun 2026 17:40:48 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+OcB86z7UoWshQmWPKc/n5ZtuQsUme606WRURwV6OJra+aZPg2RVgNytrWswCYJBajJeSF0AT9XGFd@googlegroups.com X-Received: by 2002:a05:6808:309f:b0:470:434b:aece with SMTP id 5614622812f47-489b16c598dmr294747b6e.40.1781829648564; Thu, 18 Jun 2026 17:40:48 -0700 (PDT) Received: by 2002:a05:600c:218d:b0:490:3d60:134 with SMTP id 5b1f17b1804b1-4923fc648c0ms5e9; Thu, 18 Jun 2026 17:31:06 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9IdV5YiEhyjci+SI9EAdHCLc+eqlSM4yvNK7Hk6BsO1wt6SKviWrywwKYTHuLxgUaVhNpob0aMcdiC@googlegroups.com X-Received: by 2002:a05:6000:4e:b0:461:a161:8101 with SMTP id ffacd0b85a97d-46500439771mr1959563f8f.11.1781829064114; Thu, 18 Jun 2026 17:31:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781829064; cv=none; d=google.com; s=arc-20240605; b=fe5qCHcgBH5coc49P53j7Qow6SnliCH6Bfr/pEvPCTM0mN/blprkhfU7OBJgoUEHt9 zIphUtOC6/25XDs3/5IU5efl+r4JSjoJ5u9HmhAGFfOv0cqguMC5S2HmQPIZIqCUU0LM 43TAEBivgHkvxN/UVwi3BxGAnCLNqrdEO9dyORvP99kEIhR/MAftkmlcEbMq/mPLD4z7 5GZk0NMTYdaoSGUvKITpnADG3GO9FdSGW1GAo80XYG0PIhWbTUpVH12xzP8UdgotNNwc cO/0ESSnNCnWqthO8+RGZQBE/F84sW3nI2VfIVwo8XiLlxJ7vlY0N84HqkbRbxwKX/LT ncUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=S9CSOruayTAW+Wl/FmiNbqPsbiCBIcGxB1lr0DM6Cbs=; fh=x2RhTgREnGL9Pud95B3Kk4+0Ujvb9srG2TsazUqHlF4=; b=DkjECl7WtcNeOWhdKjje89xMxOMwSmXkAsky7wXWGGXhSJ0tQrcsuOk02He8jLWXYA lZfchUG3SeSMnnAhIP8OhjRV75z/59M/xLeJ0qcAyW25omO+pGZA/qaeQYbaiDCsQhsh 5nU90moI/BRH58Wer/U7ROfwKUl4Zdsx0DhfA/8D00j63muxyHZLZrXWumgtjoZuuOQL YXsM+LELO0afhIf7YgYiY5sEdLIN/cYFO2f19Y1VUaVQdYY3DcR1OM/Ly5hOvK5378nS D8CGmBZt8nD4il+jNjklr3U1c74UvFZNj1bbFD3FFvjrFSvEc9hkkIBNt6jVAEX9RD+1 RcOA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="BeyHUVm/"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-4650d5673a2si24823f8f.3.2026.06.18.17.31.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 17:31:04 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Fri, 19 Jun 2026 00:30:53 +0000 To: Anthony Towns , Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Antoine Poinsot , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: In-Reply-To: References: =?us-ascii?Q?_____<=5Fz6=5FJUmphCkUYvI6gemSFMD9Sb=5FrDL03IQbtZQCNlk6pmioGEQBir=5FgMyZCfticFa8Ttfc0xoFHdxR07=5FMNuAfBu8do=5Fh5IDf2apVk1w1BM=3D@wuille.net>__<81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3U?= =?us-ascii?Q?e5E4zc2qWYn65gRxmmFLKg=3D@wuille.net>_?= Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 88b693554ad7609c2c2b3e21c617f2858bf49cc5 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------222e786de1d1c59c3cf2c26b40005f2bcfeeb42fb9f023a5721355024daf5660"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="BeyHUVm/"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------222e786de1d1c59c3cf2c26b40005f2bcfeeb42fb9f023a5721355024daf5660 Content-Type: multipart/mixed;boundary=---------------------7b31cde623ce4c9c50d8b7331f4e7de2 -----------------------7b31cde623ce4c9c50d8b7331f4e7de2 Content-Type: multipart/alternative;boundary=---------------------ab02db44edb9bf06b304dab94202ff82 -----------------------ab02db44edb9bf06b304dab94202ff82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" I really appreciate you all taking the time to have this important discussi= on together and still keeping things civil. The discussion on this thread h= as branched out from PQ migration destinations into also discussing confisc= atory retroactive upgrades, like rescue protocols. I think, as per Antoine'= s recent thread, it's a mistake to conflate the two subjects, so this first= email is just going to focus on designing secure PQ output types, and I'll= include responses to the retroactive stuff in a separate message. ---------- I feel like we've all been pulled deep into the weeds of forecasting differ= ent quantum doom scenarios here. I'm gonna try to pick out the key disagree= ment we are dancing around, and examine it more closely. Sipa's comment here: > I can't imagine we don't get at least a year's worth of notice in the for= m of breakthroughs on simpler QC problems. ...is emblematic of an assumption baked into the security of P2TRv2: That w= e can predict Q-day.=C2=A0Unfortunately, no one - not even quantum computin= g experts, let alone the Bitcoin community - can reliably predict when Q-da= y will happen, if it even happens at all. I think this is the core problem = we need to dissect. On one hand, if we assume we'll be able to predict Q-day in advance, then w= e can get away with a lot: Use maximally efficient EC key-spending (P2TRv2)= till the last moment, then disable EC. Deploy P2MR with only PQ sigs, and = everyone can slowly migrate to use PQ sigs on P2MR. That'd be the ideal wor= ld. But we may or may not live in that world. We have no certainty that such la= rge technological leaps will happen slowly and behave predictably. Could th= e world in 1944 (outside Los Alamos) have confidently predicted the first u= se of an atomic bomb in 1945?=C2=A0Could the world=C2=A0in 2006=C2=A0(outsi= de Apple)=C2=A0have confidently predicted the iPhone would debut in 2007? H= ow many of us in 2021 would have bet on LLMs or stable diffusion appearing?= What the odds today on net-positive fusion energy for 2027? In many cases,= even the innovators building these things couldn't have foreseen their suc= cess more than a few weeks in advance. On the other hand, we also have no certainty a leap will happen quickly, or= that it will happen at all. AJ highlighted some great quotes from the goog= le paper which suggest it might happen quickly... but for all we know, mayb= e there's some "Great Filter" that stalls QC scaling around X Toffoli gates= , or at n qubits. Ultimately we just don't know one way or the other. AJ put it very well her= e: > Picking when Q-day will occur, either individually for determining=C2=A0y= our own security posture, or collectively for organising a consensus change= seems very difficulty: it involves evaluating both complex state of the ar= t physics research, but also estimating the covert abilities of national go= vernments and the incentives to attack bitcoin prior to revealing their cap= abilities. To me, that doesn't bode well for a smooth=C2=A0and fast deploym= ent of a consensus change in advance of problems occuring. With that in mind, i will now attempt an argument for P2MR based on the pre= mise that Q-day is unpredictable (at least for now). I follow sipa's more general belief that a follow-up EC disable soft-fork f= or the new output type is desirable, to reduce harm after Q-Day from EC pub= key exposure. We all seem to agree there. However, I strongly doubt that we (the entire bitcoin community) will be ab= le to time such a fork correctly. By "correctly", I mean: within a few days= before, but no later than Q-day (the first day a CRQC would be able to sta= rt stealing coins). Why am I so strict about the timing? Consider if we accepted AJ's definitio= n of perfect timing,=C2=A0 > FWIW, I would define "timed perfectly" precisely as "EC disabling fork ha= ppens before Q-day". Maybe allowing some additional months of EC-efficiency= would be a win while not taking out too much migration time, but for me "p= erfection" here means "no one who upgraded lost money via quantum-related v= ulnerabilities". ...with which sipa seems to agree: > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed perfec= tly. The expectation should be just that it happens before Q-day, and when = it looks inevitable or the fear about that is large enough I disagree. If we disable EC months in advance of Q-day, and if we=C2=A0do = so only for the new output type, then it will likely backfire. During those= months, a subset of coins will regress back to using classical wallets - P= 2TR, P2WPKH, etc - for many reasons. Maybe they think CRQCs are not a real = threat yet. Maybe they think they can predict Q-day better than we did, and= don't want to pay the extra sats for larger PQ signatures until then. Mayb= e they need EC for a specific protocol and haven't finished migrating their= code to PQ yet. Who knows. But the longer the duration between EC disablin= g and the first verifiable proof of CRQCs (likely to arrive on or after Q-d= ay), the more opportunity and incentive there will be for users to regress = back to a place of vulnerability. Thus if we entirely rely on EC disabling for the security of the new output= type, as in P2TRv2, we should time such a deployment perfectly: Any later = and all users are vulnerable. Too much earlier, and users are incentivized = to regress. Also recall that "we disable" really means "the entire community agrees to = disable". If dictatorial power were vested in the hands of a well-informed = autist with a Dark-Forest-style Big Red Button, then maybe they'd have a ch= ance to react to Q-day. But an entire decentralized network, fraught with m= isinformation and polarized politics? Not likely, unless we can build and d= eploy a trustless, unattended canary in advance of Q-day, which somehow doe= sn't require a cooperative CRQC. That seems implausible today but I would w= elcome any evidence to the contrary. And so, since timing is hard,=C2=A0I assert that we should prefer P2MR over= P2TRv2=C2=A0because we are confident P2MR is sound even if the EC disable = fork is deployed late (after Q-day). With P2MR, we at least have some wiggle-room in our timing of the EC disabl= ing soft-fork. Maybe not a lot - depends on how much users expose their EC = leaves - but perhaps enough to give us time to react while the CRQC gets bu= sy cracking exposed keys. As to the question of P2MR's "friction" that sipa claims discourages migrat= ion, I think this is a low-impact point in the debate and I have no rebutta= l, except that a temporary tax of 32 weight units per input seems a small p= rice for insurance against theft/devaluation of one's entire stack. I suspe= ct P2MR's current popularity - even before Boris' EC recovery idea - is dri= ven by that sentiment. If anything I'd argue that P2TRv2's timing-sensitivi= ty would have an even sharper chilling effect and would curb migration prog= ress much more than P2MR's 32 extra weight units would. Maybe I am wrong, and 32 WU/input is a significant factor impacting user be= havior before Q-day. If so, this amplifies my earlier point that deploying = EC disabling too early will incentivize regression to classical addresses, = and we would need to be even more careful in our timing: The pre-Q-day effi= ciency gap between EC and PQ sigs is much wider than the gap between P2MR a= nd P2TRv2. With my main argument made, I'd like to respond to individual points and qu= estions: > I have reservations too about the "Later" EC-disabling soft fork expectat= ions about P2TRv2, but they're not about whether the future Bitcoin ecosyst= em can coordinate a softfork; that seems almost trivial if not doing so pos= es an existential threat, and could be done within a few months if it's exp= ected and designed already. I'm more worried about it not being adopted due= to indifference/friction, or being abused/misused. Interesting, what gives you confidence that we'll be able to coordinate and= time it correctly? Assuming everyone agrees and wants to, how would we go = about it? > Bitcoin can only meaningfully survive a systemic risk of this nature thro= ugh collective action Agreed! I think we just disagree about which collective actions are most im= portant, and we have differing confidence in the feasibility of those actio= ns and their timing. > This focus on allowing individual users the ability to safeguard their co= ins just feels like a red herring: I'm not worried about my own coins being= stolen. I'm worried about (fear of) a CRQC undermining trust in the curren= cy as a whole, or through a fear-driven consensus change the ecosystem dest= roying its own values beforehand. I second AJ: > While I appreciate your point, I also feel that "allowing individual user= s the ability to safeguard their coins" is pretty close to the entire point= of Bitcoin. :) Sovereign control of value is the core promise of Bitcoin.=C2=A0 However, sipa's argument is also very valid. We need to do everything we ca= n to preserve overall integrity of the entire UTXO set, as much as is human= ly possible. This preserves trust in the currency as a whole. We can have both, by deploying P2MR with PQ sigs to secure those who can mi= grate in time, and then an EC disabling follow-up, maybe with rescue protoc= ols to secure procrastinators. This protects as many UTXOs as I think are p= ossible with current knowledge, and is not as sensitive to timing as if we = used P2TRv2. > I understand the feeling of urgency, but this seems like a=C2=A0"we must = do something, this is something, thus we must do it!" approach that just gi= ves people the impression something is being done, without fundamentally ta= ckling the hard problem of actually migrating Bitcoin, and leaving that har= der problem to a (to me) very undesirable, but still unspecified future. An= d solving that harder problem will inevitably need another consensus change= later, so it doesn't help with the "running out of years" problem if you b= elieve those take too long. I also dislike that class of argument. People use it all the time here to j= ustify half-baked "solutions" to quantum problems. But that's not what I wa= s saying in my point. The act of migration itself is indeed a very complex task, vastly different= from designing the migration paths. We can't start working on the latter u= ntil we have the former. So no, working on a migration path is really impor= tant and does help with "running out of years", because if we did nothing w= e'd have nowhere to migrate coins to, or we'd have to rush something out in= a hurry when it is urgently needed. > Of course, if you believe it's the only possible future, I understand you= 'd come to a different conclusion. But is it really? Do you think this isn'= t a plausible future: > ... > There are many other possible futures. Some are minor variations of these= two scenarios. Some are fairly bad independently of the choice between P2M= R or P2TRv2 (e.g. Q-day comes before any substantial migration). Some are m= ostly fine regardless (e.g. everyone has time to migrate to later P2QR isog= eny stuff, or just no CRQC ever). But these two in particular, I think have= a much better chance of happening with P2TRv2 than P2MR, because far more = people can just adopt it with low friction. The future you describe is absolutely plausible, and I would much prefer it= , but the steps where the new output type "gets adopted by=C2=A0practically= all active users" and where "the community quickly soft forks to disable E= C paths/opcodes" are both doing=C2=A0doing a lot of work there. Both are po= ssible, but uncertain, and so we ought to prepare for the alternatives too,= right? > - =C2=A0 Isogenies (or something else) get a ton more attention, implemen= tations get more efficient, gain well-studied features like tweaking and ho= momorphic derivation, get far better confidence in their security. I hope you'll be as excited I as I am to learn that isogenies already have = tweaking/derivation! See my own post here and this paper released just 10 d= ays ago which proves the idea secure. > - =C2=A0 A (not-quite-CR)-QC breaks 128-bit ECDLP, say. It is a common misconception that we can use toy curves as canaries. Unfort= unately we can't trust succinct proofs on small curves because they could b= e classically forgeable. Pollard-Rho can break ECDLP for points of order `n= ` with only `sqrt(n)` work today. For example,=C2=A0in 2016 these researche= rs broke a 117-bit binary-field curve using FPGAs, and this paper's authors= broke a 112-bit prime-field curve using a cluster of 200 playstations!=C2= =A0 So how big does a canary curve need to be, to be out of reach of Pollard-Rh= o but within reach of a fledgling CRQC? Bitcoin miners are today cumulatively doing about 2^95 work per year=C2=A0m= easured in SHA256 hashes (source). Pollard-rho work is measured in point ad= ditions, which is slower than SHA256, but only by a constant factor. Thus for a canary to be reasonably safe against large-scale classical attac= ks triggering a false-positive, we'd need a much larger curve, probably 192= bits or more, for a canary. That's uncomfortably close to the danger zone,= especially given the warnings AJ cited, and worse, it would be a moving go= alpost as classical parallelized-computing scales up. > Personally, that leaves me at a minimum very skeptical of the utility=C2= =A0of introducing either P2MR or P2TRv2 (etc) approaches that don't also=C2= =A0introduce a quantum-safe spending path on day one. Likewise. We don't want people migrating to PQ output types without a PQ sp= ending path. So we wouldn't want to deploy P2MR without a PQ signature sche= me to back it up. I hope we'll deploy both upgrades simultaneously in a sin= gle soft-fork package. Maybe some time after deployment, we can change memp= ool relay policy to consider payments to legacy addresses as non-standard, = and so further encourage migration without heavy-handed consensus changes l= ike those proposed by BIP361. > Preserving bitcoin as a personally-possessible inflation resistant=C2=A0s= tore of value seems both possible and worth caring about, even if other con= straints means that many people can't afford to personally hold it (and hav= e to go through ETFs/exchanges/banks) and that it can't be used=C2=A0for da= y-to-day transactions. Would be very disappointing if true, and=C2=A0even g= iven Q-day in a few years I expect we could do better than just that, but i= t doesn't feel like a throw-in-the-towel event to me. A big +1 from me on this.=C2=A0 Also remember that even if Bitcoin becomes awkward to use for a few years, = we can one day install better cryptography to bring lost features back, imp= rove scaling with discounts or more-efficient signatures, etc. But once UTX= Os are lost or stolen, we can never recover them without a contentious ETH-= classic-esque hard-fork. regards, conduition On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns aj@erisian.com.au = wrote: > On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote: >=20 > > I want to first correct a potential misunderstanding here, because > > I realize the terms "Later" and "Never" aren't very descriptive. They > > are specifically about an expected and relied-upon expectation that an > > EC-disabling fork will happen that at least applies to the output type > > itself, in time. "Later" is the expectation that such a disabling will > > happen after the output type is introduced, but still in time (so, befo= re > > Q-day). Outputs without a strong expectation that their EC paths/opcode= s > > will be disabled, or not in time, I classify under "Never". >=20 > > I believe here you're instead arguing for P2MR ("Merkle-Never") > > over all "Later" options. That was my previous point: I think (solely) > > having "Never" output types like P2MR is just utterly insufficient for > > any worthwhile migration. It's so incompatible with today's workflows > > that it either won't be adopted, or (possibly inadvertently) adopted > > in an insecure fashion. Yes, it gives people the option to safeguard > > their own coins, but to me that's disaster recovery territory - I think > > we ought to prioritize maximizing the chances for saving the currency > > as a whole in case Q-day comes, not a small subset of individual users' > > coins. P2MR (alone) doesn't really achieve much in that regard in my vi= ew, > > thus we at least need something of the "Later" class in addition. >=20 > I'm not sure I follow/agree with the logic here. I think the general idea > is: >=20 > 1) we create some new address types that allow post-quantum spending, but > also allow efficient quantum-vulnerable spending that can be used prior > to Q-day >=20 > 2) many people migrate to these new address types >=20 > 3) Q-day arrives >=20 > 4) all spending goes via the post-quantum paths, and everyone's funds are > safe >=20 > There are three main variations to this, I think: >=20 > Later-dominant: towards the end of (2) but prior to (3), the > quantum-vulnerable spend paths are disabled in a predictable, planned > manner, preventing coin theft, but not disrupting active usage > significantly (or not disrupting it any more than the proximity of > Q-day already is). >=20 > Self-reliance: Q-day goes from maybe to definitely faster than consensus > changes can be coordinated, and the only reason people's funds remain > safe is that they can (and do) keep the quantum-vulnerable spend > paths secret. >=20 > Disaster-recovery: neither the "predictable/planned consensus change" of > Later nor the "everyone takes responsiblity for their own funds" > works, and the only way to avoid a large percentage of bitcoin > becoming a reward for quantum research is to replace EC spend paths > with a ZK proof of knowledge of a BIP32 seed or similar, requiring > a hard fork. Such a hard fork would be certain to be controversial > ("why at this height: I received a payment five blocks after // > my funds were stolen by a quantum attacker five blocks earlier // > why are only BIP32 funds recoverable not scheme X"), but if no other > approach works, might still be the ultimately outcome. >=20 > > So the point here was just: if you already accept the need for a "Later= " > > output type (=3D one with builtin-in EC disabling expected from the sta= rt), > > P2TRv2 is preferable over P2MR+ED, because: >=20 > As far as I can see, only having P2TRv2 addresses would rule out the > "self-reliance" path here. >=20 > Picking when Q-day will occur, either individually for determining > your own security posture, or collectively for organising a consensus > change seems very difficulty: it involves evaluating both complex state > of the art physics research, but also estimating the covert abilities > of national governments and the incentives to attack bitcoin prior to > revealing their capabilities. To me, that doesn't bode well for a smooth > and fast deployment of a consensus change in advance of problems occuring= . >=20 > It's possible that general carelessness on behalf of users would also > rule out the effectiveness of a self-reliance approach: if only the most > conscientious 1% of users make use of P2MR securely, that might secure 10= % > of funds, but having 90% of the bitcoin supply crash probably wouldn't be > very valuable either. But even then, that may make the "disaster-recovery= " > approach less problematic, by ensuring the 1%/10% who were conscientious > can avoid being part of the "my funds were stolen by a quantum attacker" > contingent, eg. >=20 > > > Theorycrafting for a second here. It's reasonable to conjecture fee > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advanta= ge > > > over P2TRv2 will yield significant savings for end-users in absolute > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes bec= omes > > > significant (100 sats per spend or more). >=20 > I don't think that is the right way to look at. 8vb/input is about > an additional 14% today (vs a taproot key-path spend), but with the > post-quantum signatures we have available now that's likely to reduce > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B, > you're only getting an expected savings in fees / increase in block > capacity on that order of magnitude, ie: 1%-7%. That's nice to have, > for sure, but doesn't compare to introducing a new address type that > puts the PQ sigs in an extension block, or one that uses ZK proofs to > do cross-input or cross-transaction signature aggregation, eg. So a 32B > witness overhead for an unused/unusable key-path post-Q-day doesn't seem > very relevant to me. >=20 > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed > > perfectly. The expectation should be just that it happens before Q-day, > > and when it looks inevitable or the fear about that is large enough. >=20 > FWIW, I would define "timed perfectly" precisely as "EC disabling > fork happens before Q-day". Maybe allowing some additional months of > EC-efficiency would be a win while not taking out too much migration time= , > but for me "perfection" here means "no one who upgraded lost money via > quantum-related vulnerabilities". >=20 > One reason I'm doubtful is that I think for some the "it looks inevitable= " > threshold has already been crossed, eg: >=20 > > > So let me attempt to partially fill the silence, similarly to what > > > Scott Aaronson did in his April 29 post. Given everything I know, > > > including scary non-public information, I now put the odds of qday by > > > 2032 at 50%. 10% by 2030. >=20 > > > IMO a good target date for migration is 2029, roughly 3.5 years > > > out. 2029 happens to be the date selected by Google, Cloudflare, and > > > the Ethereum Foundation. >=20 > https://x.com/drakefjustin/status/2061793725299224676 >=20 > > > So, here it is: if quantum computers start breaking cryptography a > > > few years from now, don=E2=80=99t you dare come to this blog and tell= me that > > > I failed to warn you. This post is your warning. Please start switchi= ng > > > to quantum-resistant encryption, and urge your company or organizatio= n > > > or blockchain or standards body to do the same. >=20 > https://scottaaronson.blog/?p=3D9718 >=20 > Personally, that leaves me at a minimum very skeptical of the utility > of introducing either P2MR or P2TRv2 (etc) approaches that don't also > introduce a quantum-safe spending path on day one. >=20 > > First a meta-point here: the reason I like separating the discussion in= to different dimensions than just "P2TRv2 vs P2MR" is because there are mor= e options than those two, and not every argument applies to the same separa= tion into two classes. Let me list them explicitly here, roughly in decreas= ing order of how strongly I feel about them: > > - We need at least a "Later" option for meaningful migration, i.e. P2TR= v2 or P2MR+ED. > > - Within the "Later" option, P2TRv2 is preferable. > > - A "Later" option benefits from being the only PQC migration strategy,= making it a Schelling point. >=20 > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the > "Later-dominant" scenario, and only to the degree that it's slightly > cheaper prior to Q-day. If it were the only available option, that would > increase the risk of loss involved with both the other approaches. (I > don't think P2TRv2 is meaningfully more private than P2MR in the way > taproot v1 is, as presumably you'd only adopt that address format if > you wanted to have a post-quantum script path) >=20 > > > You'd have to convince everyone to deploy and then adopt P2TRv2 today= under the public knowledge that it is insecure and their coins are more li= kely to be stolen. That's a hard sell. > >=20 > > > How does one pitch P2TRv2 to users? "It will be quantum secure one da= y we promise because everyone is incentivized to fix it later as Bitcoin wi= ll die if we don't." > > >=20 > > > How do you pitch P2MR? "It's quantum secure if you use it correctly." > > > To me, the pitch is "Bitcoin can only remain valuable if we mostly/al= l migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or= any "Never" output type) fundamentally requires many users to change their= workflows entirely. >=20 > Let's call NoEC-day the earlier of activation of a soft-fork disabling > EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably > equal to "the day the bitcoin ecosystem has finally agreed that CRQCs > are inevitable". >=20 > My (cynical?) view is the only people who will adopt either P2TRv2 or > P2MR prior to NoEC-day being schedule will be people who are willign > to use those features in a quantum-safe way -- that is, keeping their > EC pubkeys secret, and only revealing those EC pubkeys to spend them > immediately, prior to NoEC-day. In that view, the EC-spend-paths of such > coins prior to NoEC-day are only an opportunistic "make spends cheaper" > shortcut, they don't allow the funds to be used in lightning channels > or to let your wallet be audited via sharing an xpub or anything similar. >=20 > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible > that lightning software could get an upgrade to generate post-quantum > signatures for channel commitments or HTLC claims, I just think it's > pretty unlikely that that will happen at a meaningful scale when everyone > has much more immediate and less theoretical things to work on prior to > NoEC-day, especially when the efficiency/performance of such changes is > likely to be very low. >=20 > > This focus on allowing individual users the ability to safeguard their > > coins just feels like a red herring: [...] >=20 > While I appreciate your point, I also feel that "allowing individual > users the ability to safeguard their coins" is pretty close to the entire > point of Bitcoin. :) >=20 > > In either case, I consider anything that requires hardcoding > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus > > rules (and only allowing those coins to survive) to be squarely in > > disaster-recovery land. It feels like embracing arbitrariness, and > > giving up on the permissionlessness that makes Bitcoin interesting - > > if the community shows it can get consensus on effectively burning > > coins except those that match a whitelist, it feels hard to maintain > > censorship-freeness as a value, even if the whitelist includes most of > > the (active) coins. That is of course not to say such techniques aren't > > interesting to work on, but to me, their place is in disaster recovery > > scenarios to save what's left, after Q-day, if migration attempts were > > unsuccessful. In such a setting, I think we're already in effectively a= n > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly > > growing) set of ways to recover burned coins can be hardforked in. >=20 > Just for the record, I think the above is an accurate description of the > "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant > of bitcoin would be fairly described as a utxo-bootstrapped altcoin, > would compete in the market with the "quantum-unsafe" bitcoin that > existing nodes would continue to follow, and possibly there would be > many slightly varying such altcoins competing with each other, eg on > exactly what height the utxo snapshot was taken or what coins become > spendable. It would not be a fun time for holders of affected utxos. >=20 > > My impression is that your approach is to have an answer for many > > possible futures, including ones where Q-day arrives within just a few > > years. >=20 > "The key of strategy... is not to choose a path to victory, but to choose > so that all paths lead to a victory." >=20 > -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit >=20 > > But optimizing for disaster-recovery also means reducing the > > chances of preserving Bitcoin as we know it in the scenarios where a > > successful migration is still possible. And if Q-day does arrive that > > soon, I don't see what we can do today that would preserve Bitcoin in > > a form we care about anyway. By accepting that, we can focus on the > > futures where our choices today can still materially improve the outcom= e. >=20 > Preserving bitcoin as a personally-possessible inflation resistant > store of value seems both possible and worth caring about, even if other > constraints means that many people can't afford to personally hold it > (and have to go through ETFs/exchanges/banks) and that it can't be used > for day-to-day transactions. Would be very disappointing if true, and > even given Q-day in a few years I expect we could do better than just > that, but it doesn't feel like a throw-in-the-towel event to me. >=20 > > > Essentially yes though, I expect the majority of holders will probabl= y > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a = fork > > > thereof. Even if we can't come to consensus and deploy a new output t= ype, > > > we'll still be able to rescue most coins. It's just that we'd have no= where > > > to rescue them to, so we ought to make PQ wallets available soon, so = we're > > > not in a rush to build them later when we need them. If a PQ wallet c= an > > > use cheap EC signatures while they're still trustworthy, all the bett= er >=20 > FWIW, that's my guess on how things would play out if the near-term Q-day > timelines I've seen (ie, 2029 to 2035) match reality. I hope that's > pessimistic (either because the Q-day timelines are bad estimates, or > because migration happens in a more orderly fashion), but I guess we'll > see. I don't rate my ability to evaluate Q-day predictions very highly. >=20 > > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say. >=20 > I'm not in a position to judge, but the google paper claims: >=20 > "Indeed, if a leading quantum architecture encounters and overcomes > all its scaling challenges before producing a device able to > solve (for example) 32-bit ECDLP, then there may be little time > between the breaking of 32-bit ECDLP and the breaking of 256-bit > ECDLP. Furthermore, the community should not expect to see published > demonstrations of the most advanced quantum error-correction > architectures and quantum algorithms deployed to cryptanalytic > problems. Thus, a successful public demonstration of Shor=E2=80=99s > algorithm on a 32-bit elliptic curve should not be seen as a wake-up > call to adopt PQC as much as a potential signal that PQC adoption > has already failed." >=20 > and places the required tiffoli gates and logical qubits for a 32-bit > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100) > for 256-bit. >=20 > > Of course, if you believe it's the only possible future, I understand > > you'd come to a different conclusion. But is it really? Do you think > > this isn't a plausible future: >=20 > > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too)= gets introduced in the next few years, with hash-based PQC opcodes. > > - Over the course of the next decade or so, it gets adopted by practica= lly all active users. >=20 > I think it might be better to look at that scenario in a more fine-graine= d > way? I think your "Late-ish" scenario is: >=20 > 1) P2TRv2 (or whatever) is introduced > 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-path= s > via those outputs > 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TR= v2, > but EC spend paths continue to be what's used in practice. > 4) Some better PQ solutions become available, allowing cheap PQ-safe spen= d-paths > 5) Everyone switches from EC paths to the new PQ paths. > 6) NoEC-day happens, but no one is impacted. >=20 > I think your "Soon-ish" scenario differs as of step (4): >=20 > 4) NoEC-day happens. Massive disruption because the "what's used in pract= ice" > path breaks, but everything is recoverable. > 5) Post-quantum approaches get even higher priority >=20 > I'm skeptical of step 3 here; and would expect to see something more like= : >=20 > 3') Only a small proportion of users (ie, the most conscientious/fearful) > switch to P2TRv2 with most preferring to stick with what works >=20 > That has no real impact on the Late-ish scenario, but changes the Soon-is= h > scenario to either: >=20 > 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate > to P2TRv2, but it mostly works. >=20 > or >=20 > 4'b) NoEC-day happens essentially at the same time as Q-day; coins get > stolen and we hit the disaster-recovery scenario. >=20 > Perhaps the difference between (3') and (3) playing out in reality > is just having nearly everyone agree that the upgrade is essential, > and rather than leaving it to self-interest/market-dynamics, having a > consistent push that every single wallet/service that doesn't deprecate > every current address type is a danger to the entire ecosystem, even > absent widespread agreement on when/if Q-day will happen. Arguably that > would be easier to agree on if the incremental cost of EC spend paths > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to > zero, rather than up to ~14% per input. >=20 > Cheers, > aj >=20 > -- > You received this message because you are subscribed to a topic in the Go= ogle Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/b= itcoindev/p8AVEmAtWdA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/ajN9be00Br-O3-9R%40erisian.com.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/= jG9NFDBJtTNnd3Fl9DxXjINqOHifXM3xqxnpLHcrcKrxCHY999yf8uHB3-zBdRjhyu65nuWSUnM= l0BvmdAmxvDvx2qOyyoZ5desBEdVWGpY%3D%40proton.me. -----------------------ab02db44edb9bf06b304dab94202ff82 Content-Type: multipart/related;boundary=---------------------623f6390563e65d458e45a2fec1f3af2 -----------------------623f6390563e65d458e45a2fec1f3af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I really= appreciate you all taking the time to have this important discussion toget= her and still keeping things civil. The discussion on this thread has branc= hed out from PQ migration destinations into also discussing confiscatory re= troactive upgrades, like rescue protocols. I think, as per Antoine's recent thread, it's a mistake to conflate the = two subjects, so this first email is just going to focus on designing secur= e PQ output types, and I'll include responses to the retroactive stuff in a= separate message.

----------

I feel like we've all been pulled= deep into the weeds of forecasting different quantum doom scenarios here. = I'm gonna try to pick out the key disagreement we are dancing around, and e= xamine it more closely.

Sipa's comment here:

I can't imagine we don't get at least a year's worth of notice in the fo= rm of breakthroughs on simpler QC problems.

...is emblematic of an assumption baked into the security of P2TRv2: Tha= t we can predict Q-day. Unfortunately, no one - not even quantu= m computing experts, let alone the Bitcoin community - can reliably predict= when Q-day will happen, if it even happens at all. I think this is = the core problem we need to dissect.

On one hand, if we assume we'll = be able to predict Q-day in advance, then we can get away with a lot: Use m= aximally efficient EC key-spending (P2TRv2) till the last moment, then disa= ble EC. Deploy P2MR with only PQ sigs, and everyone can slowly migrate to u= se PQ sigs on P2MR. That'd be the ideal world.

But we may or may not live in that world. We have no certainty that such la= rge technological leaps will happen slowly and behave predictably. C= ould the world in 1944 (outside Los Alamos) have confidently predicted the = first use of an atomic bomb in 1945? Could the world 
Ultimately we just don't know one way or the other. AJ put it very well her= e:

Pic= king when Q-day will occur, either individually for determining your own security posture, or collectively for organising a consensus chan= ge seems very difficulty: it involves evaluating both complex state of the = art physics research, but also estimating the covert abilities of national = governments and the incentives to attack bitcoin prior to revealing their c= apabilities. To me, that doesn't bode well for a smooth and fast= deployment of a consensus change in advance of problems occuring.

With that in mind, i will now attempt an arg= ument for P2MR based on the premise that Q-day is unpredictable (at least f= or now).

I follow sipa's more general belief that a follow-up EC disable soft-fork f= or the new output type is desirable, to reduce harm after Q-Day from EC pub= key exposure. We all seem to agree there.

However, I strongly doubt that we (the entire bitcoin community) will be ab= le to time such a fork correctly. By "correctly", I mean: within a f= ew days before, but no later than Q-day (the first day a CRQC would be able= to start stealing coins).

Why am I so strict about the timing? Consider if we accepted AJ's definitio= n of perfect timing, 

FWIW, I would define "timed pe= rfectly" precisely as "EC disabling fork happens before Q-day". Maybe allow= ing some additional months of EC-efficiency would be a win while not taking= out too much migration time, but for me "perfection" here means "no one wh= o upgraded lost money via quantum-related vulnerabilities".

...with which sipa seems to agree:

FWIW, I don't think the P2TRv2 EC-disablin= g fork needs to be timed perfectly. The expectation should be just that it = happens before Q-day, and when it looks inevitable or the fear about that i= s large enough

I disagree. If we disable EC= months in advance of Q-day, and if we do so only for the new outpu= t type, then it will likely backfire. During those months, a subset of = coins will regress back to using classical wallets - P2TR, P2WPKH, etc - fo= r many reasons. Maybe they think CRQCs are not a real threat yet. Maybe the= y think they can predict Q-day better than we did, and don't want to pay th= e extra sats for larger PQ signatures until then. Maybe they need EC for a = specific protocol and haven't finished migrating their code to PQ yet. Who = knows. But the longer the duration between EC disabling and the first verif= iable proof of CRQCs (likely to arrive on or after Q-day), the more opportu= nity and incentive there will be for users to regress back to a place of vu= lnerability.

Thus if we entirely rely on EC disabling for the security of the new out= put type, as in P2TRv2, we should time such a deployment perfectly: Any= later and all users are vulnerable. Too much earlier, and users are incent= ivized to regress.

Also recall that "we disable" really means "the entire community = agrees to disable". If dictatorial power were vested in the hands of a = well-informed autist with a Dark-Forest-style Big Red Button, then maybe= they'd have a chance to react to Q-day. But an entire decentralized ne= twork, fraught with misinformation and polarized politics? Not likely, unle= ss we can build and deploy a trustless, unattended canary in advance of Q-= day, which somehow doesn't require a cooperative CRQC. That seems implausib= le today but I would welcome any evidence to the contrary.

And so, since timing is hard, I assert that we should prefer P2= MR over P2TRv2 because we are confident P2MR is sound even if the EC d= isable fork is deployed late (after Q-day).

With P2MR, we at leas= t have some wiggle-room in our timing of the EC disabling soft-fork. Maybe = not a lot - depends on how much users expose their EC leaves - but perhaps = enough to give us time to react while the CRQC gets busy cracking exposed k= eys.

As to the question of P2MR's "friction" that sipa claims discourages migrat= ion, I think this is a low-impact point in the debate and I have no rebutta= l, except that a temporary tax of 32 weight units per input seems a small p= rice for insurance against theft/devaluation of one's entire stack. I suspe= ct P2MR's current popularity - even before Boris' EC recovery idea - is dri= ven by that sentiment. If anything I'd argue that P2TRv2's timing-sensitivi= ty would have an even sharper chilling effect and would curb migration prog= ress much more than P2MR's 32 extra weight units would.

Maybe I am wrong, and 32 WU/input is a significant factor impacting = user behavior before Q-day. If so, this amplifies my earlier point that dep= loying EC disabling too early will incentivize regression to classical addr= esses, and we would need to be even more careful in our timing: The pre-Q-d= ay efficiency gap between EC and PQ sigs is much wider than the gap between= P2MR and P2TRv2.

With my main argument made, I'd like to respond to individual points an= d questions:


I have reservations too about the "Later" EC-disabling soft fork expecta= tions about P2TRv2, but they're not about whether the future Bitcoin ecosys= tem can coordinate a softfork; that seems almost trivial if not doing so po= ses an existential threat, and could be done within a few months if it's ex= pected and designed already. I'm more worried about it not being adopted du= e to indifference/friction, or being abused/misused.

Interesting, what gives you confidence that we'll be able to coordinate = and time it correctly? Assuming everyone agrees and wants to, how would we = go about it?


= Bitcoin can only meaningfully survive a systemic risk of this nature = through collective action

Agreed! I think w= e just disagree about which collective actions are most important, and we h= ave differing confidence in the feasibility of those actions and their timi= ng.

This focus on allowing individual users the abil= ity to safeguard their coins just feels like a red herring: I'm not worried= about my own coins being stolen. I'm worried about (fear of) a CRQC underm= ining trust in the currency as a whole, or through a fear-driven consensus = change the ecosystem destroying its own values beforehand.

I second AJ:

While I appreciate your point, I also feel that "allowing individual use= rs the ability to safeguard their coins" is pretty close to the entire poin= t of Bitcoin. :)

Sovereign control of value is the core promise of Bitcoin. <= /span>

However, sipa's argument is also very valid. We need to do everything we ca= n to preserve overall integrity of the entire UTXO set, as much as i= s humanly possible. This preserves trust in the currency as a whole.

We can have both, by deploying P2MR with PQ sigs to secure those who can mi= grate in time, and then an EC disabling follow-up, maybe with rescue protoc= ols to secure procrastinators. This protects as many UTXOs as I think are p= ossible with current knowledge, and is not as sensitive to timing as if we = used P2TRv2.


I understand the feeling of urgency, but this seems like = a "we must do something, this is something, thus we must do it!" appro= ach that just gives people the impression something is being done, without = fundamentally tackling the hard problem of actually migrating Bitcoin, and = leaving that harder problem to a (to me) very undesirable, but still unspec= ified future. And solving that harder problem will inevitably need another = consensus change later, so it doesn't help with the "running out of years" = problem if you believe those take too long.
I also dislike that class of argument. People use it all the time here to = justify half-baked "solutions" to quantum problems. But that's not what I w= as saying in my point.

The act of migration itself is indeed a very c= omplex task, vastly different from designing the migration paths. We can't = start working on the latter until we have the former. So no, working on a m= igration path is really important and does help with "running out of= years", because if we did nothing we'd have nowhere to migrate coins to, o= r we'd have to rush something out in a hurry when it is urgently needed.


Of course, if you believe it's the only possible f= uture, I understand you'd come to a different conclusion. But is it really?= Do you think this isn't a plausible future:
...
There are many other p= ossible futures. Some are minor variations of these two scenarios. Some are= fairly bad independently of the choice between P2MR or P2TRv2 (e.g. Q-day = comes before any substantial migration). Some are mostly fine regardless (e= .g. everyone has time to migrate to later P2QR isogeny stuff, or just no CR= QC ever). But these two in particular, I think have a much better chance of= happening with P2TRv2 than P2MR, because far more people can just adopt it= with low friction.
The future you describe is absolutely pl= ausible, and I would much prefer it, but the steps where the new output typ= e "gets adopted by practically all active users" and where "the community quickly soft forks to disable EC paths/opcodes" are both do= ing doing a lot of work there. Both are possible, but uncertain= , and so we ought to prepare for the alternatives too, right?
<= div style=3D"margin-top: 14px; margin-bottom: 14px;">
-   Isogen= ies (or something else) get a ton more attention, implementations get more = efficient, gain well-studied features like tweaking and homomorphic derivat= ion, get far better confidence in their security.

I hope you'll be as excited I as I am to learn that isogenies= already have tweaking/derivation! See my own post here and <= a href=3D"https://eprint.iacr.org/2026/1169" title=3D"this paper" target=3D= "_blank" rel=3D"noreferrer nofollow noopener">this paper released just 10 d= ays ago which proves the idea secure.


-   A (not-quite-CR)= -QC breaks 128-bit ECDLP, say.
It is a common misconception that we= can use toy curves as canaries. Unfortunately we can't trust succinct proo= fs on small curves because they could be classically forgeable. Pollard-Rho= can break ECDLP for points of order n=E2=80=8B with only sqrt(n)=E2=80=8B work today. For example, in 2016 these researchers broke a 117-bit binary-field= curve using FPGAs, and this paper's authors broke a 112-bit prime-field c= urve using a cluster of 200 playstations! 
So how big does a canary curve need to = be, to be out of reach of Pollard-Rho but within reach of a fledgling CRQC?=
Bitcoin miners = are today cumulatively doing about 2^95 work per year measured = in SHA256 hashes (source). Pollard-rho work is mea= sured in point additions, which is slower than SHA256, but only by a consta= nt factor.
Thus = for a canary to be reasonably safe against large-scale classical attacks tr= iggering a false-positive, we'd need a much larger curve, probably 192 bits= or more, for a canary. That's uncomfortably close to the danger zone, espe= cially given the warnings AJ cited, and worse, it would be a moving goalpos= t as classical parallelized-computing scales up.

=
Personall= y, that leaves me at a minimum very skeptical of the utility of introducing either P2MR or P2TRv2 (etc) approaches that don't also&= nbsp;introduce a quantum-safe spending path on day one.<= br>
Likewise. We don't want people migrating to PQ output types without= a PQ spending path. So we wouldn't want to deploy P2MR without a PQ signat= ure scheme to back it up. I hope we'll deploy both upgrades simultaneously = in a single soft-fork package. Maybe some time after deployment, we can cha= nge mempool relay policy to consider payments to legacy addresses as non-st= andard, and so further encourage migration without heavy-handed consensus c= hanges like those proposed by BIP361.

Preserving bitcoin as a personally-possessible infla= tion resistant store of value seems both possible and worth car= ing about, even if other constraints means that many people can't afford to= personally hold it (and have to go through ETFs/exchanges/banks) and that = it can't be used for day-to= -day transactions. Would be very disappointing if true, and even given Q-day in a few years I e= xpect we could do better than just that, but it doesn't feel like a throw-i= n-the-towel event to me.
A big +1 from me on this. 
Also remember that even if Bit= coin becomes awkward to use for a few years, we can one day install better = cryptography to bring lost features back, improve scaling with discounts or= more-efficient signatures, etc. But once UTXOs are lost or stolen, we can = never recover them without a contentious ETH-classic-esque hard-fork.
=

regards,
conduition<= /p>



On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns aj@erisian.com.au wrote:

On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:

I want to first correct a potential misunderstanding here, because
I realize the terms "Later" and "Never" aren't very descriptive. They
are specifically about an expected and relied-upon expectation that an
EC-disabling fork will happen that at least applies to the output type
itself, in time. "Later" is the expectation that such a disabling will
happen after the output type is introduced, but still in time (so, before Q-day). Outputs without a strong expectation that their EC paths/opcodes will be disabled, or not in time, I classify under "Never".

I believe here you're instead arguing for P2MR ("Merkle-Never")
over all "Later" options. That was my previous point: I think (solely)
having "Never" output types like P2MR is just utterly insufficient for
any worthwhile migration. It's so incompatible with today's workflows
that it either won't be adopted, or (possibly inadvertently) adopted
in an insecure fashion. Yes, it gives people the option to safeguard
their own coins, but to me that's disaster recovery territory - I think
we ought to prioritize maximizing the chances for saving the currency
as a whole in case Q-day comes, not a small subset of individual users'
coins. P2MR (alone) doesn't really achieve much in that regard in my view,<= br> thus we at least need something of the "Later" class in addition.

I'm not sure I follow/agree with the logic here. I think the general ide= a
is:

1) we create some new address types that allow post-quantum spending, bu= t
also allow efficient quantum-vulnerable spending that can be used prior
to Q-day

2) many people migrate to these new address types

3) Q-day arrives

4) all spending goes via the post-quantum paths, and everyone's funds ar= e
safe

There are three main variations to this, I think:

Later-dominant: towards the end of (2) but prior to (3), the
quantum-vulnerable spend paths are disabled in a predictable, planned
manner, preventing coin theft, but not disrupting active usage
significantly (or not disrupting it any more than the proximity of
Q-day already is).

Self-reliance: Q-day goes from maybe to definitely faster than consensus=
changes can be coordinated, and the only reason people's funds remain
safe is that they can (and do) keep the quantum-vulnerable spend
paths secret.

Disaster-recovery: neither the "predictable/planned consensus change" of=
Later nor the "everyone takes responsiblity for their own funds"
works, and the only way to avoid a large percentage of bitcoin
becoming a reward for quantum research is to replace EC spend paths
with a ZK proof of knowledge of a BIP32 seed or similar, requiring
a hard fork. Such a hard fork would be certain to be controversial
("why at this height: I received a payment five blocks after //
my funds were stolen by a quantum attacker five blocks earlier //
why are only BIP32 funds recoverable not scheme X"), but if no other
approach works, might still be the ultimately outcome.

So the point here was just: if you already accept the need for a "Later"=
output type (=3D one with builtin-in EC disabling expected from the start),=
P2TRv2 is preferable over P2MR+ED, because:

As far as I can see, only having P2TRv2 addresses would rule out the
"self-reliance" path here.

Picking when Q-day will occur, either individually for determining
your own security posture, or collectively for organising a consensus
change seems very difficulty: it involves evaluating both complex state
of the art physics research, but also estimating the covert abilities
of national governments and the incentives to attack bitcoin prior to
revealing their capabilities. To me, that doesn't bode well for a smooth and fast deployment of a consensus change in advance of problems occuring.<= /p>

It's possible that general carelessness on behalf of users would also rule out the effectiveness of a self-reliance approach: if only the most conscientious 1% of users make use of P2MR securely, that might secure 10%<= br> of funds, but having 90% of the bitcoin supply crash probably wouldn't be very valuable either. But even then, that may make the "disaster-recovery"<= br> approach less problematic, by ensuring the 1%/10% who were conscientious can avoid being part of the "my funds were stolen by a quantum attacker" contingent, eg.

Theorycrafting for a second here. It's reasonable to conjecture fee
rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
over P2TRv2 will yield significant savings for end-users in absolute
terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes significant (100 sats per spend or more).

I don't think that is the right way to look at. 8vb/input is about
an additional 14% today (vs a taproot key-path spend), but with the
post-quantum signatures we have available now that's likely to reduce
to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
you're only getting an expected savings in fees / increase in block
capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
for sure, but doesn't compare to introducing a new address type that
puts the PQ sigs in an extension block, or one that uses ZK proofs to
do cross-input or cross-transaction signature aggregation, eg. So a 32B
witness overhead for an unused/unusable key-path post-Q-day doesn't seem very relevant to me.

FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
perfectly. The expectation should be just that it happens before Q-day,
and when it looks inevitable or the fear about that is large enough.

FWIW, I would define "timed perfectly" precisely as "EC disabling
fork happens before Q-day". Maybe allowing some additional months of
EC-efficiency would be a win while not taking out too much migration time,<= br> but for me "perfection" here means "no one who upgraded lost money via
quantum-related vulnerabilities".

One reason I'm doubtful is that I think for some the "it looks inevitabl= e"
threshold has already been crossed, eg:

So let me attempt to partially fill the silence, similarly to what
Scott Aaronson did in his April 29 post. Given everything I know,
including scary non-public information, I now put the odds of qday by
2032 at 50%. 10% by 2030.

IMO a good target date for migration is 2029, roughly 3.5 years
out. 2029 happens to be the date selected by Google, Cloudflare, and
the Ethereum Foundation.

https://x.com/drakefjustin/status/2061793725299224676

So, here it is: if quantum computers start breaking cryptography a
few years from now, don=E2=80=99t you dare come to this blog and tell me th= at
I failed to warn you. This post is your warning. Please start switching
to quantum-resistant encryption, and urge your company or organization
or blockchain or standards body to do the same.

https:/= /scottaaronson.blog/?p=3D9718

Personally, that leaves me at a minimum very skeptical of the utility of introducing either P2MR or P2TRv2 (etc) approaches that don't also
introduce a quantum-safe spending path on day one.

First a meta-point here: the reason I like separating the discussion int= o different dimensions than just "P2TRv2 vs P2MR" is because there are more= options than those two, and not every argument applies to the same separat= ion into two classes. Let me list them explicitly here, roughly in decreasi= ng order of how strongly I feel about them:
- We need at least a "Later" option for meaningful migration, i.e. P2TRv2 o= r P2MR+ED.
- Within the "Later" option, P2TRv2 is preferable.
- A "Later" option benefits from being the only PQC migration strategy, mak= ing it a Schelling point.

Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the=
"Later-dominant" scenario, and only to the degree that it's slightly
cheaper prior to Q-day. If it were the only available option, that would increase the risk of loss involved with both the other approaches. (I
don't think P2TRv2 is meaningfully more private than P2MR in the way
taproot v1 is, as presumably you'd only adopt that address format if
you wanted to have a post-quantum script path)

You'd have to convince everyone to deploy and then adopt P2TRv2 today un= der the public knowledge that it is insecure and their coins are more likel= y to be stolen. That's a hard sell.

How does one pitch P2TRv2 to users? "It will be quantum secure one day w= e promise because everyone is incentivized to fix it later as Bitcoin will = die if we don't."

How do you pitch P2MR? "It's quantum secure if you use it correctly." To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migr= ate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "= Never" output type) fundamentally requires many users to change their workf= lows entirely.

Let's call NoEC-day the earlier of activation of a soft-fork disabling EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
are inevitable".

My (cynical?) view is the only people who will adopt either P2TRv2 or P2MR prior to NoEC-day being schedule will be people who are willign
to use those features in a quantum-safe way -- that is, keeping their
EC pubkeys secret, and only revealing those EC pubkeys to spend them
immediately, prior to NoEC-day. In that view, the EC-spend-paths of such coins prior to NoEC-day are only an opportunistic "make spends cheaper"
shortcut, they don't allow the funds to be used in lightning channels
or to let your wallet be audited via sharing an xpub or anything similar.

Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible<= br> that lightning software could get an upgrade to generate post-quantum
signatures for channel commitments or HTLC claims, I just think it's
pretty unlikely that that will happen at a meaningful scale when everyone has much more immediate and less theoretical things to work on prior to
NoEC-day, especially when the efficiency/performance of such changes is
likely to be very low.

This focus on allowing individual users the ability to safeguard their coins just feels like a red herring: [...]

While I appreciate your point, I also feel that "allowing individual
users the ability to safeguard their coins" is pretty close to the entire point of Bitcoin. :)

In either case, I consider anything that requires hardcoding
specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
rules (and only allowing those coins to survive) to be squarely in
disaster-recovery land. It feels like embracing arbitrariness, and
giving up on the permissionlessness that makes Bitcoin interesting -
if the community shows it can get consensus on effectively burning
coins except those that match a whitelist, it feels hard to maintain
censorship-freeness as a value, even if the whitelist includes most of
the (active) coins. That is of course not to say such techniques aren't
interesting to work on, but to me, their place is in disaster recovery
scenarios to save what's left, after Q-day, if migration attempts were
unsuccessful. In such a setting, I think we're already in effectively an altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
growing) set of ways to recover burned coins can be hardforked in.

Just for the record, I think the above is an accurate description of the=
"disaster-recovery" scenario above: the "quantum-safe" hard-fork variant of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
would compete in the market with the "quantum-unsafe" bitcoin that
existing nodes would continue to follow, and possibly there would be
many slightly varying such altcoins competing with each other, eg on
exactly what height the utxo snapshot was taken or what coins become
spendable. It would not be a fun time for holders of affected utxos.

My impression is that your approach is to have an answer for many
possible futures, including ones where Q-day arrives within just a few
years.

"The key of strategy... is not to choose a path to victory, but to choos= e
so that all paths lead to a victory."

-- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit

But optimizing for disaster-recovery also means reducing the
chances of preserving Bitcoin as we know it in the scenarios where a
successful migration is still possible. And if Q-day does arrive that
soon, I don't see what we can do today that would preserve Bitcoin in
a form we care about anyway. By accepting that, we can focus on the
futures where our choices today can still materially improve the outcome.

Preserving bitcoin as a personally-possessible inflation resistant
store of value seems both possible and worth caring about, even if other constraints means that many people can't afford to personally hold it
(and have to go through ETFs/exchanges/banks) and that it can't be used
for day-to-day transactions. Would be very disappointing if true, and
even given Q-day in a few years I expect we could do better than just
that, but it doesn't feel like a throw-in-the-towel event to me.

Essentially yes though, I expect the majority of holders will probably migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork thereof. Even if we can't come to consensus and deploy a new output type, we'll still be able to rescue most coins. It's just that we'd have nowhere<= br> to rescue them to, so we ought to make PQ wallets available soon, so we're<= br> not in a rush to build them later when we need them. If a PQ wallet can
use cheap EC signatures while they're still trustworthy, all the better

FWIW, that's my guess on how things would play out if the near-term Q-da= y
timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
pessimistic (either because the Q-day timelines are bad estimates, or
because migration happens in a more orderly fashion), but I guess we'll
see. I don't rate my ability to evaluate Q-day predictions very highly.

- A (not-quite-CR)-QC breaks 128-bit ECDLP, say.

I'm not in a position to judge, but the google paper claims:

"Indeed, if a leading quantum architecture encounters and overcomes
all its scaling challenges before producing a device able to
solve (for example) 32-bit ECDLP, then there may be little time
between the breaking of 32-bit ECDLP and the breaking of 256-bit
ECDLP. Furthermore, the community should not expect to see published
demonstrations of the most advanced quantum error-correction
architectures and quantum algorithms deployed to cryptanalytic
problems. Thus, a successful public demonstration of Shor=E2=80=99s
algorithm on a 32-bit elliptic curve should not be seen as a wake-up
call to adopt PQC as much as a potential signal that PQC adoption
has already failed."

and places the required tiffoli gates and logical qubits for a 32-bit break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
for 256-bit.

Of course, if you believe it's the only possible future, I understand you'd come to a different conclusion. But is it really? Do you think
this isn't a plausible future:

- A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) = gets introduced in the next few years, with hash-based PQC opcodes.
- Over the course of the next decade or so, it gets adopted by practically = all active users.

I think it might be better to look at that scenario in a more fine-grain= ed
way? I think your "Late-ish" scenario is:

1) P2TRv2 (or whatever) is introduced
2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths<= br> via those outputs
3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2= ,
but EC spend paths continue to be what's used in practice.
4) Some better PQ solutions become available, allowing cheap PQ-safe spend-= paths
5) Everyone switches from EC paths to the new PQ paths.
6) NoEC-day happens, but no one is impacted.

I think your "Soon-ish" scenario differs as of step (4):

4) NoEC-day happens. Massive disruption because the "what's used in prac= tice"
path breaks, but everything is recoverable.
5) Post-quantum approaches get even higher priority

I'm skeptical of step 3 here; and would expect to see something more lik= e:

3') Only a small proportion of users (ie, the most conscientious/fearful= )
switch to P2TRv2 with most preferring to stick with what works

That has no real impact on the Late-ish scenario, but changes the Soon-i= sh
scenario to either:

4'a) NoEC-day happens substantially before Q-day; people hurry to migrat= e
to P2TRv2, but it mostly works.

or

4'b) NoEC-day happens essentially at the same time as Q-day; coins get stolen and we hit the disaster-recovery scenario.

Perhaps the difference between (3') and (3) playing out in reality
is just having nearly everyone agree that the upgrade is essential,
and rather than leaving it to self-interest/market-dynamics, having a
consistent push that every single wallet/service that doesn't deprecate
every current address type is a danger to the entire ecosystem, even
absent widespread agreement on when/if Q-day will happen. Arguably that
would be easier to agree on if the incremental cost of EC spend paths
in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
zero, rather than up to ~14% per input.

Cheers,
aj

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.go= ogle.com/d/topic/bitcoindev/p8AVEmAtWdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@goog= legroups.com.
To view this discussion visit https://groups.= google.com/d/msgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.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/jG9NFD= BJtTNnd3Fl9DxXjINqOHifXM3xqxnpLHcrcKrxCHY999yf8uHB3-zBdRjhyu65nuWSUnMl0Bvmd= AmxvDvx2qOyyoZ5desBEdVWGpY%3D%40proton.me.
-----------------------623f6390563e65d458e45a2fec1f3af2-- -----------------------ab02db44edb9bf06b304dab94202ff82-- -----------------------7b31cde623ce4c9c50d8b7331f4e7de2 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------7b31cde623ce4c9c50d8b7331f4e7de2-- --------222e786de1d1c59c3cf2c26b40005f2bcfeeb42fb9f023a5721355024daf5660 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmo0jacJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmejAIUMFYLfBHCxnbFcKa3NOY75fqxjaQEV+pJT UGn0xRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAnEwD/aTXwkInTkI1pBxqP HCDjEyZL7fZk8J77Iac0lCLSpiYA/33EiQzbF36kCwsrQoO26gimfn77mEot zzAH6wdcAsEN =Lv3L -----END PGP SIGNATURE----- --------222e786de1d1c59c3cf2c26b40005f2bcfeeb42fb9f023a5721355024daf5660--