path: root/21/975a364f4c70a8f07e355e439b65b04d005455

Delivery-date: Thu, 27 Feb 2025 23:30:04 -0800
Received: from mail-ot1-f64.google.com ([209.85.210.64])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCXOL6U6XMBRB4OLQW7AMGQERSLYASA@googlegroups.com>)
	id 1tnuos-0005Ih-9K
	for bitcoindev@gnusha.org; Thu, 27 Feb 2025 23:30:04 -0800
Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7273b4db914sf1745289a34.0
        for <bitcoindev@gnusha.org>; Thu, 27 Feb 2025 23:30:02 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1740727796; cv=pass;
        d=google.com; s=arc-20240605;
        b=fUNt6VtNm28PjqYp6IumJ8W5sEnA4FJiSILU/UsF7iY3WrrWvHBhrEcnqA8XUcBG67
         EQsbzkXyjQnmD+j7UAv68cFEN4zsCYAo028c+ICzrekKxizWD+maIq2s6X6DvHkboDGj
         AqNWBxZ0G3U6MtYg5l0oLVye5jngeJn4FZd2hAN53zwI1dSGfHnPF5Cb5PQxPgQdKjnh
         fOZPzNvuhELSNSimeRdm5g6wBVdbmYJIclPfsuPQVkhso4bzVtxtt/rgGXjMRxj9cYNJ
         toYSimB2yiZj2A41k5xyLj+tuDHJRcdedKsl5DM4P1AMSzVRKG3VRQsufDar+5v8iLBp
         4s8g==
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=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=;
        fh=q60N2uSUsOXts6C/nLmrmXPmTf6zHjcDR2Gb4uf4wto=;
        b=bKlI3x1ZwwKLMyc/DT25QOUjeowY0U7lypv96WYzqw+WQt9t038k4HfaxIJ5ZcAtFT
         xl1yYtFyu+IhQ7rEhBF+R6Nya2cw4IsTe3dOWUNgSVcYjmid2C3IJo1LhlLBRA3VWpqI
         D+uc9LHMuFuCkk3MbMrF1MBtJ74ucHXpJa7X7UQrQ+z4H6yOV6FNb/0pmgkjH/ctkx2g
         TGg1yW171FZ7pkbSYKF6FeWGd+mUSq0SFtGeP/e8yxvV+fZCZY4G/AL7Y4Nmvom54mLJ
         lveGzbITA1J2zzHDWUgZ9A1YgukyrgA+vLdCNtu6YifCA2jcQUCdMq2/69/qmcWvGLkY
         rfVA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ffyJvBCG;
       spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c 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=1740727796; x=1741332596; 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=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=;
        b=qPe5kFx4Vvus4sLIiIjU/3QuaFP+NZ0XbENBzROgGv3BPfetZW7O2t/aBWpZaJI6oV
         whcmVpbawcDSC79eZ7wfgkT9zGC40UpIKsu320Xm8bb3irL3kOkchuIJmx0P1ff8rwgY
         2MMlcZ+gyUjA/ECwsd3Erd1wWwjN3bnJ7nzTiXW9MqGq8ePHF50UfeSGBetH39WNgTMR
         Jnq4/xTpqVyKeb+fX54rzz7W9AspB8G31IC2TbIDrEpe/NghwMhLmPCpa/dqHcrxEa3v
         Z+neOLXtFfma7WJURGW5JWNzAhMk1sl7hO46ru3VfP31kPlEWrhrOIKfHJEwtwcwNu13
         I7kQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1740727796; x=1741332596; 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=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=;
        b=MI8hRv2pLedNeJV5bQ2XZA5N2HD8Q8DbWAs6c2PiDHyV1wQ/fV5BgasMUXXgDBiUs3
         YrikQk2WR/+yVHJg1LbHbb/X40vHdW5NbfI8qf+Xwz7Awf3p9J8nf/7XG3gDuBNRde4e
         wWTxXBIdqIN6ymjRDDS21FiBwtemP524zIMMN6q0627rICrl6YXvU+qIqhuHVfty2+Gh
         c6SeKsmVzjcDhhT5TdLpUU4UbxOa/nyI5RLcXBlqu4gPkrRpN+4kSVavP5+Qcd9joE7r
         Vkd2pmSKEtR0CHWRVx+hSVKAUVduizNsRBvVyxQtr/CpNHcS1LqqNtlMb6FrXVQytOHU
         R7eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740727796; x=1741332596;
        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=e8T4H8ctdLapY8bjdgxYKCIEOJGZ0KEg/c2bOawYz0Y=;
        b=CrXACSM6RJwtkBQV2JGUDVM/I1v/5wgi3EXHjNwyKfwjqdbgj4dmtLPRUaUjLy6EEq
         v933ZIi7hMtpgKs1FLOBOBLyZ5Grejn4NZJ9IfBCUyn/R2jY7WbLs/J1r9o5oYMaISX9
         DKlWQLqXyqq8bq4/DB3F6tUTUT7jsTYZrsaVUymijhDFkgrfRfODw5O+9AiF2Eos6g95
         NvU3CjzEN/R5dsMK9FBMJ7JVuN2Nl9t9uuLzmqhDvFxI8PSXpHWAWyEbPz8KWdOSLK6V
         hjrRGIRcF4WrQKGK779QFVJaYOmVogZkk9UCYSU9cAQcA4+uPi2oeR3h7QWH0XhNYGbI
         UXkQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUseAQgrXDP2ImeAuePZFf67QQeFN7I/xRIKjrVV5AXf7t0LOrwk9F/8TYHOi+yFQTQaTIJftFMLxRm@gnusha.org
X-Gm-Message-State: AOJu0YxrXRNORju3SxOkAVIr3OKaqvk08RHFN7LwggZdwJQa503O7a7s
	vFwqCRdqUGoYWUizVrNgAY4nZLIujiKTK8Zix0KgrtICQgbiUwIc
X-Google-Smtp-Source: AGHT+IE+KK3Nl8j3qa5nfOtNC/a9mpHG/ZrdRSwCrPMmdMfE6e/+g5JU1MK8JsOughNE931AKGTYUA==
X-Received: by 2002:a05:6830:4197:b0:727:345d:3b70 with SMTP id 46e09a7af769-728b830654bmr1284715a34.28.1740727796079;
        Thu, 27 Feb 2025 23:29:56 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFJtzRlN7Gf7oht50XIffnmBRQlpyKR8/wNfMqkw2O2hw==
Received: by 2002:a05:6820:30c:b0:5fc:7c22:82bb with SMTP id
 006d021491bc7-5fea934bfdbls921337eaf.1.-pod-prod-05-us; Thu, 27 Feb 2025
 23:29:53 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCVeYfc3LoAds5eBGYFuq577Fq8C98E09h38vkWQh4px+3y/7ajI+0ZSsV/lLEmFyOSPSvE3wE7IwIOf@googlegroups.com
X-Received: by 2002:a05:6808:1706:b0:3f4:600:7f58 with SMTP id 5614622812f47-3f5586074e0mr1217287b6e.35.1740727793325;
        Thu, 27 Feb 2025 23:29:53 -0800 (PST)
Received: by 2002:a05:6808:694d:b0:3f4:4b9:4605 with SMTP id 5614622812f47-3f5596aa5a6msb6e;
        Thu, 27 Feb 2025 20:19:30 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCWZaEBuCumY4/NwMHVnaPswEyqS/6v3vVynEy1j4uHHyqYoncGnvss54ombHkSRCTZpaxszIyKmcSKV@googlegroups.com
X-Received: by 2002:a05:6830:903:b0:727:4676:4005 with SMTP id 46e09a7af769-728b82f07dfmr1221060a34.21.1740716369996;
        Thu, 27 Feb 2025 20:19:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1740716369; cv=none;
        d=google.com; s=arc-20240605;
        b=AED8qPddHOLLBpGolVgrtb/2Y8OY+OI54/tx9D/JHT2nXgB1D+0pP2V6TJm0LLmq7k
         8HKLgEfaK7i+Co2KYrHaTf3IJovoghMam9oEQPnPVQfJlvJWGViBJeQMIr7kthovx7Rt
         dO0RwoXssxUNJ4I+9HqERXd+jTJOQw9zHKJC+G7mqLNmIWmGA0/CpJCH10extRB8HOm5
         pRWqPQFs2UvPQy7KEUyqR0dAmQfJJE3Hrh1dGP+ySBoVj3ss0TD5mtoctsuU4NjFtEEy
         FOSwtANMy/EgYhT7o705nitSamTsENAScaSC///KB7J4Tt4vrw60LgLSQ7N1PBP9hCZr
         RhsQ==
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=j5utFgyM3jMxtoWpzbs3xoL/2spzwl7zG6IIWso+5lw=;
        fh=+bcQvW94nIB6Mzm6bsXdVXvF2BAI9blI+3G4qQMgZ94=;
        b=buolvVoq4mPv1MjWA9UUjJYoBchi1HnjOCddpkIXUJe6P2B0Gbd7iDxYttfDwJALvl
         YrC/fG3/rtrK4FDG2+2oaENxibm8hAitSc25IUhMFTebPrAbdkLJwt4/RBjyEd1jiSE0
         ML/82fz/ecY7q5T1pxIcAmr1TyZm8+k+ODd2yTZiZC3OTWBYuOGt4WX5Uey1SFj7GqbK
         WhLEJAVtBuzWGZGJkPWEDpgL5XNZlWB6yrBpUanNwiZILmD5IYpTPE8OVJT51h+x1Mqo
         gCgcqGIwyTKQe9aX0KvakRQlTw2+5Fw7/N15XvfcQBwQpQE851Pf5ngaugVptDgDHK9c
         eeZA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ffyJvBCG;
       spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c 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-oa1-x2c.google.com (mail-oa1-x2c.google.com. [2001:4860:4864:20::2c])
        by gmr-mx.google.com with ESMTPS id 46e09a7af769-728afd7dba0si189893a34.4.2025.02.27.20.19.29
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 27 Feb 2025 20:19:29 -0800 (PST)
Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::2c as permitted sender) client-ip=2001:4860:4864:20::2c;
Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-2bcbfad2f8cso905872fac.1
        for <bitcoindev@googlegroups.com>; Thu, 27 Feb 2025 20:19:29 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCVzzvV5eVsYULAra2mru/rsxb0++zISBwAG/mLxUrgJYZ7gBRA4OxVXi0NhfbyKlUr8p/A28I1Qbhl/@googlegroups.com
X-Gm-Gg: ASbGncuzvBbkv65BNqKdnsuFLEHF2aUcN51Yo9hYN5ZyhbxhJi2gE5eBE/K3cg1sO0m
	EpsEGtiS3uB2V0mE2+2yZVhP3p93wcG4/u7N/BNuFz0pnKoWUogsXDyjDqKEAGWtb2EN27GsPmC
	6Ichu1kuyub2lDuRrgGrbtZB3m0CR7UsJaBM0ud8bqEQ==
X-Received: by 2002:a05:6871:5385:b0:29e:8485:197b with SMTP id
 586e51a60fabf-2c1782be860mr1320486fac.2.1740716369387; Thu, 27 Feb 2025
 20:19:29 -0800 (PST)
MIME-Version: 1.0
References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com>
 <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com> <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com>
 <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com>
In-Reply-To: <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com>
From: Dustin Ray <dustinvonsandwich@gmail.com>
Date: Thu, 27 Feb 2025 20:19:17 -0800
X-Gm-Features: AQ5f1JoSkzDrda5116GvS5QT1xuy7dY1XSxF91XoN54_hYz6hiM2hryGisKtZFQ
Message-ID: <CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y+uEROb3BqxC2_G+XA@mail.gmail.com>
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Hunter Beast <hunter@surmount.systems>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000da2c71062f2c1c92"
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=ffyJvBCG;       spf=pass
 (google.com: domain of dustinvonsandwich@gmail.com designates
 2001:4860:4864:20::2c 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.5 (/)

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

Matt, you make a potent and salient point. I think that when we survey the
current state of existing pqc solutions and try to apply them to bitcoin,
we keep coming up with either a massive chain, massive key sizes, extremely
degraded performance, confiscation, or some combination of those.

I think laying the groundwork for this inevitable task now is important,
but if I understand your points correctly, I would agree that existing
solutions do not seem equipped to carry bitcoin into the post quantum
landscape.

On Thu, Feb 27, 2025 at 6:41=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.=
com>
wrote:

> I think you're approaching this from the wrong stance.
>
> If our goal is to "make bitcoin Quantum-secure", its gonna take a decade
> for the state of PQ
> research to build something that's ready for us to "just switch to". I
> don't buy that there's a
> world where we get serious about adding something lattice-based to Bitcoi=
n
> for a longggg time (I'm
> not sure I've ever heard a serious cryptographer suggest that
> lattice-based systems are a good idea,
> rather than "a good thing to layer on top of a traditional non-PQC
> scheme").
>
> In the short-term, the only (remotely-practical) thing we can do is add
> something that we have high
> confidence will still be secure in two decades (which basically is only
> hash-based schemes) and get
> wallets to include it in their taproot outputs. That gives wallets create=
d
> today the possibility of
> being robust in a QC world, but, indeed, it would require tough decisions
> in the future.
>
> If your view is that Bitcoin would simply be fine if we didn't confiscate
> any coins in response to a
> practical QC stealing 5% of total supply, I'm not really convinced, but w=
e
> can also make it a
> version-2 segwit output ("taproot but a future softfork can freely freeze
> the keypath spends") if
> you really feel strongly.
>
> TBH the whole "would we confiscate if the time comes" question I think
> simply cannot be answered
> today because it depends very, very much on specific details (eg lets say
> we did the above proposal
> and its been around for 30 years and ~all wallets support it, that's a
> very very different world
> from, for example, deploying some PQC scheme under threat where a QC coul=
d
> realistically steal coins
> in five years). The only thing we can really do today is create the optio=
n
> in the future, we cannot
> decide for the future what to do.
>
> Matt
>
> On 2/23/25 3:33 PM, Hunter Beast wrote:
> > Hi Matt,
> >
> > The only problem with that approach is that SLH-DSA signatures are quit=
e
> large. NIST has also
> > approved ML-DSA and FN-DSA, which, while both are based on lattice
> cryptography, they're not only
> > standardized, but becoming widely supported. One consideration is
> hardware acceleration, and I
> > believe those three algorithms will have the best chance of having
> hardware implementations as PQC
> > extensions are added to CPUs and SoCs.
> >
> > As for gating P2TR, the problem with that approach is that keypath
> spends would need to be disabled
> > and that has a confiscatory effect that I'm seeking to avoid in this BI=
P.
> >
> > An additional opcode should not be necessary if multisig capability is
> built into the attestation.
> >
> > I agree with your 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"
> implementation. 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 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 w=
rote:
> >
> >     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
> in their security assumptions
> >     (i.e. only keep hash-based signatures, maybe just SPHINCS+), only
> embed them in a taproot leaf, and
> >     call it a day.
> >
> >     BIP 32 compatibility isn't a really huge deal if we're talking abou=
t
> an "emergency break glass"
> >     kinda setup - most wallets are set up with a root key and can just
> embed the same PQ pubkey in all
> >     of their outputs. The privacy cost is only realized in a break glas=
s
> case, and long before then
> >     hopefully whatever we do today is replaced with something better,
> with the knowledge that we'll
> >     gain
> >     on the way to "then". We'd still want to do it in an opcode so that
> we can do multisig, though.
> >
> >     Matt
> >
> >     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
> 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 BIP here:
> >      >
> >      > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawik=
i
> <https://github.com/
> >     cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> <
> https://github.com/cryptoquick/ <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 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 obvious and concerning DDoS
> >      > implications.
> >      >
> >      >
> >      > While it would take a long time to signmany thousands of SQIsign
> transactions as well, the
> >     increased
> >      > time needed to sign the transactions likely won=E2=80=99t affect=
 the
> practicality of DDoS attacks--
> >     another
> >      > concern which has been brought to my attention. As such, I've
> decided to deprecate SQIsign
> >     from the BIP.
> >      >
> >      >
> >      > It's worth mentioning because it was brought up in the PR,
> there's a new class of algorithms
> >     that
> >      > support signature aggregation, but they generally result in
> signatures that are still quite
> >     large.
> >      > Chipmunk and RACCOON are good examples [2], [3]. I do expect tha=
t
> to improve 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 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-approved 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 tree 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 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 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 th=
e
> SegWit v3 output hash could be
> >      > provided to indicate PQC signature threshold and total, and thos=
e
> 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]. 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
> the 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/cryptoquick/bips/blob/p2trh/bip-
> >     p2trh.mediawiki <
> https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki>>
> >      >
> >      >
> >      > I have my hands full with P2QRH advocacy and development and
> would prefer to focus on that,
> >     but I
> >      > wanted to introduce P2TRH in case that is attractive as the
> community's preferred solution-- at
> >      > least for Taproot quantum security. The tradeoff is that it adds
> 8.25 vB of overhead per
> >     input, and
> >      > key tweaking might have slightly less utility for some
> 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 finis=
h
> 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 if it isn't merged by the time I'm finished,
> hopefully that will provide some
> >      > additional impetus behind it.
> >      >
> >      >
> >      > One concern Murch brought up is that introducing four 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
> (especially in its current state
> >      > lacking implementation maturity), and will help push the BIP
> below a certain complexity
> >     threshold,
> >      > making it somewhat easier to review.
> >      >
> >      > I think it's still important to include multiple 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 all time, so redundancy here is=E2=80=A6 k=
ey.
> >      >
> >      >
> >      > 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
> >      > support 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 conservative proposal.
> >      >
> >      >
> >      > At this point, the major call to action I would like to highligh=
t
> is simply the need for more
> >      > feedback from the community. Please review and provide feedback
> here: https://github.com/
> >     bitcoin/ <https://github.com/bitcoin/>
> >      > bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670 <
> https://github.com/bitcoin/bips/
> >     pull/1670>>
> >      >
> >      >
> >      > I look forward to feedback and opinions on P2QRH and 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, TABConf in Atlanta.
> >      >
> >      >
> >      >
> >      > [1] https://pqshield.github.io/nist-sigs-zoo <
> https://pqshield.github.io/nist-sigs-zoo>
> >      >
> >      > [2] https://eprint.iacr.org/2023/1820.pdf <
> https://eprint.iacr.org/2023/1820.pdf>
> >      >
> >      > [3] https://eprint.iacr.org/2024/1291.pdf <
> https://eprint.iacr.org/2024/1291.pdf>
> >      >
> >      > [4]
> https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
> <https://
> >     groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
> >      >
> >      > [5]
> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-re=
lease-overview
> >     <
> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-re=
lease-overview
> >
> >      >
> >      >
> >      > --
> >      > You received this message because you are subscribed to the
> Google Groups "Bitcoin Development
> >      > Mailing List" group.
> >      > To unsubscribe from this group and stop receiving emails from it=
,
> send an email to
> >      > bitcoindev+...@googlegroups.com <mailto:
> bitcoindev+...@googlegroups.com>.
> >      > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/8797807d-
> >     e017-44e2- <
> https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2->
> >      > b419-803291779007n%40googlegroups.com <http://40googlegroups.com=
>
> <https://groups.google.com/
> >     d/msgid/bitcoindev/8797807d- <
> https://groups.google.com/d/msgid/bitcoindev/8797807d->
> >      > e017-44e2-b419-803291779007n%
> 40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter
> >     <http://40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>>=
.
> >
> > --
> > 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 <mailto:
> bitcoindev+unsubscribe@googlegroups.com>.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-
> > fa2fa35e2230n%40googlegroups.com <https://groups.google.com/d/msgid/
> > bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%
> 40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.
>
> --
> 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/2e0fc337-3603-4a22-8056-59cf=
7e21aa43%40mattcorallo.com
> .
>

--=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/=
CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y%2BuEROb3BqxC2_G%2BXA%40mail.gmail.com.

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

<div dir=3D"auto">Matt, you make a potent and salient point. I think that w=
hen we survey the current state of existing pqc solutions and try to apply =
them to bitcoin, we keep coming up with either a massive chain, massive key=
 sizes, extremely degraded performance, confiscation, or some combination o=
f those.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I think laying =
the groundwork for this inevitable task now is important, but if I understa=
nd your points correctly, I would agree that existing solutions do not seem=
 equipped to carry bitcoin into the post quantum landscape.</div><div><br><=
div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g=
mail_attr">On Thu, Feb 27, 2025 at 6:41=E2=80=AFPM Matt Corallo &lt;<a href=
=3D"mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>&gt; wrote=
:<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-l=
eft-color:rgb(204,204,204)">I think you&#39;re approaching this from the wr=
ong stance.<br>
<br>
If our goal is to &quot;make bitcoin Quantum-secure&quot;, its gonna take a=
 decade for the state of PQ <br>
research to build something that&#39;s ready for us to &quot;just switch to=
&quot;. I don&#39;t buy that there&#39;s a <br>
world where we get serious about adding something lattice-based to Bitcoin =
for a longggg time (I&#39;m <br>
not sure I&#39;ve ever heard a serious cryptographer suggest that lattice-b=
ased systems are a good idea, <br>
rather than &quot;a good thing to layer on top of a traditional non-PQC sch=
eme&quot;).<br>
<br>
In the short-term, the only (remotely-practical) thing we can do is add som=
ething that we have high <br>
confidence will still be secure in two decades (which basically is only has=
h-based schemes) and get <br>
wallets to include it in their taproot outputs. That gives wallets created =
today the possibility of <br>
being robust in a QC world, but, indeed, it would require tough decisions i=
n the future.<br>
<br>
If your view is that Bitcoin would simply be fine if we didn&#39;t confisca=
te any coins in response to a <br>
practical QC stealing 5% of total supply, I&#39;m not really convinced, but=
 we can also make it a <br>
version-2 segwit output (&quot;taproot but a future softfork can freely fre=
eze the keypath spends&quot;) if <br>
you really feel strongly.<br>
<br>
TBH the whole &quot;would we confiscate if the time comes&quot; question I =
think simply cannot be answered <br>
today because it depends very, very much on specific details (eg lets say w=
e did the above proposal <br>
and its been around for 30 years and ~all wallets support it, that&#39;s a =
very very different world <br>
from, for example, deploying some PQC scheme under threat where a QC could =
realistically steal coins <br>
in five years). The only thing we can really do today is create the option =
in the future, we cannot <br>
decide for the future what to do.<br>
<br>
Matt<br>
<br>
On 2/23/25 3:33 PM, Hunter Beast wrote:<br>
&gt; Hi Matt,<br>
&gt; <br>
&gt; The only problem with that approach is that SLH-DSA signatures are qui=
te large. NIST has also <br>
&gt; approved ML-DSA and FN-DSA, which, while both are based on lattice cry=
ptography, they&#39;re not only <br>
&gt; standardized, but becoming widely supported. One consideration is hard=
ware acceleration, and I <br>
&gt; believe those three algorithms will have the best chance of having har=
dware implementations as PQC <br>
&gt; extensions are added to CPUs and SoCs.<br>
&gt; <br>
&gt; As for gating P2TR, the problem with that approach is that keypath spe=
nds would need to be disabled <br>
&gt; and that has a confiscatory effect that I&#39;m seeking to avoid in th=
is BIP.<br>
&gt; <br>
&gt; An additional opcode should not be necessary if multisig capability is=
 built into the attestation.<br>
&gt; <br>
&gt; I agree with your statement on full BIP-32 compatibility. BIP-360 is j=
ust a starting point, and <br>
&gt; maybe you&#39;re right, it&#39;s best thought of as a &quot;break glas=
s&quot; implementation. It&#39;s not ideal, it&#39;s <br>
&gt; full of compromises, not everyone is 100% happy with it, and that&#39;=
s probably okay, because bitcoin <br>
&gt; isn&#39;t perfect-- but it doesn&#39;t have to be in order to work.<br=
>
&gt; <br>
&gt; Thank you for your thoughts.<br>
&gt; <br>
&gt; Hunter<br>
&gt; <br>
&gt; On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Corallo =
wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0If we want to do something like this in the short t=
o medium term, IMO we should strip out all the<br>
&gt;=C2=A0 =C2=A0 =C2=A0signature schemes that are anything more than quite=
 straightforward in their security assumptions<br>
&gt;=C2=A0 =C2=A0 =C2=A0(i.e. only keep hash-based signatures, maybe just S=
PHINCS+), only embed them in a taproot leaf, and<br>
&gt;=C2=A0 =C2=A0 =C2=A0call it a day.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0BIP 32 compatibility isn&#39;t a really huge deal i=
f we&#39;re talking about an &quot;emergency break glass&quot;<br>
&gt;=C2=A0 =C2=A0 =C2=A0kinda setup - most wallets are set up with a root k=
ey and can just embed the same PQ pubkey in all<br>
&gt;=C2=A0 =C2=A0 =C2=A0of their outputs. The privacy cost is only realized=
 in a break glass case, and long before then<br>
&gt;=C2=A0 =C2=A0 =C2=A0hopefully whatever we do today is replaced with som=
ething better, with the knowledge that we&#39;ll<br>
&gt;=C2=A0 =C2=A0 =C2=A0gain<br>
&gt;=C2=A0 =C2=A0 =C2=A0on the way to &quot;then&quot;. We&#39;d still want=
 to do it in an opcode so that we can do multisig, though.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Matt<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On 2/19/25 10:40 AM, Hunter Beast wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Dear Bitcoin Dev Community,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; A bit over six months after introducing the P=
2QRH proposal (now BIP-360), I&#39;m writing to share<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; significant developments and request addition=
al feedback on our post-quantum roadmap, and I&#39;d<br>
&gt;=C2=A0 =C2=A0 =C2=A0also<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; like to mention a potential P2TRH post-quantu=
m mitigation strategy.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; First, now that there&#39;s a BIP number assi=
gned, you can find the update BIP here:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; <a href=3D"https://github.com/cryptoquick/bip=
s/blob/p2qrh/bip-0360.mediawiki" rel=3D"noreferrer" target=3D"_blank">https=
://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki</a> &lt;<a hre=
f=3D"https://github.com/" rel=3D"noreferrer" target=3D"_blank">https://gith=
ub.com/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki&gt; =
&lt;<a href=3D"https://github.com/cryptoquick/" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/cryptoquick/</a> &lt;https://<br>
&gt;=C2=A0 =C2=A0 =C2=A0<a href=3D"http://github.com/cryptoquick/" rel=3D"n=
oreferrer" target=3D"_blank">github.com/cryptoquick/</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; bips/blob/p2qrh/bip-0360.mediawiki&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; The revised BIP-360 draft reflects substantia=
l changes since initial publication, particularly<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; regarding algorithm selection. While we origi=
nally considered SQIsign, it has 15,000x slower<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; verification compared to ECC [1]. If it takes=
 1 second to verify a fully ECC block, it would<br>
&gt;=C2=A0 =C2=A0 =C2=A0take 4<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; hours to validate a block filled with SQIsign=
 transactions. This has obvious and concerning DDoS<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; implications.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; While it would take a long time to signmany t=
housands of SQIsign transactions as well, the<br>
&gt;=C2=A0 =C2=A0 =C2=A0increased<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; time needed to sign the transactions likely w=
on=E2=80=99t affect the practicality of DDoS attacks--<br>
&gt;=C2=A0 =C2=A0 =C2=A0another<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; concern which has been brought to my attentio=
n. As such, I&#39;ve decided to deprecate SQIsign<br>
&gt;=C2=A0 =C2=A0 =C2=A0from the BIP.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; It&#39;s worth mentioning because it was brou=
ght up in the PR, there&#39;s a new class of algorithms<br>
&gt;=C2=A0 =C2=A0 =C2=A0that<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; support signature aggregation, but they gener=
ally result in signatures that are still quite<br>
&gt;=C2=A0 =C2=A0 =C2=A0large.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Chipmunk and RACCOON are good examples [2], [=
3]. I do expect that to improve with time. It<br>
&gt;=C2=A0 =C2=A0 =C2=A0might be<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; worthwhile to shorten the list by making sign=
ature aggregation a requirement, so as not to<br>
&gt;=C2=A0 =C2=A0 =C2=A0regress<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; too far from Schnorr signatures. That said, I=
 think those capabilities should be introduced in a<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; separate BIP once they&#39;re more mature and=
 worthwhile.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Our current shortlist prioritizes FALCON for =
its signature aggregation potential, with<br>
&gt;=C2=A0 =C2=A0 =C2=A0SPHINCS+ and<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; CRYSTALS-Dilithium as secondary candidates. H=
owever, major technical challenges remain,<br>
&gt;=C2=A0 =C2=A0 =C2=A0particularly<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; BIP-32 compatibility issues affecting xpub ge=
neration in watch-only wallets, as detailed by<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; conduition in another mailing list discussion=
 [4], and also, how we should handle multisig<br>
&gt;=C2=A0 =C2=A0 =C2=A0wallets.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Additionally, I think it&#39;s worthwhile to =
restrict BIP-360 to NIST-approved algorithms to<br>
&gt;=C2=A0 =C2=A0 =C2=A0maintain<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; FIPS compliance. That&#39;s because HSMs such=
 as those provided by Securosys already have support<br>
&gt;=C2=A0 =C2=A0 =C2=A0for<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; all three algorithms [5], which is essential =
for secure deployment of federated L2 treasuries.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Presently, for multisigs, we have a merkle tr=
ee configuration defined for encumbering the output<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; with multiple keys. While that&#39;s efficien=
t, it&#39;s a novel construction. I&#39;m not certain we should<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; proceed with the merkle tree commitment schem=
e-- it needs more scrutiny. We could use a sort<br>
&gt;=C2=A0 =C2=A0 =C2=A0of P2SH<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; approach, just modifying the semantics of OP_=
CHECKMULTISIG in a witness script to alias to<br>
&gt;=C2=A0 =C2=A0 =C2=A0public<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; keys in the attestation. But that could intro=
duce additional overhead in a signature scheme that<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; already uses a lot more space. Without this, =
however, we do not yet have a way specified to<br>
&gt;=C2=A0 =C2=A0 =C2=A0indicate<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; thresholds or a locking script for the attest=
ation, as it is designed to be purposely<br>
&gt;=C2=A0 =C2=A0 =C2=A0limited, so as<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; specified it is only capable of n/n multisig.=
 I consider m/n multisigs to be the single largest<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; obvious omission in the spec right now. It de=
finitely needs more thought and I&#39;m open to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; suggestions. Perhaps two additional bytes at =
the top level of the SegWit v3 output hash could be<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; provided to indicate PQC signature threshold =
and total, and those would be hashed and<br>
&gt;=C2=A0 =C2=A0 =C2=A0committed to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; in the output, then provided in a field in th=
e attestation once spent.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; While finalizing PQC selections, I&#39;ve als=
o drafted P2TRH as an interim solution to secure<br>
&gt;=C2=A0 =C2=A0 =C2=A0Taproot<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; keypath spends without disabling them, as Mat=
thew Corallo proposes in the aforementioned mailing<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; list thread [4]. The P2TRH approach hashes pu=
blic keys rather than exposing them directly,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; particularly benefiting:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; - MuSig2 Lightning channel implementations<br=
>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; - FROST-based MPC vaults<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; - High-value transactions using private pools=
 that don&#39;t reveal the block template<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; For those interested, take a look at the draf=
t BIP for P2TRH here: <a href=3D"https://github.com/" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0cryptoquick/ &lt;<a href=3D"https://github.com/cryp=
toquick/" rel=3D"noreferrer" target=3D"_blank">https://github.com/cryptoqui=
ck/</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; bips/blob/p2trh/bip-p2trh.mediawiki &lt;<a hr=
ef=3D"https://github.com/cryptoquick/bips/blob/p2trh/bip-" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/cryptoquick/bips/blob/p2trh/bip-</a=
><br>
&gt;=C2=A0 =C2=A0 =C2=A0p2trh.mediawiki &lt;<a href=3D"https://github.com/c=
ryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediaw=
iki</a>&gt;&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I have my hands full with P2QRH advocacy and =
development and would prefer to focus on that,<br>
&gt;=C2=A0 =C2=A0 =C2=A0but I<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; wanted to introduce P2TRH in case that is att=
ractive as the community&#39;s preferred solution-- at<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; least for Taproot quantum security. The trade=
off is that it adds 8.25 vB of overhead per<br>
&gt;=C2=A0 =C2=A0 =C2=A0input, and<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; key tweaking might have slightly less utility=
 for some applications, and it also doesn&#39;t protect<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; against short exposure quantum attacks as def=
ined in BIP-360.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Returning to P2QRH and what&#39;s needed to p=
ush it across the finish line...<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I still need to finish the test vectors. I&#3=
9;m implementing these using a fork of rust-bitcoin and<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; modeling them after Steven Roose&#39;s work o=
n BIP-346. I&#39;ve been told that&#39;s not a blocker for<br>
&gt;=C2=A0 =C2=A0 =C2=A0merging<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; the draft, but if it isn&#39;t merged by the =
time I&#39;m finished, hopefully that will provide some<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; additional impetus behind it.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; One concern Murch brought up is that introduc=
ing four new algorithms into the network was too<br>
&gt;=C2=A0 =C2=A0 =C2=A0many--<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; adding too much complexity to the network and=
 to wallets and other applications-- and I agree.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Hopefully this is addressed to some degree by=
 removing SQIsign (especially in its current state<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; lacking implementation maturity), and will he=
lp push the BIP below a certain complexity<br>
&gt;=C2=A0 =C2=A0 =C2=A0threshold,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; making it somewhat easier to review.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I think it&#39;s still important to include m=
ultiple signature algorithm options for users to select<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; their desired level of security. It&#39;s not=
 100% certain that all of these algorithms will remain<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; quantum resistant for all time, so redundancy=
 here is=E2=80=A6 key.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Another concern is that NIST level V is overk=
ill. I have less conviction on this since secp256k1<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; technically has 128 bits of security due to P=
ollard&#39;s rho attacks. But if the intention was<br>
&gt;=C2=A0 =C2=A0 =C2=A0for 256<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; bits of security, should level V security be =
the default? It&#39;s difficult for me to say.<br>
&gt;=C2=A0 =C2=A0 =C2=A0Perhaps both<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; level V and level I implementations could be =
included, but this would be a deviation from the<br>
&gt;=C2=A0 =C2=A0 =C2=A0BIP as<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; presently specified, which defaults to level =
V security. The disadvantage of including level I<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; support for each algorithm is that it essenti=
ally doubles the complexity of libbitcoinpqc.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Ultimately, I hope the default of NIST V and =
selection of 3 mature NIST-approved algorithms<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; demonstrate a focused, polished, and conserva=
tive proposal.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; At this point, the major call to action I wou=
ld like to highlight is simply the need for more<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; feedback from the community. Please review an=
d provide feedback here: <a href=3D"https://github.com/" rel=3D"noreferrer"=
 target=3D"_blank">https://github.com/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0bitcoin/ &lt;<a href=3D"https://github.com/bitcoin/=
" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/</a>&gt;<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; bips/pull/1670 &lt;<a href=3D"https://github.=
com/bitcoin/bips/pull/1670" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/bitcoin/bips/pull/1670</a> &lt;<a href=3D"https://github.com/bitco=
in/bips/" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/b=
ips/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0pull/1670&gt;&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I look forward to feedback and opinions on P2=
QRH and P2TRH.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; P.S. I&#39;ll be advocating for BIP-360 at OP=
_NEXT in VA, btc++ in Austin, Consensus in Toronto,<br>
&gt;=C2=A0 =C2=A0 =C2=A0and BTC<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; 25 in Las Vegas, and later this year, TABConf=
 in Atlanta.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; [1] <a href=3D"https://pqshield.github.io/nis=
t-sigs-zoo" rel=3D"noreferrer" target=3D"_blank">https://pqshield.github.io=
/nist-sigs-zoo</a> &lt;<a href=3D"https://pqshield.github.io/nist-sigs-zoo"=
 rel=3D"noreferrer" target=3D"_blank">https://pqshield.github.io/nist-sigs-=
zoo</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; [2] <a href=3D"https://eprint.iacr.org/2023/1=
820.pdf" rel=3D"noreferrer" target=3D"_blank">https://eprint.iacr.org/2023/=
1820.pdf</a> &lt;<a href=3D"https://eprint.iacr.org/2023/1820.pdf" rel=3D"n=
oreferrer" target=3D"_blank">https://eprint.iacr.org/2023/1820.pdf</a>&gt;<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; [3] <a href=3D"https://eprint.iacr.org/2024/1=
291.pdf" rel=3D"noreferrer" target=3D"_blank">https://eprint.iacr.org/2024/=
1291.pdf</a> &lt;<a href=3D"https://eprint.iacr.org/2024/1291.pdf" rel=3D"n=
oreferrer" target=3D"_blank">https://eprint.iacr.org/2024/1291.pdf</a>&gt;<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; [4] <a href=3D"https://groups.google.com/g/bi=
tcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ" rel=3D"noreferrer" target=3D"_blank"=
>https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ</a> &l=
t;https://<br>
&gt;=C2=A0 =C2=A0 =C2=A0<a href=3D"http://groups.google.com/g/bitcoindev/c/=
8O857bRSVV8/m/7uu4dZNgAwAJ" rel=3D"noreferrer" target=3D"_blank">groups.goo=
gle.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; [5] <a href=3D"https://docs.securosys.com/tsb=
/Tutorials/Post-Quantum-Cryptography/pqc-release-overview" rel=3D"noreferre=
r" target=3D"_blank">https://docs.securosys.com/tsb/Tutorials/Post-Quantum-=
Cryptography/pqc-release-overview</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"https://docs.securosys.com/tsb/Tutor=
ials/Post-Quantum-Cryptography/pqc-release-overview" rel=3D"noreferrer" tar=
get=3D"_blank">https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Crypto=
graphy/pqc-release-overview</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; --<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; You received this message because you are sub=
scribed to the Google Groups &quot;Bitcoin Development<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Mailing List&quot; group.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; To unsubscribe from this group and stop recei=
ving emails from it, send an email to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; <a href=3D"mailto:bitcoindev%2B...@googlegrou=
ps.com" target=3D"_blank">bitcoindev+...@googlegroups.com</a> &lt;mailto:<a=
 href=3D"mailto:bitcoindev%2B...@googlegroups.com" target=3D"_blank">bitcoi=
ndev+...@googlegroups.com</a>&gt;.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; To view this discussion visit <a href=3D"http=
s://groups.google.com/d/msgid/bitcoindev/8797807d-" rel=3D"noreferrer" targ=
et=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/8797807d-</a><br=
>
&gt;=C2=A0 =C2=A0 =C2=A0e017-44e2- &lt;<a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/8797807d-e017-44e2-" rel=3D"noreferrer" target=3D"_blan=
k">https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-</a>&gt;=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; b419-803291779007n%<a href=3D"http://40google=
groups.com" rel=3D"noreferrer" target=3D"_blank">40googlegroups.com</a> &lt=
;<a href=3D"http://40googlegroups.com" rel=3D"noreferrer" target=3D"_blank"=
>http://40googlegroups.com</a>&gt; &lt;<a href=3D"https://groups.google.com=
/" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0d/msgid/bitcoindev/8797807d- &lt;<a href=3D"https:/=
/groups.google.com/d/msgid/bitcoindev/8797807d-" rel=3D"noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/8797807d-</a>&gt;<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; e017-44e2-b419-803291779007n%<a href=3D"http:=
//40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nor=
eferrer" target=3D"_blank">40googlegroups.com?utm_medium=3Demail&amp;utm_so=
urce=3Dfooter</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"http://40googlegroups.com?utm_medium=
=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer" target=3D"_blank">http=
://40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfooter</a>&gt;&gt=
;.<br>
&gt; <br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development <br>
&gt; Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <br>
&gt; <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=3D=
"_blank">bitcoindev+unsubscribe@googlegroups.com</a> &lt;mailto:<a href=3D"=
mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=3D"_blank">bitcoin=
dev+unsubscribe@googlegroups.com</a>&gt;.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/866ee206-4a4e-4cd6-9de3-" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-</=
a> <br>
&gt; fa2fa35e2230n%<a href=3D"http://40googlegroups.com" rel=3D"noreferrer"=
 target=3D"_blank">40googlegroups.com</a> &lt;<a href=3D"https://groups.goo=
gle.com/d/msgid/" rel=3D"noreferrer" target=3D"_blank">https://groups.googl=
e.com/d/msgid/</a> <br>
&gt; bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%<a href=3D"http://40g=
ooglegroups.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferr=
er" target=3D"_blank">40googlegroups.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter</a>&gt;.<br>
<br>
-- <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%2Bunsubscribe@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/2e0fc337-3603-4a22-8056-59cf7e21aa43%40mattcorallo.com" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/2=
e0fc337-3603-4a22-8056-59cf7e21aa43%40mattcorallo.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/CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y%2BuEROb3BqxC2_G%2BXA%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y%2BuEROb3BqxC2_G%2BXA%=
40mail.gmail.com</a>.<br />

--000000000000da2c71062f2c1c92--