Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile HSM support)

[Javier Mateos <javierpmateos@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8762 bytes --]

Hi everyone... thanks to Josh for opening this debate.

A brief practical point: rather than pushing for consensus changes to 
support a different cryptographic curve, I believe manufacturers today have 
a real opportunity to differentiate themselves by offering better 
self-custody support on their devices. Let them compete: if Apple decides 
to incorporate compatibility whit secp256k1, it will gain a competitive 
advantage over Samsung (and vice versa), and if bitcoinization expands on a 
large scale, that advantage could become very significant. If the market 
perceives value in these functionalities, companies will be motivated to 
implement them.

Adding to Greg Tonoski´s point, Samsung demonstrated that the "mobile HSM + 
secp256k1" approach is technically viable (its Blockchain Keystore/SDK 
exposes APIs capable of producing ECDSA/secp256k1 signatures on selected 
Galaxy devices). While the solution ended up fragmented by model/region and 
dependent on the vendor, there was concrete development.

Also, let's remember that Bitcoin is an open and permeable organization: 
anyone or any entity can add value, whether through software 
implementations, specification development, or tool creation. When 
interests and goals align, those contributions get integrated and 
manufacturers to experiment with practical, real-world solutions before 
forcing consensus changes, wich tend to be lengthy, complex, and risky.

Best regards,
Javier Mateos

El viernes, 8 de agosto de 2025 a las 23:06:29 UTC-3, Josh Doman escribió:

> Hi conduition, thanks for the thoughtful reply. I think you're right. 
> Given the apparent lack of interest, it's probably better to wait and see 
> which quantum-resistant signature scheme becomes standard. At that point, 
> if Bitcoin adopts the same standard as mobile devices, Bitcoin will also 
> gain native mobile support.
>
> You're correct that the present WebAuthn signing flow does not support 
> BIP32 or exporting a seed from the secure enclave. With taproot, users 
> could create multiple addresses using deterministic unspendable alternative 
> script paths, but the addresses would be easily linked once spent. Neither 
> of those limitations are ideal for Bitcoin, though they may be acceptable 
> for certain users.
>
> Josh
>
>
> On Wednesday, July 23, 2025 at 5:44:19 PM UTC-4 conduition wrote:
>
> Hey Josh, thanks for raising the idea.
>
> While it's a neat premise, I think the timelines involved 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 spec out and 
> implement a soft fork.
>
> By itself that'd be OK, but not when you consider other "new sig algo" 
> projects happening in parallel: BIP360 and other post-quantum debates which 
> will eventually lead to the addition of at least one new signature 
> algorithm to 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 expected.
>
> I'm not familiar with the WebAuthn standard, but surely 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 to research 
> WebAuthn's post-quantum signature formats. Possible relevant reading 
> <https://www.ietf.org/archive/id/draft-vitap-ml-dsa-webauthn-00.html>. 
> 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 WebAuthn).
>
> The next part is just for my own curiosity. 
>
> 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 
> for long-term cryptographic identities or ownership across distributed 
> systems. I've never heard of any WebAuthn authenticator which gives users a 
> deterministic backup seed of any kind, so how would users recover their 
> bitcoins independently in this context? Could a hypothetical webauthn 
> wallet handle 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 
> generate 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 <joshs...@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+...@googlegroups.com.
> To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com
> .
>
>
>

-- 
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/57f6748d-4c36-4b83-8ae6-cdabc830ad29n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 12315 bytes --]