From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 08 Aug 2025 19:06:37 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ukYyi-0005ki-AZ for bitcoindev@gnusha.org; Fri, 08 Aug 2025 19:06:37 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-30c4b40d872sf11675fac.3 for ; Fri, 08 Aug 2025 19:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1754705190; x=1755309990; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=voYmq5+Zx2FoRlcmva6bQfmbyhn3HOgXj+eI4V0cFaU=; b=DQuFOo+2ah0N1fAAeF9jiwxJk9f8cyuRgNOZLCnlOv4YNN1q37YQ/uU7DP+PhMtHC+ jixxYc90zYIdJS2SrRYwkz2pE/KZQemymSjV8wCYeJSxD58hf1xO/Ra8wI7V7KD8C9c0 p5DNCihWbxv2RUL1r+KFo269ewS6uvsCvvrD9OD85wef8bGCpbrMX0V5yshxQSHHuF4j /tjsuiummZke89mQeTjdeOLq4uamuJTA0l16kZ7R1ykku0XV/3psHrfWb3ijROyE40tw R855Yi0vsT9TdubvxbGagwNohHHGnSWeNSP+TV8QwrB46fjPRXtMmj02s6Lfv5r30STE NsAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754705190; x=1755309990; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=voYmq5+Zx2FoRlcmva6bQfmbyhn3HOgXj+eI4V0cFaU=; b=N7aIDJ0DiHS6zSxEskzhkM7/pO29c3QW/Dtw6n9/dN2hZBFErn1LohflZClbLb6Pba WF0xUBYdoU68CMLWfwGCyYVy1HgKBPoJRnPHlOMcs8nte4oBb9iktE3/1rzbotQUrskz VlJN4CYDqrRuE5unyPn44Y3PqJIRuYH9EteWhZUndmDtf0xjphGTdHXD5N+Srk+cKw1R 1t0+DWXcuEuXZu6RVmjenf6CbUO6w85LnfhcLm7DsTqXJzC7tLCbsidyBGB5qvgpkGnY 5jo3QVrcWwm8chMP8y+OdppgkoQ+YogNX8/Gi9aanquO9Bv936sBsZ2S3PxofYworwnk +RNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754705190; x=1755309990; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=voYmq5+Zx2FoRlcmva6bQfmbyhn3HOgXj+eI4V0cFaU=; b=ZbddNGDBxGi3dKjQUfgIJ3CxjpQs7szR0YRwU7o2Fr5+TpursTBuv6DIEWkcDoV+dv Juw0zabKb2Oih9ycY1yu8Usl48cMGAdhfUb1Utjzl68/UV+03IJUVNTo07sCGGqc4zVY YtBYhq9VyBgBGfgURGhwcmUOKx+rePGmvL90WBZBn+juGRdLs45awz/urcIO26ZYSExA uydZJw+kyO7w2C5j9VCQAn0gSdhGlUCgTLoyGPfhSqDRxGZgD60eI6GYW5HfC5PFm4YN jY9ap6pS4yIKsWM13rvgfrIZPX8U72KLk2RI5WHs2J0SrOcDqev6P02Y1jMYR4B0no+K G4cg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWxUjFYHzONblyQ879bid3ic9+RUUBsUHiKAkfnSm7qzKKMLwTnC6XOH3aLMkW5L3l51fsQ6CK5JjB3@gnusha.org X-Gm-Message-State: AOJu0YwrRE8frq4XdEQ05zG/TWgzomNxx694AhXqF8N6O3XGqXcSmePN wLZmxnUIHlz6Mo6mu5HXBifVwM/QYEd1OjFoRT00f1dcleUDVFVGO2uk X-Google-Smtp-Source: AGHT+IFtczdsIYx4sa2+yr+aygNA3LO8uSGzNugugDlay3X1At66QnhGVRrl2YuP8A16afD/5/f1LQ== X-Received: by 2002:a9d:6448:0:b0:741:dffb:13fa with SMTP id 46e09a7af769-7432c8a0fa4mr3385167a34.21.1754705189653; Fri, 08 Aug 2025 19:06:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd0o3EEOt0eDx/tb0rKSgsyt0Cpg4ZurqZAiZ6ExmKAIA== Received: by 2002:a05:6820:3288:b0:611:fdca:b1b1 with SMTP id 006d021491bc7-61b6e4949ccls685757eaf.0.-pod-prod-04-us; Fri, 08 Aug 2025 19:06:25 -0700 (PDT) X-Received: by 2002:a05:6808:30a8:b0:40c:fc48:33b5 with SMTP id 5614622812f47-43597ba6564mr2718091b6e.12.1754705185789; Fri, 08 Aug 2025 19:06:25 -0700 (PDT) Received: by 2002:a05:690c:2605:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71bf1a7df88ms7b3; Fri, 8 Aug 2025 13:48:52 -0700 (PDT) X-Received: by 2002:a05:690c:5504:10b0:71b:f755:bbab with SMTP id 00721157ae682-71bf759a9a1mr27621977b3.14.1754686131269; Fri, 08 Aug 2025 13:48:51 -0700 (PDT) Date: Fri, 8 Aug 2025 13:48:50 -0700 (PDT) From: Josh Doman To: Bitcoin Development Mailing List Message-Id: <6221341a-fea7-42ff-aabf-0ce3a783986en@googlegroups.com> In-Reply-To: References: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com> Subject: Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2662_727612150.1754686130835" X-Original-Sender: joshsdoman@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.6 (++) ------=_Part_2662_727612150.1754686130835 Content-Type: multipart/alternative; boundary="----=_Part_2663_1323640421.1754686130835" ------=_Part_2663_1323640421.1754686130835 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, thanks for the thoughtful reply. I think you're right. Given= =20 the apparent lack of interest, it's probably better to wait and see which= =20 quantum-resistant signature scheme becomes standard. At that point, if=20 Bitcoin adopts the same standard as mobile devices, Bitcoin will also gain= =20 native mobile support. You're correct that the present WebAuthn signing flow does not support=20 BIP32 or exporting a seed from the secure enclave. With taproot, users=20 could create multiple addresses using deterministic unspendable alternative= =20 script paths, but the addresses would be easily linked once spent. Neither= =20 of those limitations are ideal for Bitcoin, though they may be acceptable= =20 for certain users. Josh On Wednesday, July 23, 2025 at 5:44:19=E2=80=AFPM 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=20 well. It'd take several years to get community consensus (the fact it=20 hasn't been discussed suggests not many people are interested), to build a= =20 high-quality implementation on-par with libsecp256k1, and to spec out and= =20 implement a soft fork. By itself that'd be OK, but not when you consider other "new sig algo"=20 projects happening in parallel: BIP360 and other post-quantum debates which= =20 will eventually lead to the addition of at least one new signature=20 algorithm to consensus. By the time P256 is standardized and available,=20 everyone will likely be moving towards post-quantum opcodes. It may well be= =20 obviated if a cryptographically relevant quantum computer comes out earlier= =20 than expected. I'm not familiar with the WebAuthn standard, but surely its authors are=20 themselves also thinking about post-quantum security. Perhaps if you want= =20 HSM support in the next decade, your best shot may be to research=20 WebAuthn's post-quantum signature formats. Possible relevant reading=20 . I'd= =20 suggest you research a way to make WebAuthn's signing flow compatible with= =20 the post-quantum sig verification opcodes being developed for bitcoin (or= =20 vice-versa, talk with Ethan Heilman and try to make the Bitcoin standards= =20 compatible with WebAuthn). The next part is just for my own curiosity.=20 I'm not sure relying on webauthn is a good idea in the first place. It's a= =20 standard suited for web-based authentication to centralized services, not= =20 for long-term cryptographic identities or ownership across distributed=20 systems. I've never heard of any WebAuthn authenticator which gives users a= =20 deterministic backup seed of any kind, so how would users recover their=20 bitcoins independently in this context? Could a hypothetical webauthn=20 wallet handle something like BIP32 without upstream support in WebAuthn? And how would multi-address wallets work? I'm imagining the webauthn wallet= =20 would need to generate a new credential every time the user wants to=20 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 =20 wrote: A brief search on gnusha.org =20 suggests that it's been over 10 years since the Bitcoin community last=20 discussed adding secp256r1 support (also known as P256). The most in-depth= =20 discussions I found were on BitcoinTalk in 2011=20 and 2013=20 . Since then, P256 has gained widespread adoption across the modern internet= =20 and on mobile. Most notably, millions of users now possess mobile devices= =20 capable of generating and storing private keys in secure enclaves (see=20 Apple iCloud Keychain and Android Keystore). Millions of users might be=20 able to immediately use this to start self-custodying bitcoin, except this= =20 hardware only supports P256 signatures, which is incompatible with the=20 secp256k1 curve that Bitcoin currently uses. Reading through old discussions, it appears that the primary concern the=20 community had with P256 is the possibility of a NIST backdoor. Putting the= =20 likelihood of this aside, it seems reasonable to me that in 2025, users=20 should at least have the option of using P256, if they wish. Native HSM=20 support would significantly improve the onboarding experience for new=20 users, increase the security and accessibility of hot wallets, and=20 potentially reduce the cost of collaborative multisigs. Meanwhile, the=20 community can continue to use secp256k1 as the ideal curve for private keys= =20 secured in cold storage. At a technical level, Tapscript makes P256 mechanically straightforward to= =20 adopt, because it has built-in support for new types of public keys. For=20 example, we could define a 33-byte public key as one requiring a P256 ECDSA= =20 signature, while continuing to use 32-bytes for keys requiring Schnorr=20 signatures over secp256k1. A secondary concern that I came across is that P256 can be 2-3x slower to= =20 validate than secp256k1. Assuming this cannot be improved, we can account= =20 for slower validation by doubling or tripling the validation weight cost=20 for a P256 signature. Users can then pre-commit in their script to this=20 additional 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=20 the secure HSM on user's mobile devices, but alone, P256 is insufficient=20 for non-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn=20 signature, we'd additionally need CSFS and CAT, so we can compute a=20 WebAuthn message from a sighash and the necessary WebAuthn data on the=20 stack. Alternatively, we could create a dedicated WebAuthn opcode to verify= =20 a WebAuthn message without enabling recursive covenants. Regardless, the=20 ability to verify a P256 signature would be an important primitive. In summary, *given the widespread hardware adoption and industry usage, is= =20 it worth revisiting adding P256 support to Bitcoin?* Josh Doman --=20 You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com. To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6e= cc1been%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/= 6221341a-fea7-42ff-aabf-0ce3a783986en%40googlegroups.com. ------=_Part_2663_1323640421.1754686130835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Bitc= oin adopts the same standard as mobile devices, Bitcoin will also gain nati= ve mobile support.

You're correct that the present Web= Authn signing flow does not support BIP32 or exporting a seed from the secu= re enclave. With taproot, users could create multiple addresses using deter= ministic unspendable alternative script paths, but the addresses would be e= asily 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=E2=80=AFPM UTC-4 conduition wrote:
Hey Josh, thanks for raisin= g the idea.

While it's a neat premise, I think the timelines involved will not m= esh well. It'd take several years to get community consensus (the fact it h= asn't been discussed suggests not many people are interested), to build a h= igh-quality implementation on-par with libsecp256k1, and to spec out and im= plement a soft fork.

By itself that'd be OK, but not when you consider other "ne= w sig algo" projects happening in parallel: BIP360 and other post-quantum d= ebates which will eventually lead to the addition of at least one new signa= ture 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 earl= ier than expected.

I'm not familiar with the WebAuthn standard, but surely its a= uthors 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.= 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 standar= ds compatible with WebAuthn).

The next part is just for my own curiosity.=C2=A0<= /div>

=
I'm n= ot sure relying on webauthn is a good idea in the first place. It's a stand= ard suited for web-based authentication to centralized services, not for lo= ng-term cryptographic identities or ownership across distributed systems. I= 've never heard of any WebAuthn authenticator which gives users a determini= stic backup seed of any kind, so how would users recover their bitcoins ind= ependently in this context? Could a hypothetical webauthn wallet handle som= ething like BIP32 without upstream support in WebAuthn?

And how would multi-addr= ess 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 gnush= a.org 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 and 2013.

Since then, P256 has gained widespread adoption across the modern i= nternet and on mobile. Most notably, millions of users now possess mobile d= evices capable of generating and storing private keys in secure enclaves (s= ee 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 secp= 256k1 curve that Bitcoin currently uses.

Reading through old dis= cussions, it appears that the primary concern the community had with P256 i= s 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 opt= ion of using P256, if they wish. Native HSM support would significantly imp= rove the onboarding experience for new users, increase the security and acc= essibility of hot wallets, and potentially reduce the cost of collaborative= multisigs. Meanwhile, the community can continue to use secp256k1 as the i= deal curve for private keys secured in cold storage.

At a techni= cal level, Tapscript makes P256 mechanically straightforward to adopt, beca= use it has built-in support for new types of public keys. For example, we c= ould define a 33-byte public key as one requiring a P256 ECDSA signature, w= hile continuing to use 32-bytes for keys requiring Schnorr signatures over = secp256k1.

A secondary concern that I came across is that P256 c= an be 2-3x slower to validate than secp256k1. Assuming this cannot be impro= ved, we can account for slower validation by doubling or tripling the valid= ation 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.
=
P256 support would grant apps the ability to use platform APIs to acc= ess the secure HSM on user's mobile devices, but alone, P256 is insufficien= t for non-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn = signature, we'd additionally need CSFS and CAT, so we can compute a WebAuth= n message from a sighash and the necessary WebAuthn data on the stack. Alte= rnatively, we could create a dedicated WebAuthn opcode to verify a WebAuthn= message without enabling recursive covenants. Regardless, the ability to v= erify a P256 signature would be an important primitive.

In summa= ry, given the widespread hardware adoption and industry usage, is it wor= th 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 e= mail to bitcoindev+...@go= oglegroups.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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6221341a-fea7-42ff-aabf-0ce3a783986en%40googlegroups.com.
------=_Part_2663_1323640421.1754686130835-- ------=_Part_2662_727612150.1754686130835--