From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 13:41:40 -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 1wD73K-00027d-Qc for bitcoindev@gnusha.org; Wed, 15 Apr 2026 13:41:40 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-42322062cf3sf10752087fac.2 for ; Wed, 15 Apr 2026 13:41:37 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776285690; cv=pass; d=google.com; s=arc-20240605; b=g8aNesdorZb+v24dNnRY4R3icpwNEG8717wCcikeyKidsMzu9r1W8syWrNwrb9bdOD Ckc27cKsz80BugjWV41M3BET5adSFc10BRbihl/OcKduQGhUJZKVVtblbS05H9otQJy7 l/RNOuoJU7VCi+FhOMd6736jHJKhG3gXbe0l9u8nnirCIJm0B7AItRc93/qe6vRFWpP5 o+aUrIh/a4iJSVtWBCg6bkrvuJm3F7PkAagB5DEXqCy6zl8+ED9U7WCj7ZS0xr5ROQY2 nZcJDvMoohC3vrOv6SDjyE6atI8FiYwnchXPIdhWpgdSPbiBd+5mYOQFQU8653370AQ/ 3Elg== 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=yTFzlfFXM3Pd4pzQ9k00Ooxna3iRKKt+h5V6TK48rw4=; fh=nCqlrudx/HLYSIPc3RxzJNcDH0Kh/aM9I45ekhO5rDk=; b=b2BgNMyOhWwTbRT7i9r0/Hodhaaj+hdSCkHl1HHoZOvaJagVqjBoMGNlO/kT5FGHq3 czdqFSZUGxkPZSsxhz4af/KIPpxaKcbiklL3Ef4rrWyfnRqEsOELlptisTMoBLy7BoAa lH5bLhzPod/8aT0IhtxKD+xeTx3jSczl1bE4tYaunizgiAJlfM2gGf/xUo2NgBSAIpcs wUR2pgrZoWRIaWp05tYcnf8s8jL4/4uBye0BYUwCpHbtkwwYN38mdmJCW0kVPa9GgA4A HQy78R/4Pj3G8lpO9E4FT9got0Ttw0A049wMwD3L91gOw20wFQlSOvitHetTCckbgxj4 umDg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=joy9bId+; arc=pass (i=1); spf=pass (google.com: domain of 734402368n@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=734402368n@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=1776285690; x=1776890490; 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=yTFzlfFXM3Pd4pzQ9k00Ooxna3iRKKt+h5V6TK48rw4=; b=bGcE6GGpNcirUivdy1hOFXWpmmuzJHM4rKfXhS8LS1lPv61t1wJIPvfaCcFtYdbAL5 3idGhj7y4JsPmN8fPf4OOy2CSCwh2qnH/Kn3pL3XtpbD271+QnF5mHAMj08LzXfGdGu9 uLnbxMJSSif5/vtMd6tHMU8hG8OhOUb08mprCX8AMyjXVUTgZ4M/Z1uxm4h+iAQJhbX7 nk5rL8xT4QTfCfqquQQvoCWIZukpO9cMcUvVB+ex7dirOF8QOYqPky37nmdu7foCN4gk evnogRAVNH4lR9O6xZ4Cz5JDMwAmztMwp+EgzFdApdB56tTBJyqgbodGxZgx0PBna1vy Ipjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776285690; x=1776890490; 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=yTFzlfFXM3Pd4pzQ9k00Ooxna3iRKKt+h5V6TK48rw4=; b=c9bphRJZbsCNpuOOJI+SpphzeW3p37eOj0to9eozu/mRNQbMRgME2LiRjTTU8SbP3R tEGcUeJPJa9qaAKKRhsXxw+adN3IFcvGI0+FI/ONeQUtI8BySbqpwHzxnsOXPxjiMp/5 66JzgElEuIRmjJ/FKtqEQLvhIM3PbJRBfKLg1emQHQp3GIBfV9P4J747FJon+PwkFHo8 KSlvstBd75Gj93i0rZSlM4B8kLcCXNGtnlRxeYRmH57IH+G0UuwGORRf/7JkjmY5h0Ei EyM4nFgRoppAojD4uCDvv8ikx9jG9Ezaxu5iqlcYR7StzHHfJnpxMiw0O78Ks0WuBfk5 9hZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776285690; x=1776890490; 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=yTFzlfFXM3Pd4pzQ9k00Ooxna3iRKKt+h5V6TK48rw4=; b=mlZ6+5ACjqKr+XTXFzqi8OMQe1Q6pZtQUBNZKok/xlnl84oeqCBTI2iL6TnhNp6ayo +gfD56HoAMc5buoC9jFMhfWlRHA+53Q+RfTCY9kuGQ+dBMr1p69irW1pdONQbabQwvlJ LHgtz4XUXgSvy0fKZKoX5/MpPOiyYEHiwp6dc83c+U2yUQbMOX/D1Ht4jF+66zgK6rSW 1Puk9g1s2Whsj/fiDi7Led4KTqZuG+eYbxzUZYgbB2NpdfjOFQEYnWq0YRaciO4QSb0t r0FOJXXtBKOJcdMMGxGlqF6X+81Q5WaBQB1e+WcuegGSmMHJ6i1fmYb+tLO/i/XAXA7w mJxg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ8Q1gT+v7O5BKVoFVDTEu7zHfJzg3tSx+pASR3yc7I/NznmB16h3wjz4YlroVX85sJ3E0fvK9qvnFcS@gnusha.org X-Gm-Message-State: AOJu0YxQM/d1vOSD9uoRmbWSJj24n059fdijMR27t3pKFkzN8bUOTnXV jvh0nKxqtj3aZdQuEit2sp1Ugxwiw/NdqYaagcr9InBpKE3zNZNxZ3RA X-Received: by 2002:a05:6870:8a2c:b0:417:233a:d730 with SMTP id 586e51a60fabf-423e0e16d60mr13244612fac.15.1776285689631; Wed, 15 Apr 2026 13:41:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKDBOcPczosI8MO2/m30aoWdAgX8oWwGkSiigSdLwewRg==" Received: by 2002:a05:6870:4d4:b0:41c:583a:b50 with SMTP id 586e51a60fabf-4280c61dc27ls87332fac.1.-pod-prod-04-us; Wed, 15 Apr 2026 13:41:24 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/QJilksndtYx9HCTSY1T7soIJzVX2RsSblgLZzmlUOmZ5dfmM//ReoUu2aBun2EmUYCD3PUSPMIyh7@googlegroups.com X-Received: by 2002:a05:6808:6a83:b0:466:feb1:5f79 with SMTP id 5614622812f47-478a18195camr12085779b6e.50.1776285684006; Wed, 15 Apr 2026 13:41:24 -0700 (PDT) Received: by 2002:ab3:6544:0:b0:2f4:51e0:7d3e with SMTP id a1c4a302cd1d6-2f72e3499c1msc7a; Wed, 15 Apr 2026 13:16:18 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/GPKL4XXhxpRl8zZEr2HcQvrvKW7PxeHk2VgKd2Nx4fc968a28MHGxqXQykBkiISBAKSq/giP1D/y0@googlegroups.com X-Received: by 2002:a2e:9c95:0:b0:38e:8902:7a7f with SMTP id 38308e7fff4ca-38e8902834cmr25377101fa.13.1776284176413; Wed, 15 Apr 2026 13:16:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776284176; cv=pass; d=google.com; s=arc-20240605; b=kkfDCuALu5jajkhuVPwr1Pl+SWOHB756OFiXTlIHkVlErTi5k/H3/g+jIIigzyskDL 0mQYAijiECdQBl1vveRDZEGyUkvBnB3a3WL4yRHGguDOKJeabc8Vx3AQx6sf1+eO6+zt lInyR117DA6/UbsibiW0EwszCCQxlwXDKQKogLkFkPnkp7xi62TI+WFGS99+gVRU6aG6 mrGqZ5PND44Pe09M2EGMvoJNLCE6561WsbORNLcVfpHfcxuE5O6mOMDD00JAaB2dy0M7 WQHdR7npdog+EetSO+0dp3YntyRrcJeh0S4bM8EHzSkQP/fXcwprHVT5BqpSkIKuqtkV zyxw== 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=c+ox2asHeaY91tTcoynTsOrU0GpJeK1aJIh27nmNTp8=; fh=rv2Ml9F/M5YvHWN6SoOzLsWBwQVtm787qzfyJ0FvwQs=; b=h76vVi+kkPhp37M76OG67M1aSSSNjUGyomZCnxzmRmL6XeGg0FNpiVDWLPe/oihefL w3foO+4XxBvnBM5Gasawy4WEd8HSMa/jD8WVmhk914OWRIHq38eC1AK18+SjSrMARdQR zOvRZP5Yu3O1aGWTP8zGgeqyjNmJdYFWmxOfY5SIfl3v7Sj+wREq8a2D0iUpFd4Fmt2g a3ptba66l2g6onNzoVNi7/CHbFV9Bvvh4XsVLxzgmYx6s2PZjdwiLxR2ciqxaBZCbgk3 tk4Xs8gvGIuzszlvqKRX+tuU/4cTOHOmhjkDjLDttHxNv6BV6RBQLrVvL7kiBf/j1tFl dy2w==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=joy9bId+; arc=pass (i=1); spf=pass (google.com: domain of 734402368n@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=734402368n@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com. [2a00:1450:4864:20::12a]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-38e9eb6307fsi578631fa.7.2026.04.15.13.16.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 13:16:16 -0700 (PDT) Received-SPF: pass (google.com: domain of 734402368n@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) client-ip=2a00:1450:4864:20::12a; Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5a40b2d268bso845880e87.3 for ; Wed, 15 Apr 2026 13:16:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776284176; cv=none; d=google.com; s=arc-20240605; b=jhFlTS1RUv0ksXwK1AP/uvvaYkVdEBDGvG/gwAPiN0lKvNvlvM1xwbJQ1j8szM4npN ideqGRL/crFN+s+Om3covZNamQ1rykariEXE3Wgp2xA76u3v/umLnVAT2qeEHq5/f1Cb eigYwz6WxiM8wD/J6aI/osr5bE1jNndRH9G9/QBIK8Tts+kPdUSOFM8ZaHwVGanntbrG kws/4I0Jl1x4tz3PRlOMhxk4LeWQCvpUoFBGT6ayz9FKGwMOBmAoMpzyrbtaKQwqKm4s Bm4ytD7kl/as7eNgd18f3BZVP4p/wbhsFG1XtDqugsB6l2ZfBYNXVHQhicqSG/5Tf5AT 7ThA== 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=c+ox2asHeaY91tTcoynTsOrU0GpJeK1aJIh27nmNTp8=; fh=rv2Ml9F/M5YvHWN6SoOzLsWBwQVtm787qzfyJ0FvwQs=; b=jL4si5WMrrELxwrgPpnYwx8HFCcOR+o/fQ4nSlSfB7EK5neLzMO7BFePaGn8kJ8ANr DNAmrQUWIlfGdGbIjCY9yqGuIPWSP3rJpsexb9vCPuDKoN/jbnMrq7zdBEF4WiqkOpHa m9IMyoQXVkDBr1/e72xfoC42YMHJSTKF6dy4NZ/rDLud/MI0xhsnwWpaqPB1NK2c+rzE pT3968iUFLaVEmyu9wcErslNMFrjyPsAWtqpTVNAWCTyRZFgiAYXyoFt1f8m54/Vs6in C1Ri5e7gRQXuoUUwx706v4wbNZMxGnxXWcnpylziw6UTd/X7vS2Bsfa2zRQGp4ySRL59 y2kw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ+h8IzscqEbcIUEyOXin/ETxlOK3ds3SF8+poB71R+gdnG0DZuysBjdWHwjJU/+eUQxC15zGvtmucsD@googlegroups.com X-Gm-Gg: AeBDieskaIG+nkOFzWytvmmcBfmGdtmsfKMJI4ypYkjKLe308lJB5+jVWToof9FwEv8 HBL8KEvhT2wBNbBGEaG/jFPuDlPQ7ax1NPbG0Ca3p9ZXYQ/i8DcHpufe/193NYLwV1N2fFv+bHR NF5P9zzv8njaVHPblg6BaEXlUqGDiYOJbUlZdHHLULaLZRyhnhng3dBrxFfhj9yOJnIPsk60+6P bpsovIRry7gEAPRNnWNS4jNdnLQnCCykCfGRrH4TGAl+YW5/li09vgvMkRcLR9ExVfpxzRQBstJ TPYzPWyiWPEh30Pqng== X-Received: by 2002:a05:6512:401f:b0:5a4:3b6:94ea with SMTP id 2adb3069b0e04-5a403b695fbmr3671110e87.23.1776284175539; Wed, 15 Apr 2026 13:16:15 -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> <459bd81c-584f-4adf-9112-bb733d381c99n@googlegroups.com> <3PuZlWnztVG7MIcejfM8UHiKB9GNqaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYUND3Pm-fHnBcv9QXdHKasHjgacNrE-K-o=@protonmail.com> In-Reply-To: From: =?UTF-8?B?2YXYrdmF2K8g2KfZhNmI2LXYp9io2Yo=?= <734402368n@gmail.com> Date: Wed, 15 Apr 2026 23:16:02 +0300 X-Gm-Features: AQROBzCdZIz0LlNB0r4PHhI3k0Ey5Go_jC-Fkxejz5rMn2VMPnVOuws-Z_oAHEA Message-ID: Subject: Re: [bitcoindev] In defense of a PQ output type To: Erik Aronesty Cc: Antoine Poinsot , Antoine Riard , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000004da169064f8563c6" X-Original-Sender: 734402368n@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=joy9bId+; arc=pass (i=1); spf=pass (google.com: domain of 734402368n@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=734402368n@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: 2.3 (++) --0000000000004da169064f8563c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, As a developer building localized payment integrations and automated systems, I=E2=80=99ve been following this discussion on P2MR and BIP360 clo= sely. I=E2=80=99d like to add a perspective from the "application layer" side. While I appreciate the rigorous security of P2MR, I lean towards Matt=E2=80= =99s point regarding adoption. For developers in regions where infrastructure and fee-sensitivity are major factors, a "forced" or highly complex migration could lead to fragmentation. If the barrier to entry for Quantum-safe addresses is too high=E2=80=94either in terms of script comple= xity or transaction fees=E2=80=94many users will simply stay on legacy formats, lea= ving the network vulnerable. I believe the focus should be on "Invisible Security." If BIP360 can offer a seamless transition where the complexity is handled by libraries, it would be much more effective than a mandatory shift that might alienate non-technical users. Looking forward to hearing more on how we can balance this "sovereignty" with practical usability. Best regards, Mohammed Al-Wasabi =D9=81=D9=8A =D8=A3=D8=B1=D8=A8=D8=B9=D8=A7=D8=A1=D8=8C =D9=A1=D9=A5 =D8=A3= =D8=A8=D8=B1=D9=8A=D9=84=D8=8C =D9=A2=D9=A0=D9=A2=D9=A6 =D9=81=D9=8A =D9=A1= =D9=A0:=D9=A2=D9=A3 =D9=85=D8=8C =D9=83=D8=AA=D8=A8 Erik Aronesty : > 100% we shouldn't be forcing hybrid on people. but it should be > supported preferred and "Default". this is RFC language. "quantum secur= e > protocols should use hybrid signature schemes" etc > > On Wed, Apr 15, 2026 at 12:07=E2=80=AFPM 'Antoine Poinsot' via Bitcoin De= velopment > Mailing List wrote: > >> Hi, >> >> I don't think in this thread the question is raised to enable to secure >> one's coin under double classic cryptogrraphic assumption and PQ >> assumption, i.e "hybrid" security >> >> >> Yes. I'm assuming that a hash-based scheme would be reasonable to >> introduce on its own (as opposed to more fancy schemes). But i'm also no= t >> sure it's possible to guarantee that hybrid security is used, since a us= er >> can always choose to use a dummy secret for one of the two signature >> challenges. >> >> Best, >> Antoine >> On Friday, April 10th, 2026 at 9:28 PM, Antoine Riard < >> antoine.riard@gmail.com> wrote: >> >> Hi, >> >> Thanks for rolling up the ball forward on this topic. >> >> I'm +1 on disentangling the introduction of a PQ safe scheme from >> the more fuzzy idea of freezing coins based on output types. >> >> Even the idea of "freezing" coins, the goal of why is still unclear. >> It sounds the motivations are blurred between ensuring coins are >> staying in the hands of their legitimate owners, a goal I can share >> but I don't see how freezing help here, from the more loose idea of >> ensuring there is no crash in the bitcoin price vs fiat in the face >> of CQRC-enabled attacks, which sounds to me a pandora box. >> >> Even in this eventuality, if there is a general concern on the network >> disruptions that might be induced by CRQC attacks (e.g chain instability >> due to reorgs by competing CRQC attackers), I believe there are still >> intermediary technical solutions, e.g rate-limiting the number of output >> types that can be spent by difficulty periods to minimize the risks of >> disruptions, while not technically confiscating anyone coin. >> >> Back to introducing a PQ safe scheme, I don't think in this thread >> the question is raised to enable to secure one's coin under double >> classic cryptogrraphic assumption and PQ assumption, i.e "hybrid" >> security (more for the risk of a cryptanalysis break of any PQ safe >> scheme that would be introduced at the consensus-level). It might >> more a real engineering burden, though I believe it's giving more >> flexibility for technically savy bitcoin users to secure one's stack. >> >> Anyway, I think it's good to have a scheme ready early on given >> the development cycle to have stuff available on HW wallets and >> HSMs. E.g BIP32 support was added in 2018 on Gemalto's HSM i.e a >> mere 6 years after the standard introduction (which is not that >> bad given that blockchain were recents actors in the hardware >> industry at the time). >> >> Best, >> Antoine >> OTS hash: 6d7c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaedee9458f6= c0 >> >> Le Saturday, April 11, 2026 =C3=A0 2:06:55=E2=80=AFAM UTC+1, Hayashi a = =C3=A9crit : >> >>> Hi Conduition, Matt and Ethan >>> >>> > an ownership proof used for non-BIP32 hashed addresses >>> I=E2=80=99m concerned that shared xpubs could become an attack vector i= f we >>> allow ZKP of hash preimages for unused addresses (excluding P2PK/P2TR). >>> Given that, are there alternative methods for publishing proof of owner= ship >>> that we should consider? >>> >>> >>> It seems the current default stance is effectively "do not freeze," >>> because preserving the status quo is the only path if we cannot reach >>> consensus (and if we do not chose hardfork). However, by formalizing a >>> freezing plan=E2=80=94either through a new BIP or an amendment to BIP36= 1=E2=80=94I believe >>> we gain several strategic advantages: >>> >>> *Clarity on P2MR discussion*: It would clarify the ongoing P2MR and >>> P2TR discussions by defining how P2TR will be treated (I personally pre= fer >>> P2MR). >>> >>> *Incentivized Migration*: Establishing a clear future plan encourages >>> users to migrate to BIP32-hardened addresses with longer time period wh= ich >>> eventually maximize recovery. >>> >>> *Advance Planning for CRQCs*: We will not panic on the edge case >>> scenario that CRQCs arrive earlier than PQ signature scheme adoption or >>> when we find out we cannot allow enough migration period after PQ signa= ture >>> scheme adoption (I strongly believe we also have to prepare for this >>> future). >>> >>> While further R&D is required, we likely have sufficient information to >>> formalize a framework now. We can also disable or modify the defined >>> freezing plan if the threat landscape changes significantly. >>> >>> Hayashi >>> 2026=E5=B9=B44=E6=9C=8811=E6=97=A5=E5=9C=9F=E6=9B=9C=E6=97=A5 8:33:54 U= TC+8 Ethan Heilman: >>> >>>> > IMO even something like P2MR's additional cost will strongly >>>> discourage adoption. >>>> >>>> I don't agree. >>>> >>>> Over time as quantum attacks become a bigger and bigger concern for >>>> holders, wallets will want to show that they can offer security agains= t >>>> CRQCs. This is especially true for wallets focused on high value Bitco= in >>>> outputs. Even if someone thinks there is only a 2% chance they lose al= l >>>> their Bitcoin because of a quantum computer, that 2% chance will keep = them >>>> up at night. >>>> >>>> P2MR would have 17.25 more vBytes, an 11% overhead. >>>> >>>> P2TR 1 input, 2 output - key path spend. 154 vbytes >>>> P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output >>>> with two leafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes >>>> >>>> I'm stacking the deck against P2MR here. Under some circumstances P2MR >>>> has lower fees than P2TR. >>>> >>>> It is hard to imagine someone holding significant quantities of Bitcoi= n >>>> not wanting to pay 50 sats to ensure their Bitcoin isn't stolen by a >>>> quantum computer. >>>> >>>> >>>> On Fri, Apr 10, 2026 at 7:10=E2=80=AFPM Matt Corallo >>>> wrote: >>>> >>>>> >>>>> >>>>> On 4/10/26 1:03 PM, conduition wrote: >>>>> >> But as mentioned above I do not see why any addition of hash based >>>>> signatures to tapscript should require any kind of community consensu= s on >>>>> future disablement of insecure spend paths >>>>> > >>>>> > I think Antoine's point here is that if we introduce a PQC opcode t= o >>>>> tapscript but choose NOT to deploy P2MR, and then encourage people to= use >>>>> that opcode in P2TR script leaves, then we are locking ourselves into= the >>>>> assumption that the community will later disable P2TR key-path spendi= ng - >>>>> otherwise those addresses will be compromised by a CRQC and the PQC l= eaf >>>>> script is useless. >>>>> >>>>> Right, but you cut my quote off and appear to be responding to a poin= t >>>>> I didn't make? The very next >>>>> few words that you cut were "not only is it a likely prerequisite for >>>>> an alternative output type". >>>>> Yes, we have to figure out what kind of output type we want, whether >>>>> P2MR (360), P2TRv2 or just >>>>> P2TR. There are strong arguments for each. But none of that has any >>>>> bearing on whether we add hash >>>>> based signatures to tapscript. We have to add hash based signatures t= o >>>>> tapscript first no matter >>>>> what output type we want! >>>>> >>>>> >> Adding a PQ output type which no one will use (eg one where use of >>>>> the hash-based signature is mandatory, which drives fees up hugely an= d has >>>>> all the drawbacks you mention) is not a risk mitigation strategy - it= does >>>>> not materially allow for any migration and doesn't accomplish much of >>>>> anything. But as mentioned above I do not see why any addition of has= h >>>>> based signatures to tapscript >>>>> > >>>>> > I don't think anyone is suggesting deployment of an output type wit= h >>>>> mandatory hash-based signatures. That would be borderline unusable fo= r >>>>> anyone but large companies and wealthy elites. >>>>> > >>>>> > Every decent proposal I've seen has suggested using PQC in tandem >>>>> with ECC across multiple tapscript leaves, whether in some bastardize= d >>>>> variant of P2TR, or in BIP360's P2MR. >>>>> >>>>> IMO even something like P2MR's additional cost will strongly >>>>> discourage adoption. We have a very >>>>> long history with Bitcoin wallets not only refusing to adopt new >>>>> features but actively making some >>>>> of the worst possible design decisions from a Bitcoin PoV. IMO we >>>>> should very strongly not give them >>>>> any excuse, even if that's just fees. >>>>> >>>>> 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, sen= d >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/765490aa-5df3-4619-86cc-= 17570b6d3e99%40mattcorallo.com >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/459bd81c-584f-4adf-9112-bb7= 33d381c99n%40googlegroups.com >> . >> >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/3PuZlWnztVG7MIcejfM8UHiKB9G= NqaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYUND3Pm-fHnBcv9QXdHKasHjgacNr= E-K-o%3D%40protonmail.com >> >> . >> > -- > 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/CAJowKgJeQA0AkDMYHiobjvk%3DK= uWV38yT6KyaSiC0ZVvH1Q9zvg%40mail.gmail.com > > . > --=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/= CABgZVQDUPc0QR3qRkJi3oMG27vk5%3D6HS6M6wEHcDJjJYt1k_Rg%40mail.gmail.com. --0000000000004da169064f8563c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,

As a developer building localized payment integrations and automated sys= tems, I=E2=80=99ve been following this discussion on P2MR and BIP360 closel= y. I=E2=80=99d like to add a perspective from the "application layer&q= uot; side.

While I appreciate the rigorous security of P2MR, I lean towards Matt=E2= =80=99s point regarding adoption. For developers in regions where infrastru= cture and fee-sensitivity are major factors, a "forced" or highly= complex migration could lead to fragmentation. If the barrier to entry for= Quantum-safe addresses is too high=E2=80=94either in terms of script compl= exity or transaction fees=E2=80=94many users will simply stay on legacy for= mats, leaving the network vulnerable.

I believe the focus should be on "Invisible Security." If BIP3= 60 can offer a seamless transition where the complexity is handled by libra= ries, it would be much more effective than a mandatory shift that might ali= enate non-technical users.

Looking forward to hearing more on how we can balance this "soverei= gnty" with practical usability.

Best regards,

Mohammed Al-Wasabi



=D9=81=D9=8A =D8=A3=D8=B1=D8=A8=D8=B9=D8=A7=D8=A1=D8=8C =D9= =A1=D9=A5 =D8=A3=D8=A8=D8=B1=D9=8A=D9=84=D8=8C =D9=A2=D9=A0=D9=A2=D9=A6 =D9= =81=D9=8A =D9=A1=D9=A0:=D9=A2=D9=A3=C2=A0=D9=85=D8=8C =D9=83=D8=AA=D8=A8 Er= ik Aronesty <erik@q32.com>:
100% we shouldn't be forcing hybr= id on people.=C2=A0 =C2=A0but it should be supported preferred and "De= fault".=C2=A0 this is RFC language.=C2=A0 "quantum secure protoco= ls should use hybrid signature schemes" etc

On Wed, Apr 15, 2026 at 12:= 07=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Development Mailing Lis= t <bitc= oindev@googlegroups.com> wrote:
Hi,

I don't think in this thread=C2=A0the question= is raised to enable to secure one's coin under double=C2=A0classic cry= ptogrraphic assumption and PQ assumption, i.e "hybrid"=C2=A0secur= ity
=20
=20
=20

Yes. I'm assuming = that a hash-based scheme would be reasonable to introduce on its own (as op= posed to more fancy schemes). But i'm also not sure it's possible t= o guarantee that hybrid security is used, since a user can always choose to= use a dummy secret for one of the two signature challenges.

Best,
Antoine
On Friday, April 10th, 2026 at 9:28 PM, Antoine Riard <antoine.riard@gmail.c= om> wrote:
Hi,

Thanks for rolling up the ball forward on this topic= .

I'm +1 on disentangling the introduction of a PQ safe scheme f= rom
the more fuzzy idea of freezing coins based on output types.

= Even the idea of "freezing" coins, the goal of why is still uncle= ar.
It sounds the motivations are blurred between ensuring coins are
= staying in the hands of their legitimate owners, a goal I can share
but = I don't see how freezing help here, from the more loose idea of
ensu= ring there is no crash in the bitcoin price vs fiat in the face
of CQRC-= enabled attacks, which sounds to me a pandora box.

Even in this even= tuality, if there is a general concern on the network
disruptions that m= ight be induced by CRQC attacks (e.g chain instability
due to reorgs by = competing CRQC attackers), I believe there are still
intermediary techni= cal solutions, e.g rate-limiting the number of output
types that can be = spent by difficulty periods to minimize the risks of
disruptions, while = not technically confiscating anyone coin.

Back to introducing a PQ s= afe scheme, I don't think in this thread
the question is raised to e= nable to secure one's coin under double
classic cryptogrraphic assum= ption and PQ assumption, i.e "hybrid"
security (more for the r= isk of a cryptanalysis break of any PQ safe
scheme that would be introdu= ced at the consensus-level). It might
more a real engineering burden, th= ough I believe it's giving more
flexibility for technically savy bit= coin users to secure one's stack.

Anyway, I think it's good = to have a scheme ready early on given
the development cycle to have stuf= f available on HW wallets and
HSMs. E.g BIP32 support was added in 2018 = on Gemalto's HSM i.e a
mere 6 years after the standard introduction = (which is not that
bad given that blockchain were recents actors in the = hardware
industry at the time).

Best,
Antoine
OTS hash: 6d7= c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaedee9458f6c0

Le Saturday, Ap= ril 11, 2026 =C3=A0 2:06:55=E2=80=AFAM UTC+1, Hayashi a =C3=A9crit :
Hi Conduition, Matt and Ethan

> an ownership = proof used for non-BIP32 hashed addresses
I=E2=80=99m concerned that sha= red xpubs could become an attack vector if we allow ZKP of hash preimages f= or unused addresses (excluding P2PK/P2TR). Given that, are there alternativ= e methods for publishing proof of ownership that we should consider?

It seems the current default stance is effectively "do not freeze= ," because preserving the status quo is the only path if we cannot rea= ch consensus (and if we do not chose hardfork). However, by formalizing a f= reezing plan=E2=80=94either through a new BIP or an amendment to BIP361=E2= =80=94I believe we gain several strategic advantages:

Clarity on = P2MR discussion: It would clarify the ongoing P2MR and P2TR discussions= by defining how P2TR will be treated (I personally prefer P2MR).

Incentivized Migration: Establishing a clear future plan encourages us= ers to migrate to BIP32-hardened addresses with longer time period which ev= entually maximize recovery.

Advance Planning for CRQCs: We wi= ll not panic on the edge case scenario that CRQCs arrive earlier than PQ si= gnature scheme adoption or when we find out we cannot allow enough migratio= n period after PQ signature scheme adoption (I strongly believe we also hav= e to prepare for this future).

While further R&D is required, we= likely have sufficient information to formalize a framework now. We can al= so disable or modify the defined freezing plan if the threat landscape chan= ges significantly.

Hayashi
2026=E5=B9=B44=E6=9C=8811=E6=97=A5=E5=9C= =9F=E6=9B=9C=E6=97=A5 8:33:54 UTC+8 Ethan Heilman:
>=20 IMO even something like P2MR's additional cost will strongly discourage= adoption.

I don't agree.

Over tim= e as quantum attacks become a bigger and bigger concern for holders, wallet= s will want to show that they can offer security against CRQCs. This is esp= ecially true for wallets focused on high value Bitcoin outputs. Even if som= eone thinks there is only a 2% chance they lose all their Bitcoin because o= f a quantum computer, that 2% chance will keep them up at night.

P2M= R would have 17.25 more vBytes, an 11% overhead.

P2TR 1 input, 2 out= put - key path spend. 154 vbytes
P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output with two l= eafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes

I'm = stacking the deck against P2MR here. Under some circumstances P2MR has lowe= r fees than P2TR.

It is hard to imagine someone holding significant = quantities of Bitcoin not wanting to pay 50 sats to ensure their Bitcoin is= n't stolen by a quantum computer.


On Fri, Apr 10, 2026 at 7:10=E2=80=AFPM Matt Corallo <lf-l...@mattcorallo.com> wrote:


On 4/10/26 1:03 PM, conduition wrote:
>> But as mentioned above I do not see why any addition of hash based= signatures to tapscript should require any kind of community consensus on = future disablement of insecure spend paths
>
> I think Antoine's point here is that if we introduce a PQC opcode = to tapscript but choose NOT to deploy P2MR, and then encourage people to us= e that opcode in P2TR script leaves, then we are locking ourselves into the= assumption that the community will later disable P2TR key-path spending - = otherwise those addresses will be compromised by a CRQC and the PQC leaf sc= ript is useless.

Right, but you cut my quote off and appear to be responding to a point I di= dn't make? The very next
few words that you cut were "not only is it a likely prerequisite for = an alternative output type".
Yes, we have to figure out what kind of output type we want, whether P2MR (= 360), P2TRv2 or just
P2TR. There are strong arguments for each. But none of that has any bearing= on whether we add hash
based signatures to tapscript. We have to add hash based signatures to taps= cript first no matter
what output type we want!

>> Adding a PQ output type which no one will use (eg one where use of= the hash-based signature is mandatory, which drives fees up hugely and has= all the drawbacks you mention) is not a risk mitigation strategy - it does= not materially allow for any migration and doesn't accomplish much of = anything. But as mentioned above I do not see why any addition of hash base= d signatures to tapscript
>
> I don't think anyone is suggesting deployment of an output type wi= th mandatory hash-based signatures. That would be borderline unusable for a= nyone but large companies and wealthy elites.
>
> Every decent proposal I've seen has suggested using PQC in tandem = with ECC across multiple tapscript leaves, whether in some bastardized vari= ant of P2TR, or in BIP360's P2MR.

IMO even something like P2MR's additional cost will strongly discourage= adoption. We have a very
long history with Bitcoin wallets not only refusing to adopt new features b= ut actively making some
of the worst possible design decisions from a Bitcoin PoV. IMO we should ve= ry strongly not give them
any excuse, even if that's just fees.

Matt

--
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 bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/765490aa-5df3-4619-86cc-17570b6d3e99%40mattcorallo.com= .

--
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 bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/459bd81c-584f-4adf-9112-bb733d381c99n%40googlegroups.com= .

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.c= om/d/msgid/bitcoindev/3PuZlWnztVG7MIcejfM8UHiKB9GNqaGsQX4JmsfLMINPs84FaAp7O= Z7EdTxPYV-O2XUJQWM_eYUND3Pm-fHnBcv9QXdHKasHjgacNrE-K-o%3D%40protonmail.com<= /a>.

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CAJowKgJeQA0AkDMYHiobjvk%3DKuWV38yT6= KyaSiC0ZVvH1Q9zvg%40mail.gmail.com.

--
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/CABgZVQDUPc0QR3qRkJi3oMG27vk5%3D6HS6M6wEHcDJjJYt1k_Rg%40ma= il.gmail.com.
--0000000000004da169064f8563c6--