From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 20 Apr 2026 11:05:42 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wEt09-0007g5-J1 for bitcoindev@gnusha.org; Mon, 20 Apr 2026 11:05:42 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-4236c3b8f32sf6454337fac.0 for ; Mon, 20 Apr 2026 11:05:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776708335; cv=pass; d=google.com; s=arc-20240605; b=WY/yRn32IK6gapoZZXbgQRrVCEh2cPMdrhDfRbkd7s4FMwTYqO3cR1LWgmzvAdq3t4 5rbTtWYbfDHafPQGYEV1i6V0qBw5Cj6FTdAKLeIObY+ck2/YZvkZ0r8LMuIj/EY9OFga NNeONBXhiX3xLgoDtkhGZwsq9tABG2+XBSXHV9XizXpDLESMLRpyveN7+f1TrkeiwM+C wyLUDLqHCq+hDHJXKWgnNpK6e2N7jz9fV7FiOqr22V3jUUvLh/AxXaFYuca4lUZntdzi Nlyq7gbQ6LWmH/AaXUXaqafMT5ehjjPyXgDplVLvjqwAxiPK3k6n+5bmCS5hSH4pmE8y Ku+Q== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=6pGsTEo8A0V/7PhUOMk88Sl7gy1eYnOKFAO5MWeK26I=; fh=v86TsAO34sHyUA6ddjnt06jjAejDu8CYPhYv9E341L4=; b=CGXtrqH+edH8pFDPvSA2NjB9JWtGvu+8P1KgpXUlS77GyqxyGaG/QVO5/mGlgslxRS hQpDPCfUnnLmC0BRVPiFoDQBDSEXHYg0X+aOqV9RFjTaApvQllk3NaSAWKkZds5dakb5 QHtNnw0xTuCgTIzY5jUmU6uMTDScmE43/uxvl25qSyu1VFm1DYr1iO9++GARrFAyBixD WC6pCBt/m0q8dMTdyIHBLcdGUHMm3N9B9uxZZFFDBkQzeOhCdJ6tBrjBx+jaNsTrYH8Y BT5zxLSRV4ssTaWIdPLt3wl30gms3CYlw+UKFr4Uj9v82Dm3NrUDNCPKlp0/ZrDc4rYr 8znA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=tJBikaiS; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776708335; x=1777313135; 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 :content-transfer-encoding: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=6pGsTEo8A0V/7PhUOMk88Sl7gy1eYnOKFAO5MWeK26I=; b=xlnvJfvrbUY/Ao+/riOyr5KN1gz/KMC++2XUEc0N1ZWhub6kANP09qsBlLYJN681L4 rJTa8Dp5KFVIN0S8sHBzXpQ9YYLlGI8D8BTQ6F8V9Id8tYE1NixfoefoL7B4AQG/7nft VL6Dv+ZUFKe7rsii8rxuiBSuz9n6Zh1T7ORV9n/iMm9YsR8qYgBNc/UQSg9B19Dq8nkb XFlhLiHWw3se1nfGteaLooahtlWOSDkZyNfHicnNBNXT/vEMyOkFeWivPsxYOpCX6SOx qURVcN5CJWxK5fxEb1wFlaEIz7MiUEqyoBYhjDf1RifZ955aCeZkOFPQXuKo7u70eJgZ arew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776708335; x=1777313135; 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 :content-transfer-encoding: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=6pGsTEo8A0V/7PhUOMk88Sl7gy1eYnOKFAO5MWeK26I=; b=dUErICJmh7B5bGDT6uIwjPtJGm1meploXL+ifTP5r9HxGYu5b9evdr7U4UX0SWXH9Z Dd7CJmql+c6pym6eav3GAqlNJE9dOtxSkrkn3gObwvLzOGNx/j+reT/hbq+e/+29JucZ JBh5nZbKCqiQj7m9XUV7/E4SU8fxFFMspPMj09QJAe3aJZ7TDSAKZRurezpd4rqM6Wub sCli+NXmRh7liP7ScaLahU/vSSQy0IQ3xIVBw1dtSiCf6K9vvBFrHib2h0RFsSTbRvbQ h1/4cxeR+SKiXhscZWPmftZVoDxN90tcaod2yEtJT/FHO+QatlVJK9s/6G+uwHV6QA+j nKow== X-Forwarded-Encrypted: i=2; AFNElJ8V05V/+I081qDLZ0kdDtq7W8W5PsbTMvL0CdYrEq1zSSUicT5kBmbDFK5BmkynOPzrDn+HU/V6746n@gnusha.org X-Gm-Message-State: AOJu0Yz4E+rseH6ozBkBwVd6g8yjkfyBm78xt6KMe1+6eB7kBnpbenmT X9llAJ+nAMtxGIGCWqmhhopNPJKbnAOWa5KZFTcH4laUNT/FsvUVsRTD X-Received: by 2002:a05:6870:9e8d:b0:417:43c8:a58e with SMTP id 586e51a60fabf-42a997dc6d3mr7939964fac.3.1776708335327; Mon, 20 Apr 2026 11:05:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKI9SkrfbGYevWz0gtk92x1+EM0XgmftQKh6AIZcurmfw==" Received: by 2002:a05:6870:e0c8:b0:42b:d57d:6b3b with SMTP id 586e51a60fabf-42bd57d7236ls422002fac.2.-pod-prod-00-us-canary; Mon, 20 Apr 2026 11:05:29 -0700 (PDT) X-Received: by 2002:a05:6808:3a06:b0:45f:103c:2483 with SMTP id 5614622812f47-4799c05e9d1mr7007289b6e.23.1776708329751; Mon, 20 Apr 2026 11:05:29 -0700 (PDT) Received: by 2002:a05:690c:3687:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7baf5aa5779ms7b3; Mon, 20 Apr 2026 11:04:37 -0700 (PDT) X-Received: by 2002:a05:690c:39b:b0:7ba:f2f1:86ef with SMTP id 00721157ae682-7baf2f18f73mr25249977b3.35.1776708276532; Mon, 20 Apr 2026 11:04:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776708276; cv=none; d=google.com; s=arc-20240605; b=jQ4syQwkyg0eR50/SBzAs8hOuKs53lY5s0t7JHf6VQtID5wbehka4d24HpGpx7PLgK s+IriWEY9yQLpcbkhSQjETwA4cjlIz5kz7ZyChzshCv1kXFaXovqV75ycGEGIN1dfK4G FhZLJbd4iIeJjZWjF67edBxbNRoqiFc2q4Tr3GT9mXoxvywr7C4lePOmoCRrCFV8Yrmz ACTWRk4EZ1vz33hgmbp/M5wjNVaSdZFN3Gp++gScRcZwTwN+GWPEE1ehQ3Xvz3Iqnvmd Thzvl/5Gp5Y4a5Sxq+4oiQoZ+tBxFdYZHljB84PAlJaJsHepFX8Ue8vmYQLHK/0sNaKO yWCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=YyLHWb3CR+8aco/Op4KfqdJjSbSUNxKHN505hw5dBJU=; fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=; b=C1d7TzfSGHW7o706Sr9gFQ/rtb9MqsAy2G1m7JHZ6lqD/eTv+wG4xbhwEpO8R79sIj SrIVUvip2aB+2MKjK7XRk0D35s9I1sSG5ptXtmqa0OdvamBhvEYpoPbraDInjzytI1Bk M+8Ld1bbamuTZkBJ23jR0jmyVexvzLA9TKmGrCNSeTGdTSlE9qIT2dw5U7L67ORuMzrm ioMHtCVjTD0p+wTCl96usrlB7By/n+3dY37TlQy3MPn2Ee5xh0nP1SQMfcWRfCOCGYqq LvHzgZ1D0HzuYVRD6HSj2mlhtYFunANzCcmuJdi9CwBBW5pclMv0GiufCYDyxYVOhOsC cYpw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=tJBikaiS; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-244123.protonmail.ch (mail-244123.protonmail.ch. [109.224.244.123]) by gmr-mx.google.com with ESMTPS id 00721157ae682-7b9ee936a32si3940897b3.4.2026.04.20.11.04.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2026 11:04:36 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.123 as permitted sender) client-ip=109.224.244.123; Date: Mon, 20 Apr 2026 18:04:32 +0000 To: Matt Corallo From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Message-ID: In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 9d54231d1eca0c7ca19eb350d116096fe9394815 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=tJBikaiS; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Matt, Thanks for this. I agree it's useful to first debate the goals of a first migration step, and hopefully get broad agreement on a subset thereof. The goal you propose rules out a PQ-only output as too expensive. I don't t= hink it is necessarily so, but it's probably fair that a seamless migration is a requirement to get the vast majority of users upgraded. Even taking your goal for granted, the devil is in the tradeoffs. As stated elsewhere i don't think "we" (tm) should position ourselves as arbiter of w= ho gets to retain ownership of their coins should some users fail to migrate, = which could be necessary if this was the only dimension to optimize for. I would also be uncomfortable with a migration strategy that could legitimi= ze future confiscation. We already start seeing attempts at normalizing it by renaming it to "deprecation". This, in my view, hurts Bitcoin's perceived v= alue as much as the prospects of a CRQC materializing before it is ready to face= it. I'd like to also propose another goal. I find it extremely frustrating how = black and white thinking creeps into this discussion, whereby some participants t= reat the risk of a CRQC as a certainty, not unlike how others deny it is even a = risk worth considering. I think our migration strategy should focus on maintaini= ng consensus (at least) until there is more certainty on the progress toward a CRQC, and to not degrade Bitcoin in the event CRQCs do not become a reality within the next decade or so. Best, Antoine Poinsot On Wednesday, April 15th, 2026 at 12:51 PM, Matt Corallo wrote: > Its become obvious in recent discussions that a large part of the PQC dis= cussion has people coming at it from very different fundamental goals, and = as a result the conversations often talk past each other without making rea= l progress. So instead of doing that more I'd like to write down what I thi= nk the actual, short-term goal *is*, what it it is not. >=20 > Fundamentally, it seems to me the most reasonable goal is that we should = be seeking to increase the number of coins which are reasonably likely to b= e secured by the time a CRQC exists. Put another way, we should be seeking = to minimize the chance that the Bitcoin community feels the need to fork to= burn coins by reducing the number of coins which can be stolen to the mini= mum number [1]. >=20 > This naturally means focusing on the wallets which are the *least likely*= to migrate or otherwise get themselves in a safe spot. Focusing on those w= ho are the most likely to migrate does almost nothing to move the needle on= the total number of coins protected, nor, thus, on the probability of a fu= ture Bitcoin community feeling the need to burn coins. Sadly, this probably= means the "top wallets" that are generally terrible at adopting Bitcoin st= andards. Wallets which are the top listing on app stores like (currently in= the top few in my app store): Bitcoin.com, Trust Wallet, Coinbase Wallet, = Blockchain.com, etc. These wallets generally use a single static address (b= ecause anything else confuses their users and they get additional support t= ickets for it!) and put very little time into Bitcoin, focusing instead on = other tokens and integrations. >=20 > A few non-goals: >=20 > * To ensure that advanced setups have the absolute best in post-quantum s= ecurity. I don't see how this moves the needle on the above goal, and in fa= ct in many cases detracts from the above goal. Of course if we can accompli= sh this without detracting from the top-line goal above, great. >=20 > * To ensure we have the best possible design for the signature scheme bit= coin will be using in a world where a CRQC exists and we've gotten past the= mess. We'll almost certainly know a lot more about the security of various= schemes and have more options for how to approach the problem by the point= we're dealing with the mess of a CRQC being imminent, so it seems like a f= ools errand to try to predict what we should build for this. But even if we= know no more then than we do today, likely ending up with hash-based signa= tures as the scheme everyone uses, we'll almost certainly be having convers= ations about additional witness discounts or increased block sizes to compe= nsate for the sudden increase in transaction sizes. Maybe we would decide a= gainst such an increase, but there's no question such a conversation would = happen and it would be premature to have it today. >=20 > Matt >=20 > [1] Of course I believe that the lost coin pool is large enough that the = Bitcoin community will, almost without question, fork to disable insecure s= pend paths and burn some coins in the process, but reducing the number of c= oins burned to the absolute minimum is of course best for everyone. >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CF7A554D-EE6F-4E6B-A670-1D6F72170539%40mattcorallo.com. >=20 --=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/= qbvf74cnK7N4QsE5kriIhV2yjyDxq8Yuuxli5-cpuilhuGqT1vvjs9EKyXVHL1lv9wPKiFrhdih= 1x6Hd2q8oL_YKahj5rl2qPCjNYSg6LT0%3D%40protonmail.com.