path: root/be/3907d74b7069a7bbbdac82051eb1cd67d1d6b6

Delivery-date: Mon, 03 Mar 2025 13:55:23 -0800
Received: from mail-yw1-f187.google.com ([209.85.128.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD3YNWFH7IHBBPWKTC7AMGQEF2J6TJY@googlegroups.com>)
	id 1tpDkv-00088Y-Im
	for bitcoindev@gnusha.org; Mon, 03 Mar 2025 13:55:23 -0800
Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-6f2793679ebsf59459927b3.0
        for <bitcoindev@gnusha.org>; Mon, 03 Mar 2025 13:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741038915; x=1741643715; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=u7LoPKTlLrG/0Y3q02l/nZ6DyUnQMnHPAeGGgOXRL9g=;
        b=Xj3PG/ew9MAH7WVSLO/uGUiDIiXdZyZ29Biq0Dfj1pmkcXyfi1ZHyDI4/K1FcD5L85
         oT9ua4LvB165tKNzf6K4okBF1Si5LmpKxiHUm1g97YrQozLrqGWFzf+vGO24oMAWp8IG
         rLasaqVtWecSCDYM3gAGbJrVb6zu/BouEVG8gh39MczTpqLD0UpkY/uW1jtEke1/B0KD
         zy3l+/eKtA0fWWWIVbEtrLBfP92V+ufiiawv37yky+gLWLQVt0IeRBUcuAusSc9RvuV8
         XDvmnfm64yT1DxOU4v1ZRHEyvKXXFPR0jkFFMAD8dAhPqCvz/9oxQWlSUiua0A6ssSdl
         /Kuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741038915; x=1741643715;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=u7LoPKTlLrG/0Y3q02l/nZ6DyUnQMnHPAeGGgOXRL9g=;
        b=ASwY618OVbq2woxRrBvyyXr0qHE63EtMlGHfQQpaa4ZX96XO8mYHxVFWKdRLrjhvIX
         t0boAFvHZytn7iUu5OmQ4QpP6psUNWgutUDAfrx1lszEMscO9NnHThZ1nwMGJ2IPd5sD
         WsjhyP4qrD8uUqsIZVJUVbT/I+14butvxLI2NBVDCi2KL+D5ec2Vs9NqbnN9Ku81kYep
         TRZuy9mMo6HeFcRt45art3QobH3n5+d8GtpIwhss9tJIUEiLq1n2HkoJ/EFRR9X9ghXf
         zRR45wZKQd7Ql2LwGDu8XdUUfGpz+4yRZXW5ynRahdWwJJHIL/20LyJ38j36zp/SZmnm
         /Efg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX3pEQCtNKRkCccZ8NsnNiJrSU5FLgiFqYJLWL9BMd49RnVdfndUcMu3K+RtMzFybyA2RKm7bzN7kc+@gnusha.org
X-Gm-Message-State: AOJu0YzdlpMETTo4YgCjW2NyaZ7PK56a0B1K0s/JB2jrbTW1K194aYzX
	JVpqTMjmZsADSaEyvWFWPznAgu/B2KJGR74WAnySXAr3hFLT7VGn
X-Google-Smtp-Source: AGHT+IENCyPNT1PpWAIcSb6uixxLEGbPIc3gDD5tMZgqK6KYVqhO4wz2f70iwYBZhO6yH8T/ecwzBA==
X-Received: by 2002:a05:6902:114f:b0:e57:f8cd:f0a4 with SMTP id 3f1490d57ef6-e60b2f3eab7mr17479476276.34.1741038914673;
        Mon, 03 Mar 2025 13:55:14 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVEtaXzkQLv9E0GdfGDwOKTdsohnwhMXMyWA3H289RKIjg==
Received: by 2002:a25:e010:0:b0:e5b:3adb:a133 with SMTP id 3f1490d57ef6-e609f03cae7ls111736276.1.-pod-prod-03-us;
 Mon, 03 Mar 2025 13:55:09 -0800 (PST)
X-Received: by 2002:a05:690c:3686:b0:6ef:6a71:aa55 with SMTP id 00721157ae682-6fd49ead0dbmr214615597b3.0.1741038909618;
        Mon, 03 Mar 2025 13:55:09 -0800 (PST)
Received: by 2002:a0d:e946:0:b0:6f9:77a0:782b with SMTP id 00721157ae682-6fd4d227c57ms7b3;
        Mon, 3 Mar 2025 12:57:16 -0800 (PST)
X-Received: by 2002:a05:690c:4493:b0:6fb:b8a1:d3bb with SMTP id 00721157ae682-6fd4a02387cmr186142687b3.17.1741035434719;
        Mon, 03 Mar 2025 12:57:14 -0800 (PST)
Date: Mon, 3 Mar 2025 12:57:14 -0800 (PST)
From: Hunter Beast <hunter@surmount.systems>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <54882e16-fdd2-4887-a429-189dd8aa7368n@googlegroups.com>
In-Reply-To: <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com>
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>
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_110588_558513498.1741035434225"
X-Original-Sender: hunter@surmount.systems
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

------=_Part_110588_558513498.1741035434225
Content-Type: multipart/alternative; 
	boundary="----=_Part_110589_1462965592.1741035434225"

------=_Part_110589_1462965592.1741035434225
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't disagree with your points, but I do want to point out that the BIP=
=20
provides the option of using SLH-DSA, which is hash-based.

On Thursday, February 27, 2025 at 7:41:08=E2=80=AFPM UTC-7 Matt Corallo wro=
te:

> I think you're approaching this from the wrong stance.
>
> If our goal is to "make bitcoin Quantum-secure", its gonna take a decade=
=20
> for the state of PQ=20
> research to build something that's ready for us to "just switch to". I=20
> don't buy that there's a=20
> world where we get serious about adding something lattice-based to Bitcoi=
n=20
> for a longggg time (I'm=20
> not sure I've ever heard a serious cryptographer suggest that=20
> lattice-based systems are a good idea,=20
> rather than "a good thing to layer on top of a traditional non-PQC=20
> scheme").
>
> In the short-term, the only (remotely-practical) thing we can do is add=
=20
> something that we have high=20
> confidence will still be secure in two decades (which basically is only=
=20
> hash-based schemes) and get=20
> wallets to include it in their taproot outputs. That gives wallets create=
d=20
> today the possibility of=20
> being robust in a QC world, but, indeed, it would require tough decisions=
=20
> in the future.
>
> If your view is that Bitcoin would simply be fine if we didn't confiscate=
=20
> any coins in response to a=20
> practical QC stealing 5% of total supply, I'm not really convinced, but w=
e=20
> can also make it a=20
> version-2 segwit output ("taproot but a future softfork can freely freeze=
=20
> the keypath spends") if=20
> you really feel strongly.
>
> TBH the whole "would we confiscate if the time comes" question I think=20
> simply cannot be answered=20
> today because it depends very, very much on specific details (eg lets say=
=20
> we did the above proposal=20
> and its been around for 30 years and ~all wallets support it, that's a=20
> very very different world=20
> from, for example, deploying some PQC scheme under threat where a QC coul=
d=20
> realistically steal coins=20
> in five years). The only thing we can really do today is create the optio=
n=20
> in the future, we cannot=20
> decide for the future what to do.
>
> Matt
>
> On 2/23/25 3:33 PM, Hunter Beast wrote:
> > Hi Matt,
> >=20
> > The only problem with that approach is that SLH-DSA signatures are quit=
e=20
> large. NIST has also=20
> > approved ML-DSA and FN-DSA, which, while both are based on lattice=20
> cryptography, they're not only=20
> > standardized, but becoming widely supported. One consideration is=20
> hardware acceleration, and I=20
> > believe those three algorithms will have the best chance of having=20
> hardware implementations as PQC=20
> > extensions are added to CPUs and SoCs.
> >=20
> > As for gating P2TR, the problem with that approach is that keypath=20
> spends would need to be disabled=20
> > and that has a confiscatory effect that I'm seeking to avoid in this BI=
P.
> >=20
> > An additional opcode should not be necessary if multisig capability is=
=20
> built into the attestation.
> >=20
> > I agree with your statement on full BIP-32 compatibility. BIP-360 is=20
> just a starting point, and=20
> > maybe you're right, it's best thought of as a "break glass"=20
> implementation. It's not ideal, it's=20
> > full of compromises, not everyone is 100% happy with it, and that's=20
> probably okay, because bitcoin=20
> > isn't perfect-- but it doesn't have to be in order to work.
> >=20
> > Thank you for your thoughts.
> >=20
> > Hunter
> >=20
> > On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Corallo w=
rote:
> >=20
> > If we want to do something like this in the short to medium term, IMO w=
e=20
> should strip out all the
> > signature schemes that are anything more than quite straightforward in=
=20
> their security assumptions
> > (i.e. only keep hash-based signatures, maybe just SPHINCS+), only embed=
=20
> them in a taproot leaf, and
> > call it a day.
> >=20
> > BIP 32 compatibility isn't a really huge deal if we're talking about an=
=20
> "emergency break glass"
> > kinda setup - most wallets are set up with a root key and can just embe=
d=20
> the same PQ pubkey in all
> > of their outputs. The privacy cost is only realized in a break glass=20
> case, and long before then
> > hopefully whatever we do today is replaced with something better, with=
=20
> the knowledge that we'll
> > gain
> > on the way to "then". We'd still want to do it in an opcode so that we=
=20
> can do multisig, though.
> >=20
> > Matt
> >=20
> > 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=20
> BIP-360), I'm writing to share
> > > significant developments and request additional feedback on our=20
> 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 updat=
e=20
> BIP here:
> > >
> > > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki <
> https://github.com/
> > cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> <
> https://github.com/cryptoquick/ <https://
> > github.com/cryptoquick/>
> > > bips/blob/p2qrh/bip-0360.mediawiki>
> > >
> > >
> > > The revised BIP-360 draft reflects substantial changes since initial=
=20
> publication, particularly
> > > regarding algorithm selection. While we originally considered SQIsign=
,=20
> it has 15,000x slower
> > > verification compared to ECC [1]. If it takes 1 second to verify a=20
> fully ECC block, it would
> > take 4
> > > hours to validate a block filled with SQIsign transactions. This has=
=20
> obvious and concerning DDoS
> > > implications.
> > >
> > >
> > > While it would take a long time to signmany thousands of SQIsign=20
> transactions as well, the
> > increased
> > > time needed to sign the transactions likely won=E2=80=99t affect the=
=20
> practicality of DDoS attacks--
> > another
> > > concern which has been brought to my attention. As such, I've decided=
=20
> to deprecate SQIsign
> > from the BIP.
> > >
> > >
> > > It's worth mentioning because it was brought up in the PR, there's a=
=20
> new class of algorithms
> > that
> > > support signature aggregation, but they generally result in signature=
s=20
> that are still quite
> > large.
> > > Chipmunk and RACCOON are good examples [2], [3]. I do expect that to=
=20
> improve with time. It
> > might be
> > > worthwhile to shorten the list by making signature aggregation a=20
> requirement, so as not to
> > regress
> > > too far from Schnorr signatures. That said, I think those capabilitie=
s=20
> should be introduced in a
> > > separate BIP once they're more mature and worthwhile.
> > >
> > >
> > > Our current shortlist prioritizes FALCON for its signature aggregatio=
n=20
> potential, with
> > SPHINCS+ and
> > > CRYSTALS-Dilithium as secondary candidates. However, major technical=
=20
> challenges remain,
> > particularly
> > > BIP-32 compatibility issues affecting xpub generation in watch-only=
=20
> wallets, as detailed by
> > > conduition in another mailing list discussion [4], and also, how we=
=20
> should handle multisig
> > wallets.
> > >
> > >
> > > Additionally, I think it's worthwhile to restrict BIP-360 to=20
> NIST-approved algorithms to
> > maintain
> > > FIPS compliance. That's because HSMs such as those provided by=20
> Securosys already have support
> > for
> > > all three algorithms [5], which is essential for secure deployment of=
=20
> federated L2 treasuries.
> > >
> > >
> > > Presently, for multisigs, we have a merkle tree configuration defined=
=20
> for encumbering the output
> > > with multiple keys. While that's efficient, it's a novel construction=
.=20
> I'm not certain we should
> > > proceed with the merkle tree commitment scheme-- it needs more=20
> scrutiny. We could use a sort
> > of P2SH
> > > approach, just modifying the semantics of OP_CHECKMULTISIG in a=20
> witness script to alias to
> > public
> > > keys in the attestation. But that could introduce additional overhead=
=20
> in a signature scheme that
> > > already uses a lot more space. Without this, however, we do not yet=
=20
> have a way specified to
> > indicate
> > > thresholds or a locking script for the attestation, as it is designed=
=20
> to be purposely
> > limited, so as
> > > specified it is only capable of n/n multisig. I consider m/n multisig=
s=20
> to be the single largest
> > > obvious omission in the spec right now. It definitely needs more=20
> thought and I'm open to
> > > suggestions. Perhaps two additional bytes at the top level of the=20
> SegWit v3 output hash could be
> > > provided to indicate PQC signature threshold and total, and those=20
> 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 interi=
m=20
> solution to secure
> > Taproot
> > > keypath spends without disabling them, as Matthew Corallo proposes in=
=20
> the aforementioned mailing
> > > list thread [4]. The P2TRH approach hashes public keys rather than=20
> exposing them directly,
> > > particularly benefiting:
> > >
> > >
> > > - MuSig2 Lightning channel implementations
> > >
> > > - FROST-based MPC vaults
> > >
> > > - High-value transactions using private pools that don't reveal the=
=20
> block template
> > >
> > >
> > > For those interested, take a look at the draft BIP for P2TRH here:=20
> https://github.com/
> > cryptoquick/ <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=20
> prefer to focus on that,
> > but I
> > > wanted to introduce P2TRH in case that is attractive as the=20
> community's preferred solution-- at
> > > least for Taproot quantum security. The tradeoff is that it adds 8.25=
=20
> vB of overhead per
> > input, and
> > > key tweaking might have slightly less utility for some applications,=
=20
> 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 finish=20
> line...
> > >
> > >
> > > I still need to finish the test vectors. I'm implementing these using=
=20
> a fork of rust-bitcoin and
> > > modeling them after Steven Roose's work on BIP-346. I've been told=20
> that's not a blocker for
> > merging
> > > the draft, but if it isn't merged by the time I'm finished, hopefully=
=20
> that will provide some
> > > additional impetus behind it.
> > >
> > >
> > > One concern Murch brought up is that introducing four new algorithms=
=20
> into the network was too
> > many--
> > > adding too much complexity to the network and to wallets and other=20
> applications-- and I agree.
> > >
> > >
> > > Hopefully this is addressed to some degree by removing SQIsign=20
> (especially in its current state
> > > lacking implementation maturity), and will help push the BIP below a=
=20
> certain complexity
> > threshold,
> > > making it somewhat easier to review.
> > >
> > > I think it's still important to include multiple signature algorithm=
=20
> options for users to select
> > > their desired level of security. It's not 100% certain that all of=20
> these algorithms will remain
> > > quantum resistant for all time, so redundancy here is=E2=80=A6 key.
> > >
> > >
> > > Another concern is that NIST level V is overkill. I have less=20
> conviction on this since secp256k1
> > > technically has 128 bits of security due to Pollard's rho attacks. Bu=
t=20
> if the intention was
> > for 256
> > > bits of security, should level V security be the default? It's=20
> difficult for me to say.
> > Perhaps both
> > > level V and level I implementations could be included, but this would=
=20
> be a deviation from the
> > BIP as
> > > presently specified, which defaults to level V security. The=20
> disadvantage of including level I
> > > support for each algorithm is that it essentially doubles the=20
> complexity of libbitcoinpqc.
> > >
> > >
> > > Ultimately, I hope the default of NIST V and selection of 3 mature=20
> NIST-approved algorithms
> > > demonstrate a focused, polished, and conservative proposal.
> > >
> > >
> > > At this point, the major call to action I would like to highlight is=
=20
> simply the need for more
> > > feedback from the community. Please review and provide feedback here:=
=20
> https://github.com/
> > bitcoin/ <https://github.com/bitcoin/>
> > > bips/pull/1670 <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=
,=20
> 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]=20
> https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ=20
> <https://
> > groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
> > >
> > > [5]=20
> 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=20
> Groups "Bitcoin Development
> > > Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d=20
> an email to
> > > bitcoindev+...@googlegroups.com <mailto:
> bitcoindev+...@googlegroups.com>.
> > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/8797807d-
> > e017-44e2- <
> https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2->
> > > b419-803291779007n%40googlegroups.com <http://40googlegroups.com> <
> https://groups.google.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
> > <http://40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>>.
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development=20
> > Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to=20
> > bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com
> >.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-=20
> > fa2fa35e2230n%40googlegroups.com <https://groups.google.com/d/msgid/=20
> > bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%
> 40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.
>
>

--=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/=
54882e16-fdd2-4887-a429-189dd8aa7368n%40googlegroups.com.

------=_Part_110589_1462965592.1741035434225
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't disagree with your points, but I do want to point out that the BIP =
provides the option of using SLH-DSA, which is hash-based.<br /><br /><div =
class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursday, F=
ebruary 27, 2025 at 7:41:08=E2=80=AFPM UTC-7 Matt Corallo wrote:<br/></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I think you&#39;re appr=
oaching this from the wrong stance.
<br>
<br>If our goal is to &quot;make bitcoin Quantum-secure&quot;, its gonna ta=
ke a decade for the state of PQ=20
<br>research to build something that&#39;s ready for us to &quot;just switc=
h to&quot;. I don&#39;t buy that there&#39;s a=20
<br>world where we get serious about adding something lattice-based to Bitc=
oin for a longggg time (I&#39;m=20
<br>not sure I&#39;ve ever heard a serious cryptographer suggest that latti=
ce-based systems are a good idea,=20
<br>rather than &quot;a good thing to layer on top of a traditional non-PQC=
 scheme&quot;).
<br>
<br>In the short-term, the only (remotely-practical) thing we can do is add=
 something that we have high=20
<br>confidence will still be secure in two decades (which basically is only=
 hash-based schemes) and get=20
<br>wallets to include it in their taproot outputs. That gives wallets crea=
ted today the possibility of=20
<br>being robust in a QC world, but, indeed, it would require tough decisio=
ns in the future.
<br>
<br>If your view is that Bitcoin would simply be fine if we didn&#39;t conf=
iscate any coins in response to a=20
<br>practical QC stealing 5% of total supply, I&#39;m not really convinced,=
 but we can also make it a=20
<br>version-2 segwit output (&quot;taproot but a future softfork can freely=
 freeze the keypath spends&quot;) if=20
<br>you really feel strongly.
<br>
<br>TBH the whole &quot;would we confiscate if the time comes&quot; questio=
n I think simply cannot be answered=20
<br>today because it depends very, very much on specific details (eg lets s=
ay we did the above proposal=20
<br>and its been around for 30 years and ~all wallets support it, that&#39;=
s a very very different world=20
<br>from, for example, deploying some PQC scheme under threat where a QC co=
uld realistically steal coins=20
<br>in five years). The only thing we can really do today is create the opt=
ion in the future, we cannot=20
<br>decide for the future what to do.
<br>
<br>Matt
<br>
<br>On 2/23/25 3:33 PM, Hunter Beast wrote:
<br>&gt; Hi Matt,
<br>&gt;=20
<br>&gt; The only problem with that approach is that SLH-DSA signatures are=
 quite large. NIST has also=20
<br>&gt; approved ML-DSA and FN-DSA, which, while both are based on lattice=
 cryptography, they&#39;re not only=20
<br>&gt; standardized, but becoming widely supported. One consideration is =
hardware acceleration, and I=20
<br>&gt; believe those three algorithms will have the best chance of having=
 hardware implementations as PQC=20
<br>&gt; extensions are added to CPUs and SoCs.
<br>&gt;=20
<br>&gt; As for gating P2TR, the problem with that approach is that keypath=
 spends would need to be disabled=20
<br>&gt; and that has a confiscatory effect that I&#39;m seeking to avoid i=
n this BIP.
<br>&gt;=20
<br>&gt; An additional opcode should not be necessary if multisig capabilit=
y is built into the attestation.
<br>&gt;=20
<br>&gt; I agree with your statement on full BIP-32 compatibility. BIP-360 =
is just a starting point, and=20
<br>&gt; maybe you&#39;re right, it&#39;s best thought of as a &quot;break =
glass&quot; implementation. It&#39;s not ideal, it&#39;s=20
<br>&gt; full of compromises, not everyone is 100% happy with it, and that&=
#39;s probably okay, because bitcoin=20
<br>&gt; isn&#39;t perfect-- but it doesn&#39;t have to be in order to work=
.
<br>&gt;=20
<br>&gt; Thank you for your thoughts.
<br>&gt;=20
<br>&gt; Hunter
<br>&gt;=20
<br>&gt; On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Cora=
llo wrote:
<br>&gt;=20
<br>&gt;     If we want to do something like this in the short to medium te=
rm, IMO we should strip out all the
<br>&gt;     signature schemes that are anything more than quite straightfo=
rward in their security assumptions
<br>&gt;     (i.e. only keep hash-based signatures, maybe just SPHINCS+), o=
nly embed them in a taproot leaf, and
<br>&gt;     call it a day.
<br>&gt;=20
<br>&gt;     BIP 32 compatibility isn&#39;t a really huge deal if we&#39;re=
 talking about an &quot;emergency break glass&quot;
<br>&gt;     kinda setup - most wallets are set up with a root key and can =
just embed the same PQ pubkey in all
<br>&gt;     of their outputs. The privacy cost is only realized in a break=
 glass case, and long before then
<br>&gt;     hopefully whatever we do today is replaced with something bett=
er, with the knowledge that we&#39;ll
<br>&gt;     gain
<br>&gt;     on the way to &quot;then&quot;. We&#39;d still want to do it i=
n an opcode so that we can do multisig, though.
<br>&gt;=20
<br>&gt;     Matt
<br>&gt;=20
<br>&gt;     On 2/19/25 10:40 AM, Hunter Beast wrote:
<br>&gt;      &gt; Dear Bitcoin Dev Community,
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; A bit over six months after introducing the P2QRH propos=
al (now BIP-360), I&#39;m writing to share
<br>&gt;      &gt; significant developments and request additional feedback=
 on our post-quantum roadmap, and I&#39;d
<br>&gt;     also
<br>&gt;      &gt; like to mention a potential P2TRH post-quantum mitigatio=
n strategy.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; First, now that there&#39;s a BIP number assigned, you c=
an find the update BIP here:
<br>&gt;      &gt;
<br>&gt;      &gt; <a href=3D"https://github.com/cryptoquick/bips/blob/p2qr=
h/bip-0360.mediawiki" target=3D"_blank" rel=3D"nofollow" data-saferedirectu=
rl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/cryptoq=
uick/bips/blob/p2qrh/bip-0360.mediawiki&amp;source=3Dgmail&amp;ust=3D174111=
8741396000&amp;usg=3DAOvVaw0NSlRin2vyi_FtBWQUy5C5">https://github.com/crypt=
oquick/bips/blob/p2qrh/bip-0360.mediawiki</a> &lt;<a href=3D"https://github=
.com/" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/&amp;source=3Dgmail&am=
p;ust=3D1741118741396000&amp;usg=3DAOvVaw0PXDXxRyje9aWE6zTaI4b9">https://gi=
thub.com/</a>
<br>&gt;     cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki&gt; &lt;<a href=
=3D"https://github.com/cryptoquick/" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://git=
hub.com/cryptoquick/&amp;source=3Dgmail&amp;ust=3D1741118741396000&amp;usg=
=3DAOvVaw0Od5CcQAHj4RGiV4D1LVGF">https://github.com/cryptoquick/</a> &lt;ht=
tps://
<br>&gt;     <a href=3D"http://github.com/cryptoquick/" target=3D"_blank" r=
el=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&=
amp;q=3Dhttp://github.com/cryptoquick/&amp;source=3Dgmail&amp;ust=3D1741118=
741396000&amp;usg=3DAOvVaw3eD9Zvg-1tSiCPAGSmELxN">github.com/cryptoquick/</=
a>&gt;
<br>&gt;      &gt; bips/blob/p2qrh/bip-0360.mediawiki&gt;
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; The revised BIP-360 draft reflects substantial changes s=
ince initial publication, particularly
<br>&gt;      &gt; regarding algorithm selection. While we originally consi=
dered SQIsign, it has 15,000x slower
<br>&gt;      &gt; verification compared to ECC [1]. If it takes 1 second t=
o verify a fully ECC block, it would
<br>&gt;     take 4
<br>&gt;      &gt; hours to validate a block filled with SQIsign transactio=
ns. This has obvious and concerning DDoS
<br>&gt;      &gt; implications.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; While it would take a long time to signmany thousands of=
 SQIsign transactions as well, the
<br>&gt;     increased
<br>&gt;      &gt; time needed to sign the transactions likely won=E2=80=99=
t affect the practicality of DDoS attacks--
<br>&gt;     another
<br>&gt;      &gt; concern which has been brought to my attention. As such,=
 I&#39;ve decided to deprecate SQIsign
<br>&gt;     from the BIP.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; It&#39;s worth mentioning because it was brought up in t=
he PR, there&#39;s a new class of algorithms
<br>&gt;     that
<br>&gt;      &gt; support signature aggregation, but they generally result=
 in signatures that are still quite
<br>&gt;     large.
<br>&gt;      &gt; Chipmunk and RACCOON are good examples [2], [3]. I do ex=
pect that to improve with time. It
<br>&gt;     might be
<br>&gt;      &gt; worthwhile to shorten the list by making signature aggre=
gation a requirement, so as not to
<br>&gt;     regress
<br>&gt;      &gt; too far from Schnorr signatures. That said, I think thos=
e capabilities should be introduced in a
<br>&gt;      &gt; separate BIP once they&#39;re more mature and worthwhile=
.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Our current shortlist prioritizes FALCON for its signatu=
re aggregation potential, with
<br>&gt;     SPHINCS+ and
<br>&gt;      &gt; CRYSTALS-Dilithium as secondary candidates. However, maj=
or technical challenges remain,
<br>&gt;     particularly
<br>&gt;      &gt; BIP-32 compatibility issues affecting xpub generation in=
 watch-only wallets, as detailed by
<br>&gt;      &gt; conduition in another mailing list discussion [4], and a=
lso, how we should handle multisig
<br>&gt;     wallets.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Additionally, I think it&#39;s worthwhile to restrict BI=
P-360 to NIST-approved algorithms to
<br>&gt;     maintain
<br>&gt;      &gt; FIPS compliance. That&#39;s because HSMs such as those p=
rovided by Securosys already have support
<br>&gt;     for
<br>&gt;      &gt; all three algorithms [5], which is essential for secure =
deployment of federated L2 treasuries.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Presently, for multisigs, we have a merkle tree configur=
ation defined for encumbering the output
<br>&gt;      &gt; with multiple keys. While that&#39;s efficient, it&#39;s=
 a novel construction. I&#39;m not certain we should
<br>&gt;      &gt; proceed with the merkle tree commitment scheme-- it need=
s more scrutiny. We could use a sort
<br>&gt;     of P2SH
<br>&gt;      &gt; approach, just modifying the semantics of OP_CHECKMULTIS=
IG in a witness script to alias to
<br>&gt;     public
<br>&gt;      &gt; keys in the attestation. But that could introduce additi=
onal overhead in a signature scheme that
<br>&gt;      &gt; already uses a lot more space. Without this, however, we=
 do not yet have a way specified to
<br>&gt;     indicate
<br>&gt;      &gt; thresholds or a locking script for the attestation, as i=
t is designed to be purposely
<br>&gt;     limited, so as
<br>&gt;      &gt; specified it is only capable of n/n multisig. I consider=
 m/n multisigs to be the single largest
<br>&gt;      &gt; obvious omission in the spec right now. It definitely ne=
eds more thought and I&#39;m open to
<br>&gt;      &gt; suggestions. Perhaps two additional bytes at the top lev=
el of the SegWit v3 output hash could be
<br>&gt;      &gt; provided to indicate PQC signature threshold and total, =
and those would be hashed and
<br>&gt;     committed to
<br>&gt;      &gt; in the output, then provided in a field in the attestati=
on once spent.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; While finalizing PQC selections, I&#39;ve also drafted P=
2TRH as an interim solution to secure
<br>&gt;     Taproot
<br>&gt;      &gt; keypath spends without disabling them, as Matthew Corall=
o proposes in the aforementioned mailing
<br>&gt;      &gt; list thread [4]. The P2TRH approach hashes public keys r=
ather than exposing them directly,
<br>&gt;      &gt; particularly benefiting:
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; - MuSig2 Lightning channel implementations
<br>&gt;      &gt;
<br>&gt;      &gt; - FROST-based MPC vaults
<br>&gt;      &gt;
<br>&gt;      &gt; - High-value transactions using private pools that don&#=
39;t reveal the block template
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; For those interested, take a look at the draft BIP for P=
2TRH here: <a href=3D"https://github.com/" target=3D"_blank" rel=3D"nofollo=
w" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps=
://github.com/&amp;source=3Dgmail&amp;ust=3D1741118741396000&amp;usg=3DAOvV=
aw0PXDXxRyje9aWE6zTaI4b9">https://github.com/</a>
<br>&gt;     cryptoquick/ &lt;<a href=3D"https://github.com/cryptoquick/" t=
arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Den&amp;q=3Dhttps://github.com/cryptoquick/&amp;source=3Dgmai=
l&amp;ust=3D1741118741396000&amp;usg=3DAOvVaw0Od5CcQAHj4RGiV4D1LVGF">https:=
//github.com/cryptoquick/</a>&gt;
<br>&gt;      &gt; bips/blob/p2trh/bip-p2trh.mediawiki &lt;<a href=3D"https=
://github.com/cryptoquick/bips/blob/p2trh/bip-" target=3D"_blank" rel=3D"no=
follow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3D=
https://github.com/cryptoquick/bips/blob/p2trh/bip-&amp;source=3Dgmail&amp;=
ust=3D1741118741396000&amp;usg=3DAOvVaw2D4p8rljBGJempzrVFT4wX">https://gith=
ub.com/cryptoquick/bips/blob/p2trh/bip-</a>
<br>&gt;     p2trh.mediawiki &lt;<a href=3D"https://github.com/cryptoquick/=
bips/blob/p2trh/bip-p2trh.mediawiki" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://git=
hub.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki&amp;source=3Dgmail&=
amp;ust=3D1741118741397000&amp;usg=3DAOvVaw20oTOsDE7Whwf3vYeEKr6G">https://=
github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki</a>&gt;&gt;
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; I have my hands full with P2QRH advocacy and development=
 and would prefer to focus on that,
<br>&gt;     but I
<br>&gt;      &gt; wanted to introduce P2TRH in case that is attractive as =
the community&#39;s preferred solution-- at
<br>&gt;      &gt; least for Taproot quantum security. The tradeoff is that=
 it adds 8.25 vB of overhead per
<br>&gt;     input, and
<br>&gt;      &gt; key tweaking might have slightly less utility for some a=
pplications, and it also doesn&#39;t protect
<br>&gt;      &gt; against short exposure quantum attacks as defined in BIP=
-360.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Returning to P2QRH and what&#39;s needed to push it acro=
ss the finish line...
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; I still need to finish the test vectors. I&#39;m impleme=
nting these using a fork of rust-bitcoin and
<br>&gt;      &gt; modeling them after Steven Roose&#39;s work on BIP-346. =
I&#39;ve been told that&#39;s not a blocker for
<br>&gt;     merging
<br>&gt;      &gt; the draft, but if it isn&#39;t merged by the time I&#39;=
m finished, hopefully that will provide some
<br>&gt;      &gt; additional impetus behind it.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; One concern Murch brought up is that introducing four ne=
w algorithms into the network was too
<br>&gt;     many--
<br>&gt;      &gt; adding too much complexity to the network and to wallets=
 and other applications-- and I agree.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Hopefully this is addressed to some degree by removing S=
QIsign (especially in its current state
<br>&gt;      &gt; lacking implementation maturity), and will help push the=
 BIP below a certain complexity
<br>&gt;     threshold,
<br>&gt;      &gt; making it somewhat easier to review.
<br>&gt;      &gt;
<br>&gt;      &gt; I think it&#39;s still important to include multiple sig=
nature algorithm options for users to select
<br>&gt;      &gt; their desired level of security. It&#39;s not 100% certa=
in that all of these algorithms will remain
<br>&gt;      &gt; quantum resistant for all time, so redundancy here is=E2=
=80=A6 key.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Another concern is that NIST level V is overkill. I have=
 less conviction on this since secp256k1
<br>&gt;      &gt; technically has 128 bits of security due to Pollard&#39;=
s rho attacks. But if the intention was
<br>&gt;     for 256
<br>&gt;      &gt; bits of security, should level V security be the default=
? It&#39;s difficult for me to say.
<br>&gt;     Perhaps both
<br>&gt;      &gt; level V and level I implementations could be included, b=
ut this would be a deviation from the
<br>&gt;     BIP as
<br>&gt;      &gt; presently specified, which defaults to level V security.=
 The disadvantage of including level I
<br>&gt;      &gt; support for each algorithm is that it essentially double=
s the complexity of libbitcoinpqc.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; Ultimately, I hope the default of NIST V and selection o=
f 3 mature NIST-approved algorithms
<br>&gt;      &gt; demonstrate a focused, polished, and conservative propos=
al.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; At this point, the major call to action I would like to =
highlight is simply the need for more
<br>&gt;      &gt; feedback from the community. Please review and provide f=
eedback here: <a href=3D"https://github.com/" target=3D"_blank" rel=3D"nofo=
llow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dht=
tps://github.com/&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DA=
OvVaw2UiusGAj3aIJYjfASeg0E5">https://github.com/</a>
<br>&gt;     bitcoin/ &lt;<a href=3D"https://github.com/bitcoin/" target=3D=
"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/ur=
l?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/&amp;source=3Dgmail&amp;ust=3D=
1741118741397000&amp;usg=3DAOvVaw17NedgAqZeWXkUFumrG-25">https://github.com=
/bitcoin/</a>&gt;
<br>&gt;      &gt; bips/pull/1670 &lt;<a href=3D"https://github.com/bitcoin=
/bips/pull/1670" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bips=
/pull/1670&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw3G=
HbeLGriHAo0PDFg4MnUJ">https://github.com/bitcoin/bips/pull/1670</a> &lt;<a =
href=3D"https://github.com/bitcoin/bips/" target=3D"_blank" rel=3D"nofollow=
" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps:=
//github.com/bitcoin/bips/&amp;source=3Dgmail&amp;ust=3D1741118741397000&am=
p;usg=3DAOvVaw1CWZ4SDgCBdkghP_nYDeh2">https://github.com/bitcoin/bips/</a>
<br>&gt;     pull/1670&gt;&gt;
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; I look forward to feedback and opinions on P2QRH and P2T=
RH.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; P.S. I&#39;ll be advocating for BIP-360 at OP_NEXT in VA=
, btc++ in Austin, Consensus in Toronto,
<br>&gt;     and BTC
<br>&gt;      &gt; 25 in Las Vegas, and later this year, TABConf in Atlanta=
.
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; [1] <a href=3D"https://pqshield.github.io/nist-sigs-zoo"=
 target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.goo=
gle.com/url?hl=3Den&amp;q=3Dhttps://pqshield.github.io/nist-sigs-zoo&amp;so=
urce=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw3uKCEZvCOk-wUKjIOCS=
Is4">https://pqshield.github.io/nist-sigs-zoo</a> &lt;<a href=3D"https://pq=
shield.github.io/nist-sigs-zoo" target=3D"_blank" rel=3D"nofollow" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://pqshield=
.github.io/nist-sigs-zoo&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;=
usg=3DAOvVaw3uKCEZvCOk-wUKjIOCSIs4">https://pqshield.github.io/nist-sigs-zo=
o</a>&gt;
<br>&gt;      &gt;
<br>&gt;      &gt; [2] <a href=3D"https://eprint.iacr.org/2023/1820.pdf" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://eprint.iacr.org/2023/1820.pdf&amp;source=
=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw1i1sLRaXURi4PLc4JF5xFr"=
>https://eprint.iacr.org/2023/1820.pdf</a> &lt;<a href=3D"https://eprint.ia=
cr.org/2023/1820.pdf" target=3D"_blank" rel=3D"nofollow" data-saferedirectu=
rl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://eprint.iacr.org/20=
23/1820.pdf&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw1=
i1sLRaXURi4PLc4JF5xFr">https://eprint.iacr.org/2023/1820.pdf</a>&gt;
<br>&gt;      &gt;
<br>&gt;      &gt; [3] <a href=3D"https://eprint.iacr.org/2024/1291.pdf" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://eprint.iacr.org/2024/1291.pdf&amp;source=
=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw2NqbvtsZ8pKzDc6XCC-eei"=
>https://eprint.iacr.org/2024/1291.pdf</a> &lt;<a href=3D"https://eprint.ia=
cr.org/2024/1291.pdf" target=3D"_blank" rel=3D"nofollow" data-saferedirectu=
rl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://eprint.iacr.org/20=
24/1291.pdf&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw2=
NqbvtsZ8pKzDc6XCC-eei">https://eprint.iacr.org/2024/1291.pdf</a>&gt;
<br>&gt;      &gt;
<br>&gt;      &gt; [4] <a href=3D"https://groups.google.com/g/bitcoindev/c/=
8O857bRSVV8/m/7uu4dZNgAwAJ" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.googl=
e.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ&amp;source=3Dgmail&amp;ust=
=3D1741118741397000&amp;usg=3DAOvVaw2FIwJvcVZq-M-Yx96lwlwM">https://groups.=
google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ</a> &lt;https://
<br>&gt;     <a href=3D"http://groups.google.com/g/bitcoindev/c/8O857bRSVV8=
/m/7uu4dZNgAwAJ" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Den&amp;q=3Dhttp://groups.google.com/g/bitc=
oindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ&amp;source=3Dgmail&amp;ust=3D1741118741=
397000&amp;usg=3DAOvVaw16_RKEtdn2v9DyQqdjRt56">groups.google.com/g/bitcoind=
ev/c/8O857bRSVV8/m/7uu4dZNgAwAJ</a>&gt;
<br>&gt;      &gt;
<br>&gt;      &gt; [5] <a href=3D"https://docs.securosys.com/tsb/Tutorials/=
Post-Quantum-Cryptography/pqc-release-overview" target=3D"_blank" rel=3D"no=
follow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3D=
https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-rele=
ase-overview&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw=
3dbZoWwCqw9F89HjGiTcQY">https://docs.securosys.com/tsb/Tutorials/Post-Quant=
um-Cryptography/pqc-release-overview</a>
<br>&gt;     &lt;<a href=3D"https://docs.securosys.com/tsb/Tutorials/Post-Q=
uantum-Cryptography/pqc-release-overview" target=3D"_blank" rel=3D"nofollow=
" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps:=
//docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-ov=
erview&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw3dbZoW=
wCqw9F89HjGiTcQY">https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cry=
ptography/pqc-release-overview</a>&gt;
<br>&gt;      &gt;
<br>&gt;      &gt;
<br>&gt;      &gt; --
<br>&gt;      &gt; You received this message because you are subscribed to =
the Google Groups &quot;Bitcoin Development
<br>&gt;      &gt; Mailing List&quot; group.
<br>&gt;      &gt; To unsubscribe from this group and stop receiving emails=
 from it, send an email to
<br>&gt;      &gt; <a href data-email-masked rel=3D"nofollow">bitcoindev+..=
.@googlegroups.com</a> &lt;mailto:<a href data-email-masked rel=3D"nofollow=
">bitcoindev+...@googlegroups.com</a>&gt;.
<br>&gt;      &gt; To view this discussion visit <a href=3D"https://groups.=
google.com/d/msgid/bitcoindev/8797807d-" target=3D"_blank" rel=3D"nofollow"=
 data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps:/=
/groups.google.com/d/msgid/bitcoindev/8797807d-&amp;source=3Dgmail&amp;ust=
=3D1741118741397000&amp;usg=3DAOvVaw3PhoGaavRBqTJ3lQuuoj_I">https://groups.=
google.com/d/msgid/bitcoindev/8797807d-</a>
<br>&gt;     e017-44e2- &lt;<a href=3D"https://groups.google.com/d/msgid/bi=
tcoindev/8797807d-e017-44e2-" target=3D"_blank" rel=3D"nofollow" data-safer=
edirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.goo=
gle.com/d/msgid/bitcoindev/8797807d-e017-44e2-&amp;source=3Dgmail&amp;ust=
=3D1741118741397000&amp;usg=3DAOvVaw3JRC8ejYM2zNEfPxmUcQum">https://groups.=
google.com/d/msgid/bitcoindev/8797807d-e017-44e2-</a>&gt;
<br>&gt;      &gt; b419-803291779007n%<a href=3D"http://40googlegroups.com"=
 target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.goo=
gle.com/url?hl=3Den&amp;q=3Dhttp://40googlegroups.com&amp;source=3Dgmail&am=
p;ust=3D1741118741397000&amp;usg=3DAOvVaw0YeuMgVQ39d7BY_j14PShP">40googlegr=
oups.com</a> &lt;<a href=3D"http://40googlegroups.com" target=3D"_blank" re=
l=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&a=
mp;q=3Dhttp://40googlegroups.com&amp;source=3Dgmail&amp;ust=3D1741118741397=
000&amp;usg=3DAOvVaw0YeuMgVQ39d7BY_j14PShP">http://40googlegroups.com</a>&g=
t; &lt;<a href=3D"https://groups.google.com/" target=3D"_blank" rel=3D"nofo=
llow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dht=
tps://groups.google.com/&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;=
usg=3DAOvVaw1pcoa4uH_hDSuQbFruu1Fy">https://groups.google.com/</a>
<br>&gt;     d/msgid/bitcoindev/8797807d- &lt;<a href=3D"https://groups.goo=
gle.com/d/msgid/bitcoindev/8797807d-" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gr=
oups.google.com/d/msgid/bitcoindev/8797807d-&amp;source=3Dgmail&amp;ust=3D1=
741118741397000&amp;usg=3DAOvVaw3PhoGaavRBqTJ3lQuuoj_I">https://groups.goog=
le.com/d/msgid/bitcoindev/8797807d-</a>&gt;
<br>&gt;      &gt; e017-44e2-b419-803291779007n%<a href=3D"http://40googleg=
roups.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=
=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&am=
p;q=3Dhttp://40googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&am=
p;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw1109f9oa_WgVHID=
OII6DVj">40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfooter</a>
<br>&gt;     &lt;<a href=3D"http://40googlegroups.com?utm_medium=3Demail&am=
p;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp://40googlegroups.com=
?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D1741=
118741397000&amp;usg=3DAOvVaw1109f9oa_WgVHIDOII6DVj">http://40googlegroups.=
com?utm_medium=3Demail&amp;utm_source=3Dfooter</a>&gt;&gt;.
<br>&gt;=20
<br>&gt; --=20
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development=20
<br>&gt; Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to=20
<br>&gt; <a href data-email-masked rel=3D"nofollow">bitcoindev+...@googlegr=
oups.com</a> &lt;mailto:<a href data-email-masked rel=3D"nofollow">bitcoind=
ev+...@googlegroups.com</a>&gt;.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-" target=3D"_blank" rel=3D"nofo=
llow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dht=
tps://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-&amp;sou=
rce=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw29uS576J6w8oCkbxLBOD=
sk">https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-</=
a>=20
<br>&gt; fa2fa35e2230n%<a href=3D"http://40googlegroups.com" target=3D"_bla=
nk" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttp://40googlegroups.com&amp;source=3Dgmail&amp;ust=3D174111=
8741397000&amp;usg=3DAOvVaw0YeuMgVQ39d7BY_j14PShP">40googlegroups.com</a> &=
lt;<a href=3D"https://groups.google.com/d/msgid/" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://groups.google.com/d/msgid/&amp;source=3Dgmail&amp;ust=3D17411187=
41397000&amp;usg=3DAOvVaw0gFbptRxLzDkebjeWDm6LG">https://groups.google.com/=
d/msgid/</a>=20
<br>&gt; bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%<a href=3D"http:/=
/40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_=
blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Den&amp;q=3Dhttp://40googlegroups.com?utm_medium%3Demail%26utm_source%3=
Dfooter&amp;source=3Dgmail&amp;ust=3D1741118741397000&amp;usg=3DAOvVaw1109f=
9oa_WgVHIDOII6DVj">40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter</a>&gt;.
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/54882e16-fdd2-4887-a429-189dd8aa7368n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/54882e16-fdd2-4887-a429-189dd8aa7368n%40googlegroups.com</a>.<br />

------=_Part_110589_1462965592.1741035434225--

------=_Part_110588_558513498.1741035434225--