From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 23 Feb 2025 15:53:31 -0800 Received: from mail-yb1-f185.google.com ([209.85.219.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tmLmr-0008JV-5D for bitcoindev@gnusha.org; Sun, 23 Feb 2025 15:53:30 -0800 Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e5dd887ae2esf5622849276.2 for ; Sun, 23 Feb 2025 15:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1740354803; x=1740959603; 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=YnAj7WcgFD/QQNDedUeZMWZEu5IYLqBdaoupSiNoCq0=; b=VZP+LMyfiS+1Vq3jE3f9BTdN8NVEfd8BEkgESOAUT3jlhtcVYO5LojqqTYmDVheJuG QwKO2POdRmuRjhi7VhwLETtjUEbfMZcYfpUs0lr7rPmSOCrZMzaITgoWcGfA3houmcAj yPFBDyOd3L3sKmKTTq4jPdjSEV2T8HuQYwTNx96lBEvteoTLRPvM36pIdQpucXIkh4Gw LhZeqOYfKUPXfXfGf+XRkXcoOkDJWYM2Jv+ekCAYCZJPtQlK2UE1ZIebE5qpf1U/7D8r AXAffEJli7yTNSHnbYLLqZ1uOHoADyFapTA0hkYb2VAdyhB+aAoOSzYBG+CkxvjtrhMk w5Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740354803; x=1740959603; 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=YnAj7WcgFD/QQNDedUeZMWZEu5IYLqBdaoupSiNoCq0=; b=bxqTQN6AnmEoty/9K3Ap442dRXl8ku0IxDUYNhB97fhuHLs4sayiCAoOPcZhkLXCAi JBqevnMLjzUF2Q/QkT355OR+EHCj83f/z++pvZtOmiFO2eS52snoU3SOfm5QeNff0Yzj Gs2MrgYa6nTJsVfLAEBaxVTkZTST8y8rpoR+YNwiwhfHv2gSdu3bxuiwJ5UyhzIW/v/H rUqwg06GK8zAMTICS6v/dkFSQY+p3uleEYK9F61Sprvlk+mg1eGO1p1erWYZrV/Pwonb DLswl0wR1A2iLhl4FgtHz6xxdnpvTAARwLBLQJbjKeiXtpKRIMemliOpGcFs73noJHbK /Wxw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWOmR09UrJA0LeMKUbPAHVNAd+WrlRxXYawVAP+OxNKZ1/R11fuKWjCuSX9j0ElyrbQnPcTcPPNb/mq@gnusha.org X-Gm-Message-State: AOJu0Yxtfc8JSNt1f0dUm8VDlmlTbQD1i1OyHUxMIQI4AORzj+SezzHo tZwcSUS3+fXJCPSfflNusvGY9I1OC0sZcxiFcjULj+cYGHp50M50 X-Google-Smtp-Source: AGHT+IFSdrrquoPfyT4SLcw6DpfObASjGAtOp2DsMkmgAlg78AUbeG5CoRXmPmf3Uppcffi3KlumCQ== X-Received: by 2002:a05:6902:e0e:b0:e58:9c24:5bcb with SMTP id 3f1490d57ef6-e5e8afcf57dmr7395992276.18.1740354803201; Sun, 23 Feb 2025 15:53:23 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFpA5NH1PgnB4hitRFYnCisKrrOlMchg+LNvlulMWoAmg== Received: by 2002:a25:8704:0:b0:e5b:3917:1c48 with SMTP id 3f1490d57ef6-e5e18cc812cls478355276.0.-pod-prod-09-us; Sun, 23 Feb 2025 15:53:20 -0800 (PST) X-Received: by 2002:a05:690c:67c7:b0:6f9:8b50:bac7 with SMTP id 00721157ae682-6fbcc37c773mr94078757b3.29.1740354800248; Sun, 23 Feb 2025 15:53:20 -0800 (PST) Received: by 2002:a05:690c:600d:b0:6f9:77a0:782b with SMTP id 00721157ae682-6fbcb177b37ms7b3; Sun, 23 Feb 2025 12:33:05 -0800 (PST) X-Received: by 2002:a05:690c:6e07:b0:6fb:b907:d965 with SMTP id 00721157ae682-6fbcc1f2389mr92894427b3.3.1740342784278; Sun, 23 Feb 2025 12:33:04 -0800 (PST) Date: Sun, 23 Feb 2025 12:33:03 -0800 (PST) From: Hunter Beast To: Bitcoin Development Mailing List Message-Id: <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com> In-Reply-To: <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com> References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com> <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com> Subject: Re: [bitcoindev] P2QRH / BIP-360 Update MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_369602_228522449.1740342783810" 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_369602_228522449.1740342783810 Content-Type: multipart/alternative; boundary="----=_Part_369603_27261957.1740342783810" ------=_Part_369603_27261957.1740342783810 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matt, The only problem with that approach is that SLH-DSA signatures are quite=20 large. NIST has also approved ML-DSA and FN-DSA, which, while both are=20 based on lattice cryptography, they're not only standardized, but becoming= =20 widely supported. One consideration is hardware acceleration, and I believe= =20 those three algorithms will have the best chance of having hardware=20 implementations as PQC extensions are added to CPUs and SoCs. As for gating P2TR, the problem with that approach is that keypath spends= =20 would need to be disabled and that has a confiscatory effect that I'm=20 seeking to avoid in this BIP. An additional opcode should not be necessary if multisig capability is=20 built into the attestation. I agree with your statement on full BIP-32 compatibility. BIP-360 is just a= =20 starting point, and maybe you're right, it's best thought of as a "break=20 glass" implementation. It's not ideal, it's full of compromises, not=20 everyone is 100% happy with it, and that's probably okay, because bitcoin= =20 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= : If we want to do something like this in the short to medium term, IMO we=20 should strip out all the=20 signature schemes that are anything more than quite straightforward in=20 their security assumptions=20 (i.e. only keep hash-based signatures, maybe just SPHINCS+), only embed=20 them in a taproot leaf, and=20 call it a day.=20 BIP 32 compatibility isn't a really huge deal if we're talking about an=20 "emergency break glass"=20 kinda setup - most wallets are set up with a root key and can just embed=20 the same PQ pubkey in all=20 of their outputs. The privacy cost is only realized in a break glass case,= =20 and long before then=20 hopefully whatever we do today is replaced with something better, with the= =20 knowledge that we'll gain=20 on the way to "then". We'd still want to do it in an opcode so that we can= =20 do multisig, though.=20 Matt=20 On 2/19/25 10:40 AM, Hunter Beast wrote:=20 > Dear Bitcoin Dev Community,=20 >=20 >=20 > A bit over six months after introducing the P2QRH proposal (now BIP-360),= =20 I'm writing to share=20 > significant developments and request additional feedback on our=20 post-quantum roadmap, and I'd also=20 > like to mention a potential P2TRH post-quantum mitigation strategy.=20 >=20 >=20 > First, now that there's a BIP number assigned, you can find the update=20 BIP here:=20 >=20 > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki < https://github.com/cryptoquick/=20 > bips/blob/p2qrh/bip-0360.mediawiki>=20 >=20 >=20 > The revised BIP-360 draft reflects substantial changes since initial=20 publication, particularly=20 > regarding algorithm selection. While we originally considered SQIsign, it= =20 has 15,000x slower=20 > verification compared to ECC [1]. If it takes 1 second to verify a fully= =20 ECC block, it would take 4=20 > hours to validate a block filled with SQIsign transactions. This has=20 obvious and concerning DDoS=20 > implications.=20 >=20 >=20 > While it would take a long time to signmany thousands of SQIsign=20 transactions as well, the increased=20 > time needed to sign the transactions likely won=E2=80=99t affect the prac= ticality=20 of DDoS attacks-- another=20 > concern which has been brought to my attention. As such, I've decided to= =20 deprecate SQIsign from the BIP.=20 >=20 >=20 > It's worth mentioning because it was brought up in the PR, there's a new= =20 class of algorithms that=20 > support signature aggregation, but they generally result in signatures=20 that are still quite large.=20 > Chipmunk and RACCOON are good examples [2], [3]. I do expect that to=20 improve with time. It might be=20 > worthwhile to shorten the list by making signature aggregation a=20 requirement, so as not to regress=20 > too far from Schnorr signatures. That said, I think those capabilities=20 should be introduced in a=20 > separate BIP once they're more mature and worthwhile.=20 >=20 >=20 > Our current shortlist prioritizes FALCON for its signature aggregation=20 potential, with SPHINCS+ and=20 > CRYSTALS-Dilithium as secondary candidates. However, major technical=20 challenges remain, particularly=20 > BIP-32 compatibility issues affecting xpub generation in watch-only=20 wallets, as detailed by=20 > conduition in another mailing list discussion [4], and also, how we=20 should handle multisig wallets.=20 >=20 >=20 > Additionally, I think it's worthwhile to restrict BIP-360 to=20 NIST-approved algorithms to maintain=20 > FIPS compliance. That's because HSMs such as those provided by Securosys= =20 already have support for=20 > all three algorithms [5], which is essential for secure deployment of=20 federated L2 treasuries.=20 >=20 >=20 > Presently, for multisigs, we have a merkle tree configuration defined for= =20 encumbering the output=20 > with multiple keys. While that's efficient, it's a novel construction.=20 I'm not certain we should=20 > proceed with the merkle tree commitment scheme-- it needs more scrutiny.= =20 We could use a sort of P2SH=20 > approach, just modifying the semantics of OP_CHECKMULTISIG in a witness= =20 script to alias to public=20 > keys in the attestation. But that could introduce additional overhead in= =20 a signature scheme that=20 > already uses a lot more space. Without this, however, we do not yet have= =20 a way specified to indicate=20 > thresholds or a locking script for the attestation, as it is designed to= =20 be purposely limited, so as=20 > specified it is only capable of n/n multisig. I consider m/n multisigs to= =20 be the single largest=20 > obvious omission in the spec right now. It definitely needs more thought= =20 and I'm open to=20 > suggestions. Perhaps two additional bytes at the top level of the SegWit= =20 v3 output hash could be=20 > provided to indicate PQC signature threshold and total, and those would= =20 be hashed and committed to=20 > in the output, then provided in a field in the attestation once spent.=20 >=20 >=20 > While finalizing PQC selections, I've also drafted P2TRH as an interim=20 solution to secure Taproot=20 > keypath spends without disabling them, as Matthew Corallo proposes in the= =20 aforementioned mailing=20 > list thread [4]. The P2TRH approach hashes public keys rather than=20 exposing them directly,=20 > particularly benefiting:=20 >=20 >=20 > - MuSig2 Lightning channel implementations=20 >=20 > - FROST-based MPC vaults=20 >=20 > - High-value transactions using private pools that don't reveal the block= =20 template=20 >=20 >=20 > For those interested, take a look at the draft BIP for P2TRH here:=20 https://github.com/cryptoquick/=20 > bips/blob/p2trh/bip-p2trh.mediawiki < https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki>=20 >=20 >=20 > I have my hands full with P2QRH advocacy and development and would prefer= =20 to focus on that, but I=20 > wanted to introduce P2TRH in case that is attractive as the community's= =20 preferred solution-- at=20 > least for Taproot quantum security. The tradeoff is that it adds 8.25 vB= =20 of overhead per input, and=20 > key tweaking might have slightly less utility for some applications, and= =20 it also doesn't protect=20 > against short exposure quantum attacks as defined in BIP-360.=20 >=20 >=20 > Returning to P2QRH and what's needed to push it across the finish line...= =20 >=20 >=20 > I still need to finish the test vectors. I'm implementing these using a= =20 fork of rust-bitcoin and=20 > modeling them after Steven Roose's work on BIP-346. I've been told that's= =20 not a blocker for merging=20 > the draft, but if it isn't merged by the time I'm finished, hopefully=20 that will provide some=20 > additional impetus behind it.=20 >=20 >=20 > One concern Murch brought up is that introducing four new algorithms into= =20 the network was too many--=20 > adding too much complexity to the network and to wallets and other=20 applications-- and I agree.=20 >=20 >=20 > Hopefully this is addressed to some degree by removing SQIsign=20 (especially in its current state=20 > lacking implementation maturity), and will help push the BIP below a=20 certain complexity threshold,=20 > making it somewhat easier to review.=20 >=20 > I think it's still important to include multiple signature algorithm=20 options for users to select=20 > their desired level of security. It's not 100% certain that all of these= =20 algorithms will remain=20 > quantum resistant for all time, so redundancy here is=E2=80=A6 key.=20 >=20 >=20 > Another concern is that NIST level V is overkill. I have less conviction= =20 on this since secp256k1=20 > technically has 128 bits of security due to Pollard's rho attacks. But if= =20 the intention was for 256=20 > bits of security, should level V security be the default? It's difficult= =20 for me to say. Perhaps both=20 > level V and level I implementations could be included, but this would be= =20 a deviation from the BIP as=20 > presently specified, which defaults to level V security. The disadvantage= =20 of including level I=20 > support for each algorithm is that it essentially doubles the complexity= =20 of libbitcoinpqc.=20 >=20 >=20 > Ultimately, I hope the default of NIST V and selection of 3 mature=20 NIST-approved algorithms=20 > demonstrate a focused, polished, and conservative proposal.=20 >=20 >=20 > At this point, the major call to action I would like to highlight is=20 simply the need for more=20 > feedback from the community. Please review and provide feedback here:=20 https://github.com/bitcoin/=20 > bips/pull/1670 =20 >=20 >=20 > I look forward to feedback and opinions on P2QRH and P2TRH.=20 >=20 >=20 > P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin,=20 Consensus in Toronto, and BTC=20 > 25 in Las Vegas, and later this year, TABConf in Atlanta.=20 >=20 >=20 >=20 > [1] https://pqshield.github.io/nist-sigs-zoo=20 >=20 > [2] https://eprint.iacr.org/2023/1820.pdf=20 >=20 > [3] https://eprint.iacr.org/2024/1291.pdf=20 >=20 > [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ= =20 >=20 > [5]=20 https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-rele= ase-overview=20 >=20 >=20 > --=20 > You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development=20 > Mailing List" group.=20 > To unsubscribe from this group and stop receiving emails from it, send an= =20 email to=20 > bitcoindev+...@googlegroups.com .= =20 > To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-=20 > b419-803291779007n%40googlegroups.com < https://groups.google.com/d/msgid/bitcoindev/8797807d-=20 > 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 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/= 866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com. ------=_Part_369603_27261957.1740342783810 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matt,

The only problem with that approach is that S= LH-DSA signatures are quite large. NIST has also approved ML-DSA and FN-DSA= , which, while both are based on lattice cryptography, they're not only sta= ndardized, but becoming widely supported. One consideration is hardware acc= eleration, and I believe those three algorithms will have the best chance o= f having hardware implementations as PQC extensions are added to CPUs and S= oCs.

As for gating P2TR, the problem with that a= pproach is that keypath spends would need to be disabled and that has a con= fiscatory effect that I'm seeking to avoid in this BIP.

An additional opcode should not be necessary if multisig capability= is built into the attestation.

I agree with you= r 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" implementa= tion. 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 d= oesn't have to be in order to work.

Thank you fo= r your thoughts.

Hunter

On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Cor= allo wrote:
If we want to do= something like this in the short to medium term, IMO we should strip out a= ll the=20
signature schemes that are anything more than quite straightforward i= n their security assumptions=20
(i.e. only keep hash-based signatures, maybe just SPHINCS+), only emb= ed them in a taproot leaf, and=20
call it a day.

BIP 32 compatibility isn't a really huge deal if we're talking about = an "emergency break glass"=20
kinda setup - most wallets are set up with a root key and can just em= bed the same PQ pubkey in all=20
of their outputs. The privacy cost is only realized in a break glass = case, and long before then=20
hopefully whatever we do today is replaced with something better, wit= h the knowledge that we'll gain=20
on the way to "then". We'd still want to do it in an opcode so that w= e can do multisig, though.

Matt

On 2/19/25 10:40 AM, Hunter Beast wrote:
> Dear Bitcoin Dev Community,
>=20
>=20
> A bit over six months after introducing the P2QRH proposal (now = BIP-360), I'm writing to share=20
> significant developments and request additional feedback on our = post-quantum roadmap, and I'd also=20
> like to mention a potential P2TRH post-quantum mitigation strate= gy.
>=20
>=20
> First, now that there's a BIP number assigned, you can find the = update BIP here:
>=20
> https://github.com/cryptoq= uick/bips/blob/p2qrh/bip-0360.mediawiki <https://github.com/cryp= toquick/=20
> bips/blob/p2qrh/bip-0360.mediawiki>
>=20
>=20
> The revised BIP-360 draft reflects substantial changes since ini= tial publication, particularly=20
> regarding algorithm selection. While we originally considered SQ= Isign, it has 15,000x slower=20
> verification compared to ECC [1]. If it takes 1 second to verify= a fully ECC block, it would take 4=20
> hours to validate a block filled with SQIsign transactions. This= has obvious and concerning DDoS=20
> implications.
>=20
>=20
> While it would take a long time to signmany thousands of SQIsign= transactions as well, the increased=20
> time needed to sign the transactions likely won=E2=80=99t affect= the practicality of DDoS attacks-- another=20
> concern which has been brought to my attention. As such, I've de= cided to deprecate SQIsign from the BIP.
>=20
>=20
> It's worth mentioning because it was brought up in the PR, there= 's a new class of algorithms that=20
> support signature aggregation, but they generally result in sign= atures that are still quite large.=20
> Chipmunk and RACCOON are good examples [2], [3]. I do expect tha= t to improve with time. It might be=20
> worthwhile to shorten the list by making signature aggregation a= requirement, so as not to regress=20
> too far from Schnorr signatures. That said, I think those capabi= lities should be introduced in a=20
> separate BIP once they're more mature and worthwhile.
>=20
>=20
> Our current shortlist prioritizes FALCON for its signature aggre= gation potential, with SPHINCS+ and=20
> CRYSTALS-Dilithium as secondary candidates. However, major techn= ical challenges remain, particularly=20
> BIP-32 compatibility issues affecting xpub generation in watch-o= nly wallets, as detailed by=20
> conduition in another mailing list discussion [4], and also, how= we should handle multisig wallets.
>=20
>=20
> Additionally, I think it's worthwhile to restrict BIP-360 to NIS= T-approved algorithms to maintain=20
> FIPS compliance. That's because HSMs such as those provided by S= ecurosys already have support for=20
> all three algorithms [5], which is essential for secure deployme= nt of federated L2 treasuries.
>=20
>=20
> Presently, for multisigs, we have a merkle tree configuration de= fined for encumbering the output=20
> with multiple keys. While that's efficient, it's a novel constru= ction. I'm not certain we should=20
> proceed with the merkle tree commitment scheme-- it needs more s= crutiny. We could use a sort of P2SH=20
> approach, just modifying the semantics of OP_CHECKMULTISIG in a = witness script to alias to public=20
> keys in the attestation. But that could introduce additional ove= rhead in a signature scheme that=20
> already uses a lot more space. Without this, however, we do not = yet have a way specified to indicate=20
> thresholds or a locking script for the attestation, as it is des= igned to be purposely limited, so as=20
> specified it is only capable of n/n multisig. I consider m/n mul= tisigs to be the single largest=20
> obvious omission in the spec right now. It definitely needs more= thought and I'm open to=20
> suggestions. Perhaps two additional bytes at the top level of th= e SegWit v3 output hash could be=20
> provided to indicate PQC signature threshold and total, and thos= e would be hashed and committed to=20
> in the output, then provided in a field in the attestation once = spent.
>=20
>=20
> While finalizing PQC selections, I've also drafted P2TRH as an i= nterim solution to secure Taproot=20
> keypath spends without disabling them, as Matthew Corallo propos= es in the aforementioned mailing=20
> list thread [4]. The P2TRH approach hashes public keys rather th= an exposing them directly,=20
> particularly benefiting:
>=20
>=20
> - MuSig2 Lightning channel implementations
>=20
> - FROST-based MPC vaults
>=20
> - High-value transactions using private pools that don't reveal = the block template
>=20
>=20
> For those interested, take a look at the draft BIP for P2TRH her= e: https://github.com/cryptoquick/=20
> bips/blob/p2trh/bip-p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.med= iawiki>
>=20
>=20
> I have my hands full with P2QRH advocacy and development and wou= ld prefer to focus on that, but I=20
> wanted to introduce P2TRH in case that is attractive as the comm= unity's preferred solution-- at=20
> least for Taproot quantum security. The tradeoff is that it adds= 8.25 vB of overhead per input, and=20
> key tweaking might have slightly less utility for some applicati= ons, and it also doesn't protect=20
> against short exposure quantum attacks as defined in BIP-360.
>=20
>=20
> Returning to P2QRH and what's needed to push it across the finis= h line...
>=20
>=20
> I still need to finish the test vectors. I'm implementing these = using a fork of rust-bitcoin and=20
> modeling them after Steven Roose's work on BIP-346. I've been to= ld that's not a blocker for merging=20
> the draft, but if it isn't merged by the time I'm finished, hope= fully that will provide some=20
> additional impetus behind it.
>=20
>=20
> One concern Murch brought up is that introducing four new algori= thms into the network was too many--=20
> adding too much complexity to the network and to wallets and oth= er applications-- and I agree.
>=20
>=20
> Hopefully this is addressed to some degree by removing SQIsign (= especially in its current state=20
> lacking implementation maturity), and will help push the BIP bel= ow a certain complexity threshold,=20
> making it somewhat easier to review.
>=20
> I think it's still important to include multiple signature algor= ithm options for users to select=20
> their desired level of security. It's not 100% certain that all = of these algorithms will remain=20
> quantum resistant for all time, so redundancy here is=E2=80=A6 k= ey.
>=20
>=20
> Another concern is that NIST level V is overkill. I have less co= nviction on this since secp256k1=20
> technically has 128 bits of security due to Pollard's rho attack= s. But if the intention was for 256=20
> bits of security, should level V security be the default? It's d= ifficult for me to say. Perhaps both=20
> level V and level I implementations could be included, but this = would be a deviation from the BIP as=20
> presently specified, which defaults to level V security. The dis= advantage of including level I=20
> support for each algorithm is that it essentially doubles the co= mplexity of libbitcoinpqc.
>=20
>=20
> Ultimately, I hope the default of NIST V and selection of 3 matu= re NIST-approved algorithms=20
> demonstrate a focused, polished, and conservative proposal.
>=20
>=20
> At this point, the major call to action I would like to highligh= t is simply the need for more=20
> feedback from the community. Please review and provide feedback = here: https://github.com/bitcoin/=20
> bips/pull/1670 <https://github.com/bitcoin/bips= /pull/1670>
>=20
>=20
> I look forward to feedback and opinions on P2QRH and P2TRH.
>=20
>=20
> P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in A= ustin, Consensus in Toronto, and BTC=20
> 25 in Las Vegas, and later this year, TABConf in Atlanta.
>=20
>=20
>=20
> [1] https://pqshield.github.io/nist-sigs-zoo
>=20
> [2] https://eprint.iacr.org/2023/1820.pdf
>=20
> [3] https://eprint.iacr.org/2024/1291.pdf
>=20
> [4] https://groups.googl= e.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
>=20
> [5] = https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-rele= ase-overview
>=20
>=20
> --=20
> You received this message because you are subscribed to the Goog= le Groups "Bitcoin Development=20
> Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it= , send an email to=20
> bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com<= /a>>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-=20
> b419-803291779007n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/8797807d-=20
> e017-44e2-b419-803291779007n%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com.
------=_Part_369603_27261957.1740342783810-- ------=_Part_369602_228522449.1740342783810--