path: root/31/c80f621c9a351b4c56d16d9f3a05a793a32919

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

------=_Part_369603_27261957.1740342783810--

------=_Part_369602_228522449.1740342783810--