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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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/ > 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/ > > > 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/ > > > 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 > > 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 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 < > 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 > > >. > >=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 >. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-=20 > > fa2fa35e2230n%40googlegroups.com > 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.

On Thursday, F= ebruary 27, 2025 at 7:41:08=E2=80=AFPM UTC-7 Matt Corallo wrote:
=
I think you're appr= oaching this from the wrong stance.

If our goal is to "make bitcoin Quantum-secure", its gonna ta= ke a decade for the state of PQ=20
research to build something that's ready for us to "just switc= h to". I don't buy that there's a=20
world where we get serious about adding something lattice-based to Bitc= oin for a longggg time (I'm=20
not sure I've ever heard a serious cryptographer suggest that latti= ce-based systems are a good idea,=20
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=20
confidence will still be secure in two decades (which basically is only= hash-based schemes) and get=20
wallets to include it in their taproot outputs. That gives wallets crea= ted today the possibility of=20
being robust in a QC world, but, indeed, it would require tough decisio= ns in the future.

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

TBH the whole "would we confiscate if the time comes" questio= n I think simply cannot be answered=20
today because it depends very, very much on specific details (eg lets s= ay we did the above proposal=20
and its been around for 30 years and ~all wallets support it, that'= s a very very different world=20
from, for example, deploying some PQC scheme under threat where a QC co= uld realistically steal coins=20
in five years). The only thing we can really do today is create the opt= ion 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= quite large. NIST has also=20
> approved ML-DSA and FN-DSA, which, while both are based on lattice= cryptography, they're not only=20
> standardized, but becoming widely supported. One consideration is = hardware acceleration, and I=20
> believe those three algorithms will have the best chance of having= 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= spends would need to be disabled=20
> and that has a confiscatory effect that I'm seeking to avoid i= n this BIP.
>=20
> An additional opcode should not be necessary if multisig capabilit= y is built into the attestation.
>=20
> I agree with your statement on full BIP-32 compatibility. BIP-360 = is just a starting point, and=20
> maybe you're right, it's best thought of as a "break = glass" implementation. It's not ideal, it's=20
> full of compromises, not everyone is 100% happy with it, and that&= #39;s 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 Cora= llo wrote:
>=20
> If we want to do something like this in the short to medium te= rm, IMO we should strip out all the
> signature schemes that are anything more than quite straightfo= rward in their security assumptions
> (i.e. only keep hash-based signatures, maybe just SPHINCS+), o= nly embed 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 "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= glass case, and long before then
> hopefully whatever we do today is replaced with something bett= er, with the knowledge that we'll
> gain
> on the way to "then". We'd still want to do it i= n an opcode so that we 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 propos= al (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 mitigatio= n strategy.
> >
> >
> > First, now that there's a BIP number assigned, you c= an find the update BIP here:
> >
> > https://github.com/crypt= oquick/bips/blob/p2qrh/bip-0360.mediawiki <https://gi= thub.com/
> cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> <https://github.com/cryptoquick/ <ht= tps://
> github.com/cryptoquick/>
> > bips/blob/p2qrh/bip-0360.mediawiki>
> >
> >
> > The revised BIP-360 draft reflects substantial changes s= ince initial publication, particularly
> > regarding algorithm selection. While we originally consi= dered SQIsign, it has 15,000x slower
> > verification compared to ECC [1]. If it takes 1 second t= o verify a fully ECC block, it would
> take 4
> > hours to validate a block filled with SQIsign transactio= ns. 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=99= t 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 t= he 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 ex= pect that to improve with time. It
> might be
> > worthwhile to shorten the list by making signature aggre= gation a requirement, so as not to
> regress
> > too far from Schnorr signatures. That said, I think thos= e capabilities should be introduced in a
> > separate BIP once they're more mature and worthwhile= .
> >
> >
> > Our current shortlist prioritizes FALCON for its signatu= re aggregation potential, with
> SPHINCS+ and
> > CRYSTALS-Dilithium as secondary candidates. However, maj= or 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 a= lso, how we should handle multisig
> wallets.
> >
> >
> > Additionally, I think it's worthwhile to restrict BI= P-360 to NIST-approved algorithms to
> maintain
> > FIPS compliance. That's because HSMs such as those p= rovided 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 configur= ation 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 need= s more scrutiny. We could use a sort
> of P2SH
> > approach, just modifying the semantics of OP_CHECKMULTIS= IG in a witness script to alias to
> public
> > keys in the attestation. But that could introduce additi= onal 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 i= t 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 ne= eds more thought and I'm open to
> > suggestions. Perhaps two additional bytes at the top lev= el of the SegWit v3 output hash could be
> > provided to indicate PQC signature threshold and total, = and those would be hashed and
> committed to
> > in the output, then provided in a field in the attestati= on once spent.
> >
> >
> > While finalizing PQC selections, I've also drafted P= 2TRH as an interim solution to secure
> Taproot
> > keypath spends without disabling them, as Matthew Corall= o proposes in the aforementioned mailing
> > list thread [4]. The P2TRH approach hashes public keys r= ather than exposing them directly,
> > particularly benefiting:
> >
> >
> > - MuSig2 Lightning channel implementations
> >
> > - FROST-based MPC vaults
> >
> > - High-value transactions using private pools that don&#= 39;t reveal the block template
> >
> >
> > For those interested, take a look at the draft BIP for P= 2TRH here: https://github.com/
> cryptoquick/ <https:= //github.com/cryptoquick/>
> > bips/blob/p2trh/bip-p2trh.mediawiki <https://gith= ub.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 a= pplications, 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 acro= ss the finish line...
> >
> >
> > I still need to finish the test vectors. I'm impleme= nting 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 ne= w 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 S= QIsign (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 sig= nature algorithm options for users to select
> > their desired level of security. It's not 100% certa= in that all of 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 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, b= ut 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 double= s the complexity of libbitcoinpqc.
> >
> >
> > Ultimately, I hope the default of NIST V and selection o= f 3 mature NIST-approved algorithms
> > demonstrate a focused, polished, and conservative propos= al.
> >
> >
> > At this point, the major call to action I would like to = highlight is simply the need for more
> > feedback from the community. Please review and provide f= eedback here: 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 P2T= RH.
> >
> >
> > 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-zo= o>
> >
> > [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 <https://
> groups.google.com/g/bitcoind= ev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
> >
> > [5] https://docs.securosys.com/tsb/Tutorials/Post-Quant= um-Cryptography/pqc-release-overview
> <https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cry= ptography/pqc-release-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 <mailto: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%40googlegr= oups.com <http://40googlegroups.com&g= t; <https://groups.google.com/
> d/msgid/bitcoindev/8797807d- <https://groups.goog= le.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= Groups "Bitcoin Development=20
> Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, = send an email to=20
> bitcoindev+...@googlegr= oups.com <mailto:bitcoind= ev+...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-=20
> fa2fa35e2230n%40googlegroups.com &= lt;https://groups.google.com/= d/msgid/=20
> bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com?utm_medium=3Demail&utm_source=3Df= ooter>.

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