1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Delivery-date: Tue, 22 Jul 2025 15:03:51 -0700
Received: from mail-oo1-f55.google.com ([209.85.161.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+bncBDDJX3VKZACRBPMVQDCAMGQES3U54DY@googlegroups.com>)
id 1ueL5S-0004xp-Vu
for bitcoindev@gnusha.org; Tue, 22 Jul 2025 15:03:51 -0700
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-61594e7b862sf6398597eaf.0
for <bitcoindev@gnusha.org>; Tue, 22 Jul 2025 15:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1753221825; x=1753826625; 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:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=od3vbguTPJMaqa0q9Y3aSqsY8whARMkCZSeKIbJr78U=;
b=TIjzMnyUKrqNUn7V4EE0t8no1GKWRGJpO4QID1JWrW6UXFo1NNMwFXqUNUbxfcR06U
oS+9l0hdkbJhOgyA3g9t34s8xKXFh75TwQZCrmFPO3I8Pp3I4Lblo6zyGtNQEX9LFhBi
2Y0tn7EnkLgbI8iA24Q2FKZwrLjrKj+0puFuZcfCh+OqGjwm8ACWC5Z6lhupcQiiiiKw
VnG96wnY1pf9iHtpgJ0Yp7oQZBZupk+7DXbJkKx2orN46jbaXTjrU/uIRyFHPRnVToRh
eQ693LxEoYL+qoBZ9hXtVdvU7oXmy+sT1//acRxRY5dc5qU6SkXjQjkU//YcnoYlX9h/
+kKA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1753221825; x=1753826625; 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:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=od3vbguTPJMaqa0q9Y3aSqsY8whARMkCZSeKIbJr78U=;
b=cjpDMLzTo67o/kM0n/F9ftBMicY/8q3aDLDWbYqUkIq4z4mpOETjPd06fn6/IJ2iHW
R5oU+cxZi/XuJdEQlOCUGQ6KHFu+S+Z2Chyd2qp8oMF66+MXjkgn11yHtd9fNoAq3cYN
Qeop6gwcxu3kSv5ITbs4zSAhkQB50v4kfpBxxW5bfRypeXLwESvRt3ESbXVd+UNPMfQ/
GvQxU2FyQoyRi1rJ6k1dpSVM+CVjIG0wj+pxUl2/M8yEmLiXXk/D5q3d1KLaSJRpZmWp
k+WFDJiF9CTgemqSvGUAQoBd92XfnOCb3AI3JZt9BNpSR4dLLkLYEBtMaaePl0o6ozxJ
G9pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1753221825; x=1753826625;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=od3vbguTPJMaqa0q9Y3aSqsY8whARMkCZSeKIbJr78U=;
b=aCPx17QFaitP2YVTX4d2YL9mcXqgmFAyZ7tB5BXNMIqHCAjh8cgSZJAUzMk5R5OzKm
uzUnR3QAew3LOWwqy6kxIC0ObkN4PfttkDi9IYZdrx+dp/meKZf0SmQ0XFvOknHbUC0u
uORpDjFRjvyvevDcnoCSDdBgnKC6Tt6238yj/M1i55SSrUSC+34WJGUAyNOrJ+cQxsmz
n+Ksx08ZMxt7AgYzyZSWNBYrF9vjIIWmFr5QphVPNQBWQ8by/63TphxIPc2NI1VpLe4s
Vr1/qKCb7k5yDmQYyfP+8o1/E2xK+XMqOZmDVDw5YnHX7r0+TzPU0G3SV4u/EccFLn+f
YUxA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXDgCFs94NOy+1iidvL+nTNeDIkGUKyOy6fzc/pbKS+tWwqGRuNVMdbs10cYiVDKnXkY/fVVFl341pF@gnusha.org
X-Gm-Message-State: AOJu0Yy/Vf40djfFYSTY6ZfxKn4Dn0IrUqo05XNg47+68Tejd34Ag+Ob
QZl19eb1fhAKQHI5hn/mI6NTtUJAFHzxp51ui4lut5Zc+owCXu11uiMu
X-Google-Smtp-Source: AGHT+IE/VmYIY5Q/ePn03vwyKVaNi3C5XzYBVO39Z+mndyn2zLTF3/Jqpm1GZFYPIGRMyrCvt0K+6A==
X-Received: by 2002:a05:6808:17a9:b0:40b:4230:387b with SMTP id 5614622812f47-426c42f756cmr689554b6e.6.1753221824496;
Tue, 22 Jul 2025 15:03:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeruRQuspTZr4WFTkX0WTdVze3NSyDbNrWjvTsJeSRYhw==
Received: by 2002:a05:6820:530c:b0:611:af23:1d9e with SMTP id
006d021491bc7-615ac57d8bfls1735548eaf.0.-pod-prod-01-us; Tue, 22 Jul 2025
15:03:41 -0700 (PDT)
X-Received: by 2002:a05:6808:1985:b0:421:4d86:67b with SMTP id 5614622812f47-426c6434dffmr857838b6e.26.1753221821168;
Tue, 22 Jul 2025 15:03:41 -0700 (PDT)
Received: by 2002:a81:dc0a:0:b0:711:63b1:720 with SMTP id 00721157ae682-719b29f903ams7b3;
Tue, 22 Jul 2025 14:44:03 -0700 (PDT)
X-Received: by 2002:a05:690c:3683:b0:719:5d76:74b with SMTP id 00721157ae682-719b42d1908mr9666717b3.33.1753220642563;
Tue, 22 Jul 2025 14:44:02 -0700 (PDT)
Date: Tue, 22 Jul 2025 14:44:02 -0700 (PDT)
From: Josh Doman <joshsdoman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
Subject: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile HSM support)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_1096_1724980226.1753220642283"
X-Original-Sender: joshsdoman@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_1096_1724980226.1753220642283
Content-Type: multipart/alternative;
boundary="----=_Part_1097_1344044231.1753220642283"
------=_Part_1097_1344044231.1753220642283
Content-Type: text/plain; charset="UTF-8"
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.
------=_Part_1097_1344044231.1753220642283
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
A brief search on <a href=3D"https://gnusha.org/pi/bitcoindev/?q=3Dsecp256r=
1">gnusha.org</a> suggests that it's been over 10 years since the Bitcoin c=
ommunity last discussed adding secp256r1 support (also known as P256). The =
most in-depth discussions I found were on BitcoinTalk in <a href=3D"https:/=
/bitcointalk.org/?topic=3D2699.0">2011</a> and <a href=3D"https://bitcointa=
lk.org/index.php?topic=3D151120.0">2013</a>.<br /><br />Since then, P256 ha=
s gained widespread adoption across the modern internet and on mobile. Most=
notably, millions of users now possess mobile devices capable of generatin=
g and storing private keys in secure enclaves (see Apple iCloud Keychain an=
d Android Keystore). Millions of users might be able to immediately use thi=
s to start self-custodying bitcoin, except this hardware only supports P256=
signatures, which is incompatible with the secp256k1 curve that Bitcoin cu=
rrently uses.<br /><br />Reading through old discussions, it appears that t=
he 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 experie=
nce 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.<br /><br />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 publi=
c key as one requiring a P256 ECDSA signature, while continuing to use 32-b=
ytes for keys requiring Schnorr signatures over secp256k1.<br /><br />A sec=
ondary concern that I came across is that P256 can be 2-3x slower to valida=
te than secp256k1. Assuming this cannot be improved, we can account for slo=
wer validation by doubling or tripling the validation weight cost for a P25=
6 signature. Users can then pre-commit in their script to this additional w=
eight or commit to it in the annex, as intended by <a href=3D"https://githu=
b.com/bitcoin/bips/blob/master/bip-0341.mediawiki">BIP341</a>.<br /><br />P=
256 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 n=
on-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn signatu=
re, we'd additionally need CSFS and CAT, so we can compute a WebAuthn messa=
ge from a sighash and the necessary WebAuthn data on the stack. Alternative=
ly, we could create a dedicated WebAuthn opcode to verify a WebAuthn messag=
e without enabling recursive covenants. Regardless, the ability to verify a=
P256 signature would be an important primitive.<br /><br />In summary, <b>=
given the widespread hardware adoption and industry usage, is it worth revi=
siting adding P256 support to Bitcoin?</b><br /><div><b><br /></b></div><di=
v>Josh Doman</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" 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/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com</a>.<br />
------=_Part_1097_1344044231.1753220642283--
------=_Part_1096_1724980226.1753220642283--
|
