Delivery-date: Fri, 25 Jul 2025 10:01:48 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gregtonoski@gmail.com designates 2607:f8b0:4864:20::b29 as permitted sender) client-ip=2607:f8b0:4864:20::b29;
MIME-Version: 1.0
References: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
In-Reply-To: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
From: Greg Tonoski <gregtonoski@gmail.com>
Date: Wed, 23 Jul 2025 10:49:55 +0200
Message-ID: <CAMHHROzaOap8d8gJ+zOcSQ5t9f7u_MQ5M=5abebkWpqkM7tprQ@mail.gmail.com>
Subject: Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile
 HSM support)
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000009d2f2063a94ccae"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--00000000000009d2f2063a94ccae
Content-Type: text/plain; charset="UTF-8"

I can see another attempt to re-open the vulnerability OP_CAT which had
been closed in Bitcoin long time ago. It's pushed under the guise of
secp256r1  which has nothing to do with the OP_CAT. Also, HSM and other
technobabble is irrelevant. For example, mobile users already have "mobile
HSM support" - see Samsung Blockchain Keystore.

-- 
Greg Tonoski

On Wed, 23 Jul 2025, 00:03 Josh Doman, <joshsdoman@gmail.com> wrote:

> A brief search on gnusha.org
> <https://gnusha.org/pi/bitcoindev/?q=secp256r1> 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 2011 <https://bitcointalk.org/?topic=2699.0> and 2013
> <https://bitcointalk.org/index.php?topic=151120.0>.
>
> Since then, P256 has gained widespread adoption across the modern internet
> and on mobile. Most notably, millions of users now possess mobile devices
> capable of generating and storing private keys in secure enclaves (see
> Apple iCloud Keychain and Android Keystore). Millions of users might be
> able to immediately use this to start self-custodying bitcoin, except this
> hardware only supports P256 signatures, which is incompatible with the
> secp256k1 curve that Bitcoin currently uses.
>
> 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
> should at least have the option of using P256, if they wish. Native HSM
> support would significantly improve the onboarding experience for new
> users, increase 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 storage.
>
> At a technical level, Tapscript makes P256 mechanically straightforward to
> 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
> signatures over secp256k1.
>
> 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
> for a P256 signature. Users can then pre-commit in their script to this
> additional weight or commit to it in the annex, as intended by BIP341
> <https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki>.
>
> 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
> for non-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn
> signature, we'd additionally need CSFS and CAT, so we can compute a
> WebAuthn message from a sighash and the necessary WebAuthn data on the
> stack. Alternatively, we could create a dedicated WebAuthn opcode to verify
> a WebAuthn message without enabling recursive covenants. Regardless, the
> ability to verify a P256 signature would be an important primitive.
>
> In summary, *given the widespread hardware adoption and industry usage,
> is it worth revisiting adding P256 support to Bitcoin?*
>
> Josh Doman
>
> --
> 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/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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/CAMHHROzaOap8d8gJ%2BzOcSQ5t9f7u_MQ5M%3D5abebkWpqkM7tprQ%40mail.gmail.com.

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

<div dir=3D"auto">I can see another attempt to re-open the vulnerability OP=
_CAT which had been closed in Bitcoin long time ago. It&#39;s pushed under =
the guise of secp256r1=C2=A0 which has nothing to do with the OP_CAT. Also,=
 HSM and other technobabble is irrelevant. For example, mobile users alread=
y have &quot;mobile HSM support&quot; - see Samsung Blockchain Keystore.<br=
><br>--=C2=A0<div dir=3D"auto">Greg Tonoski<br><br><div class=3D"gmail_quot=
e gmail_quote_container" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Wed, 23 Jul 2025, 00:03 Josh Doman, &lt;<a href=3D"mailto:joshsdoman@gm=
ail.com">joshsdoman@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">A brief search on <a href=3D"https://gnusha.or=
g/pi/bitcoindev/?q=3Dsecp256r1" target=3D"_blank" rel=3D"noreferrer">gnusha=
.org</a> suggests that it&#39;s been over 10 years since the Bitcoin commun=
ity last discussed adding secp256r1 support (also known as P256). The most =
in-depth discussions I found were on BitcoinTalk in <a href=3D"https://bitc=
ointalk.org/?topic=3D2699.0" target=3D"_blank" rel=3D"noreferrer">2011</a> =
and <a href=3D"https://bitcointalk.org/index.php?topic=3D151120.0" target=
=3D"_blank" rel=3D"noreferrer">2013</a>.<br><br>Since then, P256 has gained=
 widespread adoption across the modern internet and on mobile. Most notably=
, millions of users now possess mobile devices capable of generating and st=
oring private keys in secure enclaves (see Apple iCloud Keychain and Androi=
d Keystore). Millions of users might be able to immediately use this to sta=
rt self-custodying bitcoin, except this hardware only supports P256 signatu=
res, which is incompatible with the secp256k1 curve that Bitcoin currently =
uses.<br><br>Reading through old discussions, it appears that the primary c=
oncern the community had with P256 is the possibility of a NIST backdoor. P=
utting the likelihood of this aside, it seems reasonable to me that in 2025=
, users should at least have the option of using P256, if they wish. Native=
 HSM support would significantly improve the onboarding experience for new =
users, increase the security and accessibility of hot wallets, and potentia=
lly reduce the cost of collaborative multisigs. Meanwhile, the community ca=
n continue to use secp256k1 as the ideal curve for private keys secured in =
cold storage.<br><br>At a technical level, Tapscript makes P256 mechanicall=
y straightforward to adopt, because it has built-in support for new types o=
f public keys. For example, we could define a 33-byte public key as one req=
uiring a P256 ECDSA signature, while continuing to use 32-bytes for keys re=
quiring Schnorr signatures over secp256k1.<br><br>A secondary concern that =
I came across is that P256 can be 2-3x slower to validate than secp256k1. A=
ssuming this cannot be improved, we can account for slower validation by do=
ubling or tripling the validation weight cost for a P256 signature. Users c=
an then pre-commit in their script to this additional weight or commit to i=
t in the annex, as intended by <a href=3D"https://github.com/bitcoin/bips/b=
lob/master/bip-0341.mediawiki" target=3D"_blank" rel=3D"noreferrer">BIP341<=
/a>.<br><br>P256 support would grant apps the ability to use platform APIs =
to access the secure HSM on user&#39;s mobile devices, but alone, P256 is i=
nsufficient for non-custodial WebAuthn / passkey-based wallets. To verify a=
 WebAuthn signature, we&#39;d additionally need CSFS and CAT, so we can com=
pute a WebAuthn message from a sighash and the necessary WebAuthn data on t=
he stack. Alternatively, we could create a dedicated WebAuthn opcode to ver=
ify a WebAuthn message without enabling recursive covenants. Regardless, th=
e ability to verify a P256 signature would be an important primitive.<br><b=
r>In summary, <b>given the widespread hardware adoption and industry usage,=
 is it worth revisiting adding P256 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 &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer">bitcoindev+unsubscribe@googlegroups.com</a>.=
<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"noreferrer">h=
ttps://groups.google.com/d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6ec=
c1been%40googlegroups.com</a>.<br><br>
</blockquote></div></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/CAMHHROzaOap8d8gJ%2BzOcSQ5t9f7u_MQ5M%3D5abebkWpqkM7tprQ%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAMHHROzaOap8d8gJ%2BzOcSQ5t9f7u_MQ5M%3D5abebkWpqkM7tprQ%=
40mail.gmail.com</a>.<br />

--00000000000009d2f2063a94ccae--