From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 12:23:55 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD5q5-0001O6-Ti for bitcoindev@gnusha.org; Wed, 15 Apr 2026 12:23:55 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-4232f8d6092sf7391981fac.3 for ; Wed, 15 Apr 2026 12:23:53 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776281028; cv=pass; d=google.com; s=arc-20240605; b=HihfF0O8IA+cAlCp7+73rlPliWjm0cCzSnGVCbtsXKVMq9NVd6Oj/bJj6tVGiSPi3q I6MYz9/dIYCor3QGtfhl1IqETtR361CqxocieJ8lGnIklKcRBn8jRL+n2V4/MvsKlNj3 2hCTNMwBCO4CjKmssWmibwg6I19vtz8RnNZcGpFrPSP0eV7ojlUu/khWTcdf3vUjISZd CTc+jfPyojncOjrOIrFUUGiYpX4Mn5dORA+exj/Yb6Jjys/OjqCx2h1l/g/zVj7KR/kA kXQRXWiLFxJuPzoVWBO17QI5q71ndXOK3kMFVfR9gv5CKMR+cdJAS+XmrMfkdDfJUs94 zumg== 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; bh=f0ZoY9gqgGOGwhoYa6qQ12Obd72MUmM7XW+KhI89fCQ=; fh=kZocFxHttz7gDzEG4Z5lbDNonI8Ln1M128uQi50KBAE=; b=ixnRLjwbNc2Yfrx/ld3RIG4JgUhFrbkI6c+H2KLgWBgrDtBZil5L6XG6BwekcnBsUn 2i0yqG+6205J53DOVYpMWuN3Wz2HXAaPcEMENJBIzYJW8A3SwQipTRG6shenL8JVICWP Sv1U50ISIk26zrdVFqVHB7vhKGPIprSz+dZJMB6MWpkiwem5OaKjmP8O13eavoB2vv70 kaEwNt+mho+lPxm0Q4EW/3d6p1ICrwbNd0wE3y03RwWN90Znx9aCHOvcjdofpkYZ56Y3 VyC7MJyD4GMgJlebNmTp97zVjURJ6PZliXgy2RxFYJax4OfVJCrcbF2W7GoOadCukUwj KALA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=Y3TtqJ8J; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776281028; x=1776885828; 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=f0ZoY9gqgGOGwhoYa6qQ12Obd72MUmM7XW+KhI89fCQ=; b=e6qZfdhBKjNLjZDamoeabFbLI9ZolKysLr0z/S+BwSU5oB1JB0hObEH1Rh07uyUjEd Q0L3YCdhtIn4u9fQIbOqzn+MsYymGMz2tSlCTwzuYJr0dZwHWYcwZqmWtjfNneYPsY7J f8KfgEGLlpSI6dlpx9mzytuumiZ3QHZm6Aa6+qu/6uibKvbkB3QMOcLdTNEhvftZxfQW THXY1JQIRUne4ADkBjiv46Zn4YKCZFJuz4FgkL41u5Sg8Gf+d3lTk5W0htdi4M4azNtu zmBjwYuHNumNfYce7os71uysQ4CfFKNTVsnEZ3oAsHNq/8bvn/mH+C2140zWTQer148z C4LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776281028; x=1776885828; 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=f0ZoY9gqgGOGwhoYa6qQ12Obd72MUmM7XW+KhI89fCQ=; b=iw4rYsTuQ3GS5Anq+fmHMPJ9ic8kFpTYPH3ylI1EjjeBq1L0BhSZ+Um4Y81eat8BYV T2SOu/sOieiqz8BbhnNPcBYRMtoYRbxCpaINBPZVPz0Gqr+ZIvM16AEFjE/KlGqDD8AG MtYwx2uJPbj2+liTE+ZrTfWPxTzEsm3E8BxVHkZ7xiOAHge11U4fiyKo0jNvjdSTlAeI PV+jBryEQHzPI0EwlKbsgZicivRdD7dxIZ8PBF4FgUhTNAYY6DHp13V2+2ZojDy1QDmw x8lqMWFKaLyGtXqlokeuNGneZVvIakWPuV/mrwkUGtCtJEIYdxF+a/X9/UZnTx5SLfFz JmXA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ9RQxWlGi0Z4DaR5cBFezBbHjfK71Y5RnXKPG6MA1a41e+3ns7OX3YGrmdoFmRax5lGZGZBpGq/Omxi@gnusha.org X-Gm-Message-State: AOJu0YxVyDo0TP5eJSSmCfqbDF68UmE4vDmaUrlEZl9N6uT3WIgDSvWy UMbgysPDqPtL9RYpsRUPUGNXVxOYX7SL+E0FcjOC4XnhRPm1cZhJORRV X-Received: by 2002:a4a:ec41:0:b0:694:21fa:4ee7 with SMTP id 006d021491bc7-69421fa51cdmr523316eaf.32.1776281027710; Wed, 15 Apr 2026 12:23:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiI+ewmrQ370C2o9Apj2kp9Hcikg9dx5pXFhkI28s6+UXA==" Received: by 2002:a05:6820:f004:b0:68c:84f8:16a1 with SMTP id 006d021491bc7-69437dffdf1ls82556eaf.0.-pod-prod-04-us; Wed, 15 Apr 2026 12:23:42 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9d+AiEV1Ju1LoeVdqCkDRFO+7MfveE2YcbHBGaHhXBwW8ENbKETfrONkplUuGo0leHwqFqwr2fGa2U@googlegroups.com X-Received: by 2002:a05:6808:1509:b0:467:268d:31d4 with SMTP id 5614622812f47-4789f01019bmr10771544b6e.20.1776281022278; Wed, 15 Apr 2026 12:23:42 -0700 (PDT) Received: by 2002:a05:600d:9:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-488f07dcd1bms5e9; Wed, 15 Apr 2026 12:14:20 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/4hjkVaRRcvaE5gHkR2pKBPOiaaApsMVhj1oPg8KpFnZThh5OJ5s8DGQF4iC4oQIf48YhgWzHTYcWl@googlegroups.com X-Received: by 2002:a05:6000:26d0:b0:43d:7d6f:f535 with SMTP id ffacd0b85a97d-43d7d6ff6admr17415828f8f.35.1776280458411; Wed, 15 Apr 2026 12:14:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776280458; cv=pass; d=google.com; s=arc-20240605; b=Ui6Erge0txpvx5FRc/rK3MLA6RcgPGSDT+mHFbX9asQ+GpEQYKXIptE0QEk3fU5kWK a+K2x7GH1PWx64rmkTcdHMPyLBex/8tIYmiCsa1voSsKBOT3ZFJUqYveuthrWGay4r/D FYF91nsVsLmzxhQak05YXaeyo4jp+B9iI+q2T62XHTFu8evrWdBqrSCaafLgx0bT4HMy sonmNGoWPwoICDm4BX1Ygoj5HIkDsqnr1kqrpMV8phl13Gwft5csRDg4dm9FN3V497U2 0DYTWvvXXLa20Fm/HbhoTscuPcKgIY2KVYKZasWy15gm56DZ7Rj2kdYAumSW8EEEMysp wlpw== 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=n/41HBD1Onv6GAOUetIddeIcs4ZiNdamrCFewDid/78=; fh=xQHaYKvIa6r6jo0VnqzCcBOl5ATHaIZiGclSk9eOf3o=; b=TKxn6d3UPsAE8FiGSsYvQ6xuEn6wjjGv5QMWxN9qNGYCsLNPWrAlnYw6pM3CrLh5EW U0sgZtpSYNWoE8pxsxU4JaFSJEZMBwbjS54HJsGPyCTTF63EvCGCZOboFiMVGlrxdR3W EIr/C5KrNJ3nAzEL5WC79ARcwjcTRjPKEL9dqIDAf6Oldy6Y6YJJZmjKSFA8UaT1dBqs RPi/SiR3KWD1BpqBpXV9fZd9pEd0nllTCzn54QYhcQm8IOkhyzdGOeCAH/eFDC82MWmf rvT1jAhpS69ylmMYJxh9fR6ZdiVt5rU75aeK7FFrlyIkkqYOU8vIi2AyePs0l4YfAqrt d7KA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=Y3TtqJ8J; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com. [2a00:1450:4864:20::630]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43ead3ce726si58306f8f.3.2026.04.15.12.14.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 12:14:18 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) client-ip=2a00:1450:4864:20::630; Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-b9c3a9fe80fso929092866b.3 for ; Wed, 15 Apr 2026 12:14:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776280458; cv=none; d=google.com; s=arc-20240605; b=GaptMGjc6Eef01nyuBEKJSHhzthAMDFAosCz8nCcbS9xi6bUAIHQU1qUpQMiBzZGVA 25/0xguyrNnGgnaeZFOFpeoZMzjXQ6U0gX/vpkW1senr7hAFuuRDuOW2WdUrQit9T5Vl 1FXBt/5kH/ZFQuy+KYFpIGHWJQjIxzH9HJMPgEa/j6dFpvFTWf/EyHA/xGmg6OTAUpJo DaUzr4z8tehwkjtDPMHlLQlRGe8F4a5KhYeE7aE7ERUq2KRCo2JnAELt3fNvzxDkxcnC st+DIzvzcd39hSDqS6PNazjtbAml5PnAaaIbJFfQ6ZDTx8jn1GwawO1vI2JSiz2kqnnL qF5A== 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=n/41HBD1Onv6GAOUetIddeIcs4ZiNdamrCFewDid/78=; fh=xQHaYKvIa6r6jo0VnqzCcBOl5ATHaIZiGclSk9eOf3o=; b=Odj801WjBPJbuOJ+A8XspEmDwwqYEvpyHVVsi9OdzQvQQ4BWkQwl2KRwVsDwp3x1vw QmA+LickzLu4BFXl1AsJhwvo3RaQxqtcdhETrb9q8PqPTJ/jmiS7Tj6BJHwUJ/FXdqRw sReQRafwKqW/0xg0+NNIWJP1rAd1kowdJr8SfKif/f42Yf9PTv3/04gc7eHgYnVju0Nx aTwuYjev7ILKcxgsU2kn1TnTcfXeMQTdGbU+JHnNrfqYtfSE+qbRD9IqnooVZk/3JO7G 1pTfNFjPEaysOOA2slzcJkJIlZB7TLHVhpaS2r2Vv8CGjFs0kS1vHXVIgkNxzrsifjyV wn9A==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ+/L/cs8G6GXXCNwVvIh0rloGS94Lskiz+j30FLSHk5pCDDqtrMwYfydX5cSRXy3EwNe2vfNlTw/6Kj@googlegroups.com X-Gm-Gg: AeBDieuxwREd0M+a74NES2FLFvO5VWcUpG+PvkCuc+hSzXuxzvuSOI3Wt1xdvi3nryT mHw95AVlr3yiEiual/cn3qpj7HiS60/pFZnGlqWtbROLF5mzyGTQb4cEh0kcaElXzK5jP6Ffp9E IfF3NAbI5w4KjXhLjNLOPlZbGVIdSNU1O2rMgR82E2TXN/wiGeRoI0/tTW7qWfNdihajtfjAeuK dnzk5x5tOGI170moe8ZP4YIZ3qTprv8go0zQEulx+ly/cY3EC8vuZTNdVIXQ9U0gt/pcCILqbuz 9Cu4qh4zxrq7mjI/DAPzzMcpseB/UwAI2msdqH6iok5oJG5ypm09ejLQxnd6yg== X-Received: by 2002:a17:906:478c:b0:ba1:43cd:1b76 with SMTP id a640c23a62f3a-ba143cd1f19mr227258666b.17.1776280457494; Wed, 15 Apr 2026 12:14:17 -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: <3PuZlWnztVG7MIcejfM8UHiKB9GNqaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYUND3Pm-fHnBcv9QXdHKasHjgacNrE-K-o=@protonmail.com> From: Erik Aronesty Date: Wed, 15 Apr 2026 12:14:05 -0700 X-Gm-Features: AQROBzApcizDkBmkl61uk5I3dI1-u5e9sIGIURSCEQ8Blnol_LdxV_WNDxZ3B3Y Message-ID: Subject: Re: [bitcoindev] In defense of a PQ output type To: Antoine Poinsot Cc: Antoine Riard , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b0c74c064f8485a4" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=Y3TtqJ8J; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=earonesty@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.7 (/) --000000000000b0c74c064f8485a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 100% we shouldn't be forcing hybrid on people. but it should be supported preferred and "Default". this is RFC language. "quantum secure protocols should use hybrid signature schemes" etc On Wed, Apr 15, 2026 at 12:07=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Deve= lopment 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 not > sure it's possible to guarantee that hybrid security is used, since a use= r > 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: 6d7c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaedee9458f6c= 0 > > 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 if= we allow >> ZKP of hash preimages for unused addresses (excluding P2PK/P2TR). Given >> that, are there alternative methods for publishing proof of ownership th= at >> 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 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 P2= MR). >> >> *Incentivized Migration*: Establishing a clear future plan encourages >> users to migrate to BIP32-hardened addresses with longer time period whi= ch >> 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 signat= ure >> 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 UT= C+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 against >>> CRQCs. This is especially true for wallets focused on high value Bitcoi= n >>> outputs. Even if someone thinks there is only a 2% chance they lose all >>> their Bitcoin because of a quantum computer, that 2% chance will keep t= hem >>> 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 Bitcoin >>> 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 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 = use >>>> that opcode in P2TR script leaves, then we are locking ourselves into = the >>>> assumption that the community will later disable P2TR key-path spendin= g - >>>> otherwise those addresses will be compromised by a CRQC and the PQC le= af >>>> script is useless. >>>> >>>> Right, but you cut my quote off and appear to be responding to a point >>>> 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 to >>>> 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 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 >>>> based signatures to tapscript >>>> > >>>> > I don't think anyone is suggesting deployment of an output type with >>>> mandatory hash-based signatures. That would be borderline unusable for >>>> 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 bastardized >>>> variant of P2TR, or in BIP360's P2MR. >>>> >>>> IMO even something like P2MR's additional cost will strongly discourag= e >>>> 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, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/765490aa-5df3-4619-86cc-1= 7570b6d3e99%40mattcorallo.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/459bd81c-584f-4adf-9112-bb73= 3d381c99n%40googlegroups.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/3PuZlWnztVG7MIcejfM8UHiKB9GN= qaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYUND3Pm-fHnBcv9QXdHKasHjgacNrE= -K-o%3D%40protonmail.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/= CAJowKgJeQA0AkDMYHiobjvk%3DKuWV38yT6KyaSiC0ZVvH1Q9zvg%40mail.gmail.com. --000000000000b0c74c064f8485a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
100% we shouldn't be forcing hybrid on people.=C2=A0 = =C2=A0but it should be supported preferred and "Default".=C2=A0 t= his is RFC language.=C2=A0 "quantum secure protocols should use hybrid= signature schemes" etc

On Wed, Apr 15, 2026 at 1= 2:07=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Development Mailing L= ist <bitcoindev@googlegro= ups.com> wrote:
Hi,
=

I don't think in this thread=C2=A0= the question is raised to enable to secure one's coin under double=C2= =A0classic cryptogrraphic assumption and PQ assumption, i.e "hybrid&qu= ot;=C2=A0security
=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 an= d Ethan

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


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

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

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

Advan= ce 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 signature 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 form= alize a framework now. We can also disable or modify the defined freezing p= lan 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 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAJowKgJeQA0AkDMYHiobjvk%3DKuWV38yT6KyaSiC0ZVvH1Q9zvg%40ma= il.gmail.com.
--000000000000b0c74c064f8485a4--