From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 19 Apr 2026 07:06:00 -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 1wESmd-000487-Am for bitcoindev@gnusha.org; Sun, 19 Apr 2026 07:06:00 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-4230d3a66b9sf3815545fac.1 for ; Sun, 19 Apr 2026 07:05:59 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776607553; cv=pass; d=google.com; s=arc-20240605; b=Me+j2NDaq05bzuQuuzp3zqkTYrBiCrJzPcfkNW6TYvmGhy1VBJ97dsjfIfimTUpd2q lxt1WKwebKBaQIRX4xjpHgaPwg6Aum018xjODgiY/Igpu6aYNQBn+WSidBEDLmxpuB8e HfkQPBEIaGcxbxaZBuUO1aL8bma88VK6FDLB4Ce1HRfy7tMrPQVpQUVNhoa1PbXk9gFM 0DpD+P0iIPF/rB/H9zTsKhttlt2BUW9O7F7aJNmbF7wAXoEFOLMCfNhLnCv/LeCEoM4G c2V+ygek8Anyjy6ztAya6x7kYUs8HxtVmszce5HIUkxUb+n9+CRdHSqjGj5lyt8hqi+Y p83w== 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:content-transfer-encoding :in-reply-to:content-language:references:cc:to:from:subject :mime-version:date:message-id:sender:dkim-signature; bh=YVYekCZ7wo7AbrryHwy/UwggnSgMLcr3fIAXXmSW5fw=; fh=xVdQO+YiIxEOJZUZV7JhHYSvzBcoIL2zOPJyAHhE3L4=; b=bzRd4eWnlP7VJhMSmyvx0CIAOcwyHZwwehyesFPmyEWgnB4x6XyLIk1+cwFwqyl9I0 nb/m6CyDWMqO8TqN36ur6pLRTfEqDFxyo3Qd4A5RvuMtEHh+9S9AQazDPZsbli0EdIH/ hwl9M+eEyoIY0PN1NxTh7iKKs2NQ7lIZC9TYHYpB7SiyfizGge3cXprfXH3wHQeJjp7t ISsgJRmBcl8Fq3j7+b52Rsv47re0cNlwT7nXqusmx54YcuPKEa8GqOkHLbRmtGOC1r8p hQxcixbae8zErNAFhElgGxyElZonGFVAv0398tH7kBCdeBZgpqpiF772KPbyeAE1SzZA Bc8w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776603661 header.b=p8gtr3OV; dkim=pass header.i=@clients.mail.as397444.net header.s=1776603663 header.b=FnY0AOaa; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776607553; x=1777212353; 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:content-transfer-encoding:in-reply-to :content-language:references:cc:to:from:subject:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=YVYekCZ7wo7AbrryHwy/UwggnSgMLcr3fIAXXmSW5fw=; b=uqNGQdU5WaTZQPTGIhIF+vC7VcEgaiXaIMfSaLpDrShu3jUxDfb/N30Q6N6ekJlp9t 5iOFyFhMbtB6hXL5YUyqm/AlvP+zEe/fN/mPY2FraOSeomDrAeyOBEc1BPNpwTZSKJ1i FSmmau/Ik6h8syCkPDB2dSMYyHfd8fjmuNEQSbiSd/nMAykvldMBjKj0wSPEQexqifWJ /AtojwI9pI1Kp0YHCfBqOLsQTxnF7rFIGIB2N6oycWHQj3f81NYulEmAe1rMh7U5Hnb1 wX5Lx8fKpQBIk77c6z3lvtcQisJi13hKDcs34BwtThxxKNK8dlCvNPxjDpKBVD4AgP80 HgFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776607553; x=1777212353; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to :content-language:references:cc:to:from:subject:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=YVYekCZ7wo7AbrryHwy/UwggnSgMLcr3fIAXXmSW5fw=; b=IRhqIIvvENXJqphY+aVznGoPW3ExqgHxWseMJmW7OuERb5ofWFAAse7gm5Q7k4fOXy yYa1V5jRVlW2XmIlVXELyjcy+05Xhub1cMqq+w88GfTkzk81zrJ5pnHjbYG00i4JFiAb xlEfrDGcLeM+rGJMXWy/3d7rLlmOjiNXEOLbnnQ8VSp/MU38sKcwWL05FRTTJ4sgLg8y 19aFTJInpxprhRRYCsdE1TmYRqhNC3TaubidCRW5o4bwaTGW2TlOMNkUnRgeX7NYq3FJ wFtMGJm4Zx0MQ7uW3J00zHqjAwVgD4p3Q+usVAMGGLea6GDoJmglZe/meiO6cAKXjodw fzeQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ8OLo7pP3B3TnO3aDaM9BgSUjr2+M6VJaGogaRXPsf7AnCnKFXtU0pqV8ejzVk2ZaQZTE4+puRF+cie@gnusha.org X-Gm-Message-State: AOJu0YyFaaVa7HrJK3nZ4qlyvForFfshOGKUo+aGlfEkEBIWlB75hcFI uia4Zv/C985qf/M5f7S7nJy7pC9wm4gdvoGTbFCElaHtiJkH9LJfM93D X-Received: by 2002:a05:6870:7089:b0:417:211:33ca with SMTP id 586e51a60fabf-42adededef7mr5906864fac.36.1776607552865; Sun, 19 Apr 2026 07:05:52 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJ5OHbkrt2rAhG6ONy/2VrVfM6nhh9u7qnm4lBbvYD1WA==" Received: by 2002:a05:6870:8c35:b0:41c:592a:81e9 with SMTP id 586e51a60fabf-4280be4713als1119177fac.0.-pod-prod-01-us; Sun, 19 Apr 2026 07:05:46 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/c7peRvaLmqMWRaxmLWBmqoc8PeKvMpVxRJKjS/NwRIyQYb4JJhLjEWceJd8Sk6DazUQTiN1oYip83@googlegroups.com X-Received: by 2002:a05:6808:f94:b0:479:98fd:807d with SMTP id 5614622812f47-4799c8f2759mr5280035b6e.15.1776607546846; Sun, 19 Apr 2026 07:05:46 -0700 (PDT) Received: by 2002:a54:4898:0:b0:479:9f23:6621 with SMTP id 5614622812f47-4799f236c9emsb6e; Sun, 19 Apr 2026 06:36:53 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/IxRwa2UJ7tT4RkJMda9LHrQpYp+En18jhALmhC0owDCOz71JTonmILv1veUGvva8UmewEZtw2GAeB@googlegroups.com X-Received: by 2002:a17:90a:da8f:b0:35e:594a:5b75 with SMTP id 98e67ed59e1d1-361404c1034mr9928382a91.25.1776605812182; Sun, 19 Apr 2026 06:36:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776605812; cv=none; d=google.com; s=arc-20240605; b=CeMsGx1kMW3yDwcHFAErnp+fpwy3YtrAAjrYzawey5AD7lef4JFsM06NX6yczwtE93 UJOhPydYPAVPrcUIYO+dzMLuT8sf0k983gnHwBUgrgraSECdnM4IJpV3QFnLu/yuEzQV WeYKLzhaMG9z+cGgINj+VrACr+wRR0xviSLLrYIkSYGtELnXiYIq/Nqbr5NLddSz1cmV vQ5Rh0rzrp02EZrxLEtp76bIWSo643Svdt0isnyJfp4DFLk6onIUPc4j1rymQi9Mv+GM DBHQQtDVdZdJCwFZmfxuAy6MlEmE+xMwlqX9FtBl9HbRkUVj2+4jwXC9qW7A5o4iU6r6 RH0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:mime-version:date:message-id:dkim-signature :dkim-signature; bh=IroM3yRMCWObV6rD4NJ0xWuiGQOOhZbn+beIQdyOZWM=; fh=WrUyyu3mL4sxXQ2aR5jDpwrAN6zeUdtrDDUVJDZkThA=; b=X0asXe1FEfpjKmFs8heMfhaYHhGpJq3XTHWYBKTWZzSWGpG2BzTTyFwhxUTWdejXTk LAhGVA5eLmlm3sgynVhCYGixPZ7ypHdTKHAuNZFg5r+TN2tBZ51cmxThwOOdkRLlrvXG PK+oD9EZF4iOb0dicN7zYrdCceDCfgmcEP+fcVgBueix/9GGcwxnpzh/jzpOxBd3wIZm WCop2dZs4HTdQl9ZY6vEhXWyVQ+OMx6+r5KscGzm6hfaZLDEt7Wo0v0dngyAnkpi91vx cjcsXyX74E8QQOuIULQLcSDoNl9cJsflZGb6IILFKgMbcwfL5MlIBgnWCDQAhme1VN8e V2aA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776603661 header.b=p8gtr3OV; dkim=pass header.i=@clients.mail.as397444.net header.s=1776603663 header.b=FnY0AOaa; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3613fa8149dsi152405a91.1.2026.04.19.06.36.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2026 06:36:51 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wESKN-000000001KA-018n; Sun, 19 Apr 2026 13:36:49 +0000 Message-ID: <39f3c26e-2cb5-4dcb-a269-78c793174b2a@mattcorallo.com> Date: Sun, 19 Apr 2026 09:36:48 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] PQC - What is our Goal, Even? From: Matt Corallo To: conduition Cc: Ethan Heilman , bitcoindev@googlegroups.com References: <2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@mattcorallo.com> Content-Language: en-US In-Reply-To: <2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@mattcorallo.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776603661 header.b=p8gtr3OV; dkim=pass header.i=@clients.mail.as397444.net header.s=1776603663 header.b=FnY0AOaa; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.3 (/) On 4/18/26 8:29 PM, Matt Corallo wrote: >=20 >=20 > On 4/18/26 11:44 AM, conduition wrote: >> =C2=A0=C2=A0=C2=A0 I think I maybe under-stated my concern over the no-a= ddress-reuse requirement for P2MR. We've >> =C2=A0=C2=A0=C2=A0 been trying to convince wallets to not reuse addresse= s for 15+ years and have not only had no >> =C2=A0=C2=A0=C2=A0 success, popular wallets have been actively migrating= the opposite direction instead. In the >> =C2=A0=C2=A0=C2=A0 face of address reuse, P2MR has zero advantages over = P2TRv2. >> >> >> I think we agree that merely spec-ing out P2MR as "not safe to reuse" in= a BIP will be=20 >> insufficient to prevent all address reuse. We also agree that /reused /P= 2MR and P2TRv2 share the=20 >> same security profile, with or without a future EC restriction (which ca= n be applied to either=20 >> output type). >> >> But we seem to disagree in our conclusions. You believe that because of = this overlap in security=20 >> profiles, that we therefore ought to prefer P2TRv2 - presumably because = of its short-term=20 >> efficiency. I think that's a huge leap of logic. The overall security pr= ofile of P2TRv2 and P2MR=20 >> are wildly different and you are only taking a subset of P2MR's profile = into account. >> >> To reach your conclusion that P2TRv2 is preferable, you'd need to assume= that the vast majority=20 >> users who migrate to P2MR will reuse addresses - vast enough of a majori= ty that the short-term=20 >> efficiency savings of P2TRv2 key-spending outweighs the safety of the (p= resumed) tiny minority of=20 >> users who actually use P2MR properly. >> >> We have historical evidence this assumption won't hold. Take a look at P= roject Eleven's bitcoin=20 >> risk list metrics dashboard . The volume=20 >> of bitcoin exposed today due to address reuse is only a minority fractio= n of the overall supply -=20 >> about 5 million BTC at present. Still significant, but not an overwhelmi= ng majority by any means.=20 >> We have no reason to expect everyone will suddenly start reusing address= es consistently with P2MR,=20 >> at least not any more than they already do. >> >> If anything, address-reuse will reduce, and not just because we ask them= to. If you look at the=20 >> highest-value addresses at fault of address-reuse today, they are mostly= corporate cold wallets:=20 >> binance, robinhood, bitfinex, tether, etc, and these make up a significa= nt chunk of those 5=20 >> million exposed coins. We can reasonably expect those players to use P2M= R properly out of self-=20 >> interest - These coins will be the lowest-hanging fruit targets if they = fail to do so. >> >> So yes, even after taking address reuse into account, P2MR is more secur= e than P2TRv2, and=20 >> personally I think the safety delta between them is wide enough to excus= e the minor handicap in=20 >> P2MR's pre-quantum efficiency. >=20 > I think the gap between our views is that I don't buy that the "percentag= e harm reduction" outcome=20 > is all that interesting. Sure, there's some % where it certainly is, but = its probably in the 99+%=20 > range, not in the 75-90% range. I think maybe the biggest gap is I just d= on't find any "solution"=20 > that results in 10-20% of bitcoin (*especially* active bitcoin people hol= d keys to that made some=20 > progress in migrating but maybe screwed up address reuse) being stolen as= at all interesting. If we=20 > manage to get 90% of active coins secured and then 10-20% of active walle= ts get some of their funds=20 > stolen, have we actually accomplished something grand, or is Bitcoin's re= putation so shot that we=20 > might as well pack it up and go work on some new fresh chain that is PQC = from day one? I'm fairly=20 > confident the answer is the second, not just in that "we"'ve failed, but = that the market will see it=20 > the same way. >=20 > Sure, in any solution set here there is going to be coins lost, but if so= meone did the work to=20 > migrate, having a high % chance of screwing it up isn't an interesting sc= enario to consider -=20 > bitcoin is simply dead in that case. I wanted to expand on my answer here for a moment. I think the reasoning of= "well, some people will=20 be able to use P2MR correctly" isn't just not fixing an interesting problem= , I think its somewhat=20 dangerous. First of all, the more I think about the address reuse problem (its been a = while since I've really=20 thought about address reuse, so it took a day to come back to me...) the mo= re I don't think its=20 going away. As you note about a quarter of all coins have an address-reuse = issue, and if you remove=20 the large cold wallets its probably half that again. But when we consider b= oth the uses of Bitcoin=20 that drive address reuse and look at the chain, there's a lot more risk her= e than just 1/8 of coins=20 (not to mention just 1/8 of coins is way too much). In a world where there's material address reuse, and those folks are using = P2MR, suddenly it becomes=20 "their fault" for "using it wrong" (even in cases when it isn't). Blaming b= itcoin users when the=20 protocol was too hard to use is something we've tried very hard to avoid th= rough engineering that=20 makes it harder to misuse. Instead, here, we're encouraging it. This doesn'= t just discourage any=20 future fork which might disable EC path spends (maybe some of that can be h= eaded off with clear=20 documentation in a P2MR BIP, but this blaming has already started...), but = it encourages a culture=20 of blaming bitcoin holders for the mistakes made at the protocol layer. On address reuse, as far as I'm aware, its driven by at least three factors= - * There's the somewhat obnoxious "wallets get user complaints when their = address changes cause=20 they're used to address-based blockchains so wallet devs turn off the addre= ss rotation feature to=20 save on support costs" one which is the most frustrating, and may well driv= e the most wallets, but=20 certainly doesn't drive the most coins. Maybe this one is fixable. I'm quit= e skeptical, but you and=20 Ethan certainly seem to think it is. * For funds, family offices, many custodians, and exchange hot wallets, a= ddress reuse is an=20 important security feature - much of the large-bitcoin-wallet industry is b= uilt around keeping a=20 list of allowed addresses (exchange accounts for sales, but also on the fli= p side a list of their=20 own wallets which their exchange accounts are limited to withdraw *to*). Th= ey have processes in=20 place to verify every transaction only goes to one of the addresses in thei= r list. When I go to look=20 at the addresses with the most bitcoin transacted in the last year, there's= some cold wallets, but=20 number two is 1KNm4K8GUK8sMoxc2Z3zU8Uv5FDVjrA72p, which some random website= seems to think is jump=20 trading...it has received a total of 97M bitcoin across its lifetime. Maybe= the large players will=20 rewrite their logic to use a combination of xpubs for EC key generation and= a static PQ pubkey,=20 building the tree as required, but exchanges are gonna struggle with the ex= tra address=20 generation/chain scanning burden and I'd think would instead just switch to= PQ-only and charge the=20 extra cost as a deposit/withdraw fee, or more likely "use it wrong" and upg= rade "when the time=20 comes", blaming their customers for sending coins to a "revoked address" wh= en they do so. Maybe a=20 new output type really (finally) needs a new address type that has an expir= y date... * But maybe most importantly, sadly ultimately no one can control when so= meone else sends them=20 bitcoin. For spending wallets that are used to receive coins, the sending w= allet having a "contacts"=20 feature or users just reusing an address that was provided to them is enoug= h to potentially screw a=20 wallet. While the first isn't so common (though certainly growing), the sec= ond presumably is=20 somewhat more. Here too, maybe the solution is just an address format with = an expiry date, but of=20 course that would slow down any migration by probably five years and likely= isn't a great tradeoff=20 either. * Its probably worth noting that dusting attacks could trigger many walle= ts to reveal a public key=20 too soon. Of course any "quantum safe" wallet should handle this in the way= Bitcoin Core does -=20 ensuring it spends all outputs with the same address at once, but this is j= ust one more way relying=20 on this stuff can so easily go wrong. Matt --=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/= 39f3c26e-2cb5-4dcb-a269-78c793174b2a%40mattcorallo.com.