From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 27 Feb 2025 23:30:04 -0800 Received: from mail-ot1-f64.google.com ([209.85.210.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 1tnuos-0005Ih-9K for bitcoindev@gnusha.org; Thu, 27 Feb 2025 23:30:04 -0800 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7273b4db914sf1745289a34.0 for ; Thu, 27 Feb 2025 23:30:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1740727796; cv=pass; d=google.com; s=arc-20240605; b=fUNt6VtNm28PjqYp6IumJ8W5sEnA4FJiSILU/UsF7iY3WrrWvHBhrEcnqA8XUcBG67 EQsbzkXyjQnmD+j7UAv68cFEN4zsCYAo028c+ICzrekKxizWD+maIq2s6X6DvHkboDGj AqNWBxZ0G3U6MtYg5l0oLVye5jngeJn4FZd2hAN53zwI1dSGfHnPF5Cb5PQxPgQdKjnh fOZPzNvuhELSNSimeRdm5g6wBVdbmYJIclPfsuPQVkhso4bzVtxtt/rgGXjMRxj9cYNJ toYSimB2yiZj2A41k5xyLj+tuDHJRcdedKsl5DM4P1AMSzVRKG3VRQsufDar+5v8iLBp 4s8g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=; fh=q60N2uSUsOXts6C/nLmrmXPmTf6zHjcDR2Gb4uf4wto=; b=bKlI3x1ZwwKLMyc/DT25QOUjeowY0U7lypv96WYzqw+WQt9t038k4HfaxIJ5ZcAtFT xl1yYtFyu+IhQ7rEhBF+R6Nya2cw4IsTe3dOWUNgSVcYjmid2C3IJo1LhlLBRA3VWpqI D+uc9LHMuFuCkk3MbMrF1MBtJ74ucHXpJa7X7UQrQ+z4H6yOV6FNb/0pmgkjH/ctkx2g TGg1yW171FZ7pkbSYKF6FeWGd+mUSq0SFtGeP/e8yxvV+fZCZY4G/AL7Y4Nmvom54mLJ lveGzbITA1J2zzHDWUgZ9A1YgukyrgA+vLdCNtu6YifCA2jcQUCdMq2/69/qmcWvGLkY rfVA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ffyJvBCG; spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c as permitted sender) smtp.mailfrom=dustinvonsandwich@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=20230601; t=1740727796; x=1741332596; 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=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=; b=qPe5kFx4Vvus4sLIiIjU/3QuaFP+NZ0XbENBzROgGv3BPfetZW7O2t/aBWpZaJI6oV whcmVpbawcDSC79eZ7wfgkT9zGC40UpIKsu320Xm8bb3irL3kOkchuIJmx0P1ff8rwgY 2MMlcZ+gyUjA/ECwsd3Erd1wWwjN3bnJ7nzTiXW9MqGq8ePHF50UfeSGBetH39WNgTMR Jnq4/xTpqVyKeb+fX54rzz7W9AspB8G31IC2TbIDrEpe/NghwMhLmPCpa/dqHcrxEa3v Z+neOLXtFfma7WJURGW5JWNzAhMk1sl7hO46ru3VfP31kPlEWrhrOIKfHJEwtwcwNu13 I7kQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740727796; x=1741332596; 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=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=; b=MI8hRv2pLedNeJV5bQ2XZA5N2HD8Q8DbWAs6c2PiDHyV1wQ/fV5BgasMUXXgDBiUs3 YrikQk2WR/+yVHJg1LbHbb/X40vHdW5NbfI8qf+Xwz7Awf3p9J8nf/7XG3gDuBNRde4e wWTxXBIdqIN6ymjRDDS21FiBwtemP524zIMMN6q0627rICrl6YXvU+qIqhuHVfty2+Gh c6SeKsmVzjcDhhT5TdLpUU4UbxOa/nyI5RLcXBlqu4gPkrRpN+4kSVavP5+Qcd9joE7r Vkd2pmSKEtR0CHWRVx+hSVKAUVduizNsRBvVyxQtr/CpNHcS1LqqNtlMb6FrXVQytOHU R7eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740727796; x=1741332596; 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-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=; b=CrXACSM6RJwtkBQV2JGUDVM/I1v/5wgi3EXHjNwyKfwjqdbgj4dmtLPRUaUjLy6EEq v933ZIi7hMtpgKs1FLOBOBLyZ5Grejn4NZJ9IfBCUyn/R2jY7WbLs/J1r9o5oYMaISX9 DKlWQLqXyqq8bq4/DB3F6tUTUT7jsTYZrsaVUymijhDFkgrfRfODw5O+9AiF2Eos6g95 NvU3CjzEN/R5dsMK9FBMJ7JVuN2Nl9t9uuLzmqhDvFxI8PSXpHWAWyEbPz8KWdOSLK6V hjrRGIRcF4WrQKGK779QFVJaYOmVogZkk9UCYSU9cAQcA4+uPi2oeR3h7QWH0XhNYGbI UXkQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUseAQgrXDP2ImeAuePZFf67QQeFN7I/xRIKjrVV5AXf7t0LOrwk9F/8TYHOi+yFQTQaTIJftFMLxRm@gnusha.org X-Gm-Message-State: AOJu0YxrXRNORju3SxOkAVIr3OKaqvk08RHFN7LwggZdwJQa503O7a7s vFwqCRdqUGoYWUizVrNgAY4nZLIujiKTK8Zix0KgrtICQgbiUwIc X-Google-Smtp-Source: AGHT+IE+KK3Nl8j3qa5nfOtNC/a9mpHG/ZrdRSwCrPMmdMfE6e/+g5JU1MK8JsOughNE931AKGTYUA== X-Received: by 2002:a05:6830:4197:b0:727:345d:3b70 with SMTP id 46e09a7af769-728b830654bmr1284715a34.28.1740727796079; Thu, 27 Feb 2025 23:29:56 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFJtzRlN7Gf7oht50XIffnmBRQlpyKR8/wNfMqkw2O2hw== Received: by 2002:a05:6820:30c:b0:5fc:7c22:82bb with SMTP id 006d021491bc7-5fea934bfdbls921337eaf.1.-pod-prod-05-us; Thu, 27 Feb 2025 23:29:53 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVeYfc3LoAds5eBGYFuq577Fq8C98E09h38vkWQh4px+3y/7ajI+0ZSsV/lLEmFyOSPSvE3wE7IwIOf@googlegroups.com X-Received: by 2002:a05:6808:1706:b0:3f4:600:7f58 with SMTP id 5614622812f47-3f5586074e0mr1217287b6e.35.1740727793325; Thu, 27 Feb 2025 23:29:53 -0800 (PST) Received: by 2002:a05:6808:694d:b0:3f4:4b9:4605 with SMTP id 5614622812f47-3f5596aa5a6msb6e; Thu, 27 Feb 2025 20:19:30 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWZaEBuCumY4/NwMHVnaPswEyqS/6v3vVynEy1j4uHHyqYoncGnvss54ombHkSRCTZpaxszIyKmcSKV@googlegroups.com X-Received: by 2002:a05:6830:903:b0:727:4676:4005 with SMTP id 46e09a7af769-728b82f07dfmr1221060a34.21.1740716369996; Thu, 27 Feb 2025 20:19:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1740716369; cv=none; d=google.com; s=arc-20240605; b=AED8qPddHOLLBpGolVgrtb/2Y8OY+OI54/tx9D/JHT2nXgB1D+0pP2V6TJm0LLmq7k 8HKLgEfaK7i+Co2KYrHaTf3IJovoghMam9oEQPnPVQfJlvJWGViBJeQMIr7kthovx7Rt dO0RwoXssxUNJ4I+9HqERXd+jTJOQw9zHKJC+G7mqLNmIWmGA0/CpJCH10extRB8HOm5 pRWqPQFs2UvPQy7KEUyqR0dAmQfJJE3Hrh1dGP+ySBoVj3ss0TD5mtoctsuU4NjFtEEy FOSwtANMy/EgYhT7o705nitSamTsENAScaSC///KB7J4Tt4vrw60LgLSQ7N1PBP9hCZr RhsQ== 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=j5utFgyM3jMxtoWpzbs3xoL/2spzwl7zG6IIWso+5lw=; fh=+bcQvW94nIB6Mzm6bsXdVXvF2BAI9blI+3G4qQMgZ94=; b=buolvVoq4mPv1MjWA9UUjJYoBchi1HnjOCddpkIXUJe6P2B0Gbd7iDxYttfDwJALvl YrC/fG3/rtrK4FDG2+2oaENxibm8hAitSc25IUhMFTebPrAbdkLJwt4/RBjyEd1jiSE0 ML/82fz/ecY7q5T1pxIcAmr1TyZm8+k+ODd2yTZiZC3OTWBYuOGt4WX5Uey1SFj7GqbK WhLEJAVtBuzWGZGJkPWEDpgL5XNZlWB6yrBpUanNwiZILmD5IYpTPE8OVJT51h+x1Mqo gCgcqGIwyTKQe9aX0KvakRQlTw2+5Fw7/N15XvfcQBwQpQE851Pf5ngaugVptDgDHK9c eeZA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ffyJvBCG; spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c as permitted sender) smtp.mailfrom=dustinvonsandwich@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com. [2001:4860:4864:20::2c]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-728afd7dba0si189893a34.4.2025.02.27.20.19.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Feb 2025 20:19:29 -0800 (PST) Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c as permitted sender) client-ip=2001:4860:4864:20::2c; Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-2bcbfad2f8cso905872fac.1 for ; Thu, 27 Feb 2025 20:19:29 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVzzvV5eVsYULAra2mru/rsxb0++zISBwAG/mLxUrgJYZ7gBRA4OxVXi0NhfbyKlUr8p/A28I1Qbhl/@googlegroups.com X-Gm-Gg: ASbGncuzvBbkv65BNqKdnsuFLEHF2aUcN51Yo9hYN5ZyhbxhJi2gE5eBE/K3cg1sO0m EpsEGtiS3uB2V0mE2+2yZVhP3p93wcG4/u7N/BNuFz0pnKoWUogsXDyjDqKEAGWtb2EN27GsPmC 6Ichu1kuyub2lDuRrgGrbtZB3m0CR7UsJaBM0ud8bqEQ== X-Received: by 2002:a05:6871:5385:b0:29e:8485:197b with SMTP id 586e51a60fabf-2c1782be860mr1320486fac.2.1740716369387; Thu, 27 Feb 2025 20:19:29 -0800 (PST) MIME-Version: 1.0 References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com> <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com> <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com> <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com> In-Reply-To: <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com> From: Dustin Ray Date: Thu, 27 Feb 2025 20:19:17 -0800 X-Gm-Features: AQ5f1JoSkzDrda5116GvS5QT1xuy7dY1XSxF91XoN54_hYz6hiM2hryGisKtZFQ Message-ID: Subject: Re: [bitcoindev] P2QRH / BIP-360 Update To: Matt Corallo Cc: Hunter Beast , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000da2c71062f2c1c92" X-Original-Sender: Dustinvonsandwich@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ffyJvBCG; spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c as permitted sender) smtp.mailfrom=dustinvonsandwich@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 (/) --000000000000da2c71062f2c1c92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Matt, you make a potent and salient point. I think that when we survey the current state of existing pqc solutions and try to apply them to bitcoin, we keep coming up with either a massive chain, massive key sizes, extremely degraded performance, confiscation, or some combination of those. I think laying the groundwork for this inevitable task now is important, but if I understand your points correctly, I would agree that existing solutions do not seem equipped to carry bitcoin into the post quantum landscape. On Thu, Feb 27, 2025 at 6:41=E2=80=AFPM Matt Corallo wrote: > I think you're approaching this from the wrong stance. > > If our goal is to "make bitcoin Quantum-secure", its gonna take a decade > for the state of PQ > research to build something that's ready for us to "just switch to". I > don't buy that there's a > world where we get serious about adding something lattice-based to Bitcoi= n > for a longggg time (I'm > not sure I've ever heard a serious cryptographer suggest that > lattice-based systems are a good idea, > rather than "a good thing to layer on top of a traditional non-PQC > scheme"). > > In the short-term, the only (remotely-practical) thing we can do is add > something that we have high > confidence will still be secure in two decades (which basically is only > hash-based schemes) and get > wallets to include it in their taproot outputs. That gives wallets create= d > today the possibility of > being robust in a QC world, but, indeed, it would require tough decisions > in the future. > > If your view is that Bitcoin would simply be fine if we didn't confiscate > any coins in response to a > practical QC stealing 5% of total supply, I'm not really convinced, but w= e > can also make it a > version-2 segwit output ("taproot but a future softfork can freely freeze > the keypath spends") if > you really feel strongly. > > TBH the whole "would we confiscate if the time comes" question I think > simply cannot be answered > today because it depends very, very much on specific details (eg lets say > we did the above proposal > and its been around for 30 years and ~all wallets support it, that's a > very very different world > from, for example, deploying some PQC scheme under threat where a QC coul= d > realistically steal coins > in five years). The only thing we can really do today is create the optio= n > in the future, we cannot > decide for the future what to do. > > Matt > > On 2/23/25 3:33 PM, Hunter Beast wrote: > > Hi Matt, > > > > The only problem with that approach is that SLH-DSA signatures are quit= e > large. NIST has also > > approved ML-DSA and FN-DSA, which, while both are based on lattice > cryptography, they're not only > > standardized, but becoming widely supported. One consideration is > hardware acceleration, and I > > believe those three algorithms will have the best chance of having > hardware implementations as PQC > > extensions are added to CPUs and SoCs. > > > > As for gating P2TR, the problem with that approach is that keypath > spends would need to be disabled > > and that has a confiscatory effect that I'm seeking to avoid in this BI= P. > > > > An additional opcode should not be necessary if multisig capability is > built into the attestation. > > > > I agree with your statement on full BIP-32 compatibility. BIP-360 is > just a starting point, and > > maybe you're right, it's best thought of as a "break glass" > implementation. It's not ideal, it's > > full of compromises, not everyone is 100% happy with it, and that's > probably okay, because bitcoin > > isn't perfect-- but it doesn't have to be in order to work. > > > > Thank you for your thoughts. > > > > Hunter > > > > On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Corallo w= rote: > > > > If we want to do something like this in the short to medium term, > IMO we should strip out all the > > signature schemes that are anything more than quite straightforward > in their security assumptions > > (i.e. only keep hash-based signatures, maybe just SPHINCS+), only > embed them in a taproot leaf, and > > call it a day. > > > > BIP 32 compatibility isn't a really huge deal if we're talking abou= t > an "emergency break glass" > > kinda setup - most wallets are set up with a root key and can just > embed the same PQ pubkey in all > > of their outputs. The privacy cost is only realized in a break glas= s > case, and long before then > > hopefully whatever we do today is replaced with something better, > with the knowledge that we'll > > gain > > on the way to "then". We'd still want to do it in an opcode so that > we can do multisig, though. > > > > Matt > > > > On 2/19/25 10:40 AM, Hunter Beast wrote: > > > Dear Bitcoin Dev Community, > > > > > > > > > A bit over six months after introducing the P2QRH proposal (now > BIP-360), I'm writing to share > > > significant developments and request additional feedback on our > post-quantum roadmap, and I'd > > also > > > like to mention a potential P2TRH post-quantum mitigation > strategy. > > > > > > > > > First, now that there's a BIP number assigned, you can find the > update BIP here: > > > > > > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawik= i > > cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> < > https://github.com/cryptoquick/ > github.com/cryptoquick/> > > > bips/blob/p2qrh/bip-0360.mediawiki> > > > > > > > > > The revised BIP-360 draft reflects substantial changes since > initial publication, particularly > > > regarding algorithm selection. While we originally considered > SQIsign, it has 15,000x slower > > > verification compared to ECC [1]. If it takes 1 second to verify > a fully ECC block, it would > > take 4 > > > hours to validate a block filled with SQIsign transactions. This > has obvious and concerning DDoS > > > implications. > > > > > > > > > While it would take a long time to signmany thousands of SQIsign > transactions as well, the > > increased > > > time needed to sign the transactions likely won=E2=80=99t affect= the > practicality of DDoS attacks-- > > another > > > concern which has been brought to my attention. As such, I've > decided to deprecate SQIsign > > from the BIP. > > > > > > > > > It's worth mentioning because it was brought up in the PR, > there's a new class of algorithms > > that > > > support signature aggregation, but they generally result in > signatures that are still quite > > large. > > > Chipmunk and RACCOON are good examples [2], [3]. I do expect tha= t > to improve with time. It > > might be > > > worthwhile to shorten the list by making signature aggregation a > requirement, so as not to > > regress > > > too far from Schnorr signatures. That said, I think those > capabilities should be introduced in a > > > separate BIP once they're more mature and worthwhile. > > > > > > > > > Our current shortlist prioritizes FALCON for its signature > aggregation potential, with > > SPHINCS+ and > > > CRYSTALS-Dilithium as secondary candidates. However, major > technical challenges remain, > > particularly > > > BIP-32 compatibility issues affecting xpub generation in > watch-only wallets, as detailed by > > > conduition in another mailing list discussion [4], and also, how > we should handle multisig > > wallets. > > > > > > > > > Additionally, I think it's worthwhile to restrict BIP-360 to > NIST-approved algorithms to > > maintain > > > FIPS compliance. That's because HSMs such as those provided by > Securosys already have support > > for > > > all three algorithms [5], which is essential for secure > deployment of federated L2 treasuries. > > > > > > > > > Presently, for multisigs, we have a merkle tree configuration > defined for encumbering the output > > > with multiple keys. While that's efficient, it's a novel > construction. I'm not certain we should > > > proceed with the merkle tree commitment scheme-- it needs more > scrutiny. We could use a sort > > of P2SH > > > approach, just modifying the semantics of OP_CHECKMULTISIG in a > witness script to alias to > > public > > > keys in the attestation. But that could introduce additional > overhead in a signature scheme that > > > already uses a lot more space. Without this, however, we do not > yet have a way specified to > > indicate > > > thresholds or a locking script for the attestation, as it is > designed to be purposely > > limited, so as > > > specified it is only capable of n/n multisig. I consider m/n > multisigs to be the single largest > > > obvious omission in the spec right now. It definitely needs more > thought and I'm open to > > > suggestions. Perhaps two additional bytes at the top level of th= e > SegWit v3 output hash could be > > > provided to indicate PQC signature threshold and total, and thos= e > would be hashed and > > committed to > > > in the output, then provided in a field in the attestation once > spent. > > > > > > > > > While finalizing PQC selections, I've also drafted P2TRH as an > interim solution to secure > > Taproot > > > keypath spends without disabling them, as Matthew Corallo > proposes in the aforementioned mailing > > > list thread [4]. The P2TRH approach hashes public keys rather > than exposing them directly, > > > particularly benefiting: > > > > > > > > > - MuSig2 Lightning channel implementations > > > > > > - FROST-based MPC vaults > > > > > > - High-value transactions using private pools that don't reveal > the block template > > > > > > > > > For those interested, take a look at the draft BIP for P2TRH > here: https://github.com/ > > cryptoquick/ > > > bips/blob/p2trh/bip-p2trh.mediawiki < > https://github.com/cryptoquick/bips/blob/p2trh/bip- > > p2trh.mediawiki < > https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki>> > > > > > > > > > I have my hands full with P2QRH advocacy and development and > would prefer to focus on that, > > but I > > > wanted to introduce P2TRH in case that is attractive as the > community's preferred solution-- at > > > least for Taproot quantum security. The tradeoff is that it adds > 8.25 vB of overhead per > > input, and > > > key tweaking might have slightly less utility for some > applications, and it also doesn't protect > > > against short exposure quantum attacks as defined in BIP-360. > > > > > > > > > Returning to P2QRH and what's needed to push it across the finis= h > line... > > > > > > > > > I still need to finish the test vectors. I'm implementing these > using a fork of rust-bitcoin and > > > modeling them after Steven Roose's work on BIP-346. I've been > told that's not a blocker for > > merging > > > the draft, but if it isn't merged by the time I'm finished, > hopefully that will provide some > > > additional impetus behind it. > > > > > > > > > One concern Murch brought up is that introducing four new > algorithms into the network was too > > many-- > > > adding too much complexity to the network and to wallets and > other applications-- and I agree. > > > > > > > > > Hopefully this is addressed to some degree by removing SQIsign > (especially in its current state > > > lacking implementation maturity), and will help push the BIP > below a certain complexity > > threshold, > > > making it somewhat easier to review. > > > > > > I think it's still important to include multiple signature > algorithm options for users to select > > > their desired level of security. It's not 100% certain that all > of these algorithms will remain > > > quantum resistant for all time, so redundancy here is=E2=80=A6 k= ey. > > > > > > > > > Another concern is that NIST level V is overkill. I have less > conviction on this since secp256k1 > > > technically has 128 bits of security due to Pollard's rho > attacks. But if the intention was > > for 256 > > > bits of security, should level V security be the default? It's > difficult for me to say. > > Perhaps both > > > level V and level I implementations could be included, but this > would be a deviation from the > > BIP as > > > presently specified, which defaults to level V security. The > disadvantage of including level I > > > support for each algorithm is that it essentially doubles the > complexity of libbitcoinpqc. > > > > > > > > > Ultimately, I hope the default of NIST V and selection of 3 > mature NIST-approved algorithms > > > demonstrate a focused, polished, and conservative proposal. > > > > > > > > > At this point, the major call to action I would like to highligh= t > is simply the need for more > > > feedback from the community. Please review and provide feedback > here: https://github.com/ > > bitcoin/ > > > bips/pull/1670 https://github.com/bitcoin/bips/ > > pull/1670>> > > > > > > > > > I look forward to feedback and opinions on P2QRH and P2TRH. > > > > > > > > > P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in > Austin, Consensus in Toronto, > > and BTC > > > 25 in Las Vegas, and later this year, TABConf in Atlanta. > > > > > > > > > > > > [1] https://pqshield.github.io/nist-sigs-zoo < > https://pqshield.github.io/nist-sigs-zoo> > > > > > > [2] https://eprint.iacr.org/2023/1820.pdf < > https://eprint.iacr.org/2023/1820.pdf> > > > > > > [3] https://eprint.iacr.org/2024/1291.pdf < > https://eprint.iacr.org/2024/1291.pdf> > > > > > > [4] > https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ > > groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ> > > > > > > [5] > https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-re= lease-overview > > < > https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-re= lease-overview > > > > > > > > > > > -- > > > 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 bitcoindev+...@googlegroups.com>. > > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/8797807d- > > e017-44e2- < > https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-> > > > b419-803291779007n%40googlegroups.com > > d/msgid/bitcoindev/8797807d- < > https://groups.google.com/d/msgid/bitcoindev/8797807d-> > > > e017-44e2-b419-803291779007n% > 40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter > > >= . > > > > -- > > 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 bitcoindev+unsubscribe@googlegroups.com>. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3- > > fa2fa35e2230n%40googlegroups.com > bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n% > 40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>. > > -- > 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/2e0fc337-3603-4a22-8056-59cf= 7e21aa43%40mattcorallo.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/= CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y%2BuEROb3BqxC2_G%2BXA%40mail.gmail.com. --000000000000da2c71062f2c1c92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Matt, you make a potent and salient point. I think that w= hen we survey the current state of existing pqc solutions and try to apply = them to bitcoin, we keep coming up with either a massive chain, massive key= sizes, extremely degraded performance, confiscation, or some combination o= f those.

I think laying = the groundwork for this inevitable task now is important, but if I understa= nd your points correctly, I would agree that existing solutions do not seem= equipped to carry bitcoin into the post quantum landscape.

<= div class=3D"gmail_quote gmail_quote_container">
On Thu, Feb 27, 2025 at 6:41=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.com> wrote= :
I think you're approaching this from the wr= ong stance.

If our goal is to "make bitcoin Quantum-secure", its gonna take a= decade for the state of PQ
research to build something that's ready for us to "just switch to= ". I don't buy that there's a
world where we get serious about adding something lattice-based to Bitcoin = for a longggg time (I'm
not sure I've ever heard a serious cryptographer suggest that lattice-b= ased systems are a good idea,
rather than "a good thing to layer on top of a traditional non-PQC sch= eme").

In the short-term, the only (remotely-practical) thing we can do is add som= ething that we have high
confidence will still be secure in two decades (which basically is only has= h-based schemes) and get
wallets to include it in their taproot outputs. That gives wallets created = today the possibility of
being robust in a QC world, but, indeed, it would require tough decisions i= n the future.

If your view is that Bitcoin would simply be fine if we didn't confisca= te any coins in response to a
practical QC stealing 5% of total supply, I'm not really convinced, but= we can also make it a
version-2 segwit output ("taproot but a future softfork can freely fre= eze the keypath spends") if
you really feel strongly.

TBH the whole "would we confiscate if the time comes" question I = think simply cannot be answered
today because it depends very, very much on specific details (eg lets say w= e did the above proposal
and its been around for 30 years and ~all wallets support it, that's a = very very different world
from, for example, deploying some PQC scheme under threat where a QC could = realistically steal coins
in five years). The only thing we can really do today is create the option = in the future, we cannot
decide for the future what to do.

Matt

On 2/23/25 3:33 PM, Hunter Beast wrote:
> Hi Matt,
>
> The only problem with that approach is that SLH-DSA signatures are qui= te large. NIST has also
> approved ML-DSA and FN-DSA, which, while both are based on lattice cry= ptography, they're not only
> standardized, but becoming widely supported. One consideration is hard= ware acceleration, and I
> believe those three algorithms will have the best chance of having har= dware implementations as PQC
> extensions are added to CPUs and SoCs.
>
> As for gating P2TR, the problem with that approach is that keypath spe= nds would need to be disabled
> and that has a confiscatory effect that I'm seeking to avoid in th= is BIP.
>
> An additional opcode should not be necessary if multisig capability is= built into the attestation.
>
> I agree with your statement on full BIP-32 compatibility. BIP-360 is j= ust a starting point, and
> maybe you're right, it's best thought of as a "break glas= s" implementation. It's not ideal, it's
> full of compromises, not everyone is 100% happy with it, and that'= s probably okay, because bitcoin
> isn't perfect-- but it doesn't have to be in order to work. >
> Thank you for your thoughts.
>
> Hunter
>
> On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Corallo = wrote:
>
>=C2=A0 =C2=A0 =C2=A0If we want to do something like this in the short t= o medium term, IMO we should strip out all the
>=C2=A0 =C2=A0 =C2=A0signature schemes that are anything more than quite= straightforward in their security assumptions
>=C2=A0 =C2=A0 =C2=A0(i.e. only keep hash-based signatures, maybe just S= PHINCS+), only embed them in a taproot leaf, and
>=C2=A0 =C2=A0 =C2=A0call it a day.
>
>=C2=A0 =C2=A0 =C2=A0BIP 32 compatibility isn't a really huge deal i= f we're talking about an "emergency break glass"
>=C2=A0 =C2=A0 =C2=A0kinda setup - most wallets are set up with a root k= ey and can just embed the same PQ pubkey in all
>=C2=A0 =C2=A0 =C2=A0of their outputs. The privacy cost is only realized= in a break glass case, and long before then
>=C2=A0 =C2=A0 =C2=A0hopefully whatever we do today is replaced with som= ething better, with the knowledge that we'll
>=C2=A0 =C2=A0 =C2=A0gain
>=C2=A0 =C2=A0 =C2=A0on the way to "then". We'd still want= to do it in an opcode so that we can do multisig, though.
>
>=C2=A0 =C2=A0 =C2=A0Matt
>
>=C2=A0 =C2=A0 =C2=A0On 2/19/25 10:40 AM, Hunter Beast wrote:
>=C2=A0 =C2=A0 =C2=A0 > Dear Bitcoin Dev Community,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > A bit over six months after introducing the P= 2QRH proposal (now BIP-360), I'm writing to share
>=C2=A0 =C2=A0 =C2=A0 > significant developments and request addition= al feedback on our post-quantum roadmap, and I'd
>=C2=A0 =C2=A0 =C2=A0also
>=C2=A0 =C2=A0 =C2=A0 > like to mention a potential P2TRH post-quantu= m mitigation strategy.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > First, now that there's a BIP number assi= gned, you can find the update BIP here:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > https= ://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki <https://gith= ub.com/
>=C2=A0 =C2=A0 =C2=A0cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> = <https://github.com/cryptoquick/ <https://
>=C2=A0 =C2=A0 =C2=A0github.com/cryptoquick/>
>=C2=A0 =C2=A0 =C2=A0 > bips/blob/p2qrh/bip-0360.mediawiki>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The revised BIP-360 draft reflects substantia= l changes since initial publication, particularly
>=C2=A0 =C2=A0 =C2=A0 > regarding algorithm selection. While we origi= nally considered SQIsign, it has 15,000x slower
>=C2=A0 =C2=A0 =C2=A0 > verification compared to ECC [1]. If it takes= 1 second to verify a fully ECC block, it would
>=C2=A0 =C2=A0 =C2=A0take 4
>=C2=A0 =C2=A0 =C2=A0 > hours to validate a block filled with SQIsign= transactions. This has obvious and concerning DDoS
>=C2=A0 =C2=A0 =C2=A0 > implications.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > While it would take a long time to signmany t= housands of SQIsign transactions as well, the
>=C2=A0 =C2=A0 =C2=A0increased
>=C2=A0 =C2=A0 =C2=A0 > time needed to sign the transactions likely w= on=E2=80=99t affect the practicality of DDoS attacks--
>=C2=A0 =C2=A0 =C2=A0another
>=C2=A0 =C2=A0 =C2=A0 > concern which has been brought to my attentio= n. As such, I've decided to deprecate SQIsign
>=C2=A0 =C2=A0 =C2=A0from the BIP.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > It's worth mentioning because it was brou= ght up in the PR, there's a new class of algorithms
>=C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 > support signature aggregation, but they gener= ally result in signatures that are still quite
>=C2=A0 =C2=A0 =C2=A0large.
>=C2=A0 =C2=A0 =C2=A0 > Chipmunk and RACCOON are good examples [2], [= 3]. I do expect that to improve with time. It
>=C2=A0 =C2=A0 =C2=A0might be
>=C2=A0 =C2=A0 =C2=A0 > worthwhile to shorten the list by making sign= ature aggregation a requirement, so as not to
>=C2=A0 =C2=A0 =C2=A0regress
>=C2=A0 =C2=A0 =C2=A0 > too far from Schnorr signatures. That said, I= think those capabilities should be introduced in a
>=C2=A0 =C2=A0 =C2=A0 > separate BIP once they're more mature and= worthwhile.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Our current shortlist prioritizes FALCON for = its signature aggregation potential, with
>=C2=A0 =C2=A0 =C2=A0SPHINCS+ and
>=C2=A0 =C2=A0 =C2=A0 > CRYSTALS-Dilithium as secondary candidates. H= owever, major technical challenges remain,
>=C2=A0 =C2=A0 =C2=A0particularly
>=C2=A0 =C2=A0 =C2=A0 > BIP-32 compatibility issues affecting xpub ge= neration in watch-only wallets, as detailed by
>=C2=A0 =C2=A0 =C2=A0 > conduition in another mailing list discussion= [4], and also, how we should handle multisig
>=C2=A0 =C2=A0 =C2=A0wallets.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Additionally, I think it's worthwhile to = restrict BIP-360 to NIST-approved algorithms to
>=C2=A0 =C2=A0 =C2=A0maintain
>=C2=A0 =C2=A0 =C2=A0 > FIPS compliance. That's because HSMs such= as those provided by Securosys already have support
>=C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 > all three algorithms [5], which is essential = for secure deployment of federated L2 treasuries.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Presently, for multisigs, we have a merkle tr= ee configuration defined for encumbering the output
>=C2=A0 =C2=A0 =C2=A0 > with multiple keys. While that's efficien= t, it's a novel construction. I'm not certain we should
>=C2=A0 =C2=A0 =C2=A0 > proceed with the merkle tree commitment schem= e-- it needs more scrutiny. We could use a sort
>=C2=A0 =C2=A0 =C2=A0of P2SH
>=C2=A0 =C2=A0 =C2=A0 > approach, just modifying the semantics of OP_= CHECKMULTISIG in a witness script to alias to
>=C2=A0 =C2=A0 =C2=A0public
>=C2=A0 =C2=A0 =C2=A0 > keys in the attestation. But that could intro= duce additional overhead in a signature scheme that
>=C2=A0 =C2=A0 =C2=A0 > already uses a lot more space. Without this, = however, we do not yet have a way specified to
>=C2=A0 =C2=A0 =C2=A0indicate
>=C2=A0 =C2=A0 =C2=A0 > thresholds or a locking script for the attest= ation, as it is designed to be purposely
>=C2=A0 =C2=A0 =C2=A0limited, so as
>=C2=A0 =C2=A0 =C2=A0 > specified it is only capable of n/n multisig.= I consider m/n multisigs to be the single largest
>=C2=A0 =C2=A0 =C2=A0 > obvious omission in the spec right now. It de= finitely needs more thought and I'm open to
>=C2=A0 =C2=A0 =C2=A0 > suggestions. Perhaps two additional bytes at = the top level of the SegWit v3 output hash could be
>=C2=A0 =C2=A0 =C2=A0 > provided to indicate PQC signature threshold = and total, and those would be hashed and
>=C2=A0 =C2=A0 =C2=A0committed to
>=C2=A0 =C2=A0 =C2=A0 > in the output, then provided in a field in th= e attestation once spent.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > While finalizing PQC selections, I've als= o drafted P2TRH as an interim solution to secure
>=C2=A0 =C2=A0 =C2=A0Taproot
>=C2=A0 =C2=A0 =C2=A0 > keypath spends without disabling them, as Mat= thew Corallo proposes in the aforementioned mailing
>=C2=A0 =C2=A0 =C2=A0 > list thread [4]. The P2TRH approach hashes pu= blic keys rather than exposing them directly,
>=C2=A0 =C2=A0 =C2=A0 > particularly benefiting:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > - MuSig2 Lightning channel implementations >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > - FROST-based MPC vaults
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > - High-value transactions using private pools= that don't reveal the block template
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > For those interested, take a look at the draf= t BIP for P2TRH here: https://github.com/
>=C2=A0 =C2=A0 =C2=A0cryptoquick/ <https://github.com/cryptoqui= ck/>
>=C2=A0 =C2=A0 =C2=A0 > bips/blob/p2trh/bip-p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-
>=C2=A0 =C2=A0 =C2=A0p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediaw= iki>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I have my hands full with P2QRH advocacy and = development and would prefer to focus on that,
>=C2=A0 =C2=A0 =C2=A0but I
>=C2=A0 =C2=A0 =C2=A0 > wanted to introduce P2TRH in case that is att= ractive as the community's preferred solution-- at
>=C2=A0 =C2=A0 =C2=A0 > least for Taproot quantum security. The trade= off is that it adds 8.25 vB of overhead per
>=C2=A0 =C2=A0 =C2=A0input, and
>=C2=A0 =C2=A0 =C2=A0 > key tweaking might have slightly less utility= for some applications, and it also doesn't protect
>=C2=A0 =C2=A0 =C2=A0 > against short exposure quantum attacks as def= ined in BIP-360.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Returning to P2QRH and what's needed to p= ush it across the finish line...
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I still need to finish the test vectors. I= 9;m implementing these using a fork of rust-bitcoin and
>=C2=A0 =C2=A0 =C2=A0 > modeling them after Steven Roose's work o= n BIP-346. I've been told that's not a blocker for
>=C2=A0 =C2=A0 =C2=A0merging
>=C2=A0 =C2=A0 =C2=A0 > the draft, but if it isn't merged by the = time I'm finished, hopefully that will provide some
>=C2=A0 =C2=A0 =C2=A0 > additional impetus behind it.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > One concern Murch brought up is that introduc= ing four new algorithms into the network was too
>=C2=A0 =C2=A0 =C2=A0many--
>=C2=A0 =C2=A0 =C2=A0 > adding too much complexity to the network and= to wallets and other applications-- and I agree.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Hopefully this is addressed to some degree by= removing SQIsign (especially in its current state
>=C2=A0 =C2=A0 =C2=A0 > lacking implementation maturity), and will he= lp push the BIP below a certain complexity
>=C2=A0 =C2=A0 =C2=A0threshold,
>=C2=A0 =C2=A0 =C2=A0 > making it somewhat easier to review.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I think it's still important to include m= ultiple signature algorithm options for users to select
>=C2=A0 =C2=A0 =C2=A0 > their desired level of security. It's not= 100% certain that all of these algorithms will remain
>=C2=A0 =C2=A0 =C2=A0 > quantum resistant for all time, so redundancy= here is=E2=80=A6 key.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Another concern is that NIST level V is overk= ill. I have less conviction on this since secp256k1
>=C2=A0 =C2=A0 =C2=A0 > technically has 128 bits of security due to P= ollard's rho attacks. But if the intention was
>=C2=A0 =C2=A0 =C2=A0for 256
>=C2=A0 =C2=A0 =C2=A0 > bits of security, should level V security be = the default? It's difficult for me to say.
>=C2=A0 =C2=A0 =C2=A0Perhaps both
>=C2=A0 =C2=A0 =C2=A0 > level V and level I implementations could be = included, but this would be a deviation from the
>=C2=A0 =C2=A0 =C2=A0BIP as
>=C2=A0 =C2=A0 =C2=A0 > presently specified, which defaults to level = V security. The disadvantage of including level I
>=C2=A0 =C2=A0 =C2=A0 > support for each algorithm is that it essenti= ally doubles the complexity of libbitcoinpqc.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Ultimately, I hope the default of NIST V and = selection of 3 mature NIST-approved algorithms
>=C2=A0 =C2=A0 =C2=A0 > demonstrate a focused, polished, and conserva= tive proposal.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > At this point, the major call to action I wou= ld like to highlight is simply the need for more
>=C2=A0 =C2=A0 =C2=A0 > feedback from the community. Please review an= d provide feedback here: https://github.com/
>=C2=A0 =C2=A0 =C2=A0bitcoin/ <https://github.com/bitcoin/><= br> >=C2=A0 =C2=A0 =C2=A0 > bips/pull/1670 <https://gi= thub.com/bitcoin/bips/pull/1670 <https://github.com/bitcoin/b= ips/
>=C2=A0 =C2=A0 =C2=A0pull/1670>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I look forward to feedback and opinions on P2= QRH and P2TRH.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > P.S. I'll be advocating for BIP-360 at OP= _NEXT in VA, btc++ in Austin, Consensus in Toronto,
>=C2=A0 =C2=A0 =C2=A0and BTC
>=C2=A0 =C2=A0 =C2=A0 > 25 in Las Vegas, and later this year, TABConf= in Atlanta.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [1] https://pqshield.github.io= /nist-sigs-zoo <https://pqshield.github.io/nist-sigs-= zoo>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [2] https://eprint.iacr.org/2023/= 1820.pdf <https://eprint.iacr.org/2023/1820.pdf><= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [3] https://eprint.iacr.org/2024/= 1291.pdf <https://eprint.iacr.org/2024/1291.pdf><= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ &l= t;https://
>=C2=A0 =C2=A0 =C2=A0groups.goo= gle.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [5] https://docs.securosys.com/tsb/Tutorials/Post-Quantum-= Cryptography/pqc-release-overview
>=C2=A0 =C2=A0 =C2=A0<https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Crypto= graphy/pqc-release-overview>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 > You received this message because you are sub= scribed to the Google Groups "Bitcoin Development
>=C2=A0 =C2=A0 =C2=A0 > Mailing List" group.
>=C2=A0 =C2=A0 =C2=A0 > To unsubscribe from this group and stop recei= ving emails from it, send an email to
>=C2=A0 =C2=A0 =C2=A0 > bitcoindev+...@googlegroups.com <mailto:bitcoi= ndev+...@googlegroups.com>.
>=C2=A0 =C2=A0 =C2=A0 > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8797807d- >=C2=A0 =C2=A0 =C2=A0e017-44e2- <https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2->=
>=C2=A0 =C2=A0 =C2=A0 > b419-803291779007n%40googlegroups.com <= ;http://40googlegroups.com> <https://groups.google.com/
>=C2=A0 =C2=A0 =C2=A0d/msgid/bitcoindev/8797807d- <https://groups.google.com/d/msgid/bitcoindev/8797807d-><= br> >=C2=A0 =C2=A0 =C2=A0 > e017-44e2-b419-803291779007n%40googlegroups.com?utm_medium=3Demail&utm_so= urce=3Dfooter
>=C2=A0 =C2=A0 =C2=A0<http= ://40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>>= ;.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development
> Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send= an email to
> bitcoindev+unsubscribe@googlegroups.com <mailto:bitcoin= dev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-
> fa2fa35e2230n%40googlegroups.com <https://groups.googl= e.com/d/msgid/
> bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com?utm_medium=3Demail&utm_source= =3Dfooter>.

--
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/2= e0fc337-3603-4a22-8056-59cf7e21aa43%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y%2BuEROb3BqxC2_G%2BXA%= 40mail.gmail.com.
--000000000000da2c71062f2c1c92--