Delivery-date: Wed, 23 Jul 2025 14:44:26 -0700
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
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4"; charset=utf-8
Reply-To: conduition <conduition@proton.me>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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--