From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 08:22:52 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD24o-0007Ug-DU for bitcoindev@gnusha.org; Wed, 15 Apr 2026 08:22:52 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-688b73cc616sf7719944eaf.0 for ; Wed, 15 Apr 2026 08:22:50 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776266565; cv=pass; d=google.com; s=arc-20240605; b=PhtAtS/0qFNFwodTbg4eC3CQ9ME8Mj9tmE+ek2ruat/2U+aDo+/NZt3UUib/CvsfDY 93gZbZVEnhxg5swTKHzFtau1a/1GEUdjCx9IOsY6TspPE6GCJ9T9sNUJGHKW4H1zxY7N RIzOQarZYo1A1hzyxuIY+JitkXXeQEa8V1j455BCwmwq1tqrzAlVeZt7+wBgQ8HDfL89 LXgKPX9ZgVVxtvyKIniJqMcMZ2csispwk756DwH71efgNF0vSSnhwTGtB04pNtoXXZUz WgbbNpAhN8ouF8k8mmvGFOcYYc0EGo1Svu6FmISqC3agMdYIQkDc3k7DDaT98ah/prWF c39w== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=VTMuoLqYpd3K7RElFe58WzyRqNN5Poq1Xzs4UJE6mfQ=; fh=cIwfdR1515N11DCoLZ5X9lLiJfjzFZ8Ne+uyCZtOy6Q=; b=LJIOLDuQG+l6VtVfey5ld1P2cRxU7gKB+P6DXnMbN1B7dZXP+JB5DQM4NkJWvf0xIY w1fxnOFRuYGTEAlwnpC4adoA8vmlN6TskTw+0T9/GWsdDfLaYvVmeMLLWxNDVDqirhT2 8hDOEGvQ3zoAVHUZ+2yhlp8u5KW9BdDyPzL30e1dflgr0EKTybXnWxYkEHEVOtPpTwkM 1Ftas6h3OGSATlRjLNxdpGfJyj/+D73ngxGmy6uOP16uNHpi6JJ6Qjh8J04H7rAuNTU4 g6FpnQUu6QDOLryv06VFdn6cHid7aWCVlvIu1ctPZwpAPOH82Fm+ejrGBjdZOcCGArbp 3FLw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=pdKGhS0J; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776266564; x=1776871364; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=VTMuoLqYpd3K7RElFe58WzyRqNN5Poq1Xzs4UJE6mfQ=; b=N7q9rMrZNMvEuNl1lLRmZ94ftbI6o1XIp0TUk07ZPMcWWC6B7Z9COXSdoPTBpqG2n9 aP8wKOSi/Do7JFG5mOkhIYT1f2eREwnJXSDQCf4+9j5NCjDhbxe+m/K41EEmH/KH4JBA 1/mToIwyj1RGFaSx2FEvRKyLR7nusmk45JmbbF0MA+RboqdDCscdf41ajUfJGW+mPFH6 qK+WpeXznCqmAsCkbrlB8PBizRn363bAGtBPfYllVtXeqS5I8DuxgZK/N7p6UXQEk5pr sTz+66plA2hYi44HLoycNeM7sW3aIt+PfOi3DNjGQjkWMbVZFYmwv5l1iU4ZfDWh6rk+ DFdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776266565; x=1776871365; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VTMuoLqYpd3K7RElFe58WzyRqNN5Poq1Xzs4UJE6mfQ=; b=qfWjPiPjfYuJa+zxQqv1lMUQUIatbLZhWOqt/X9SsyaF7owqf9a69ubpE8WxH4fCp4 y0VlpNqTdkW8IvS7CxFOfOQC3wuxC0dWrOIEduKsuF7mPNBfLxz23h4bUJokoHIWKs79 zUg9ldSswr1aWAjTISc2wZ3n5c0/zLT/IOPlkutraMSKqLEnFXhMjuWdqZLQiSHzXlzd hk/KGj8uft9jdn/QX/qB4WMlvRVXi5RCVEDzaDJAY5d7lGm+dahFupttKxFgNaxqlMQr E0Blc3Bq2PdcgX+7slSQladROT8RIHpn+ZMWOuDU0aA7ZKOBX6gfKB4EUZN9of/0zqhT Abug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776266565; x=1776871365; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=VTMuoLqYpd3K7RElFe58WzyRqNN5Poq1Xzs4UJE6mfQ=; b=ATZpb9jII4YqU/Oe/g2ekuIG5zWN68a1Cur/XPE8BlXxWzjBLdp5noqlVF3q7GlJNW BN2Gq0Me9+Ok9AwPdNKd2fLoOyjkL2yYkFrSzlmZiS77ROMObMw8Zbvw++vsT0FV+pIQ LpqEztNNJJhhrSL801CPtR1HhBErBwp/wpq+euGq8QoIXhsv1gdFXwMdsV01jKM8W0Wy sRhdh2w99PsQYImEho8KbuM3BD4FGN75aEFgsJGG9xGpcWQGnArdBXgMTZVOuhidcpso wmxJimPuBbcSIipviFmzRx14f8vKS70ZM4NkzlF8f1LGszYmUJ8TW12HORwf0bkp0ghk XC+Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ9sNTGxzTAxFNouhx1bKr4ltWK2bxKY0/I0rg7If0fJFA//ng/8APg8aNFhP+91ILBxD1+rB9UIeWAA@gnusha.org X-Gm-Message-State: AOJu0YwSazGqYoM9ECTrqklUaMBy/VeeHDh7YoEvS9LAg7GF5XMS90X2 9g/qR7HdAtJr2O3sUuk9FRozjcSPIbfWvuOwqwt+zE06qEBVzcYyoT6M X-Received: by 2002:a05:6820:7801:b0:685:9910:eb89 with SMTP id 006d021491bc7-68be8dd4435mr7068023eaf.58.1776266564552; Wed, 15 Apr 2026 08:22:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiI9Ymx+1VfuGFOQonwHV4Ulmbzes09jyH/vNRxEjXb8vQ==" Received: by 2002:a05:6820:2225:b0:67b:b01c:5f3d with SMTP id 006d021491bc7-68bc29bf7e4ls2717872eaf.1.-pod-prod-04-us; Wed, 15 Apr 2026 08:22:39 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/Z03d4iwrfaAksf8xRdK9jq32sZunodKQsqDAo0yV2WHQGx4XuUscqZa7s7rczMftsWQhZQqcVGsAN@googlegroups.com X-Received: by 2002:a05:6808:2e44:b0:46e:c1cd:866a with SMTP id 5614622812f47-478a03fe884mr10804050b6e.27.1776266559706; Wed, 15 Apr 2026 08:22:39 -0700 (PDT) Received: by 2002:a05:6808:6189:b0:467:e362:ec8e with SMTP id 5614622812f47-47974686444msb6e; Wed, 15 Apr 2026 07:36:36 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/aUBmMQrgW+iD2nxbFIklSfuLfWde9NC9jHZGpGVkONgKdpBm3suOIk+UGRebMDbDRdqTSZNSvMX+J@googlegroups.com X-Received: by 2002:a05:6830:6d14:b0:7dc:283:898b with SMTP id 46e09a7af769-7dc27cba20bmr13505039a34.10.1776263795940; Wed, 15 Apr 2026 07:36:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776263795; cv=pass; d=google.com; s=arc-20240605; b=M6pHnraGVoZKiZ7zGKjEe57nHNMd7NMd3l8+lGvV1+8R87oWMZetMaX+ijPnm5ctji 43JfqBssScYyZDSj/A5X3jy6tcE9ZYF/FObwgPMSDPLLZwcCBUkAPwyP7551tvmkuO1X 85hHgG65QPqMl90KUhhg7C8vkH5Md0n1/eDGZQLpKZmuFgoaVOnhNxikF8IroQGB8b/f lib1p7bGxueMhz59Wmp10ZSzXKkZj49F9I420vLpunJFI6tZrW/sDtDt888PUA0Zi6OA cuTp3+txGwDHZSgMaZ51oxdn8TPMII5ItgK0CGpRYK6lOwjTYkiyDNdGKsteC1TL4SaH +uww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ShO9abt5ij3+4nn4EVuFY59NLoN+xrd+6LeJw7RCXj4=; fh=4yojNlS25NAomVM3wSmMYyR8uKFW4pM6IeosGwe9lIw=; b=fo0GDfs3KVXqOB1UKHjMtPXScRUpm4qCpGTED59XM2GfPh9kFkyVBA4kkYaiv6N42m F1Fjp9cSO//gYSytCZr//IrMheR/leNWHl/qoMiDr55VZBbJ4DkpkzGimX4DlKrXc8/R AV2K1E4wnlJDwmCJxOEp/RiP1fLUd/U78m2h6kr2IhXDesj0e951SOtrqnR5RjvyMxyZ uASeIiNHthrblKE/LZXVcP2pO+TR0QTrSa/N+0F01UZdmQRn09IxEn3Up9g9sUjlkRHZ 4IAtQ17Sa92JTVu/LOZNgoRjJ5Gfp3MiTxigdyvs2bbOcdUj1VrfVLONAAcCMlPG4k2x gntg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=pdKGhS0J; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com. [2607:f8b0:4864:20::1029]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7dc76b4a82fsi63384a34.7.2026.04.15.07.36.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 07:36:35 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) client-ip=2607:f8b0:4864:20::1029; Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-35d94f4ee36so4045804a91.3 for ; Wed, 15 Apr 2026 07:36:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776263795; cv=none; d=google.com; s=arc-20240605; b=hu+/BgaVGi4ciSFi5fTIQz6jwdnA6EUL6mjEZVPbNCVQ/Pk85PgrN0Vy0PVUQm9khf amy2zXEn5kjYaYuQMu38xfmdakNEE7F7QZutaAk+QPhyg8jYpaBrmPoZPPrlFKiJ7mMm 3mQqLk6LoAajoxBa9Gyj1nPl6T+WSQGvwy64F55iw++bSBZdW9/42iiNu466YJkm959Z qG9ugygHs6eKO9BmUJMaMRvNQUBRT9IUyKBUpjr2NFUvPTFkNv/MFgGMbtu0f20zbB3S pq4x7vYf/Z1HNjv22gBd2tOuueYLwsRzVHc17HNHbzbtJWTxJ82eZAxldFcum8iHXau0 Vy4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ShO9abt5ij3+4nn4EVuFY59NLoN+xrd+6LeJw7RCXj4=; fh=4yojNlS25NAomVM3wSmMYyR8uKFW4pM6IeosGwe9lIw=; b=et74kVH7QuZ7rXy2j1ElGQDbaJQ3OZnWxezPoZ/SGBkzaAN4Kpcgk6njTzxlPoT5lK 36ysG6dAzrdF4ad8uFLgGwpXQ5oUo6eMpq0n7CZatB0HPeXNwEw5T5yYPnL2fj8R2cW6 TLvLBpkopFxTjdbiMhaLsaOK0yz2IFKBJtggHxU+hzWbuCkyuo6TcKK+3ePRHEaHK0eq n8uuHDlfenxAjG2MzVbDio3y8gu5g3DFfAvEiUvbtPQT6YCBhiqI63IGx7BOFyjmqZmm 0nL3gCcOawE3jv/H3U/SW2vbY7a4ZC+DSUH6ac7JQ2oUZzH8bKqCftF31bRiaryVU3R3 zs5Q==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ+BeQBVv9C/CVyxPi0VbZ+d9G9CllfW3e3E8hRtRv48/1hxUvUMzb9A2wnOjV/o9d/+fLGsKoTcSjku@googlegroups.com X-Gm-Gg: AeBDietRQFm1qJHw5G5i0R3+rHW5i/XAji8qdR+R7FYgs6PnhyOrKG4ejfQ+qvZtFZ7 oC+YVlx2hBx9638o9X+dT8lOKuLbHli9kEk3Kx/B/yqMkGoi2QOPuETnam46R6lqElX0GIAF8ja q4WE0ZkP/D9fYTW9XP01XXziyaMmRRVdAbsxM7GsE+czy4V0f8w+YpCkENzJ5FhCZWyqaunAwCX mXbSnU+7x2XdDfoBIfVQrwuENsh41vs/1X0RZBgxNlxFLCcdPXK3gYrYame3xbjZWFWJId3lakN LU/e11x86jJenwvXwt8yeTOcUOqQlvzUID/vAtUS8t4H+lrODaVxAc253sPjeYVGoEFC1evhaI/ edkmtrKeXl7JMildXfp8MnbwFpdj8aHQ0uKepG4GD2uJ6Czmm/HFp1n8Oa1PSF+c+mDQSBRajIy oh17YlFOkoJoDOW2CjNA3tTrZ3ANqII9NjfHc5B6KQt3b5C2rFPbvKHjw+67aK8Z+X1ZtaGHnVr IKUy6U/0NTzcZOcmA== X-Received: by 2002:a17:90b:2b46:b0:35f:b423:688b with SMTP id 98e67ed59e1d1-35fb4236a9dmr12742053a91.28.1776263794894; Wed, 15 Apr 2026 07:36:34 -0700 (PDT) MIME-Version: 1.0 References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> <765490aa-5df3-4619-86cc-17570b6d3e99@mattcorallo.com> <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com> <42806684-3cc4-42e2-8052-43288a93e91e@mattcorallo.com> <3e14b17a-5920-4814-a86d-fca39ad2329e@mattcorallo.com> In-Reply-To: <3e14b17a-5920-4814-a86d-fca39ad2329e@mattcorallo.com> From: Ethan Heilman Date: Wed, 15 Apr 2026 10:36:24 -0400 X-Gm-Features: AQROBzBg3NrA2yovGxaf7ZKFOOP1jdMHLjPjnMJiGk1xdw0A_hXbT7D8QORV4Ts Message-ID: Subject: Re: [bitcoindev] In defense of a PQ output type To: Matt Corallo Cc: conduition , Antoine Poinsot , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000085ad25064f80a42a" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=pdKGhS0J; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000085ad25064f80a42a Content-Type: text/plain; charset="UTF-8" The proposal is P2MR with PQ sigs and no Schnorr address reuse. Address reuse in this setting should be treated as security vulnerability. > As such, P2MR with a EC-based key for short-term efficiency reasons has the same quantum security as P2TR or P2TRv2. This is incorrect. 1. As long as the Schnorr pubkey has not been leaked by the wallet. The wallet is PQ safe. 2. Even if the Schnorr pubkey has been leaked by the wallet, if the PQ leaf hash is not publicly known it is safe against long exposure attacks. P2TR is **always** vulnerable to short and long exposure attacks. There is no better wallet hygiene that can fix this. You are comparing: P2MR + PQ signatures: A wallet messing up their implementation of PQ safe transactions and introducing a vulnerability and weakening a subset of outputs. If implemented correctly 100% of the outputs are safe. vs. P2TR: A design where 100% of outputs are vulnerable even if the implementation is perfect. These aren't the same thing at all, nor do they provide the same security. On Wed, Apr 15, 2026, 07:02 Matt Corallo wrote: > Oh, apologies, I was in a bit of a rush yesterday and forgot the most > important reason why P2MR > doesn't help at all - address reuse. > > In practice the "long tail" of Bitcoin wallets (which, as noted below are > most of what we care > about) do strict address reuse. Mostly a consequence of address-based > blockchain systems its become > an expected feature that the address displayed in a wallet is static and > does not change. As such, > P2MR with a EC-based key for short-term efficiency reasons has the same > quantum security as P2TR or > P2TRv2. > > Matt > > On 4/14/26 4:04 PM, Matt Corallo wrote: > > I'm gonna top-post because I think we're too far in the weeds and the > high-level argument is getting > > lost. No, of course I do not thing that our job is to "convince" any > quantum skeptics. What is our > > job is making sure the *bitcoin system* is ready in case a CRQC does > become a reality. That means > > looking at the system as a whole, not individuals. Notably, this means > that if the decisions we make > > result in a bitcoin where some people who are super worried about a CRQC > have migrated but everyone > > else hasn't, and a CRQC becomes an imminent reality, *we've failed*. In > such a world, bitcoin > > becomes largely value-less and the paranoid folks who migrated long ago > and paid for it have > > accomplished absolutely nothing. I hope we can at least agree on this > point. > > > > On 4/14/26 2:56 PM, conduition wrote: > >> Hi Matt, > >> > >>> Right but you didn't contend with my point at all, only ignored it. > Its great that you can move > >>> your coins into something so that your coins aren't stolen but...who > cares? If a huge % of > >>> outstanding bitcoin supply is being stolen that impacts you just as > much as if your own coins > >>> were being stolen! > >> > >> I don't think I ignored anything, but maybe I just didn't understand > your point. > >> > >> To me, your point seems to be (I'm summarizing here) that "Nobody will > migrate to P2MR before Q- > >> day because it is slightly worse than P2TR until Q-day". And your > conclusion is, in your own words: > >> > >>> Thus, ISTM the focus *has* to be on something that has minimal > drawbacks - not losing the script > >>> policy privacy of P2TR, low or no fee overhead, etc. > >> > >> This seems to imply you're arguing that at least some of those same > people (who wouldn't use P2MR) > >> WOULD migrate to P2TRv2, because it is exactly as good as P2TR until > Q-Day. > > > > Yes, exactly. > > > >> I respectfully disagree with this argument, and I gave my reasoning as > to why in my last reply. To > >> review: > >> > >> - P2MR is quantum-secure by default. > >> - P2MR is more efficient long-term. > > > > This assumes a CRQC. > > > >> - P2MR does not commit us to carrying legacy crypto cruft past its > shelf-life. > > > > Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard that > all wallets use forever. No > > matter what we do we carry the "cruft" of P2TR in Bitcoin forever (+/-), > P2TRv2 has literally zero > > additional cruft. > > > >> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have no > incentive to migrate either > >> way. > > > > See below > > > >> - The short-term efficiency difference in P2MR and P2TRv2 is a > negligible trade-off to anyone who > >> ISN'T a total quantum-skeptic. > >> - Fee-sensitive users are online and adaptive, and can use P2TR until > Q-day; They do not need > >> P2TRv2 any more than fee-insensitive users. > > > > I disagree very strongly with this. This would be true if everyone had > their own custom-built wallet > > that they designed to meet their goals exactly. In the real world people > pick wallets based on many > > other factors, and developers build wallets for many different users, > some of which may be fee > > sensitive and some of which may not be, all of whom will use the same > default configuration. > > > >> - P2MR has utility even if Q-day never comes. > > > > I disagree. The overall utility to the Bitcoin system of something like > P2TR is also the global > > default that is strongly baked in which results in > > > >> - Also, I failed to make this point in my last reply: P2MR and P2TRv2 > have the same privacy > >> profile AFAICT, assuming both commit to a hash-based fallback leaf > script. > > > > I don't see how this is true in practice. Maybe in a world where > everyone uses P2MR with a single > > left-hand leaf at depth one with a single EC schnorr key which is > musig2, but....come on. The value > > of taproot is that its design natively adds this *for free* to every > contracting protocol, and not > > only adds it for free but *forces* every contracting protocol to carry > at least some of the cost if > > they decline to do this. This results in a massive net privacy win > across the entire Bitcoin > > ecosystem, and I don't see how you can argue that these things are > equivalent in practice, just > > because they could in theory be used in a way where they are in theory. > > > >> Therefore, P2MR is the better long-term choice. > >> > >> If we assume Bitcoin will survive long into the future after CRQCs > appear, then we should favor > >> the best long-term design choices over short-term compromises. Thus, we > should deploy P2MR and NOT > >> deploy P2TRv2. > > > > Not only do I disagree with most of your points here, but I disagree > that we should be optimizing > > for a "long-term design" which we intend to be *the* design we use in > the face of an imminent CRQC. > > We already know we're not doing that - we're not using lattices or > isogenies or whatever we'll > > actually end up using because those things aren't ready. They likely > will be by the time a CQRC is > > imminent. If they aren't, we'll almost certainly be back to the drawing > board on witness discounts > > and whatever else which will mandate a new address format anyway. There > is basically zero chance > > that whatever we do today will be what we end up using "normally" in a > world with a CRQC. > > > >>> But what about someone who sees quantum computers as 90% FUD that > might happen eventually but > >>> won't for 50 years but still gets users nagging them about it and > support for importing some new > >>> seedphrase format that derives a SHRINCS key in addition to the EC > ones? That's much less of a > >>> straw man and way more realistic - and also a place where someone > might do the work (or, well, > >>> merge a PR if its done for them) but probably won't if they're > building a consumer wallet that is > >>> used by some to transact regularly (but, let's face it, used primarily > by some people who put > >>> some money in and then forgot about it for five years). > >> > >> Very specific. You're talking about wallet developers here, right? > Exchanges? Bitcoin businesses > >> in general etc? And you're saying that the people running these > businesses and building the > >> wallets - those who are being "nagged" to implement something that the > rest of the cryptographic > >> world has already starting rolling out in production [1] - You're > saying that a subclass of these > >> people - those who are "mostly" skeptical of quantum hype - WOULD > implement P2TRv2, but WOULDN'T > >> implement P2MR? > >> > >> It's debatable how big that subclass would be, especially given the > current landscape. > > > > I don't think this is "very specific" at all? In fact I think this is > the *dominant* case. By coin > > volume, yes, the biggest wallet is Coinbase's custody product. By wallet > count, the biggest wallet > > is probably something like Trust Wallet. Its trash, doesn't care about > Bitcoin, makes many terrible > > design decisions which are actively hostile to its users, and yet they > are the ones who actually > > decide in what way most bitcoin are stored! I don't know what their > particular view on quantum is, > > but my sense of most developers is that the view is generally "well, > it'll happen at some point, but > > its not totally urgent". Meanwhile, people are almost without question > going to nag some wallets for > > "quantum security" once its a thing. > > > > You might reasonably disagree with whether they would implement P2TRv2 > vs P2MR, I think its > > definitely a subtle argument, but I don't think you can reasonably > disagree that these are exactly > > the most important constituent here. > > > > > But even if one confidently sees CRQCs as 50 years away, then I'd > refer back to my earlier > > response, and argue that any such skeptical developer has no reason to > implement either P2MR or > > P2TRv2 today, apart from compatibility with other software which DOES > implement them. If "nagging" > > is the only motivation a dev or business owner has to implement a PQ > output type, then one need not > > distinguish between the two. They'd just implement whatever is > standardized to please their users, > > and carry on with their day.> > >> If I'm being a little more realistic, most wallet devs will follow > whatever is standardized just > >> to get more market share. I somehow doubt devs will turn up their noses > and say "it's not > >> efficient enough, I won't implement that even if a large chunk of my > customers are clamoring for it." > >> > >> I think this reveals the source of our disagreement. In your arguments, > you are placing a lot of > >> weight on the importance of pre-quantum fee-efficiency in the new > output type, so much so that you > >> seem to think devs would willingly ignore a potential existential > threat to save users a few sats > >> per transaction. > > > > It is far from only "pre-quantum fee-effeciency", its also the value for > the entire Bitcoin system > > of the privacy taproot offers. But I think the more important argument > specifically here is the > > question of what they will make the *default*. In a world with P2MR I > could absolutely see them > > implementing a P2MR option which you can opt into in the settings. That > fails to accomplish our > > goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but I > at least think that's > > somewhat less likely, but in any case better for the bitcoin system > overall if that's where we land. > > > >> But maybe look at it this way: > >> > >> - Whether quantum computers are 5, 10, 50 years or more away, anyone > who truly cares about a few > >> extra sats per TX can continue to use P2TR when actively transacting > pre-Q-Day, and use P2MR for > >> high-security cold storage. The result is mostly the same as if we > deployed P2TRv2. Yes, there is > >> some risk of being caught with your pants down on Q-day, but the same > is true of P2TRv2 because we > >> might not time the key-spend disabling follow-up fork correctly. > >> - Mining fees are a part of everyday life for Bitcoiners, and the > pre-quantum fee difference > >> between P2TR and P2MR is NOTHING compared to the fee spike we'll all > have to endure after Q-day, > >> no matter what fancy cryptography we may end up using by then. There > are far more important things > >> we can optimize. > >> > >>> Again, you ignore that the impact is global, not local. Yes, > quantum-skeptics have to be brought > >>> along over time if you want to have any hope of bitcoin actually being > relevant. > >> > >> Our job is not to proselytize and convince people that the quantum > threat is real, nor is it even > >> to encourage migration by design. Our job is to prepare an optimal > migration path in case the > >> threat is real. If CRQCs do appear, everyone will want to migrate to > PQC sooner or later. If they > >> do not, everyone moves on with their lives and the new output type > becomes a relic (in P2MR's > >> case, an occasionally useful one). > >> > >> Even if you feel your job IS to convince and migrate as many users as > possible, I would argue > >> it'll be hard to convince anyone to migrate to an address format that > isn't PQ-safe by default. > >> Bitcoiners trust code, not promises, and P2TRv2 is only PQ-safe if you > trust its promise of a > >> future soft fork, while its code would be PQ-vulnerable by default. And > the only benefit to > >> accepting this risk seems to be a trivial discount in fees pre-Q-day. I > don't speak for everyone > >> of course, but personally I'd rather keep my cold-storage coins on a > P2WSH address than on P2TRv2, > >> because at least then I know for sure a CRQC will have a hard time > stealing my coins regardless of > >> what upgrades the community does or doesn't deploy in the future. > > > > See intro. I don't really see how you can reasonably conclude that our > goal is only to enable a > > small subset of people to migrate. That way leas only to a total failure > of the bitcoin system. > > > >>> Sure, but any short term hash-based signature migration path is really > not intended as the final > >>> state anyway - if Bitcoin is stuck with only hash based signatures and > a CRQC exists in 20 years > >>> that's a pretty terrible outcome. Hopefully by the time a CRQC becomes > a real threat we have much > >>> more confidence in lattice-based systems (or whatever PQC is popular > then) and we can add > >>> whatever output type makes sense at that point. > >> > >> I agree about hash-based sigs not being the endgame. Though, this > doesn't mean P2MR isn't. We're > >> talking about output types here, not opcodes. I would argue P2MR > remains useful regardless of the > >> cryptography we use: lattice, isogeny, hash-based, multivariate, > whatever. Merkle trees have been > >> around for almost 50 years and seem hard to beat. > >> > >> For instance, we could reconstruct P2TR using isogenies [2], but would > we really want to? Using > >> today's witness discount levels, it would actually be MORE efficient > overall to spend with SQIsign > >> inside a P2MR tree, than it would be to use SQIsign to key-spend with > some hypothetical "Pay-to- > >> supersingular-curve" output type [^3]. I realize I'm kinda trashing my > own research by saying > >> this, but it shows how hard it is to beat P2MR, even if you can accept > new cryptographic > >> assumptions and the accompanying performance penalties. > > > > Yes, we probably would. Not because of efficiency but because a goal of > taproot is *privacy* while > > offering efficiency for the common (all-sign) case. That is generally > true across contracting > > protocols and makes things net-cheaper with a taproot-style system where > you hit the common case > > often. This is another reason why P2MR is quite a loss - > > > >> Even if we do someday find some novel cryptosystem which permits > rerandomization, and we design a > >> new output type as efficient and performant as P2TR but in a > post-quantum context, is the systemic > >> risk really worth saving a few vbytes - a small fraction of the entire > witness? If so, how many > >> decades or centuries need to pass for everyone else to share that > confidence? > >> > >> Personally I think we should learn our lesson from this P2TR debacle, > and encourage users to hide > >> public keys behind hash functions from now on, and to bolster riskier > algorithms with hash-based > >> fallback keys, so that we always have at least one layer of protection > between keys and any novel > >> cryptanalytic breakthroughs. Posting our plain pubkeys on-chain does > sometimes have fun benefits, > >> but the drawbacks are deadly serious. > >> > >> Until SHA256 collision resistance is broken, I'd expect P2MR is > probably the pinnacle of secure PQ > >> address formats, and even then we'd probably end up reimplementing P2MR > with some newer hash > >> function. Hopefully someday someone proves me wrong, but we can only > engineer with what we know > >> today, and today P2MR seems the most optimal conservative option for > long-term security and > >> cryptographic agility. > > > > As mentioned above if we end up in this situation we're almost certainly > going to be discussing a > > P2MRv2 with an additional witness discount, so... > > > >>> And with them they will take bitcoin's value... > >> > >> If you're really worried about a supply glut caused by CRQCs stealing > and dumping them, then > >> debating about P2TRv2 and P2MR is a distraction. IMO, most coins will > probably not migrate before > >> Q-Day regardless of what output types we deploy, because many coins are > held by dead hands, or by > >> living hands who just don't read the news. > >> > >> If this concerns you (and it concerns me too), then saving a few vbytes > per spend pre-Q-day is > >> trivial by comparison, and optimizing it will make little impact on the > integrity of the UTXO set > >> after Q-day. I would instead suggest you pursue the retroactive area of > research (rescue > >> protocols, quantum canaries, hourglass, exposure statistics, etc). This > is a domain where real > >> impact can be made to mitigate the risk of a supply glut when/if CRQCs > appear. Opportunities > >> abound. We would be glad of the help :) > > > > This is fair, and we should do this too, but I don't see how it implies > we should not also be > > concerned with ensuring maximum possible migration. > > > > > >> Anyways, I appreciate the good-spirited debate, but to save myself time > I don't think I'll > >> continue replying. I've laid out my argument for P2MR pretty clearly > and I feel it is as > >> convincing as I can make it. I'd be happy to acknowledge any > misunderstanding I may have had about > >> your earlier points in favor of P2TRv2. > > > > Fair enough. I continue to think we're talking past each other somewhat > but ultimately I think my > > concern is for ensuring bitcoin survives, while you're more concerned > with giving those who are > > concerned an option to feel warm and fuzzy :). > > > >> As to the original subject of the email thread, and Antoine's original > points, seems like we are > >> all in agreement. > > Indeed. > > > > -- 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/CAEM%3Dy%2BX7n4iHUHwBEfEggQQeM5FCU2Jt3CFrdZChNd2i3-CgQg%40mail.gmail.com. --00000000000085ad25064f80a42a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The proposal is P2MR with PQ sigs and no Schnorr add= ress reuse. Address reuse in this setting should be treated as security vul= nerability.

> As such= , P2MR with a EC-based key for short-term efficiency reasons has the same q= uantum security as P2TR or P2TRv2.

This is incorrect.=C2=A0

1. As long as the Schnorr pubkey has not been leaked by the wal= let. The wallet is PQ safe.

2. Even if the Schnorr pubkey has been leaked by the wallet, if the PQ = leaf hash is not publicly known it is safe against long exposure attacks.= =C2=A0

P2TR is **always*= * vulnerable to short and long exposure attacks. There is no better wallet = hygiene that can fix this.

You are comparing:=C2=A0

P2MR + PQ signatures:=C2=A0 A wallet messing up their implementation of= PQ safe transactions and introducing a vulnerability and weakening a subse= t of outputs. If implemented correctly 100% of the outputs are safe.
<= div dir=3D"auto">
vs.=C2=A0

P2TR: A design where 100% of outputs are vul= nerable even if the implementation is perfect.

<= /div>
These aren't the same thing at all, nor do they = provide the same security.=C2=A0

On Wed, Apr 15, 2026, 07:02 Matt Corallo <lf-lists@mattcorallo.com> wrote:
Oh, apologies, I was in a b= it of a rush yesterday and forgot the most important reason why P2MR
doesn't help at all - address reuse.

In practice the "long tail" of Bitcoin wallets (which, as noted b= elow are most of what we care
about) do strict address reuse. Mostly a consequence of address-based block= chain systems its become
an expected feature that the address displayed in a wallet is static and do= es not change. As such,
P2MR with a EC-based key for short-term efficiency reasons has the same qua= ntum security as P2TR or
P2TRv2.

Matt

On 4/14/26 4:04 PM, Matt Corallo wrote:
> I'm gonna top-post because I think we're too far in the weeds = and the high-level argument is getting
> lost. No, of course I do not thing that our job is to "convince&q= uot; any quantum skeptics. What is our
> job is making sure the *bitcoin system* is ready in case a CRQC does b= ecome a reality. That means
> looking at the system as a whole, not individuals. Notably, this means= that if the decisions we make
> result in a bitcoin where some people who are super worried about a CR= QC have migrated but everyone
> else hasn't, and a CRQC becomes an imminent reality, *we've fa= iled*. In such a world, bitcoin
> becomes largely value-less and the paranoid folks who migrated long ag= o and paid for it have
> accomplished absolutely nothing. I hope we can at least agree on this = point.
>
> On 4/14/26 2:56 PM, conduition wrote:
>> Hi Matt,
>>
>>> Right but you didn't contend with my point at all, only ig= nored it. Its great that you can move
>>> your coins into something so that your coins aren't stolen= but...who cares? If a huge % of
>>> outstanding bitcoin supply is being stolen that impacts you ju= st as much as if your own coins
>>> were being stolen!
>>
>> I don't think I ignored anything, but maybe I just didn't = understand your point.
>>
>> To me, your point seems to be (I'm summarizing here) that &quo= t;Nobody will migrate to P2MR before Q-
>> day because it is slightly worse than P2TR until Q-day". And = your conclusion is, in your own words:
>>
>>> Thus, ISTM the focus *has* to be on something that has minimal= drawbacks - not losing the script
>>> policy privacy of P2TR, low or no fee overhead, etc.
>>
>> This seems to imply you're arguing that at least some of those= same people (who wouldn't use P2MR)
>> WOULD migrate to P2TRv2, because it is exactly as good as P2TR unt= il Q-Day.
>
> Yes, exactly.
>
>> I respectfully disagree with this argument, and I gave my reasonin= g as to why in my last reply. To
>> review:
>>
>> - P2MR is quantum-secure by default.
>> - P2MR is more efficient long-term.
>
> This assumes a CRQC.
>
>> - P2MR does not commit us to carrying legacy crypto cruft past its= shelf-life.
>
> Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard tha= t all wallets use forever. No
> matter what we do we carry the "cruft" of P2TR in Bitcoin fo= rever (+/-), P2TRv2 has literally zero
> additional cruft.
>
>> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who hav= e no incentive to migrate either
>> way.
>
> See below
>
>> - The short-term efficiency difference in P2MR and P2TRv2 is a neg= ligible trade-off to anyone who
>> ISN'T a total quantum-skeptic.
>> - Fee-sensitive users are online and adaptive, and can use P2TR un= til Q-day; They do not need
>> P2TRv2 any more than fee-insensitive users.
>
> I disagree very strongly with this. This would be true if everyone had= their own custom-built wallet
> that they designed to meet their goals exactly. In the real world peop= le pick wallets based on many
> other factors, and developers build wallets for many different users, = some of which may be fee
> sensitive and some of which may not be, all of whom will use the same = default configuration.
>
>> - P2MR has utility even if Q-day never comes.
>
> I disagree. The overall utility to the Bitcoin system of something lik= e P2TR is also the global
> default that is strongly baked in which results in
>
>> - Also, I failed to make this point in my last reply: P2MR and P2T= Rv2 have the same privacy
>> profile AFAICT, assuming both commit to a hash-based fallback leaf= script.
>
> I don't see how this is true in practice. Maybe in a world where e= veryone uses P2MR with a single
> left-hand leaf at depth one with a single EC schnorr key which is musi= g2, but....come on. The value
> of taproot is that its design natively adds this *for free* to every c= ontracting protocol, and not
> only adds it for free but *forces* every contracting protocol to carry= at least some of the cost if
> they decline to do this. This results in a massive net privacy win acr= oss the entire Bitcoin
> ecosystem, and I don't see how you can argue that these things are= equivalent in practice, just
> because they could in theory be used in a way where they are in theory= .
>
>> Therefore, P2MR is the better long-term choice.
>>
>> If we assume Bitcoin will survive long into the future after CRQCs= appear, then we should favor
>> the best long-term design choices over short-term compromises. Thu= s, we should deploy P2MR and NOT
>> deploy P2TRv2.
>
> Not only do I disagree with most of your points here, but I disagree t= hat we should be optimizing
> for a "long-term design" which we intend to be *the* design = we use in the face of an imminent CRQC.
> We already know we're not doing that - we're not using lattice= s or isogenies or whatever we'll
> actually end up using because those things aren't ready. They like= ly will be by the time a CQRC is
> imminent. If they aren't, we'll almost certainly be back to th= e drawing board on witness discounts
> and whatever else which will mandate a new address format anyway. Ther= e is basically zero chance
> that whatever we do today will be what we end up using "normally&= quot; in a world with a CRQC.
>
>>> But what about someone who sees quantum computers as 90% FUD t= hat might happen eventually but
>>> won't for 50 years but still gets users nagging them about= it and support for importing some new
>>> seedphrase format that derives a SHRINCS key in addition to th= e EC ones? That's much less of a
>>> straw man and way more realistic - and also a place where some= one might do the work (or, well,
>>> merge a PR if its done for them) but probably won't if the= y're building a consumer wallet that is
>>> used by some to transact regularly (but, let's face it, us= ed primarily by some people who put
>>> some money in and then forgot about it for five years).
>>
>> Very specific. You're talking about wallet developers here, ri= ght? Exchanges? Bitcoin businesses
>> in general etc? And you're saying that the people running thes= e businesses and building the
>> wallets - those who are being "nagged" to implement some= thing that the rest of the cryptographic
>> world has already starting rolling out in production [1] - You'= ;re saying that a subclass of these
>> people - those who are "mostly" skeptical of quantum hyp= e - WOULD implement P2TRv2, but WOULDN'T
>> implement P2MR?
>>
>> It's debatable how big that subclass would be, especially give= n the current landscape.
>
> I don't think this is "very specific" at all? In fact I = think this is the *dominant* case. By coin
> volume, yes, the biggest wallet is Coinbase's custody product. By = wallet count, the biggest wallet
> is probably something like Trust Wallet. Its trash, doesn't care a= bout Bitcoin, makes many terrible
> design decisions which are actively hostile to its users, and yet they= are the ones who actually
> decide in what way most bitcoin are stored! I don't know what thei= r particular view on quantum is,
> but my sense of most developers is that the view is generally "we= ll, it'll happen at some point, but
> its not totally urgent". Meanwhile, people are almost without que= stion going to nag some wallets for
> "quantum security" once its a thing.
>
> You might reasonably disagree with whether they would implement P2TRv2= vs P2MR, I think its
> definitely a subtle argument, but I don't think you can reasonably= disagree that these are exactly
> the most important constituent here.
>
>=C2=A0 > But even if one confidently sees CRQCs as 50 years away, th= en I'd refer back to my earlier
> response, and argue that any such skeptical developer has no reason to= implement either P2MR or
> P2TRv2 today, apart from compatibility with other software which DOES = implement them. If "nagging"
> is the only motivation a dev or business owner has to implement a PQ o= utput type, then one need not
> distinguish between the two. They'd just implement whatever is sta= ndardized to please their users,
> and carry on with their day.>
>> If I'm being a little more realistic, most wallet devs will fo= llow whatever is standardized just
>> to get more market share. I somehow doubt devs will turn up their = noses and say "it's not
>> efficient enough, I won't implement that even if a large chunk= of my customers are clamoring for it."
>>
>> I think this reveals the source of our disagreement. In your argum= ents, you are placing a lot of
>> weight on the importance of pre-quantum fee-efficiency in the new = output type, so much so that you
>> seem to think devs would willingly ignore a potential existential = threat to save users a few sats
>> per transaction.
>
> It is far from only "pre-quantum fee-effeciency", its also t= he value for the entire Bitcoin system
> of the privacy taproot offers. But I think the more important argument= specifically here is the
> question of what they will make the *default*. In a world with P2MR I = could absolutely see them
> implementing a P2MR option which you can opt into in the settings. Tha= t fails to accomplish our
> goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but= I at least think that's
> somewhat less likely, but in any case better for the bitcoin system ov= erall if that's where we land.
>
>> But maybe look at it this way:
>>
>> - Whether quantum computers are 5, 10, 50 years or more away, anyo= ne who truly cares about a few
>> extra sats per TX can continue to use P2TR when actively transacti= ng pre-Q-Day, and use P2MR for
>> high-security cold storage. The result is mostly the same as if we= deployed P2TRv2. Yes, there is
>> some risk of being caught with your pants down on Q-day, but the s= ame is true of P2TRv2 because we
>> might not time the key-spend disabling follow-up fork correctly. >> - Mining fees are a part of everyday life for Bitcoiners, and the = pre-quantum fee difference
>> between P2TR and P2MR is NOTHING compared to the fee spike we'= ll all have to endure after Q-day,
>> no matter what fancy cryptography we may end up using by then. The= re are far more important things
>> we can optimize.
>>
>>> Again, you ignore that the impact is global, not local. Yes, q= uantum-skeptics have to be brought
>>> along over time if you want to have any hope of bitcoin actual= ly being relevant.
>>
>> Our job is not to proselytize and convince people that the quantum= threat is real, nor is it even
>> to encourage migration by design. Our job is to prepare an optimal= migration path in case the
>> threat is real. If CRQCs do appear, everyone will want to migrate = to PQC sooner or later. If they
>> do not, everyone moves on with their lives and the new output type= becomes a relic (in P2MR's
>> case, an occasionally useful one).
>>
>> Even if you feel your job IS to convince and migrate as many users= as possible, I would argue
>> it'll be hard to convince anyone to migrate to an address form= at that isn't PQ-safe by default.
>> Bitcoiners trust code, not promises, and P2TRv2 is only PQ-safe if= you trust its promise of a
>> future soft fork, while its code would be PQ-vulnerable by default= . And the only benefit to
>> accepting this risk seems to be a trivial discount in fees pre-Q-d= ay. I don't speak for everyone
>> of course, but personally I'd rather keep my cold-storage coin= s on a P2WSH address than on P2TRv2,
>> because at least then I know for sure a CRQC will have a hard time= stealing my coins regardless of
>> what upgrades the community does or doesn't deploy in the futu= re.
>
> See intro. I don't really see how you can reasonably conclude that= our goal is only to enable a
> small subset of people to migrate. That way leas only to a total failu= re of the bitcoin system.
>
>>> Sure, but any short term hash-based signature migration path i= s really not intended as the final
>>> state anyway - if Bitcoin is stuck with only hash based signat= ures and a CRQC exists in 20 years
>>> that's a pretty terrible outcome. Hopefully by the time a = CRQC becomes a real threat we have much
>>> more confidence in lattice-based systems (or whatever PQC is p= opular then) and we can add
>>> whatever output type makes sense at that point.
>>
>> I agree about hash-based sigs not being the endgame. Though, this = doesn't mean P2MR isn't. We're
>> talking about output types here, not opcodes. I would argue P2MR r= emains useful regardless of the
>> cryptography we use: lattice, isogeny, hash-based, multivariate, w= hatever. Merkle trees have been
>> around for almost 50 years and seem hard to beat.
>>
>> For instance, we could reconstruct P2TR using isogenies [2], but w= ould we really want to? Using
>> today's witness discount levels, it would actually be MORE eff= icient overall to spend with SQIsign
>> inside a P2MR tree, than it would be to use SQIsign to key-spend w= ith some hypothetical "Pay-to-
>> supersingular-curve" output type [^3]. I realize I'm kind= a trashing my own research by saying
>> this, but it shows how hard it is to beat P2MR, even if you can ac= cept new cryptographic
>> assumptions and the accompanying performance penalties.
>
> Yes, we probably would. Not because of efficiency but because a goal o= f taproot is *privacy* while
> offering efficiency for the common (all-sign) case. That is generally = true across contracting
> protocols and makes things net-cheaper with a taproot-style system whe= re you hit the common case
> often. This is another reason why P2MR is quite a loss -
>
>> Even if we do someday find some novel cryptosystem which permits r= erandomization, and we design a
>> new output type as efficient and performant as P2TR but in a post-= quantum context, is the systemic
>> risk really worth saving a few vbytes - a small fraction of the en= tire witness? If so, how many
>> decades or centuries need to pass for everyone else to share that = confidence?
>>
>> Personally I think we should learn our lesson from this P2TR debac= le, and encourage users to hide
>> public keys behind hash functions from now on, and to bolster risk= ier algorithms with hash-based
>> fallback keys, so that we always have at least one layer of protec= tion between keys and any novel
>> cryptanalytic breakthroughs. Posting our plain pubkeys on-chain do= es sometimes have fun benefits,
>> but the drawbacks are deadly serious.
>>
>> Until SHA256 collision resistance is broken, I'd expect P2MR i= s probably the pinnacle of secure PQ
>> address formats, and even then we'd probably end up reimplemen= ting P2MR with some newer hash
>> function. Hopefully someday someone proves me wrong, but we can on= ly engineer with what we know
>> today, and today P2MR seems the most optimal conservative option f= or long-term security and
>> cryptographic agility.
>
> As mentioned above if we end up in this situation we're almost cer= tainly going to be discussing a
> P2MRv2 with an additional witness discount, so...
>
>>> And with them they will take bitcoin's value...
>>
>> If you're really worried about a supply glut caused by CRQCs s= tealing and dumping them, then
>> debating about P2TRv2 and P2MR is a distraction. IMO, most coins w= ill probably not migrate before
>> Q-Day regardless of what output types we deploy, because many coin= s are held by dead hands, or by
>> living hands who just don't read the news.
>>
>> If this concerns you (and it concerns me too), then saving a few v= bytes per spend pre-Q-day is
>> trivial by comparison, and optimizing it will make little impact o= n the integrity of the UTXO set
>> after Q-day. I would instead suggest you pursue the retroactive ar= ea of research (rescue
>> protocols, quantum canaries, hourglass, exposure statistics, etc).= This is a domain where real
>> impact can be made to mitigate the risk of a supply glut when/if C= RQCs appear. Opportunities
>> abound. We would be glad of the help :)
>
> This is fair, and we should do this too, but I don't see how it im= plies we should not also be
> concerned with ensuring maximum possible migration.
>
>
>> Anyways, I appreciate the good-spirited debate, but to save myself= time I don't think I'll
>> continue replying. I've laid out my argument for P2MR pretty c= learly and I feel it is as
>> convincing as I can make it. I'd be happy to acknowledge any m= isunderstanding I may have had about
>> your earlier points in favor of P2TRv2.
>
> Fair enough. I continue to think we're talking past each other som= ewhat but ultimately I think my
> concern is for ensuring bitcoin survives, while you're more concer= ned with giving those who are
> concerned an option to feel warm and fuzzy :).
>
>> As to the original subject of the email thread, and Antoine's = original points, seems like we are
>> all in agreement.
> Indeed.
>

--
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/CAEM%3Dy%2BX7n4iHUHwBEfEggQQeM5FCU2Jt3CFrdZChNd2i3-CgQg%= 40mail.gmail.com.
--00000000000085ad25064f80a42a--