path: root/c9/6eefba7349ead20e98fbf0b2f53efa9a73b02d

Delivery-date: Thu, 27 Feb 2025 18:41:15 -0800
Received: from mail-oo1-f57.google.com ([209.85.161.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBQGEQS7AMGQEKNOVLJA@googlegroups.com>)
	id 1tnqJN-0004qj-Oa
	for bitcoindev@gnusha.org; Thu, 27 Feb 2025 18:41:15 -0800
Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-5fcf2505ee7sf1744734eaf.0
        for <bitcoindev@gnusha.org>; Thu, 27 Feb 2025 18:41:13 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1740710468; cv=pass;
        d=google.com; s=arc-20240605;
        b=dYnXsqz+3a2cCExZQ0OtO4BpRVHuUhdrLSU64KgfD7sDKrMvtRQTCx2j/69SBpSMjz
         SWCxbyAVqxg/qf0MBVS1qFhQTfUPPAg6jm13Es4PK7BdBlDgBTYfkX34oTsbTf4zdanp
         Zf7LMKksnqJmuaTKIohqnbHKsf6NojyLu7eGeItoHgsvXkzj9GFJv5YZeZ0N/GEXQ9wV
         ytUXOj/vSeF2ZfNDaj50KFpUPH9zK+XVx1WE1zFNM90rdp6RuhUaqyo9b6QhDMEueUA4
         I1NBqZYaqtaxDbRRBKMYE4N/uwP/Pb0q23Nubki49sRzJfMYTfXh4+PSD7/VUeOryjTs
         0RiA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:content-transfer-encoding
         :in-reply-to:from:content-language:references:to:subject
         :mime-version:date:message-id:sender:dkim-signature;
        bh=O5qEtPozExPjl+q7xBE2d15BQgmXDQ64KQBxjoLsHlw=;
        fh=W06NSZMj5JwFrvyR0fGvME8v8Wkt3aam2+MxEZLQ+Bo=;
        b=J/5Ih9f7G6c7tYhZkoxoLdUli5aHvkDpfIZZ1gzmGB6xcBSwpDoZO6pXhKF2dH1jcM
         ddVkApbZgs919dbakk/aoOsGjSWD1Pe9rXUaaA8eviJeHZjYb4ZXuORMgiIDVfxFJOJG
         RB+6R+iXMc+VVSW8VuzwtwGgDnD83vuneji22qJahix3eBPMdfBIq0hmfI+bLZY/wEEp
         25mPRVyxwTpOyzNon/OhfEqvIu67BHCbR99sH4YWgjA1iTytVlg0YASEgdlyHcHCes54
         sKmFCJShRwxV0NnZlvH6x/6oiaxQ8rUphrn1xH8ZSLH2VlgxJpnVv0Rd4P4zK+yEWlCo
         wb1g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=jfVGfC7X;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=hWtyFmlA;
       spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1740710468; x=1741315268; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:in-reply-to:from
         :content-language:references:to:subject:mime-version:date:message-id
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=O5qEtPozExPjl+q7xBE2d15BQgmXDQ64KQBxjoLsHlw=;
        b=Gdw+ISnZOQIVdVUqNnqgs+FItqSx64pz89xj3IJIlSC0IE25rQ7Be6NtVJ64eZUXMa
         2US7tAo9BOA0LHWStcuSxPp/zrzzikwHZ1yqf70XSUq/oyCsSV71U2vhPlBwwZK5Ee0/
         A0tE+VAEAc8QXt+wEkk4RRxem1cGdXbMvtWj4hmaqDUws/FgdH2VYsssvEj9OYY3nagY
         s+5bSeI0IouvSnlTwy9SORk1AaS+IrLN80Pp+3l4joyiLjwIPSzy4i+w8nfmbPVJ3JzU
         DakaUF5SasQ/32SKH8/+XjmN4wGmog3rNoE1sTf+pX0PIUiFRvadsdDXLQLS5etv/qTV
         OV5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740710468; x=1741315268;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:in-reply-to:from
         :content-language:references:to:subject:mime-version:date:message-id
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=O5qEtPozExPjl+q7xBE2d15BQgmXDQ64KQBxjoLsHlw=;
        b=cwTSH2eEvoF/l2V5ik3k6HpMDjgYiHqrJBmdPCVR/KMCU3Py5tAZrri5Tl71rmeJNY
         p79n0vDtR0L/RIa1A7sjTtA1zm2jnPDcWeSm8OQouO1hoYJIfy8WnE67D1cfTdntfuSw
         ZLrk5MhJTc/RWDFBmkFjbOY17PcoDT3lpCvlW/9lBvMSBuWBNmNDHU1s+0rO96JtOAst
         Y4+auqzEhO9txiUS6S4TqVCNG1kpZ7UZ/1rUVw6CdGLt/QCgxyqLGfdrjr1zz7kCNVsN
         JuO3oUhYVeVSiXK5tBN4lSWeVkdV7+Wr+wolP05LqrYksa2/Ky7aCHc91fTA3BHl7kjc
         DLTw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXCIWBVmwtQWli4U4xJr3GsThDTC26wh3c+duwK7lJR2EbQrXUbSRZMAVbL2zxSbYrEL0BgTQ8jwPVi@gnusha.org
X-Gm-Message-State: AOJu0YxD60MHjjQbVQ09AeZslhsnMHN6TiMNMsefBAN4u824VWUB7ZJb
	iRhrPgI07q8J0yebGbBqaW1ZibVZSvFQkH1tdhQP33wcxtB5v+hV
X-Google-Smtp-Source: AGHT+IGCSHqLsVGZ3pP1fisDtKk41X4QnpHdvzM69c5IjCzh6b1PI4VUGxGMf9PQyPPeDKxUeIRCZQ==
X-Received: by 2002:a05:6820:2217:b0:5fc:e323:785e with SMTP id 006d021491bc7-5feb360c2c2mr853997eaf.5.1740710467922;
        Thu, 27 Feb 2025 18:41:07 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGvkJUWnH2OUJKoGADTkEQ/8I2KGPiWlz/x2XuglNgBCw==
Received: by 2002:a4a:e798:0:b0:5fc:f152:166a with SMTP id 006d021491bc7-5fea93386c1ls772393eaf.1.-pod-prod-07-us;
 Thu, 27 Feb 2025 18:41:04 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCVZUj/TDqnTUIdFU7O1zh2WQdS1G3jH94olaYgUp+mRbJ5FFGUAGGteddJcmBWOQ1HQtQ04Y1A9a/lr@googlegroups.com
X-Received: by 2002:a05:6808:f8f:b0:3f4:cae:d5bd with SMTP id 5614622812f47-3f558556c78mr1072488b6e.20.1740710464531;
        Thu, 27 Feb 2025 18:41:04 -0800 (PST)
Received: by 2002:a05:6808:424a:b0:3f4:4b9:4605 with SMTP id 5614622812f47-3f54e6a996dmsb6e;
        Wed, 26 Feb 2025 11:02:07 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCXZB6HkZZTb6lRJrwA7EAlkz+aTklVDlw28KHnMfWgfgCrzvLqQrCRPDGWq7TGaK1seEjeqh43uChFS@googlegroups.com
X-Received: by 2002:a05:6a21:999c:b0:1e1:aef4:9ce8 with SMTP id adf61e73a8af0-1f10ae2e320mr8370514637.28.1740596526623;
        Wed, 26 Feb 2025 11:02:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1740596526; cv=none;
        d=google.com; s=arc-20240605;
        b=ZRe6dYOSXnVHYvfDB4+Iw9yYu1gxpd8M3aUmr0Ae5VWPdOFCqaay851MmCPW8syLNw
         Dpt1oN+Ok+jlh+Fd5LTj+W/snqiBUkRkJ/8nq/D4TBP3w1z0WboGIRNuie5Og6qahaS/
         477aAnxWRkKrUiBhFB3CPQklT6Cz1yiLLoaQC3A0bUH9ERBegX/L9dzDuijIq2mgMHG+
         zLYoMQZ81fC3i4/lkr8CfnjaV4wWUuESPIlL6LJWW6zw1tdnqYjJxOOZlsW4iABDAB0a
         E+xQEoGuDhe/ulpk8oWZAHN/GaFHUdwPa3ehzaWRapkDQi2pEDDaKrVAW6X263bXXmj2
         IJ3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:mime-version:date:message-id:dkim-signature
         :dkim-signature;
        bh=/qDqiN7/R8NyDSnAVKaxkEuspVrnghYhI0sAw8oY+oM=;
        fh=hcqDlhfHQsGtLaEYlrnwkDWezRv3/z95KdJhX9TL5V4=;
        b=JXIEpQYhNuu+c7J23JAP7QGfQsnWqxDzlxH/DQnOqyZ3ccRDSyQ+pTilcgxhdZHYmA
         tSOtBFGaA7lzpY1mq6sWNMS06rbX7D3uFcye0NV1yEpaxBCAYdnsNA3D7kqgBiDS36/6
         5VK5IMbWxUefzJwVSt48c+Ztfgjxugg6H4ljzUWSi5gTnvp76JWOWhQAqNlIHv59lguR
         kK3oa1craqOiCgeeovhI/AAY+tYmuIBApIStJ9I3hH+n4n0QPY+Yr/K5qk4Wn6YSXuc5
         7o5XhRLyr3jYwBVkKNE79jHCkWv8ggrshL47mxTNOr8N/1XmZAxxKYpWR5U4Khg0nAdS
         syZQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=jfVGfC7X;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=hWtyFmlA;
       spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99])
        by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-aeda4a7a791si202972a12.0.2025.02.26.11.02.06
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 26 Feb 2025 11:02:06 -0800 (PST)
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99;
X-DKIM-Note: Keys used to sign are likely public at
X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and
X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
	(envelope-from <lf-lists@mattcorallo.com>)
	id 1tnMfT-0015YQ-2q;
	Wed, 26 Feb 2025 19:02:04 +0000
Message-ID: <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com>
Date: Wed, 26 Feb 2025 14:02:02 -0500
MIME-Version: 1.0
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
To: Hunter Beast <hunter@surmount.systems>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com>
 <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com>
 <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: lf-lists@mattcorallo.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@mattcorallo.com header.s=1740595262 header.b=jfVGfC7X;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265
 header.b=hWtyFmlA;       spf=pass (google.com: domain of lf-lists@mattcorallo.com
 designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
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.8 (/)

I think you're approaching this from the wrong stance.

If our goal is to "make bitcoin Quantum-secure", its gonna take a decade fo=
r the state of PQ=20
research to build something that's ready for us to "just switch to". I don'=
t buy that there's a=20
world where we get serious about adding something lattice-based to Bitcoin =
for a longggg time (I'm=20
not sure I've ever heard a serious cryptographer suggest that lattice-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 som=
ething that we have high=20
confidence will still be secure in two decades (which basically is only has=
h-based schemes) and get=20
wallets to include it in their taproot outputs. That gives wallets created =
today the possibility of=20
being robust in a QC world, but, indeed, it would require tough decisions i=
n the future.

If your view is that Bitcoin would simply be fine if we didn't confiscate a=
ny 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 t=
he keypath spends") if=20
you really feel strongly.

TBH the whole "would we confiscate if the time comes" question I think simp=
ly cannot be answered=20
today because it depends very, very much on specific details (eg lets say w=
e 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 could =
realistically steal coins=20
in five years). The only thing we can really do today is create the option =
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 crypto=
graphy, they're not only=20
> standardized, but becoming widely supported. One consideration is hardwar=
e acceleration, and I=20
> believe those three algorithms will have the best chance of having hardwa=
re 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 in this BIP.
>=20
> An additional opcode should not be necessary if multisig capability is bu=
ilt 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" implementatio=
n. It's not ideal, it's=20
> full of compromises, not everyone is 100% happy with it, and that's proba=
bly 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 wro=
te:
>=20
>     If we want to do something like this in the short to medium term, IMO=
 we should strip out all the
>     signature schemes that are anything more than quite straightforward i=
n their security assumptions
>     (i.e. only keep hash-based signatures, maybe just SPHINCS+), only emb=
ed 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 em=
bed 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 better, wit=
h the knowledge that we'll
>     gain
>     on the way to "then". We'd still want to do it in an opcode so that w=
e 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 BI=
P-360), I'm writing to share
>      > significant developments and request additional feedback on our po=
st-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 up=
date 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/c=
ryptoquick/ <https://
>     github.com/cryptoquick/>
>      > bips/blob/p2qrh/bip-0360.mediawiki>
>      >
>      >
>      > The revised BIP-360 draft reflects substantial changes since initi=
al publication, particularly
>      > regarding algorithm selection. While we originally considered SQIs=
ign, it has 15,000x slower
>      > verification compared to ECC [1]. If it takes 1 second to verify a=
 fully ECC block, it would
>     take 4
>      > hours to validate a block filled with SQIsign transactions. This h=
as obvious and concerning DDoS
>      > implications.
>      >
>      >
>      > While it would take a long time to signmany thousands of SQIsign t=
ransactions as well, the
>     increased
>      > time needed to sign the transactions likely won=E2=80=99t affect t=
he practicality of DDoS attacks--
>     another
>      > concern which has been brought to my attention. As such, I've deci=
ded to deprecate SQIsign
>     from the BIP.
>      >
>      >
>      > It's worth mentioning because it was brought up in the PR, there's=
 a new class of algorithms
>     that
>      > support signature aggregation, but they generally result in signat=
ures that are still quite
>     large.
>      > Chipmunk and RACCOON are good examples [2], [3]. I do expect that =
to improve with time. It
>     might be
>      > worthwhile to shorten the list by making signature aggregation a r=
equirement, so as not to
>     regress
>      > too far from Schnorr signatures. That said, I think those capabili=
ties should be introduced in a
>      > separate BIP once they're more mature and worthwhile.
>      >
>      >
>      > Our current shortlist prioritizes FALCON for its signature aggrega=
tion potential, with
>     SPHINCS+ and
>      > CRYSTALS-Dilithium as secondary candidates. However, major technic=
al challenges remain,
>     particularly
>      > BIP-32 compatibility issues affecting xpub generation in watch-onl=
y wallets, as detailed by
>      > conduition in another mailing list discussion [4], and also, how w=
e should handle multisig
>     wallets.
>      >
>      >
>      > Additionally, I think it's worthwhile to restrict BIP-360 to NIST-=
approved algorithms to
>     maintain
>      > FIPS compliance. That's because HSMs such as those provided by Sec=
urosys already have support
>     for
>      > all three algorithms [5], which is essential for secure deployment=
 of federated L2 treasuries.
>      >
>      >
>      > Presently, for multisigs, we have a merkle tree configuration defi=
ned for encumbering the output
>      > with multiple keys. While that's efficient, it's a novel construct=
ion. I'm not certain we should
>      > proceed with the merkle tree commitment scheme-- it needs more scr=
utiny. We could use a sort
>     of P2SH
>      > approach, just modifying the semantics of OP_CHECKMULTISIG in a wi=
tness script to alias to
>     public
>      > keys in the attestation. But that could introduce additional overh=
ead in a signature scheme that
>      > already uses a lot more space. Without this, however, we do not ye=
t have a way specified to
>     indicate
>      > thresholds or a locking script for the attestation, as it is desig=
ned to be purposely
>     limited, so as
>      > specified it is only capable of n/n multisig. I consider m/n multi=
sigs to be the single largest
>      > obvious omission in the spec right now. It definitely needs more t=
hought and I'm open to
>      > suggestions. Perhaps two additional bytes at the top level 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 attestation once sp=
ent.
>      >
>      >
>      > While finalizing PQC selections, I've also drafted P2TRH as an int=
erim solution to secure
>     Taproot
>      > keypath spends without disabling them, as Matthew Corallo proposes=
 in the aforementioned mailing
>      > list thread [4]. The P2TRH approach hashes public keys rather than=
 exposing them directly,
>      > particularly benefiting:
>      >
>      >
>      > - MuSig2 Lightning channel implementations
>      >
>      > - FROST-based MPC vaults
>      >
>      > - High-value transactions using private pools that don't reveal th=
e block template
>      >
>      >
>      > For those interested, take a look at the draft BIP for P2TRH here:=
 https://github.com/
>     cryptoquick/ <https://github.com/cryptoquick/>
>      > bips/blob/p2trh/bip-p2trh.mediawiki <https://github.com/cryptoquic=
k/bips/blob/p2trh/bip-
>     p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-p=
2trh.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 commun=
ity'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 application=
s, 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 =
line...
>      >
>      >
>      > I still need to finish the test vectors. I'm implementing these us=
ing 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, hopefu=
lly that will provide some
>      > additional impetus behind it.
>      >
>      >
>      > One concern Murch brought up is that introducing four new algorith=
ms into the network was too
>     many--
>      > adding too much complexity to the network and to wallets and other=
 applications-- and I agree.
>      >
>      >
>      > Hopefully this is addressed to some degree by removing SQIsign (es=
pecially in its current state
>      > lacking implementation maturity), and will help push the BIP below=
 a certain complexity
>     threshold,
>      > making it somewhat easier to review.
>      >
>      > I think it's still important to include multiple signature algorit=
hm options for users to select
>      > their desired level of security. It's not 100% certain that all of=
 these algorithms will remain
>      > quantum resistant for all time, so redundancy here is=E2=80=A6 key=
.
>      >
>      >
>      > Another concern is that NIST level V is overkill. I have less conv=
iction 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 dif=
ficult for me to say.
>     Perhaps both
>      > level V and level I implementations could be included, but this wo=
uld be a deviation from the
>     BIP as
>      > presently specified, which defaults to level V security. The disad=
vantage of including level I
>      > support for each algorithm is that it essentially doubles the comp=
lexity of libbitcoinpqc.
>      >
>      >
>      > Ultimately, I hope the default of NIST V and selection of 3 mature=
 NIST-approved algorithms
>      > demonstrate a focused, polished, and conservative proposal.
>      >
>      >
>      > At this point, the major call to action I would like to highlight =
is simply the need for more
>      > feedback from the community. Please review and provide feedback he=
re: https://github.com/
>     bitcoin/ <https://github.com/bitcoin/>
>      > bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670 <https:/=
/github.com/bitcoin/bips/
>     pull/1670>>
>      >
>      >
>      > I look forward to feedback and opinions on P2QRH and P2TRH.
>      >
>      >
>      > P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Aus=
tin, 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.git=
hub.io/nist-sigs-zoo>
>      >
>      > [2] https://eprint.iacr.org/2023/1820.pdf <https://eprint.iacr.org=
/2023/1820.pdf>
>      >
>      > [3] https://eprint.iacr.org/2024/1291.pdf <https://eprint.iacr.org=
/2024/1291.pdf>
>      >
>      > [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZN=
gAwAJ <https://
>     groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
>      >
>      > [5] https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptogr=
aphy/pqc-release-overview
>     <https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/p=
qc-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+...@googlegroup=
s.com>.
>      > To view this discussion visit https://groups.google.com/d/msgid/bi=
tcoindev/8797807d-
>     e017-44e2- <https://groups.google.com/d/msgid/bitcoindev/8797807d-e01=
7-44e2->
>      > b419-803291779007n%40googlegroups.com <http://40googlegroups.com> =
<https://groups.google.com/
>     d/msgid/bitcoindev/8797807d- <https://groups.google.com/d/msgid/bitco=
indev/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+unsubscribe@googlegroups.com <mailto:bitcoindev+unsubscribe@go=
oglegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/866ee206-4a4e-4cd6-9de3-=20
> fa2fa35e2230n%40googlegroups.com <https://groups.google.com/d/msgid/=20
> bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com?utm_m=
edium=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/=
2e0fc337-3603-4a22-8056-59cf7e21aa43%40mattcorallo.com.