path: root/39/186a6125d581ced335843fad0a98c001ae7c31

Delivery-date: Wed, 19 Feb 2025 10:47:12 -0800
Received: from mail-qv1-f63.google.com ([209.85.219.63])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCXOL6U6XMBRBJWO3C6QMGQEZ4MMVXY@googlegroups.com>)
	id 1tkp6E-0007CI-TX
	for bitcoindev@gnusha.org; Wed, 19 Feb 2025 10:47:12 -0800
Received: by mail-qv1-f63.google.com with SMTP id 6a1803df08f44-6e65a5ee5f0sf21613676d6.1
        for <bitcoindev@gnusha.org>; Wed, 19 Feb 2025 10:47:11 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1739990825; cv=pass;
        d=google.com; s=arc-20240605;
        b=gwOHr4M07kNdwj3i6fm46wGU35sMH2GiKkSDa8UJrrtyewzDhKEu396BqSdyMKcY/4
         vIoTYU3b/DwiAXdeIMNUjofZEJ7WnrJazTpH/LzKUXZVWO0eb+DT2X99mkICaHe+WcGR
         x9M+bb78FJwJzvQJg88gcyLNj2Mv6bLmF7f+787eCeSEMJt8Hvskr3Q97ILnsj1/fHWw
         P1OuUMBin44IFOQBJEzXHj1LFe08/F+yX+WEBONGmWKiqiZgoKiFhHSfpFpaninWYr4K
         YBNbgloTDiv9CeZoDQO5xQb+kGnjxOPMmTkmUNGyxSDo4aIcEhTP4UVq4PC0g690b40H
         Y7OQ==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=tgqXN5U/X6N3bY18SHRlZu7CztVFtfNYOtLTD+xiUPo=;
        fh=LL7DrqC0UHhKGIi7Sfa3wDoZNjDvfjUddvOyBr3Mmv8=;
        b=liccclTm/ePMPVwbfYpAp1f5CAGZaCHvNh1idzqtEhw/gEgOr8FrcEHBCuZdpa6gFe
         ysOp909RDoo392GjIRVGSN+aQOx7yQZ/xmktEqpRS6DPFLHhm3SMCiyL2VfaPG5P/+k7
         EdJypvrlbHy6VBCZmgeprafSQmpsO8gDaObwNKYUOSI0bJa0vio0exDzg6ItMrQ7DxNz
         gKWSxLNnKU955rbd3ETQmZqfgLHLiz0DUs4WAWAgBSEYiOFOzdRemoSopzn7rPYk44Y8
         appSmXmi7m8Mioza35uetfx/9R793ZV9wgr9DA2FytFMhBjS6K2IzimoJu1KjBm6rAj5
         Lecg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=J4C0EGqc;
       spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c2a as permitted sender) smtp.mailfrom=dustinvonsandwich@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1739990825; x=1740595625; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tgqXN5U/X6N3bY18SHRlZu7CztVFtfNYOtLTD+xiUPo=;
        b=q68z5t4bTdnZZHSX30DsodPDxTNJMcQdjJhaRgmYXTzIuzYW4Ir54+93X0upA7LCrH
         /n7kFofVVyCJhLip+uMRSlJR7ahcjfn+OBESzjuxWISObuz9uv+kNDBsAULTFZVYynlM
         gjp8MC9bZXPzLchTf8A05nMaHHvee8jADJ122U3xQLDk5XrQ27/4G4xBpzMbNtP1+3pF
         0HnHoPSUF6mrZSH/KKKYdUhnIGcELrga3pdF+fjTdA1Ykhq02iKFsXk8Syn08nvdtH+m
         ewTE4NS5O+IrlMQuSFl7K4HL9T20xv1docLWA6g5Fm8AUx/0YSkQxqnX4OLaDwVR+PII
         katQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1739990825; x=1740595625; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=tgqXN5U/X6N3bY18SHRlZu7CztVFtfNYOtLTD+xiUPo=;
        b=hN8S51tZN2usgXlkQbVKMN4Z/rcrk2k8ORTeGPhK/vobDJRmsG5Cu/X0BhiFU+SDGk
         g0jLP0uVaEC4HOfYA4Djqhdq4Crswi71jRLa29YaMGr0hnq+iExvxClc5CwCaiAoouoK
         v9LVaaL4qpUmW9c8uFZGKUirg2dX2yqX1RYJZ3f3Ns8IINIajcbncKtxzTy0J8lpxUOY
         Vwc5UmGgqQJIMnh2NuaOEYb25DkXKm9+BvAaT1veQcIO28pyiIHtP21duqAB++4no9Bo
         kqsUO5g89lVSSxbUODJu/u9Y3s0iM+xmjRE8W+mk0Jf90Jz0rOuM3VLqR4wVBwgdHhvB
         KWqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1739990825; x=1740595625;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=tgqXN5U/X6N3bY18SHRlZu7CztVFtfNYOtLTD+xiUPo=;
        b=kUdHRL8vO5nzVw9i7SmnVXFa5acPPuwsNkWGD3d9otfdnBFpEY8x/r5rU3EbybkR5T
         l/b58xjJTi9E94UVGsHR0GBaf9gPayiK8MIhMvMN2v5WFCfe4PT7DTwnOtFxpqGgC8IH
         VDUJnilMlAruMIY39Ks7MelmOtBTVIDKriAohi9VRHDtftiTPErmHTDiqlyH1TgS2rH9
         sfAHKkTvVR08aptUGNhQT+CJpPCX8gg/sk6xvybA5bnCYrUon1YtJjgnm2/E6EoT6+c2
         aJdd4KAgmtMuTvzZ89X+r9ebNK+QFbZONscoVtyiOVbFR8/LeFQZvIfUoqlWy5X0W4nV
         oX6w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVdv6H6xUu/sEXgLKnqUqvV2Vk8KAW+xJZlDquby3A1u0tiX29Zq3xgI+6un4eA0HKuvawGuq2rCc7c@gnusha.org
X-Gm-Message-State: AOJu0YySrFrx6Atv1JKrITzPFxnTuK2I2jordbJs4E6Cd3/MkYUl17DA
	tL20X38eAjcrIV9L/TYci8/sbY0yn6CzCmkdW+BxKjJEkw0aSK0R
X-Google-Smtp-Source: AGHT+IELUG/aPEoA1GsDhvOYkz5JqFt19poIUJ24SPC/P5qP6M/rWP8nK4lkfOQHH9Z1y/g9ehW0Gw==
X-Received: by 2002:a05:622a:3c9:b0:471:bdbd:2f05 with SMTP id d75a77b69052e-4721517e8b4mr4370201cf.25.1739990824618;
        Wed, 19 Feb 2025 10:47:04 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFXK6LOBuMJT+UZCP+Y1vL1Z30ruHTPkXACiUo0Rf+4Mg==
Received: by 2002:a05:622a:103:b0:471:b736:6cc1 with SMTP id
 d75a77b69052e-47214fa89cbls1431021cf.1.-pod-prod-00-us; Wed, 19 Feb 2025
 10:47:02 -0800 (PST)
X-Received: by 2002:a05:620a:444c:b0:7c0:a260:ec1b with SMTP id af79cd13be357-7c0c228d3d7mr39087985a.25.1739990821913;
        Wed, 19 Feb 2025 10:47:01 -0800 (PST)
Received: by 2002:a05:620a:1a1d:b0:7c0:bbff:9f72 with SMTP id af79cd13be357-7c0bc00457bms85a;
        Wed, 19 Feb 2025 09:23:55 -0800 (PST)
X-Received: by 2002:a05:6214:2aa7:b0:6e4:25ff:4bac with SMTP id 6a1803df08f44-6e6a25ba7e8mr677016d6.10.1739985834783;
        Wed, 19 Feb 2025 09:23:54 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1739985834; cv=none;
        d=google.com; s=arc-20240605;
        b=FGoyu2Z2htWdoEExe5HCZfBcPOjE5Yaq1F4yg3MfTji2zGJjVnmo8901SGVkx0MvAp
         QRgf4hS1azinwcNpXdomSTJZrOsW0XQODDxhg4ImgR9P/wTHCmXNH6h+KCQzvzwi2muu
         LXZjPuIzIlLg0szE+3AxhT2wCigFkabTNs8LZv/oJAvO8cOGNte/QkTEihmA7RQoXWK4
         oWR/raypd2K+MDXAgSWKZVbvp9xTrkagzqIT62m6bjQ+gs8pDCCubahgv9cUY78Hurp/
         vnZ8C9Zcv6TyE6kZ8HvXW1RcmV3ksjNhqCda+4oP6wvBTo05JVSvsOiO6/edslRvIj/Z
         DgLg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=ddjiyD1ZSwwfCaVeBBJ7M3etoc99xnhmaaaS/xhrPFo=;
        fh=oW5/5oUmRRMvy96u/Fl5uZTynMYP3W/WShfBcMiH4EY=;
        b=Xa+8r/cuuwepenNusdzStOBZ+0TLTk6C/wwV8+WxvEUxXaTXTtzF4c5E4fybRRA5Pt
         z5VwSRf1NYdMfim/XUvdT8YYTMgqJz7DdYr0alxkWFM5ZN77BwRwGXEt2je8g11lxyum
         iLAfzHpTQpsAqb0iMmYuDJrMandVt8D6jw461e0ImdsUopy1zexlW1a2jeQ9NJsvTx60
         GaCpo0BHnQ6NzrkujvL6jHIH7YJH6hOMnR61gDxScXGbEgDlwfugOwiCkIT69KhQkaMB
         Jg8kV87GFfm70523lTmXp/7r8NWonOc/W3oZ0tOfKRD0oKw/7ygL1ldxBH/wukZXDzOV
         dgBA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=J4C0EGqc;
       spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c2a as permitted sender) smtp.mailfrom=dustinvonsandwich@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com. [2607:f8b0:4864:20::c2a])
        by gmr-mx.google.com with ESMTPS id 6a1803df08f44-6e65d9a14c5si6439396d6.7.2025.02.19.09.23.54
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 19 Feb 2025 09:23:54 -0800 (PST)
Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c2a as permitted sender) client-ip=2607:f8b0:4864:20::c2a;
Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-5fcd811d939so666921eaf.0
        for <bitcoindev@googlegroups.com>; Wed, 19 Feb 2025 09:23:54 -0800 (PST)
X-Gm-Gg: ASbGncuwVw7S2gaaR+HedowwLncIeyk4e/9wPhj1eHcZH+xBGZYzkHBrwZyxhP0K9J6
	KOv2ICJOtJXqu4TpS7daIsMvh0s+oAqzf6aRKUhaIBsJs32IRedrszwZyxV8a2Tf2ofZEdFJBbx
	T25RIXWxPqFqz7xw6FIxm4TDjOAgKh
X-Received: by 2002:a05:6870:a689:b0:2b8:8194:72b6 with SMTP id
 586e51a60fabf-2bd2fb2a255mr37334fac.7.1739985834238; Wed, 19 Feb 2025
 09:23:54 -0800 (PST)
MIME-Version: 1.0
References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com>
In-Reply-To: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com>
From: Dustin Ray <dustinvonsandwich@gmail.com>
Date: Wed, 19 Feb 2025 09:23:43 -0800
X-Gm-Features: AWEUYZkxyV42pMBr84DNqQ0Ff_mM_v8bwItaEjMexqLBJKd1e4BJi7A4yiiFA54
Message-ID: <CAC3UE4KkpxCO++huw=kw6YRayEvnhWtngzPkngiAvk16v3Kfew@mail.gmail.com>
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
To: Hunter Beast <hunter@surmount.systems>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000906c1b062e8205f4"
X-Original-Sender: Dustinvonsandwich@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=J4C0EGqc;       spf=pass
 (google.com: domain of dustinvonsandwich@gmail.com designates
 2607:f8b0:4864:20::c2a as permitted sender) smtp.mailfrom=dustinvonsandwich@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.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.2 (/)

--000000000000906c1b062e8205f4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for your work on this, it's exciting to watch it move along.

One item I have not yet addressed yet that is worth discussing is the
hierarchical deterministic seed characteristic of private keys for any of
the post quantum schemes you have mentioned so far. At present, if FALCON
is shortlisted, how do you propose to backup private keys? Must a new
wallet backup be made for each new public key that is generated?

Per your comment on security levels, I agree that your previous proposal
was absolutely overkill. My personal thought is that we will be just fine
by matching the current security levels provided by ecdsa, many years of
scrutiny has shown that this is sufficient.


On Wed, Feb 19, 2025 at 7:57=E2=80=AFAM Hunter Beast <hunter@surmount.syste=
ms>
wrote:

> Dear Bitcoin Dev Community,
>
> A bit over six months after introducing the P2QRH proposal (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 mitigation strategy.
>
> First, now that there's a BIP number assigned, you can find the update BI=
P
> here:
>
> https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki
>
> The revised BIP-360 draft reflects substantial changes since initial
> publication, particularly regarding algorithm selection. While we
> originally considered SQIsign, it has 15,000x slower verification compare=
d
> to ECC [1]. If it takes 1 second to verify a fully ECC block, it would ta=
ke
> 4 hours to validate a block filled with SQIsign transactions. This has
> obvious and concerning DDoS implications.
>
> While it would take a long time to sign many thousands of SQIsign
> transactions as well, the increased time needed to sign the transactions
> likely won=E2=80=99t affect the practicality of DDoS attacks-- another co=
ncern
> which has been brought to my attention. As such, I've decided to deprecat=
e
> 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 generall=
y
> result in signatures that are still quite large. Chipmunk and RACCOON are
> good examples [2], [3]. I do expect that to improve with time. It might b=
e
> worthwhile to shorten the list by making signature aggregation a
> requirement, so as not to regress too far from Schnorr signatures. That
> said, I think those capabilities should be introduced in a separate BIP
> once they're more mature and worthwhile.
>
> Our current shortlist prioritizes FALCON for its signature aggregation
> potential, with SPHINCS+ and CRYSTALS-Dilithium as secondary candidates.
> However, major 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 also,
> how we should handle multisig wallets.
>
> Additionally, I think it's worthwhile to restrict BIP-360 to NIST-approve=
d
> algorithms to maintain FIPS compliance. That's because HSMs such as those
> provided 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 configuration 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 tre=
e
> commitment scheme-- it needs more scrutiny. We could use a sort of P2SH
> approach, just modifying the semantics of OP_CHECKMULTISIG in a witness
> script to alias to public keys in the attestation. But that could introdu=
ce
> additional 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 it 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 needs more thought 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 thresho=
ld
> and total, and those 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 interim
> solution to secure Taproot keypath spends without disabling them, as
> Matthew Corallo proposes in the aforementioned mailing list thread [4]. T=
he
> 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 the block
> template
>
> For those interested, take a look at the draft BIP for P2TRH here:
> 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
> applications, 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 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 i=
f
> it isn't merged by the time I'm finished, hopefully that will provide som=
e
> additional impetus behind it.
>
> One concern Murch brought up is that introducing four new 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 SQIsign (especiall=
y
> in its current state lacking implementation maturity), and will help push
> the BIP below a certain complexity threshold, making it somewhat easier t=
o
> review.
>
>
>
> I think it's still important to include multiple signature algorithm
> 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 al=
l
> 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, but
> this would be a deviation from the BIP as presently specified, which
> defaults to level V security. The disadvantage of including level I suppo=
rt
> for each algorithm is that it essentially doubles the complexity of
> libbitcoinpqc.
>
> Ultimately, I hope the default of NIST V and selection of 3 mature
> NIST-approved algorithms demonstrate a focused, polished, and conservativ=
e
> 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 here: 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,
> Consensus in Toronto, and BTC 25 in Las Vegas, and later this year, TABCo=
nf
> in Atlanta.
>
>
> [1] https://pqshield.github.io/nist-sigs-zoo
>
> [2] https://eprint.iacr.org/2023/1820.pdf
>
> [3] https://eprint.iacr.org/2024/1291.pdf
>
> [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
>
> [5]
> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-re=
lease-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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-b419-8032=
91779007n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-b419-803=
291779007n%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/=
CAC3UE4KkpxCO%2B%2Bhuw%3Dkw6YRayEvnhWtngzPkngiAvk16v3Kfew%40mail.gmail.com.

--000000000000906c1b062e8205f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div></div><div><div dir=3D"auto" style=3D"font-family:-apple-system,helvet=
icaneue;font-size:16px;font-style:normal;font-weight:400;letter-spacing:nor=
mal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0=
);color:rgb(0,0,0)">Thanks for your work on this, it&#39;s exciting to watc=
h it move along.</div><div dir=3D"auto" style=3D"font-family:-apple-system,=
helveticaneue;font-size:16px;font-style:normal;font-weight:400;letter-spaci=
ng:normal;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb=
(0,0,0);color:rgb(0,0,0)"><br></div><div dir=3D"auto" style=3D"font-family:=
-apple-system,helveticaneue;font-size:16px;font-style:normal;font-weight:40=
0;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);bo=
rder-color:rgb(0,0,0);color:rgb(0,0,0)">One item I have not yet addressed y=
et that is worth discussing is the hierarchical deterministic seed characte=
ristic of private keys for any of the post quantum schemes you have mention=
ed so far. At present, if FALCON is shortlisted, how do you propose to back=
up private keys? Must a new wallet backup be made for each new public key t=
hat is generated?</div><div dir=3D"auto" style=3D"font-family:-apple-system=
,helveticaneue;font-size:16px;font-style:normal;font-weight:400;letter-spac=
ing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rg=
b(0,0,0);color:rgb(0,0,0)"><br></div><div dir=3D"auto" style=3D"font-family=
:-apple-system,helveticaneue;font-size:16px;font-style:normal;font-weight:4=
00;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:no=
rmal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);b=
order-color:rgb(0,0,0);color:rgb(0,0,0)">Per your comment on security level=
s, I agree that your previous proposal was absolutely overkill. My personal=
 thought is that we will be just fine by matching the current security leve=
ls provided by ecdsa, many years of scrutiny has shown that this is suffici=
ent.</div><div dir=3D"auto" style=3D"font-family:-apple-system,helveticaneu=
e;font-size:16px;font-style:normal;font-weight:400;letter-spacing:normal;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-=
decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);colo=
r:rgb(0,0,0)"><br></div><div dir=3D"auto" style=3D"font-family:-apple-syste=
m,helveticaneue;font-size:16px;font-style:normal;font-weight:400;letter-spa=
cing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:r=
gb(0,0,0);color:rgb(0,0,0)"><br></div></div><div><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19=
, 2025 at 7:57=E2=80=AFAM Hunter Beast &lt;hunter@surmount.systems&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-=
left-color:rgb(204,204,204)"><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-family:Arial,sans-serif;fo=
nt-size:11pt;background-color:transparent;color:rgb(0,0,0)">Dear Bitcoin De=
v Community,</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-=
top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,=
sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-=
variant-alternates:normal;vertical-align:baseline;background-color:transpar=
ent;color:rgb(0,0,0)">A bit over six months after introducing the P2QRH pro=
posal (now BIP-360), I&#39;m writing to share significant developments and =
request additional feedback on our post-quantum roadmap, and I&#39;d also l=
ike to mention a potential P2TRH post-quantum mitigation strategy.</span></=
p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom=
:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-serif;font-varia=
nt-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:no=
rmal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"=
>First, now that there&#39;s a BIP number assigned, you can find the update=
 BIP here:</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt"><a href=3D"https://github.com/cryptoquick/bips/blob/p2=
qrh/bip-0360.mediawiki" target=3D"_blank"><span style=3D"font-size:11pt;fon=
t-family:Arial,sans-serif;font-weight:700;font-variant-numeric:normal;font-=
variant-east-asian:normal;font-variant-alternates:normal;text-decoration:un=
derline;vertical-align:baseline;background-color:transparent;color:rgb(17,8=
5,204)">https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki</=
span></a></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-serif=
;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-al=
ternates:normal;vertical-align:baseline;background-color:transparent;color:=
rgb(0,0,0)">The revised BIP-360 draft reflects substantial changes since in=
itial publication, particularly regarding algorithm selection. While we ori=
ginally considered SQIsign, 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 has obviou=
s and concerning DDoS implications.</span></p><br><p dir=3D"ltr" style=3D"l=
ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:=
11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-=
east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;ba=
ckground-color:transparent;color:rgb(0,0,0)">While it would take a long tim=
e to </span><span style=3D"font-size:11pt;font-family:Arial,sans-serif;font=
-style:italic;font-variant-numeric:normal;font-variant-east-asian:normal;fo=
nt-variant-alternates:normal;vertical-align:baseline;background-color:trans=
parent;color:rgb(0,0,0)">sign</span><span style=3D"font-size:11pt;font-fami=
ly:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:nor=
mal;font-variant-alternates:normal;vertical-align:baseline;background-color=
:transparent;color:rgb(0,0,0)"> many thousands of SQIsign transactions as w=
ell, 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&#39;ve decided to deprecate SQIsign fro=
m the BIP.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sa=
ns-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline;background-color:transparen=
t;color:rgb(0,0,0)">It&#39;s worth mentioning because it was brought up in =
the PR, there&#39;s a new class of algorithms that support signature aggreg=
ation, but they generally result in signatures that are still quite large. =
Chipmunk and RACCOON are good examples [2], [3]. I do expect that to improv=
e with time. It might be worthwhile to shorten the list by making signature=
 aggregation a requirement, so as not to regress too far from Schnorr signa=
tures. That said, I think those capabilities should be introduced in a sepa=
rate BIP once they&#39;re more mature and worthwhile.</span></p><br><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:n=
ormal;font-variant-east-asian:normal;font-variant-alternates:normal;vertica=
l-align:baseline;background-color:transparent;color:rgb(0,0,0)">Our current=
 shortlist prioritizes FALCON for its signature aggregation potential, with=
 SPHINCS+ and CRYSTALS-Dilithium as secondary candidates. However, major te=
chnical challenges remain, particularly BIP-32 compatibility issues affecti=
ng xpub generation in watch-only wallets, as detailed by conduition in anot=
her mailing list discussion [4], and also, how we should handle multisig wa=
llets.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-s=
erif;font-variant-numeric:normal;font-variant-east-asian:normal;font-varian=
t-alternates:normal;vertical-align:baseline;background-color:transparent;co=
lor:rgb(0,0,0)">Additionally, I think it&#39;s worthwhile to restrict BIP-3=
60 to NIST-approved algorithms to maintain FIPS compliance. That&#39;s beca=
use HSMs such as those provided by Securosys already have support for all t=
hree algorithms [5], which is essential for secure deployment of federated =
L2 treasuries.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;fon=
t-variant-alternates:normal;vertical-align:baseline;background-color:transp=
arent;color:rgb(0,0,0)">Presently, for multisigs, we have a merkle tree con=
figuration defined for encumbering the output with multiple keys. While tha=
t&#39;s efficient, it&#39;s a novel construction. I&#39;m not certain we sh=
ould proceed with the merkle tree commitment scheme-- it needs more scrutin=
y. We could use a sort of P2SH approach, just modifying the semantics of OP=
_CHECKMULTISIG in a witness script to alias to public keys in the attestati=
on. But that could introduce additional 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 attestati=
on, as it is designed to be purposely limited, so as specified it is only c=
apable of n/n multisig. I consider m/n multisigs to be the single largest o=
bvious omission in the spec right now. It definitely needs more thought and=
 I&#39;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 t=
hreshold and total, and those would be hashed and committed to in the outpu=
t, then provided in a field in the attestation once spent.</span></p><br><p=
 dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><s=
pan style=3D"font-size:11pt;font-family:Arial,sans-serif;font-variant-numer=
ic:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ver=
tical-align:baseline;background-color:transparent;color:rgb(0,0,0)">While f=
inalizing PQC selections, I&#39;ve also drafted P2TRH as an interim solutio=
n to secure Taproot keypath spends without disabling them, as Matthew Coral=
lo proposes in the aforementioned mailing list thread [4]. The P2TRH approa=
ch hashes public keys rather than exposing them directly, particularly bene=
fiting:</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0=
pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-=
serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-varia=
nt-alternates:normal;vertical-align:baseline;background-color:transparent;c=
olor:rgb(0,0,0)">- MuSig2 Lightning channel implementations</span></p><p di=
r=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span=
 style=3D"font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:=
normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertic=
al-align:baseline;background-color:transparent;color:rgb(0,0,0)">- FROST-ba=
sed MPC vaults</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sa=
ns-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline;background-color:transparen=
t;color:rgb(0,0,0)">- High-value transactions using private pools that don&=
#39;t reveal the block template</span></p><br><p dir=3D"ltr" style=3D"line-=
height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt=
;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east=
-asian:normal;font-variant-alternates:normal;vertical-align:baseline;backgr=
ound-color:transparent;color:rgb(0,0,0)">For those interested, take a look =
at the draft BIP for P2TRH here: </span><a href=3D"https://github.com/crypt=
oquick/bips/blob/p2trh/bip-p2trh.mediawiki" target=3D"_blank"><span style=
=3D"font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal=
;font-variant-east-asian:normal;font-variant-alternates:normal;text-decorat=
ion:underline;vertical-align:baseline;background-color:transparent;color:rg=
b(17,85,204)">https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.medi=
awiki</span></a></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top=
:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,san=
s-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-var=
iant-alternates:normal;vertical-align:baseline;background-color:transparent=
;color:rgb(0,0,0)">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&#39;s preferred solution-- at least fo=
r Taproot quantum security. The tradeoff is that it adds 8.25 vB of overhea=
d per input, and key tweaking might have slightly less utility for some app=
lications, and it also doesn&#39;t protect against short exposure quantum a=
ttacks as defined in BIP-360.</span></p><br><p dir=3D"ltr" style=3D"line-he=
ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;f=
ont-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-a=
sian:normal;font-variant-alternates:normal;vertical-align:baseline;backgrou=
nd-color:transparent;color:rgb(0,0,0)">Returning to P2QRH and what&#39;s ne=
eded to push it across the finish line...</span></p><br><p dir=3D"ltr" styl=
e=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font=
-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-va=
riant-east-asian:normal;font-variant-alternates:normal;vertical-align:basel=
ine;background-color:transparent;color:rgb(0,0,0)">I still need to finish t=
he test vectors. I&#39;m implementing these using a fork of rust-bitcoin an=
d modeling them after Steven Roose&#39;s work on BIP-346. I&#39;ve been tol=
d that&#39;s not a blocker for merging the draft, but if it isn&#39;t merge=
d by the time I&#39;m finished, hopefully that will provide some additional=
 impetus behind it.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;=
margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family=
:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:norma=
l;font-variant-alternates:normal;vertical-align:baseline;background-color:t=
ransparent;color:rgb(0,0,0)">One concern Murch brought up is that introduci=
ng four new algorithms into the network was too many-- adding too much comp=
lexity to the network and to wallets and other applications-- and I agree.=
=C2=A0</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-s=
erif;font-variant-numeric:normal;font-variant-east-asian:normal;font-varian=
t-alternates:normal;vertical-align:baseline;background-color:transparent;co=
lor:rgb(0,0,0)">Hopefully this is addressed to some degree by removing SQIs=
ign (especially in its current state lacking implementation maturity), and =
will help push the BIP below a certain complexity threshold, making it some=
what easier to review.</span></p><p dir=3D"ltr" style=3D"line-height:1.38;m=
argin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:=
Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal=
;font-variant-alternates:normal;vertical-align:baseline;background-color:tr=
ansparent;color:rgb(0,0,0)">=C2=A0</span></p><p dir=3D"ltr" style=3D"line-h=
eight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;=
font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-=
asian:normal;font-variant-alternates:normal;vertical-align:baseline;backgro=
und-color:transparent;color:rgb(0,0,0)">I think it&#39;s still important to=
 include multiple signature algorithm options for users to select their des=
ired level of security. It&#39;s not 100% certain that all of these algorit=
hms will remain quantum resistant for all time, so redundancy here is=E2=80=
=A6 key.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans=
-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-vari=
ant-alternates:normal;vertical-align:baseline;background-color:transparent;=
color:rgb(0,0,0)">Another concern is that NIST level V is overkill. I have =
less conviction on this since secp256k1 technically has 128 bits of securit=
y due to Pollard&#39;s rho attacks. But if the intention was for 256 bits o=
f security, should level V security be the default? It&#39;s difficult for =
me to say. Perhaps both level V and level I implementations could be includ=
ed, but this would be a deviation from the BIP as presently specified, whic=
h defaults to level V security. The disadvantage of including level I suppo=
rt for each algorithm is that it essentially doubles the complexity of libb=
itcoinpqc.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sa=
ns-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline;background-color:transparen=
t;color:rgb(0,0,0)">Ultimately, I hope the default of NIST V and selection =
of 3 mature NIST-approved algorithms demonstrate a focused, polished, and c=
onservative proposal.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.3=
8;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fami=
ly:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:nor=
mal;font-variant-alternates:normal;vertical-align:baseline;background-color=
:transparent;color:rgb(0,0,0)">At this point, the major call to action I wo=
uld like to highlight is simply the need for more feedback from the communi=
ty. Please review and provide feedback here: </span><a href=3D"https://gith=
ub.com/bitcoin/bips/pull/1670" target=3D"_blank"><span style=3D"font-size:1=
1pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-e=
ast-asian:normal;font-variant-alternates:normal;text-decoration:underline;v=
ertical-align:baseline;background-color:transparent;color:rgb(17,85,204)">h=
ttps://github.com/bitcoin/bips/pull/1670</span></a></p><br><p dir=3D"ltr" s=
tyle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"f=
ont-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font=
-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:ba=
seline;background-color:transparent;color:rgb(0,0,0)">I look forward to fee=
dback and opinions on P2QRH and P2TRH.</span></p><br><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-=
size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-var=
iant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseli=
ne;background-color:transparent;color:rgb(0,0,0)">P.S. I&#39;ll be advocati=
ng 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.</span></p><b=
r><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom=
:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-serif;font-varia=
nt-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:no=
rmal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"=
>[1] <a href=3D"https://pqshield.github.io/nist-sigs-zoo" target=3D"_blank"=
 style=3D"font-family:Arial,sans-serif">https://pqshield.github.io/nist-sig=
s-zoo</a></span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt=
;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-se=
rif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant=
-alternates:normal;vertical-align:baseline;background-color:transparent;col=
or:rgb(0,0,0)">[2] <a href=3D"https://eprint.iacr.org/2023/1820.pdf" target=
=3D"_blank" style=3D"font-family:Arial,sans-serif">https://eprint.iacr.org/=
2023/1820.pdf</a></span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin=
-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial=
,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font=
-variant-alternates:normal;vertical-align:baseline;background-color:transpa=
rent;color:rgb(0,0,0)">[3] <a href=3D"https://eprint.iacr.org/2024/1291.pdf=
" target=3D"_blank" style=3D"font-family:Arial,sans-serif">https://eprint.i=
acr.org/2024/1291.pdf</a></span></p><p dir=3D"ltr" style=3D"line-height:1.3=
8;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fami=
ly:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:nor=
mal;font-variant-alternates:normal;vertical-align:baseline;background-color=
:transparent;color:rgb(0,0,0)">[4] <a href=3D"https://groups.google.com/g/b=
itcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ" target=3D"_blank" style=3D"font-fam=
ily:Arial,sans-serif">https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/=
m/7uu4dZNgAwAJ</a></span></p><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;fon=
t-variant-alternates:normal;vertical-align:baseline;background-color:transp=
arent;color:rgb(0,0,0)">[5] <a href=3D"https://docs.securosys.com/tsb/Tutor=
ials/Post-Quantum-Cryptography/pqc-release-overview" target=3D"_blank" styl=
e=3D"font-family:Arial,sans-serif">https://docs.securosys.com/tsb/Tutorials=
/Post-Quantum-Cryptography/pqc-release-overview</a></span></p><br>

<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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/8797807d-e017-44e2-b419-803291779007n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/8797807d-e017-44e2-b419-803291779007n%40googlegrou=
ps.com</a>.<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/CAC3UE4KkpxCO%2B%2Bhuw%3Dkw6YRayEvnhWtngzPkngiAvk16v3Kfew%40mail=
.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.co=
m/d/msgid/bitcoindev/CAC3UE4KkpxCO%2B%2Bhuw%3Dkw6YRayEvnhWtngzPkngiAvk16v3K=
few%40mail.gmail.com</a>.<br />

--000000000000906c1b062e8205f4--