From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 19 Apr 2026 15:08:55 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wEaJz-0001N6-5j for bitcoindev@gnusha.org; Sun, 19 Apr 2026 15:08:55 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-415e1e9aa5dsf3310391fac.0 for ; Sun, 19 Apr 2026 15:08:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776636529; cv=pass; d=google.com; s=arc-20240605; b=WKpNrihRLKVnY7Z4PAs4KhaWmEZSfe6iiigSR2Hjhf1qPD4TxweYEKZYAAgoCbau1h opdJfJphChrDEKNM/+bxeDXDiqKT2riOQCoy+dTkYbpSK2FDVW+h2nMychN5lp6BbEEa ioi1FVwsEE7tBgWl3zr7Q3OJAG3WyCQDmmWx7WjUqUoX0lX/7kBehakRPd8YSY3TkxZy O0/Z2i/t2k6DPNkO2DOlBNTcUo/k0rmMVGc00g7qKlhXWpHSLjEpscEvDyJjN/xRu7mC jNcHWG6xw8+JvF57nk5bSQB/eSu/T1pKc1ZEScOIZhNi04eHsZDZ71LZ/9yo7nMCORFH WRlA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=X0MNdHX8GdO8zKE/V+gvGtZ5aGzj4sSeJRxP6GFROnk=; fh=cXmnY5cUnzRfvMcAJ4uzRxBsXZMZUADBTpRdEPKOTNE=; b=Rdmy7bV1Sfut9VE3lmBZG0ew7HlPLj3OImcqmbEwUurB8riR/dyYIprqTi/KW57u5c XsLvDhIqoPh0QcE/ajTYnAGFjFcZ/cD1cziMwDLYWJOpZ0wlbaV6QVUFJzT6LIRrk017 jFEHKjy+W3o35hKWmaa7NGobMm67HnL1iqzUbVDRoUb1NjZuxGSmQqEWi1ylga3GyNoW NsQP0EMj4PubbHUiFZpD+LtSBnHrYxtvfzDzi2H2Xmz6hoTW8B93BMHKEtf8RCCH6+GC 37K6wZkffAB5GeX5v13JT8xAg3ZasoutwJK6dr9Wj9sjykvFF67lQwKmDZru4m/mUk1c 5r0Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776634862 header.b=K2Wg0ryy; dkim=pass header.i=@clients.mail.as397444.net header.s=1776634864 header.b=16ZQPPya; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776636528; x=1777241328; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:cc :to:subject:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=X0MNdHX8GdO8zKE/V+gvGtZ5aGzj4sSeJRxP6GFROnk=; b=wqbFisgGjlbQhzG68kam57rg/bnDunxF0nSYWAjEZER9git/AeSBiT3ZU2cm7Lfp1O Ztkio+vlZVdFyn1ZD3+JtAjJMEA6al2QiCkzjzrWVfWNhdffojVIyz7ygf5ErHXRoXU5 wv23aJK6zr2KoGeZ3s1kZlv9BqgWB2jir7swTsi6iMa83z6SkBP27RSP2gx1oZQH3gVL YH6YwPFgyTYP3TG9TU61dj76DgtUHPzKwgSU5GOUUnWS84s/cnIjLhQ7aeJrLf0KYnIj wTyI1XBz8dmSaNIhg/6/oww8DPuaAfaZ9O+z2MYtLamgwZlKwU3LZMHy3fascAgj6VMc QZug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776636529; x=1777241329; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:cc :to:subject:mime-version:date:message-id:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=X0MNdHX8GdO8zKE/V+gvGtZ5aGzj4sSeJRxP6GFROnk=; b=FRt7l6Id7Twd6pTHBUGkgUIcSfgm50WSI8F0YlEixdbvszdevMUEJgsOFal70c6hCm vdJzwP4aK7bqDepGv2c4r8aenzA7nhgGoeHw7IeF6tWCD6EXet7O88DoyACHFKnBGan5 UU+6YhUEIY0DvpxUXd+e+UtLrAZ+29z4BBFRlZQUxf84FanRFv0xkcLF15c3hqk72EMj mmvJ4hQgeLHEHL+f2tORUjN0Xl1Jko083mq5SF7cnFBX2sYqhkV4GVc6UolOSBDNmqGx nN4H0wn/081Gd231L91sUA49/G3dKcqszRijoNeRzkg7w17kPqAZ2lMopQJGn2wgY0IM 7Q0w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ9OMza3ISYyUkJo/apBnrJmVYOxiDzztd9CIubC3IMbYamIVXD6miryKD+Cl9fxGzGTyA/jFqVPJHsf@gnusha.org X-Gm-Message-State: AOJu0Yzog4voFL7SXyICwk41ZHFrHrQvRiLxcq1Jtvqja6iyZY0QbSaI A95ACoiqrSM6AYtw1ds24RR/EXyKKMUGvzjuhYl5PayTHB8v1naeS3FG X-Received: by 2002:a05:6870:1d08:b0:3d3:ce01:1779 with SMTP id 586e51a60fabf-42aded98b4fmr5714052fac.38.1776636528579; Sun, 19 Apr 2026 15:08:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLDeVOTmwlBoBWCJWnc8eVJfsY1VEHoGuFDaID0bVxePA==" Received: by 2002:a05:6870:e8d:b0:41c:5212:2c74 with SMTP id 586e51a60fabf-4280c4bb6e8ls1928753fac.1.-pod-prod-05-us; Sun, 19 Apr 2026 15:08:43 -0700 (PDT) X-Received: by 2002:a05:6808:2381:b0:467:9ca:4b8a with SMTP id 5614622812f47-4799c937f6emr5729824b6e.11.1776636523605; Sun, 19 Apr 2026 15:08:43 -0700 (PDT) Received: by 2002:a05:620a:a389:b0:8d0:26c1:4847 with SMTP id af79cd13be357-8e7927564b3ms85a; Sun, 19 Apr 2026 15:00:15 -0700 (PDT) X-Received: by 2002:a05:622a:1e07:b0:50d:9d8a:ebe9 with SMTP id d75a77b69052e-50e36bb058amr172002421cf.27.1776636014441; Sun, 19 Apr 2026 15:00:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776636014; cv=none; d=google.com; s=arc-20240605; b=Smc12GoVmIwNXN7xtqpaeeuE1gTWNBNV0PuCJhb/s8F7NG0072asMez2UBXOlMaFhi UsR5+fUvXwMbZwZFWPd3AW3mM/h56/rbwoMJZWgXdVqS8KsY/Vu9kYW442jqKWnXTeJg H/KEJJ/GqlZ3z8O21XXJ7GLhaNKdN7CFGSKET8uwzDHD3Bu4UlWAncC0F1fhfReOdVe2 HskzcsDGP0rAaa89mc+UT/3PonlWB3ylgKksxSMiyp8dURkfoqltfMmV0ygdfeOK3O1i eqXrSLEXwkVnf8SOkVysJW7iVfM7LCw4k5GFLrjBkjaau1ftegUTtYmILE2NEstVW/Pu AgPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=VDEDd8g+QQ9o0MegUAkgcCu77dESAOn1KmBxSxDUwGw=; fh=/FDIxXLGHckABgs3/uJQS5c3qVAQv3qfjYeG2KDvAp4=; b=VbRBitu+pVNN5UDWxf+ahcKu0Fk9PiSSbKKgd38McKofNZqq8GbU3OHE/ToDlef3QM 4MQW0cTWWh1ZH+lel348X621E2v+oPqQS9DZYkd7JjDg7Zk86UZYDk+Kl6rXnj7fSUtM OPyyOmmtTxCMZIZEpsTKEKwVCV9978x/wx4Hnu5hFiNce878rD9RNFDQXWipBfJDyfxc o16Xz79e1fTV/DjhhKmJnfpMgj+vCMAUSOfO7g9V0yGnF9vBJzPB2lwlfPvDNQNYrF2u tN0qrTXhoSD9DC0yzaW/9wxgNunyfwPrVryzxDS/g9EVRiLqXf7Vg2Fb9JjNNI3JOus+ uMXg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776634862 header.b=K2Wg0ryy; dkim=pass header.i=@clients.mail.as397444.net header.s=1776634864 header.b=16ZQPPya; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-50e39448cf6si2278661cf.6.2026.04.19.15.00.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2026 15:00:14 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wEaBV-000000005LI-0qYE; Sun, 19 Apr 2026 22:00:11 +0000 Message-ID: Date: Sun, 19 Apr 2026 18:00:10 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] In defense of a PQ output type To: Antoine Poinsot , "dplusplus@gmail.com" , Olaoluwa Osuntokun Cc: Bitcoin Development Mailing List References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776634862 header.b=K2Wg0ryy; dkim=pass header.i=@clients.mail.as397444.net header.s=1776634864 header.b=16ZQPPya; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On 4/15/26 2:15 PM, Antoine Poinsot wrote: > D++, Laolu, Matt, > > Thank you for your responses. Since you raise related points i'll reply in a > single email. > > I think the disagreement boils down to what we are trying to achieve. The debate > on output types is downstream of this, so i think it's worth pinning down the > goal(s) first. My view is that we should mitigate short term risks to consensus > in the event CRQCs never materialize, and minimize the amount of BTC (as well > as UTxOs, ideally) at risk by the time they start being practical in the event > they do. And, importantly, do so without creating more risks to Bitcoin's > perceived value. > > This explicityly rules out some theoretically possible scenarios, which i > believe can't be realistically addressed but are fortunately extremely unlikely. > > Another thing i'd like to address is how some replies appear to interpret my > post as a defense of BIP 360. I think their approach of keeping Taproot's Merkle > tree of BIP 342 Scripts is a fine design, but my argument applies to an output > type that enables a hash-based PQ signature scheme, and preferably disables EC > opcodes. BIP 360 as it stands does neither. > > Both D++ and Matt pointed out how my argument that introducing the PQ scheme in > Taproot would create perverse incentives with regard to the later decision of > freezing could be addressed by using a new Segwit version for PQ-Taproot, with a > social expectation that the key path of such outputs may be disabled. Fair > point, but i still think this is a weak guarantee. If usage of this new output > type became popular for unrelated and unforeseen reasons, this could make > disabling EC spending paths as murky as for regular Taproot. > > Another argument someone gave me in meatspace was that users of PQ schemes would > turn into supporters of a freeze nonetheless, once they obtain the safety of a > PQ output type for their own coins. That's plausible, but far from a certainty. > I don't see much push for disabling the SHA1 operation today. And even if the > share of BTC protected by EC operations was substantial enough to be a systemic > risk, users of a PQ output type may prefer some amount of risk to the certain > undermining of their asset's value proposition. > > Laolu, in response to the three futures i laid down that i think we should be > optimising for, you pointed there is also a possible future in which there is > classical advances in breaking the ECDLP problem. Sure, but i don't see why this > should suddenly become a future we optimise for. > > Both Laolu and Matt pointed (in different languages) that a PQ output type is > not mutually exclusive with a Taproot embedded version. It probably wouldn't > hurt to also introduce a PQ scheme inside Taproot, unless we think that > making the take-up of CRQC outputs publicly visible is a desirable property. But > it's not clear to me that it would achieve much next to a PQ output type. > Presumably, concerned large holders would favour the assurance of an > actually CRQC-resistant output type, unless they believe the CRQC risk is lower > than that of leaving their secure signing environment *and* they give credit to > the social-signaling claim that such Taproot-v2 outputs will have their key path > spend eventually be frozen. Same for laggards, why would they bear the cost of > upgrading to a Taproot-v2 output if they assess the CRQC risk to be low enough? > And once they believe it is high enough, why not use the CRQC-resistant output > type instead? It seems to me that outside of newly created wallets, the case for > a Taproot embedded PQ scheme is stronger *in place* of a PQ output type. If > large holders have to use it in order to get access to a PQ spend path, then we > can reasonably expect them to keep using the EC spend path until it gets > disabled, thereby reducing their onchain footprint. However this alternative > does weaken the risk mitigation(s), because one would have to believe the key > spend path actually gets frozen eventually.. The problem is the entity who owns the coins is not the one making this decision. There is some wallet developer who is going to decide what code to write based on their understanding of their target market. Users are then going to decide which wallet to use based on recommendations from their friends, random websites, or an app store. No one is carefully weighing at what point they need to come back online and make a transaction before Q-day and then deciding which output type to use. Instead, the best we can do is provide an option or two that we think gets the most coins migrated "in time". > Matt, you stated the (only) goal of a migration strategy should be to enable the > maximum number of coins to be retained by their owner, and that this is only > possible by disabling EC spend path(s) and (i guess hard-)forking a ZK-proof > spend path for those fortunate users that happened to use a common key > derivation standard. First of all, this is only true for those owners that are > somehow unable to make a transaction until the advent of CRQCs, as any other > owner could simply migrate to a PQ output type instead. Or, more likely, unaware that they need to. > And therefore, this is > also incompatible with a higher-version-Taproot-output design that allows users > to opt into a future EC spend path(s) freeze. Which are you arguing for? Providing a shorter term alternative like a higher-version-Taproot-output blunts the cost of later migration logic like ZK-proof-of-BIP-32. > More importantly, i think your goal statement goes to the heart of the issue. > Maximizing the amount of coins to be retained by their owner is of course > desirable, but it can't be the only goal. Especially if it comes at the cost of > consensus changes that risk burning other users' coins. In this case, we simply disagree. In the face of coins which can be stolen by a CRQC, the best outcome is to maximize the probability that their true owner retains control. That means, yes, having some probability that the coins are burned. I'm unaware of a way to do so otherwise. > Finally, Matt you also asserted that a PQ output type alone is not a migration > strategy since it would not achieve much. I think that if you spell out the > argument behind this statement, the case is actually weaker than it seems. The > burden associated with using a hash-based PQ scheme would certainly slow down > adoption for those users that have less at stake, or whose usage patterns would > be particularly impacted. But it's only natural that holders with different > stakes and risk profiles make different risk assessments. Each may migrate to > the new output type as the assurance it provides comes to outweigh its > associated costs. See above. I think this is somewhat simplistic reasoning about how decisions around address formats are actually made. But I will say, I've somewhat come around to the idea of a PQ-only output type in conjunction with something more akin to flagged-P2TR. The former provides an option for those who think that there will be a bitcoin if only large, conservative holders are able to retain their coins in the face of a surprise CRQC, the latter provides an option that is cheap, retains existing implementation as much as possible, and provides a way to get PQC pubkeys attached to outputs in a measurable way to inform a later Bitcoin community of whether a ZK recovery scheme is viable and required. Matt -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c7df3994-948b-4b3b-a8fa-c91e780cadfd%40mattcorallo.com.