From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 Aug 2025 14:11:40 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uoTcJ-0004SU-1s for bitcoindev@gnusha.org; Tue, 19 Aug 2025 14:11:40 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-30ccec20b9bsf12461552fac.2 for ; Tue, 19 Aug 2025 14:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1755637893; x=1756242693; 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=MEu4cv0lgygnl87Gx8RtX0pCii+UhS70wPmCv6w+WTA=; b=EdbMXP6PgkG62JM+6Tk1En5rHPsT066jIqcqXrDhU83alXt+0Gbqg0aQXQxgyF5Ewy cqJsmsJ2uUSsno7mT3r3e6E18VV/LSM3EbxVxvr49yoqC9ipRFmhJ0t348LZywkn36JB Lb+a7FJ1EkDmWSB9KMP9EBMKAtq5wVpcqWGUcb3UYIckEJr/APxdjZCVVQG8AxPQkKOY tng6HtSURnMirT9y0VhZbbDGByIWfQTwMpdXv7AjNNUVBgE5sAuAdUinmSeujTrjhHqs RZTXWfP6Kz2GTrsO2Qa75uqsLbn/CA8/cqNo3FWCdDIPa2Uwz7p/lRxAwe3ZDP0g9g4J or4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755637893; x=1756242693; 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=MEu4cv0lgygnl87Gx8RtX0pCii+UhS70wPmCv6w+WTA=; b=TeerQdDHar5N7LEb2HKGeG09/tdiufjB2KsdjYBih9QkiDU5In1WwfRWlzORGRA60u NSXUkX0+GTEOm6xPu/tUCw3pBslqWPu95EjoHYbnhwyin4ASupNbMn4xSZnpyxlnVwlW HyxFkdnZ+im6LbtkAlNmn4J4a8dBpfv0DeJNB0XjwLaf7MLYU1EkRWjpUG1w1WhM9Cup uFjRTgZ/+3HarMx3H9lLAAgR/YpYwFMm14EiD0ZFPAqAwvayell1wIjhNZINS3Qxn9xo ufFT5bissqQ8C+/mrAH6uW62A8wwHKLoZ9MRwvbvruDpDKrrlloCQlRO5b5bbhWJbmh9 B7fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755637893; x=1756242693; 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=MEu4cv0lgygnl87Gx8RtX0pCii+UhS70wPmCv6w+WTA=; b=MpB/lqZNvsvy3YyWJIj3DTGqFAv4utd4KDOd9DreosklkhotllQXhEOkh9LqqHc7G6 hbGdJ4JNaoK7ZwvrgBH4ryxRSQxvdsT4QYx5pN+iuN/irM1eNuqlP9W/kytUeI8Wt+LR vVkNkjjxDE+nNT0P3LAhvpYEIG8Gwga51V1VIMzXEyzKWGFWTxDh29yIoguwJr1qz6HU 4HugHuc2gKMqs9j+v2/koRdd9WqoGXm9WvqEAZlEObpYu3uFqtyO5QChfXBDHD8M96Nu 8YwcoPSUU1TBgAb0uOb3JkvAEHrZnjNuksl8G80Wdxwq9HOyQTq4hjDyLoIxMZJRwEuU eZvA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV+W+lzA3fiGp34Dtkt+b1KOZ9hptlBosYml9AwbCy0Dqcpzn9FOI/h7uYzJirUuqqxY10uJ5CCVMH4@gnusha.org X-Gm-Message-State: AOJu0YyYsSbEOGi3r6ifZaYExwVaV4atoC8BnuBUDZrRnvp6dxyDyjne vx7q/6yYeEiI7fhwF/lyJESyeDnY9eVj69TiH6v6a/4VL+vSS6nMMesw X-Google-Smtp-Source: AGHT+IEXJhR+bm3tjXAzTb0XdoIU8sF6HGuiByY2hl/PRJ2b+uy1f4JLx8ZmopHWmu0llpO38uYEkw== X-Received: by 2002:a05:6870:ac0d:b0:30b:6fa2:695a with SMTP id 586e51a60fabf-31122830c66mr308473fac.11.1755637892772; Tue, 19 Aug 2025 14:11:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc8/M0yrdzm3NFxZgdisp1uT4DV5cNer0iP5Ei3dZqelQ== Received: by 2002:a05:6871:8403:b0:310:fb62:9051 with SMTP id 586e51a60fabf-310fb629560ls608920fac.0.-pod-prod-02-us; Tue, 19 Aug 2025 14:11:29 -0700 (PDT) X-Received: by 2002:a05:6808:508e:b0:434:f1b:1a83 with SMTP id 5614622812f47-437720c8f36mr268069b6e.31.1755637889525; Tue, 19 Aug 2025 14:11:29 -0700 (PDT) Received: by 2002:a05:690c:5c19:b0:71b:f426:a5b0 with SMTP id 00721157ae682-71e78d2643fms7b3; Tue, 19 Aug 2025 04:15:52 -0700 (PDT) X-Received: by 2002:a05:690c:630f:b0:71f:9c53:bac6 with SMTP id 00721157ae682-71f9d6aadb1mr24702207b3.36.1755602151960; Tue, 19 Aug 2025 04:15:51 -0700 (PDT) Date: Tue, 19 Aug 2025 04:15:51 -0700 (PDT) From: Javier Mateos To: Bitcoin Development Mailing List Message-Id: <57f6748d-4c36-4b83-8ae6-cdabc830ad29n@googlegroups.com> In-Reply-To: <6221341a-fea7-42ff-aabf-0ce3a783986en@googlegroups.com> References: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com> <6221341a-fea7-42ff-aabf-0ce3a783986en@googlegroups.com> Subject: Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_613828_955557089.1755602151579" X-Original-Sender: javierpmateos@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_613828_955557089.1755602151579 Content-Type: multipart/alternative; boundary="----=_Part_613829_1495533508.1755602151579" ------=_Part_613829_1495533508.1755602151579 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone... thanks to Josh for opening this debate. A brief practical point: rather than pushing for consensus changes to=20 support a different cryptographic curve, I believe manufacturers today have= =20 a real opportunity to differentiate themselves by offering better=20 self-custody support on their devices. Let them compete: if Apple decides= =20 to incorporate compatibility whit secp256k1, it will gain a competitive=20 advantage over Samsung (and vice versa), and if bitcoinization expands on a= =20 large scale, that advantage could become very significant. If the market=20 perceives value in these functionalities, companies will be motivated to=20 implement them. Adding to Greg Tonoski=C2=B4s point, Samsung demonstrated that the "mobile = HSM +=20 secp256k1" approach is technically viable (its Blockchain Keystore/SDK=20 exposes APIs capable of producing ECDSA/secp256k1 signatures on selected=20 Galaxy devices). While the solution ended up fragmented by model/region and= =20 dependent on the vendor, there was concrete development. Also, let's remember that Bitcoin is an open and permeable organization:=20 anyone or any entity can add value, whether through software=20 implementations, specification development, or tool creation. When=20 interests and goals align, those contributions get integrated and=20 manufacturers to experiment with practical, real-world solutions before=20 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=C3= =B3: > Hi conduition, thanks for the thoughtful reply. I think you're right.=20 > Given the apparent lack of interest, it's probably better to wait and see= =20 > which quantum-resistant signature scheme becomes standard. At that point,= =20 > if Bitcoin adopts the same standard as mobile devices, Bitcoin will also= =20 > gain 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 alternati= ve=20 > script paths, but the addresses would be easily linked once spent. Neithe= r=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 whi= ch=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 earli= er=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 > .=20 > I'd suggest you research a way to make WebAuthn's signing flow compatible= =20 > with the post-quantum sig verification opcodes being developed for bitcoi= n=20 > (or vice-versa, talk with Ethan Heilman and try to make the Bitcoin=20 > standards 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=20 > wallet 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= =20 > over 10 years since the Bitcoin community last discussed adding secp256r1= =20 > support (also known as P256). The most in-depth discussions I found were = on=20 > BitcoinTalk in 2011 and 2013=20 > . > > Since then, P256 has gained widespread adoption across the modern interne= t=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 thi= s=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 th= e=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 ke= ys=20 > secured in cold storage. > > At a technical level, Tapscript makes P256 mechanically straightforward t= o=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 ECD= SA=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 veri= fy=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,= =20 > is 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-993f= 6ecc1been%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/= 57f6748d-4c36-4b83-8ae6-cdabc830ad29n%40googlegroups.com. ------=_Part_613829_1495533508.1755602151579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone... thanks to Josh for opening this debate.

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

Adding to Greg Tonoski=C2=B4s point, Samsung demons= trated that the "mobile HSM + secp256k1" approach is technically viable (it= s Blockchain Keystore/SDK exposes APIs capable of producing ECDSA/secp256k1= signatures on selected Galaxy devices). While the solution ended up fragme= nted by model/region and dependent on the vendor, there was concrete develo= pment.

Also, let's remember that Bitcoin is an o= pen and permeable organization: anyone or any entity can add value, whether= through software implementations, specification development, or tool creat= ion. When interests and goals align, those contributions get integrated and= manufacturers to experiment with practical, real-world solutions before fo= rcing consensus changes, wich tend to be lengthy, complex, and risky.
=
Best regards,
Javier Mateos

El viernes, 8 de agosto de 2= 025 a las 23:06:29 UTC-3, Josh Doman escribi=C3=B3:
Hi conduition, thanks for the though= tful 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.

<= /div>
You're correct that the present WebAuthn signing flow does no= t support BIP32 or exporting a seed from the secure enclave. With taproot, = users could create multiple addresses using deterministic unspendable alter= native script paths, but the addresses would be easily linked once spent. N= either of those limitations are ideal for Bitcoin, though they may be accep= table for certain users.

Josh
<= br>
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 th= ink 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 happeni= ng 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 mo= ving towards post-quantum opcodes. It may well be obviated if a cryptograph= ically 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 de= cade, your best shot may be to research WebAuthn's post-quantum signatu= re formats. Possible relevant reading. I'd suggest you research a way = to make WebAuthn's signing flow compatible with the post-quantum sig ve= rification opcodes being developed for bitcoin (or vice-versa, talk with Et= han Heilman and try to make the Bitcoin standards compatible with WebAuthn)= .

The next part i= s just for my own curiosity.=C2=A0

I'm not sure relying on webauthn is a good idea in th= e first place. It's a standard suited for web-based authentication to c= entralized services, not for long-term cryptographic identities or ownershi= p across distributed systems. I've never heard of any WebAuthn authenti= cator which gives users a deterministic backup seed of any kind, so how wou= ld users recover their bitcoins independently in this context? Could a hypo= thetical webauthn wallet handle something like BIP32 without upstream suppo= rt in WebAuthn?

A= nd how would multi-address wallets work? I'm imagining the webauthn wal= let would need to generate a new credential every time the user wants to ge= nerate a new P256 address. Wouldn't that clutter the user's keychai= n?

regards,
=
conduition
=
On Tuesday, July 22nd, 2025 at 3:03 PM, Josh Doman <joshs...@gmail.com> wrote:
A brief search on gnusha.org suggests that = it's been over 10 years since the Bitcoin community last discussed addi= ng 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 discuss= ions, it appears that the primary concern the community had with P256 is th= e 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 accessi= bility of hot wallets, and potentially reduce the cost of collaborative mul= tisigs. Meanwhile, the community can continue to use secp256k1 as the ideal= curve for private keys secured in cold storage.

At a technical leve= l, Tapscript makes P256 mechanically straightforward to adopt, because it h= as built-in support for new types of public keys. For example, we could def= ine a 33-byte public key as one requiring a P256 ECDSA signature, while con= tinuing to use 32-bytes for keys requiring Schnorr signatures over secp256k= 1.

A secondary concern that I came across is that P256 can be 2-3x s= lower 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 th= is additional weight or commit to it in the annex, as intended by BIP341.

P256 support woul= d grant apps the ability to use platform APIs to access the secure HSM on u= ser'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 c= ould create a dedicated WebAuthn opcode to verify a WebAuthn message withou= t enabling recursive covenants. Regardless, the ability to verify a P256 si= gnature would be an important primitive.

In summary, given the wi= despread hardware adoption and industry usage, is it worth revisiting addin= g P256 support to Bitcoin?

Josh Doman

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