path: root/b4/648d11e6487def3a9204054abf8fe08f23543a

Delivery-date: Wed, 23 Jul 2025 14:44:26 -0700
Received: from mail-oa1-f57.google.com ([209.85.160.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBMFPQXCAMGQEPTAQOAA@googlegroups.com>)
	id 1uehGE-0008HH-0V
	for bitcoindev@gnusha.org; Wed, 23 Jul 2025 14:44:26 -0700
Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-300884cb43bsf338254fac.2
        for <bitcoindev@gnusha.org>; Wed, 23 Jul 2025 14:44:25 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1753307060; cv=pass;
        d=google.com; s=arc-20240605;
        b=GtE9WtrzFjOX6W6ZFm5i2SiLw72LugGY1LOuvFZ1cpesI/34jjW5UVlnQ9vsE6th65
         a9Fn/YL/FxyP1biIEBoYUeYWScTfasU49hzN6brHM8+KUN6Q2SHLdFdpYHfGHKLjCrqV
         smhzh2U6irI4UlXq5G9d7SExmIPafMphXOQftaKnRzXdlebF3P0XMdLFdhFI++sil7Kk
         xny1ldo0GgdCOLFOtXcCEUrKUqrjvGherkwivT0+Gd8zkLbBgJXm5TmczQkylEsCvP/I
         vFKk4Nck/vyRHFlcg9S3LMRhLoKGW99uEW4MxyQ8uF40nUjlWgnUbR7l/TG3vt/a68m0
         ulDQ==
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:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=t7omqqEEm01d4FkRzHC3E1Rs0bVTONELH+4RH8AGVLg=;
        fh=Ksr9Jo4dYT+gR46iP9b5xrgDQkQLPsA7E+R4Wunp+A8=;
        b=iBlUEGrczkm85z3jHpuYpfguqwQavkYioHY/+mqxTqcqIoYI7N+BSMORDzXczhBpM2
         gqGKqX5qOgHKVEfVpWYbC2MzS8dgnRmD4JluUcmL5oZqDj6WMRhU8mvXAq4dn6kTb1d0
         qNazNZFPpI9MyTg6sxnTUIuekjOYdbmgMa1VgOGW/aadcrpXlCehvyOBoih+iibxX5LD
         pWGPFbC2QyvESvoKWUvHpSvPeHedUtu/F+7kqCDEdrr9NMb3LzKB/YgEM9HKLHYA0hNq
         07ALA10wDcrhcM38u1Z+60AF3RnwlkWOFii7kDNvR7wsMqe4feG9L8UV3BDfhhNDh5yx
         YoHQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=lfeqPSHk;
       spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1753307060; x=1753911860; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=t7omqqEEm01d4FkRzHC3E1Rs0bVTONELH+4RH8AGVLg=;
        b=kRgizzupqRgCfTrciviZ+bVxCwyJFVHSCsX+6wMY01NchP6NPFkUdvgLNsvtZq9TKz
         Okrp1uartexeBdZ5RcbSoWxIi+bSN/SDKQTIzOyT477m+x7xRTu5kxBYbBSs08opfDzR
         Czwe9lScKlhjM89oQRm3piViisJUWG1xqkhoWCzhjhDanjyxga/QU2YZVDXDJaPpgURd
         cPZfsCrtwYUZ3fGhNp/Lm5G/V7rA8Ghu8XdwFEa8jFeRzhO+/X9nlBWXDrLoJE1cQEkw
         KTF4HFrh4JcIBU2JGz+vTsK7skNxLR8aSQHv/S51sfkfDYoUZIrR58HqcXXP+cL5lv/V
         U7Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753307060; x=1753911860;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=t7omqqEEm01d4FkRzHC3E1Rs0bVTONELH+4RH8AGVLg=;
        b=ZVCFPhCNsHz1ogBSrFwirV59gmSLh7ZlCKsyu0/YbgWZHAvb44p9oACUEZ2csF3lej
         xENQJukTf0gBww57cnlEeEMeEa6c5fmdsycnmzph3Cax3mAEtSA6fliaMp7pNHmKHqW5
         qTQmxf8PjV5MJ/dvrTw9X/z0GrT1SiZHaqYw8e6SLP77KRtosZOL2kDCTxIJGfqB11ED
         MJezr/0XKZozvsEAmaGfmg9RjIs0TPBfIP1tS3eMFWRPMwHxaG5ZBYFguYk2L/fvW2nt
         ydMvYeUf6Ojr5qgKrbPc3u/t8pqe6OMjrReovTZw4rRZrSXk+qWCNzpR41RVErGzRUNC
         elnA==
X-Forwarded-Encrypted: i=2; AJvYcCXq+5e7sEmq/9BfJydIywf0i4mD9ZZAv12WBg/+zVz9LZEAUiAJ/YlxFQNlVXfaO0khL7VV+ANfAwFZ@gnusha.org
X-Gm-Message-State: AOJu0YxmmncmBQOr8yOB6GqoHa6PCUMW0yt5AE27WLg9JVXNRluxbF2Z
	Tv0X5XQhwF67Gpi0/Frji015rdC+6XklZuenSgyoNrsYuzLyuclxRb1s
X-Google-Smtp-Source: AGHT+IEz0UZuzJpRx0OHWRobyYQST+nKNhQqwB5PFKtxUSnPhA/1RQ/W0ARSpyTjeqbHiHNnAhSkkw==
X-Received: by 2002:a05:6870:b61f:b0:2e9:fd62:9061 with SMTP id 586e51a60fabf-306c72eed1emr3629291fac.32.1753307059536;
        Wed, 23 Jul 2025 14:44:19 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc0E/WEm0+7OKK5ThxoORlGTFqjjJBo+749ntb0AoxweA==
Received: by 2002:a05:6870:f707:b0:306:c9db:27c1 with SMTP id
 586e51a60fabf-306ddc1cdbels136102fac.2.-pod-prod-09-us; Wed, 23 Jul 2025
 14:44:16 -0700 (PDT)
X-Received: by 2002:a05:6808:159f:b0:40c:7996:73e3 with SMTP id 5614622812f47-426c643b0d3mr3676510b6e.28.1753307056655;
        Wed, 23 Jul 2025 14:44:16 -0700 (PDT)
Received: by 2002:a05:600c:c116:b0:456:ce4:c44e with SMTP id 5b1f17b1804b1-458677e9109ms5e9;
        Wed, 23 Jul 2025 08:40:55 -0700 (PDT)
X-Received: by 2002:a05:600d:4:b0:439:9b2a:1b2f with SMTP id 5b1f17b1804b1-4586974aeccmr27979505e9.3.1753285253373;
        Wed, 23 Jul 2025 08:40:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1753285253; cv=none;
        d=google.com; s=arc-20240605;
        b=Zxj65L4t1Q0etCjDWP1UbOiYILU9vZj9HxyV4Y/NM05vpOwVY1zmxPSGeo0coqmAM5
         TdwxwaOAwDTT1nSm+pl4otK4rMuELbuFkgppPdbwX6b288sC719RgL5PRoKX+O/pu8AW
         FvjPgdui+LHBPySHf+hYXNHmafVJ0koqP0W/qLjMDfx7gddXA18Nn3ZEVlovQS22p40X
         ebPeX+5mxTxtJtoNXNYVU0Zl48VHMt70G+h4OWom/7hfMRF6TCVvC/MvWN7TB3DlKaAW
         qd0AGbuudviALqOvmfzq8a20poJ606FGI0bqWkZvoVO2XyMA5reGbKsfIZiGt9rCiLjb
         w8QA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=tYGzkLlQHvBFFzxZkoc3HanRd+q/UQC7T97adweO+HE=;
        fh=zw14EGzQje/EQlEB4Z3hSEaC3Thm583Hfs9yKrsDsSY=;
        b=IwHCqvbV/gC+tSpevqFtzX1C4+TMIWkrc4/9Wc5qbHgmU/IFHoEkBoqiLBabA3hQFJ
         cYlQrOi/0epnrSfYErkbmS5EEKYb5j4TTga3O9ALrJu/h3YlK9wdQUv4yLm6l6KKnNvD
         Pdhcg3VVHS8wpdeOwcVCidRZqfOePDsVsoorZOmSJcpFsOGaYTop1H0bZWJWnztvQaZR
         a0XJUSVE3xylCYN2sk02zz/fpXNBn3bK20c8IRSSGOIEwU58R6M+iZk4/Xxrb7YHulm/
         EjioPlh/mQ5sC6fcsIP4cpbyU1R/J+J/VSWVQXOgEFnyev08gCo6WWvSzOD0SHSoPGBA
         K8WQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=lfeqPSHk;
       spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45862cd79e0si550865e9.0.2025.07.23.08.40.53
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 23 Jul 2025 08:40:53 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Wed, 23 Jul 2025 15:40:45 +0000
To: Josh Doman <joshsdoman@gmail.com>
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile
 HSM support)
Message-ID: <GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk=@proton.me>
In-Reply-To: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
References: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: 7d90f27ec8409fe659cf26101e13c5a96a9b67f7
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4"; charset=utf-8
X-Original-Sender: conduition@proton.me
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@proton.me header.s=protonmail header.b=lfeqPSHk;       spf=pass
 (google.com: domain of conduition@proton.me designates 185.70.43.22 as
 permitted sender) smtp.mailfrom=conduition@proton.me;       dmarc=pass
 (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
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: 2.1 (++)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4
Content-Type: multipart/mixed;boundary=---------------------68f72579bfe03ee21aa74ea90fdff0da

-----------------------68f72579bfe03ee21aa74ea90fdff0da
Content-Type: multipart/alternative;boundary=---------------------27fdabd9e2d81625eb76b91397d94845

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

Hey Josh, thanks for raising the idea.

While it's a neat premise, I think the timelines involved will not mesh wel=
l. It'd take several years to get community consensus (the fact it hasn't b=
een discussed suggests not many people are interested), to build a high-qua=
lity implementation on-par with libsecp256k1, and to spec out and implement=
 a soft fork.

By itself that'd be OK, but not when you consider other "new sig algo" proj=
ects happening in parallel: BIP360 and other post-quantum debates which wil=
l eventually lead to the addition of at least one new signature algorithm t=
o consensus. By the time P256 is standardized and available, everyone will =
likely be moving towards post-quantum opcodes. It may well be obviated if a=
 cryptographically relevant quantum computer comes out earlier than expecte=
d.

I'm not familiar with the WebAuthn standard, but surely its authors are the=
mselves also thinking about post-quantum security. Perhaps if you want HSM =
support in the next decade, your best shot may be to research WebAuthn's po=
st-quantum signature formats. Possible relevant reading. I'd suggest you re=
search a way to make WebAuthn's signing flow compatible with the post-quant=
um sig verification opcodes being developed for bitcoin (or vice-versa, tal=
k with Ethan Heilman and try to make the Bitcoin standards compatible with =
WebAuthn).

The next part is just for my own curiosity.=C2=A0

I'm not sure relying on webauthn is a good idea in the first place. It's a =
standard suited for web-based authentication to centralized services, not f=
or long-term cryptographic identities or ownership across distributed syste=
ms. I've never heard of any WebAuthn authenticator which gives users a dete=
rministic backup seed of any kind, so how would users recover their bitcoin=
s independently in this context? Could a hypothetical webauthn wallet handl=
e something like BIP32 without upstream support in WebAuthn?

And how would multi-address wallets work? I'm imagining the webauthn wallet=
 would need to generate a new credential every time the user wants to gener=
ate a new P256 address. Wouldn't that clutter the user's keychain?

regards,
conduition
On Tuesday, July 22nd, 2025 at 3:03 PM, Josh Doman <joshsdoman@gmail.com> w=
rote:

> A brief search on gnusha.org suggests that it's been over 10 years since =
the Bitcoin community last discussed adding secp256r1 support (also known a=
s P256). The most in-depth discussions I found were on BitcoinTalk in 2011 =
and 2013.
>=20

> Since then, P256 has gained widespread adoption across the modern interne=
t and on mobile. Most notably, millions of users now possess mobile devices=
 capable of generating and storing private keys in secure enclaves (see App=
le iCloud Keychain and Android Keystore). Millions of users might be able t=
o immediately use this to start self-custodying bitcoin, except this hardwa=
re only supports P256 signatures, which is incompatible with the secp256k1 =
curve that Bitcoin currently uses.
>=20

> Reading through old discussions, it appears that the primary concern the =
community had with P256 is the possibility of a NIST backdoor. Putting the =
likelihood of this aside, it seems reasonable to me that in 2025, users sho=
uld at least have the option of using P256, if they wish. Native HSM suppor=
t would significantly improve the onboarding experience for new users, incr=
ease the security and accessibility of hot wallets, and potentially reduce =
the cost of collaborative multisigs. Meanwhile, the community can continue =
to use secp256k1 as the ideal curve for private keys secured in cold storag=
e.
>=20

> At a technical level, Tapscript makes P256 mechanically straightforward t=
o adopt, because it has built-in support for new types of public keys. For =
example, we could define a 33-byte public key as one requiring a P256 ECDSA=
 signature, while continuing to use 32-bytes for keys requiring Schnorr sig=
natures over secp256k1.
>=20

> A secondary concern that I came across is that P256 can be 2-3x slower to=
 validate than secp256k1. Assuming this cannot be improved, we can account =
for slower validation by doubling or tripling the validation weight cost fo=
r a P256 signature. Users can then pre-commit in their script to this addit=
ional weight or commit to it in the annex, as intended by BIP341.
>=20

> P256 support would grant apps the ability to use platform APIs to access =
the secure HSM on user's mobile devices, but alone, P256 is insufficient fo=
r non-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn sign=
ature, we'd additionally need CSFS and CAT, so we can compute a WebAuthn me=
ssage from a sighash and the necessary WebAuthn data on the stack. Alternat=
ively, we could create a dedicated WebAuthn opcode to verify a WebAuthn mes=
sage without enabling recursive covenants. Regardless, the ability to verif=
y a P256 signature would be an important primitive.
>=20

> In summary, given the widespread hardware adoption and industry usage, is=
 it worth revisiting adding P256 support to Bitcoin?
>=20

>=20

> Josh Doman
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.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/=
GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrV=
l24qmyqVgBvrZ8FT0POeomam2qB6-cqk%3D%40proton.me.

-----------------------27fdabd9e2d81625eb76b91397d94845
Content-Type: multipart/related;boundary=---------------------bac8cedddd21798afd47914c6dd713aa

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hey Josh, t=
hanks for raising the idea.</div><div style=3D"font-family: Arial, sans-ser=
if; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px;">While it's a neat premise, I think the timelines invol=
ved will not mesh well. It'd take several years to get community consensus =
(the fact it hasn't been discussed suggests not many people are interested)=
, to build a high-quality implementation on-par with libsecp256k1, and to s=
pec out and implement a soft fork.</div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px;">By itself that'd be OK, but not when you consid=
er other "new sig algo" projects happening in parallel: BIP360 and other po=
st-quantum debates which will eventually lead to the addition of at least o=
ne new signature algorithm to consensus. By the time P256 is standardized a=
nd available, everyone will likely be moving towards post-quantum opcodes. =
It may well be obviated if a cryptographically relevant quantum computer co=
mes out earlier than expected.</div><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-s=
erif; font-size: 14px;">I'm not familiar with the WebAuthn standard, but su=
rely its authors are themselves also thinking about post-quantum security. =
Perhaps if you want HSM support in the next decade, your best shot may be t=
o research WebAuthn's post-quantum signature formats. <a href=3D"https://ww=
w.ietf.org/archive/id/draft-vitap-ml-dsa-webauthn-00.html" title=3D"Possibl=
e relevant reading">Possible relevant reading</a>. I'd suggest you research=
 a way to make WebAuthn's signing flow compatible with the post-quantum sig=
 verification opcodes being developed for bitcoin (or vice-versa, talk with=
 Ethan Heilman and try to make the Bitcoin standards compatible with WebAut=
hn).</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><=
br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Th=
e next part is just for my own curiosity.&nbsp;</div><div style=3D"font-fam=
ily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;">I'm not sure relying on webauthn i=
s a good idea in the first place. It's a standard suited for web-based auth=
entication to centralized services, not for long-term cryptographic identit=
ies or ownership across distributed systems. I've never heard of any WebAut=
hn authenticator which gives users a deterministic backup seed of any kind,=
 so how would users recover their bitcoins independently in this context? C=
ould a hypothetical webauthn wallet handle something like BIP32 without ups=
tream support in WebAuthn?</div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif=
; font-size: 14px;">And how would multi-address wallets work? I'm imagining=
 the webauthn wallet would need to generate a new credential every time the=
 user wants to generate a new P256 address. Wouldn't that clutter the user'=
s keychain?</div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14=
px;">regards,</div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;">conduition</div><div class=3D"protonmail_quote">
        On Tuesday, July 22nd, 2025 at 3:03 PM, Josh Doman &lt;joshsdoman@g=
mail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            A brief search on <a href=3D"https://gnusha.org/pi/bitcoindev/?=
q=3Dsecp256r1" target=3D"_blank" rel=3D"noreferrer nofollow noopener">gnush=
a.org</a> suggests that it's been over 10 years since the Bitcoin community=
 last discussed adding secp256r1 support (also known as P256). The most in-=
depth discussions I found were on BitcoinTalk in <a href=3D"https://bitcoin=
talk.org/?topic=3D2699.0" target=3D"_blank" rel=3D"noreferrer nofollow noop=
ener">2011</a> and <a href=3D"https://bitcointalk.org/index.php?topic=3D151=
120.0" target=3D"_blank" rel=3D"noreferrer nofollow noopener">2013</a>.<br>=
<br>Since then, P256 has gained widespread adoption across the modern inter=
net and on mobile. Most notably, millions of users now possess mobile devic=
es capable of generating and storing private keys in secure enclaves (see A=
pple iCloud Keychain and Android Keystore). Millions of users might be able=
 to immediately use this to start self-custodying bitcoin, except this hard=
ware only supports P256 signatures, which is incompatible with the secp256k=
1 curve that Bitcoin currently uses.<br><br>Reading through old discussions=
, it appears that the primary concern the community had with P256 is the po=
ssibility of a NIST backdoor. Putting the likelihood of this aside, it seem=
s reasonable to me that in 2025, users should at least have the option of u=
sing P256, if they wish. Native HSM support would significantly improve the=
 onboarding experience for new users, increase the security and accessibili=
ty of hot wallets, and potentially reduce the cost of collaborative multisi=
gs. Meanwhile, the community can continue to use secp256k1 as the ideal cur=
ve for private keys secured in cold storage.<br><br>At a technical level, T=
apscript makes P256 mechanically straightforward to adopt, because it has b=
uilt-in support for new types of public keys. For example, we could define =
a 33-byte public key as one requiring a P256 ECDSA signature, while continu=
ing to use 32-bytes for keys requiring Schnorr signatures over secp256k1.<b=
r><br>A secondary concern that I came across is that P256 can be 2-3x slowe=
r to validate than secp256k1. Assuming this cannot be improved, we can acco=
unt for slower validation by doubling or tripling the validation weight cos=
t for a P256 signature. Users can then pre-commit in their script to this a=
dditional weight or commit to it in the annex, as intended by <a href=3D"ht=
tps://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" target=3D"_bl=
ank" rel=3D"noreferrer nofollow noopener">BIP341</a>.<br><br>P256 support w=
ould grant apps the ability to use platform APIs to access the secure HSM o=
n user's mobile devices, but alone, P256 is insufficient for non-custodial =
WebAuthn / passkey-based wallets. To verify a WebAuthn signature, we'd addi=
tionally need CSFS and CAT, so we can compute a WebAuthn message from a sig=
hash and the necessary WebAuthn data on the stack. Alternatively, we could =
create a dedicated WebAuthn opcode to verify a WebAuthn message without ena=
bling recursive covenants. Regardless, the ability to verify a P256 signatu=
re would be an important primitive.<br><br>In summary, <b>given the widespr=
ead hardware adoption and industry usage, is it worth revisiting adding P25=
6 support to Bitcoin?</b><br><div><b><br></b></div><div>Josh Doman</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.google.com/=
d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </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/GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTch=
lGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk%3D%40proton.me?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/GVA2lG=
8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmy=
qVgBvrZ8FT0POeomam2qB6-cqk%3D%40proton.me</a>.<br />

-----------------------bac8cedddd21798afd47914c6dd713aa--
-----------------------27fdabd9e2d81625eb76b91397d94845--
-----------------------68f72579bfe03ee21aa74ea90fdff0da
Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI
YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO
dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3
Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL
YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox
K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo
CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J
MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr
T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR
TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp
S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag
UFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
-----------------------68f72579bfe03ee21aa74ea90fdff0da--

--------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmiBAm0JkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmeNq7aI/CZB2GpK29m19bz8hDGG/grBMEpOTYu6
ciytlBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB0BAD+IaPCjkmJVhE+bFX/
6v0XINusqoMvKy7cdKOdvXF+ho8A/jQFghaQtUPUpIVwwAu//pwqIm/Wv/3H
OriDiB7XLXEN
=HpPf
-----END PGP SIGNATURE-----


--------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4--