path: root/4c/2f14fd792627bdf08c7b120aa3e5a36747e259

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 <bitcoindev+bncBDQ6BG4PT4CRBAORSPCQMGQE4EMSWGA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <javierpmateos@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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>
 <GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk=@proton.me>
 <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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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
> <https://www.ietf.org/archive/id/draft-vitap-ml-dsa-webauthn-00.html>.=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 <joshs...@gmail.com>=
=20
> wrote:
>
> A brief search on gnusha.org=20
> <https://gnusha.org/pi/bitcoindev/?q=3Dsecp256r1> 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 <https://bitcointalk.org/?topic=3D2699.0> and 2013=20
> <https://bitcointalk.org/index.php?topic=3D151120.0>.
>
> 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
> <https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki>.
>
> 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.<div><br /></div><div=
>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.</di=
v><div><br /></div><div>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.</div><div><br /></div><div>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.<br />=
<br />Best regards,<br />Javier Mateos<br /><br /></div><div class=3D"gmail=
_quote"><div dir=3D"auto" class=3D"gmail_attr">El viernes, 8 de agosto de 2=
025 a las 23:06:29 UTC-3, Josh Doman escribi=C3=B3:<br/></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid r=
gb(204, 204, 204); padding-left: 1ex;">Hi conduition, thanks for the though=
tful reply. I think you&#39;re right. Given the apparent lack of interest, =
it&#39;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><br><=
/div><div>You&#39;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.<br><div><br></div><div>Josh</div></div><div><div><=
br><br><div><div dir=3D"auto">On Wednesday, July 23, 2025 at 5:44:19=E2=80=
=AFPM UTC-4 conduition wrote:<br></div><blockquote style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px">Hey Josh, thanks for raising the idea.</div><div style=3D=
"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-=
family:Arial,sans-serif;font-size:14px">While it&#39;s a neat premise, I th=
ink the timelines involved will not mesh well. It&#39;d take several years =
to get community consensus (the fact it hasn&#39;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.</div><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">By itself that&#39;d be OK=
, but not when you consider other &quot;new sig algo&quot; 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.</div><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">I&#39;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&#39;s post-quantum signatu=
re formats. <a href=3D"https://www.ietf.org/archive/id/draft-vitap-ml-dsa-w=
ebauthn-00.html" title=3D"Possible relevant reading" rel=3D"nofollow" targe=
t=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Des&amp=
;q=3Dhttps://www.ietf.org/archive/id/draft-vitap-ml-dsa-webauthn-00.html&am=
p;source=3Dgmail&amp;ust=3D1755687422918000&amp;usg=3DAOvVaw20bSXz90F9IOtcz=
vGl9rYD">Possible relevant reading</a>. I&#39;d suggest you research a way =
to make WebAuthn&#39;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)=
.</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div=
><div style=3D"font-family:Arial,sans-serif;font-size:14px">The next part i=
s just for my own curiosity.=C2=A0</div><div style=3D"font-family:Arial,san=
s-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px">I&#39;m not sure relying on webauthn is a good idea in th=
e first place. It&#39;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&#39;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?</div><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">A=
nd how would multi-address wallets work? I&#39;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&#39;t that clutter the user&#39;s keychai=
n?</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></di=
v><div style=3D"font-family:Arial,sans-serif;font-size:14px">regards,</div>=
<div style=3D"font-family:Arial,sans-serif;font-size:14px">conduition</div>=
<div></div><div>
        On Tuesday, July 22nd, 2025 at 3:03 PM, Josh Doman &lt;<a rel=3D"no=
follow">joshs...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            A brief search on <a href=3D"https://gnusha.org/pi/bitcoindev/?=
q=3Dsecp256r1" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-=
saferedirecturl=3D"https://www.google.com/url?hl=3Des&amp;q=3Dhttps://gnush=
a.org/pi/bitcoindev/?q%3Dsecp256r1&amp;source=3Dgmail&amp;ust=3D17556874229=
18000&amp;usg=3DAOvVaw3QsaoMlOK45b1_cQlEbuUN">gnusha.org</a> suggests that =
it&#39;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 <a href=3D"https://bitcointalk.org/?topic=3D26=
99.0" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Des&amp;q=3Dhttps://bitcointalk.or=
g/?topic%3D2699.0&amp;source=3Dgmail&amp;ust=3D1755687422918000&amp;usg=3DA=
OvVaw2OJtZPPTuU7yNjZ6JXEb7B">2011</a> and <a href=3D"https://bitcointalk.or=
g/index.php?topic=3D151120.0" rel=3D"noreferrer nofollow noopener" target=
=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Des&amp;=
q=3Dhttps://bitcointalk.org/index.php?topic%3D151120.0&amp;source=3Dgmail&a=
mp;ust=3D1755687422918000&amp;usg=3DAOvVaw0OoQAXWUADpcvsDQB99PVb">2013</a>.=
<br><br>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.<br><br>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.<br><br>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.<br><br>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 <a href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel=3D"=
noreferrer nofollow noopener" target=3D"_blank" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Des&amp;q=3Dhttps://github.com/bitcoin/bips/blo=
b/master/bip-0341.mediawiki&amp;source=3Dgmail&amp;ust=3D1755687422918000&a=
mp;usg=3DAOvVaw2F3lzPtQI-oi10ZjUUsNJd">BIP341</a>.<br><br>P256 support woul=
d grant apps the ability to use platform APIs to access the secure HSM on u=
ser&#39;s mobile devices, but alone, P256 is insufficient for non-custodial=
 WebAuthn / passkey-based wallets. To verify a WebAuthn signature, we&#39;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.<br><br>In summary, <b>given the wi=
despread hardware adoption and industry usage, is it worth revisiting addin=
g P256 support to Bitcoin?</b><br><div><b><br></b></div><div>Josh Doman</di=
v>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <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 rel=3D"noreferrer nofollow noopener">bitcoindev+...@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" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Des&amp;q=3Dhttps://groups.google.com/d/msgid/=
bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%2540googlegroups.com&amp;s=
ource=3Dgmail&amp;ust=3D1755687422918000&amp;usg=3DAOvVaw1XDbIeTLcsga-gcqci=
S3ab">https://groups.google.com/d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-=
993f6ecc1been%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></div></div></div></blockquote></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/57f6748d-4c36-4b83-8ae6-cdabc830ad29n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/57f6748d-4c36-4b83-8ae6-cdabc830ad29n%40googlegroups.com</a>.<br />

------=_Part_613829_1495533508.1755602151579--

------=_Part_613828_955557089.1755602151579--