From: Josh Doman <joshsdoman@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile HSM support)
Date: Tue, 22 Jul 2025 14:44:02 -0700 (PDT) [thread overview]
Message-ID: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3342 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 3721 bytes --]
next reply other threads:[~2025-07-22 22:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 21:44 Josh Doman [this message]
2025-07-23 8:49 ` Greg Tonoski
2025-07-23 15:40 ` 'conduition' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com \
--to=joshsdoman@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox