summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
author'conduition' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com>2025-07-23 15:40:45 +0000
committerbitcoindev <bitcoindev@googlegroups.com>2025-07-23 14:44:26 -0700
commit1d45f43aca47956b9c235fc2a41c0bec4ab08188 (patch)
tree2a183be74594d707e102b55c989046331514eeee
parentc7fab75de0300d2deaf4ef5317e8dfcb76c883a3 (diff)
downloadpi-bitcoindev-master.tar.gz
pi-bitcoindev-master.zip
Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile HSM support)HEADmaster
-rw-r--r--b4/648d11e6487def3a9204054abf8fe08f23543a449
1 files changed, 449 insertions, 0 deletions
diff --git a/b4/648d11e6487def3a9204054abf8fe08f23543a b/b4/648d11e6487def3a9204054abf8fe08f23543a
new file mode 100644
index 000000000..6ee99fdad
--- /dev/null
+++ b/b4/648d11e6487def3a9204054abf8fe08f23543a
@@ -0,0 +1,449 @@
+Delivery-date: Wed, 23 Jul 2025 14:44:26 -0700
+Received: from mail-oa1-f57.google.com ([209.85.160.57])
+ by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+ (Exim 4.94.2)
+ (envelope-from <bitcoindev+bncBCL7RHHJZYJBBMFPQXCAMGQEPTAQOAA@googlegroups.com>)
+ id 1uehGE-0008HH-0V
+ for bitcoindev@gnusha.org; Wed, 23 Jul 2025 14:44:26 -0700
+Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-300884cb43bsf338254fac.2
+ for <bitcoindev@gnusha.org>; Wed, 23 Jul 2025 14:44:25 -0700 (PDT)
+ARC-Seal: i=2; a=rsa-sha256; t=1753307060; cv=pass;
+ d=google.com; s=arc-20240605;
+ b=GtE9WtrzFjOX6W6ZFm5i2SiLw72LugGY1LOuvFZ1cpesI/34jjW5UVlnQ9vsE6th65
+ a9Fn/YL/FxyP1biIEBoYUeYWScTfasU49hzN6brHM8+KUN6Q2SHLdFdpYHfGHKLjCrqV
+ smhzh2U6irI4UlXq5G9d7SExmIPafMphXOQftaKnRzXdlebF3P0XMdLFdhFI++sil7Kk
+ xny1ldo0GgdCOLFOtXcCEUrKUqrjvGherkwivT0+Gd8zkLbBgJXm5TmczQkylEsCvP/I
+ vFKk4Nck/vyRHFlcg9S3LMRhLoKGW99uEW4MxyQ8uF40nUjlWgnUbR7l/TG3vt/a68m0
+ ulDQ==
+ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
+ h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+ :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
+ :references:in-reply-to:message-id:subject:cc:from:to:date
+ :dkim-signature;
+ bh=t7omqqEEm01d4FkRzHC3E1Rs0bVTONELH+4RH8AGVLg=;
+ fh=Ksr9Jo4dYT+gR46iP9b5xrgDQkQLPsA7E+R4Wunp+A8=;
+ b=iBlUEGrczkm85z3jHpuYpfguqwQavkYioHY/+mqxTqcqIoYI7N+BSMORDzXczhBpM2
+ gqGKqX5qOgHKVEfVpWYbC2MzS8dgnRmD4JluUcmL5oZqDj6WMRhU8mvXAq4dn6kTb1d0
+ qNazNZFPpI9MyTg6sxnTUIuekjOYdbmgMa1VgOGW/aadcrpXlCehvyOBoih+iibxX5LD
+ pWGPFbC2QyvESvoKWUvHpSvPeHedUtu/F+7kqCDEdrr9NMb3LzKB/YgEM9HKLHYA0hNq
+ 07ALA10wDcrhcM38u1Z+60AF3RnwlkWOFii7kDNvR7wsMqe4feG9L8UV3BDfhhNDh5yx
+ YoHQ==;
+ darn=gnusha.org
+ARC-Authentication-Results: i=2; gmr-mx.google.com;
+ dkim=pass header.i=@proton.me header.s=protonmail header.b=lfeqPSHk;
+ spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
+ dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=googlegroups.com; s=20230601; t=1753307060; x=1753911860; darn=gnusha.org;
+ h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+ :list-id:mailing-list:precedence:reply-to
+ :x-original-authentication-results:x-original-sender:mime-version
+ :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
+ :date:from:to:cc:subject:date:message-id:reply-to;
+ bh=t7omqqEEm01d4FkRzHC3E1Rs0bVTONELH+4RH8AGVLg=;
+ b=kRgizzupqRgCfTrciviZ+bVxCwyJFVHSCsX+6wMY01NchP6NPFkUdvgLNsvtZq9TKz
+ Okrp1uartexeBdZ5RcbSoWxIi+bSN/SDKQTIzOyT477m+x7xRTu5kxBYbBSs08opfDzR
+ Czwe9lScKlhjM89oQRm3piViisJUWG1xqkhoWCzhjhDanjyxga/QU2YZVDXDJaPpgURd
+ cPZfsCrtwYUZ3fGhNp/Lm5G/V7rA8Ghu8XdwFEa8jFeRzhO+/X9nlBWXDrLoJE1cQEkw
+ KTF4HFrh4JcIBU2JGz+vTsK7skNxLR8aSQHv/S51sfkfDYoUZIrR58HqcXXP+cL5lv/V
+ U7Xw==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20230601; t=1753307060; x=1753911860;
+ h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+ :list-id:mailing-list:precedence:reply-to
+ :x-original-authentication-results:x-original-sender:mime-version
+ :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
+ :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
+ :message-id:reply-to;
+ bh=t7omqqEEm01d4FkRzHC3E1Rs0bVTONELH+4RH8AGVLg=;
+ b=ZVCFPhCNsHz1ogBSrFwirV59gmSLh7ZlCKsyu0/YbgWZHAvb44p9oACUEZ2csF3lej
+ xENQJukTf0gBww57cnlEeEMeEa6c5fmdsycnmzph3Cax3mAEtSA6fliaMp7pNHmKHqW5
+ qTQmxf8PjV5MJ/dvrTw9X/z0GrT1SiZHaqYw8e6SLP77KRtosZOL2kDCTxIJGfqB11ED
+ MJezr/0XKZozvsEAmaGfmg9RjIs0TPBfIP1tS3eMFWRPMwHxaG5ZBYFguYk2L/fvW2nt
+ ydMvYeUf6Ojr5qgKrbPc3u/t8pqe6OMjrReovTZw4rRZrSXk+qWCNzpR41RVErGzRUNC
+ elnA==
+X-Forwarded-Encrypted: i=2; AJvYcCXq+5e7sEmq/9BfJydIywf0i4mD9ZZAv12WBg/+zVz9LZEAUiAJ/YlxFQNlVXfaO0khL7VV+ANfAwFZ@gnusha.org
+X-Gm-Message-State: AOJu0YxmmncmBQOr8yOB6GqoHa6PCUMW0yt5AE27WLg9JVXNRluxbF2Z
+ Tv0X5XQhwF67Gpi0/Frji015rdC+6XklZuenSgyoNrsYuzLyuclxRb1s
+X-Google-Smtp-Source: AGHT+IEz0UZuzJpRx0OHWRobyYQST+nKNhQqwB5PFKtxUSnPhA/1RQ/W0ARSpyTjeqbHiHNnAhSkkw==
+X-Received: by 2002:a05:6870:b61f:b0:2e9:fd62:9061 with SMTP id 586e51a60fabf-306c72eed1emr3629291fac.32.1753307059536;
+ Wed, 23 Jul 2025 14:44:19 -0700 (PDT)
+X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc0E/WEm0+7OKK5ThxoORlGTFqjjJBo+749ntb0AoxweA==
+Received: by 2002:a05:6870:f707:b0:306:c9db:27c1 with SMTP id
+ 586e51a60fabf-306ddc1cdbels136102fac.2.-pod-prod-09-us; Wed, 23 Jul 2025
+ 14:44:16 -0700 (PDT)
+X-Received: by 2002:a05:6808:159f:b0:40c:7996:73e3 with SMTP id 5614622812f47-426c643b0d3mr3676510b6e.28.1753307056655;
+ Wed, 23 Jul 2025 14:44:16 -0700 (PDT)
+Received: by 2002:a05:600c:c116:b0:456:ce4:c44e with SMTP id 5b1f17b1804b1-458677e9109ms5e9;
+ Wed, 23 Jul 2025 08:40:55 -0700 (PDT)
+X-Received: by 2002:a05:600d:4:b0:439:9b2a:1b2f with SMTP id 5b1f17b1804b1-4586974aeccmr27979505e9.3.1753285253373;
+ Wed, 23 Jul 2025 08:40:53 -0700 (PDT)
+ARC-Seal: i=1; a=rsa-sha256; t=1753285253; cv=none;
+ d=google.com; s=arc-20240605;
+ b=Zxj65L4t1Q0etCjDWP1UbOiYILU9vZj9HxyV4Y/NM05vpOwVY1zmxPSGeo0coqmAM5
+ TdwxwaOAwDTT1nSm+pl4otK4rMuELbuFkgppPdbwX6b288sC719RgL5PRoKX+O/pu8AW
+ FvjPgdui+LHBPySHf+hYXNHmafVJ0koqP0W/qLjMDfx7gddXA18Nn3ZEVlovQS22p40X
+ ebPeX+5mxTxtJtoNXNYVU0Zl48VHMt70G+h4OWom/7hfMRF6TCVvC/MvWN7TB3DlKaAW
+ qd0AGbuudviALqOvmfzq8a20poJ606FGI0bqWkZvoVO2XyMA5reGbKsfIZiGt9rCiLjb
+ w8QA==
+ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
+ h=mime-version:feedback-id:references:in-reply-to:message-id:subject
+ :cc:from:to:date:dkim-signature;
+ bh=tYGzkLlQHvBFFzxZkoc3HanRd+q/UQC7T97adweO+HE=;
+ fh=zw14EGzQje/EQlEB4Z3hSEaC3Thm583Hfs9yKrsDsSY=;
+ b=IwHCqvbV/gC+tSpevqFtzX1C4+TMIWkrc4/9Wc5qbHgmU/IFHoEkBoqiLBabA3hQFJ
+ cYlQrOi/0epnrSfYErkbmS5EEKYb5j4TTga3O9ALrJu/h3YlK9wdQUv4yLm6l6KKnNvD
+ Pdhcg3VVHS8wpdeOwcVCidRZqfOePDsVsoorZOmSJcpFsOGaYTop1H0bZWJWnztvQaZR
+ a0XJUSVE3xylCYN2sk02zz/fpXNBn3bK20c8IRSSGOIEwU58R6M+iZk4/Xxrb7YHulm/
+ EjioPlh/mQ5sC6fcsIP4cpbyU1R/J+J/VSWVQXOgEFnyev08gCo6WWvSzOD0SHSoPGBA
+ K8WQ==;
+ dara=google.com
+ARC-Authentication-Results: i=1; gmr-mx.google.com;
+ dkim=pass header.i=@proton.me header.s=protonmail header.b=lfeqPSHk;
+ spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
+ dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
+Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
+ by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45862cd79e0si550865e9.0.2025.07.23.08.40.53
+ for <bitcoindev@googlegroups.com>
+ (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
+ Wed, 23 Jul 2025 08:40:53 -0700 (PDT)
+Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
+Date: Wed, 23 Jul 2025 15:40:45 +0000
+To: Josh Doman <joshsdoman@gmail.com>
+From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
+Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
+Subject: Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile
+ HSM support)
+Message-ID: <GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk=@proton.me>
+In-Reply-To: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
+References: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
+Feedback-ID: 72003692:user:proton
+X-Pm-Message-ID: 7d90f27ec8409fe659cf26101e13c5a96a9b67f7
+MIME-Version: 1.0
+Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4"; charset=utf-8
+X-Original-Sender: conduition@proton.me
+X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
+ header.i=@proton.me header.s=protonmail header.b=lfeqPSHk; spf=pass
+ (google.com: domain of conduition@proton.me designates 185.70.43.22 as
+ permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass
+ (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
+X-Original-From: conduition <conduition@proton.me>
+Reply-To: conduition <conduition@proton.me>
+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.1 (++)
+
+This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
+--------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4
+Content-Type: multipart/mixed;boundary=---------------------68f72579bfe03ee21aa74ea90fdff0da
+
+-----------------------68f72579bfe03ee21aa74ea90fdff0da
+Content-Type: multipart/alternative;boundary=---------------------27fdabd9e2d81625eb76b91397d94845
+
+-----------------------27fdabd9e2d81625eb76b91397d94845
+Content-Transfer-Encoding: quoted-printable
+Content-Type: text/plain; charset="UTF-8"
+
+Hey Josh, thanks for raising the idea.
+
+While it's a neat premise, I think the timelines involved will not mesh wel=
+l. It'd take several years to get community consensus (the fact it hasn't b=
+een discussed suggests not many people are interested), to build a high-qua=
+lity 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" proj=
+ects happening in parallel: BIP360 and other post-quantum debates which wil=
+l eventually lead to the addition of at least one new signature algorithm t=
+o 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 expecte=
+d.
+
+I'm not familiar with the WebAuthn standard, but surely its authors are the=
+mselves 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 po=
+st-quantum signature formats. Possible relevant reading. I'd suggest you re=
+search a way to make WebAuthn's signing flow compatible with the post-quant=
+um sig verification opcodes being developed for bitcoin (or vice-versa, tal=
+k with Ethan Heilman and try to make the Bitcoin standards compatible with =
+WebAuthn).
+
+The next part is just for my own curiosity.=C2=A0
+
+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 f=
+or long-term cryptographic identities or ownership across distributed syste=
+ms. I've never heard of any WebAuthn authenticator which gives users a dete=
+rministic backup seed of any kind, so how would users recover their bitcoin=
+s independently in this context? Could a hypothetical webauthn wallet handl=
+e 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 gener=
+ate 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 <joshsdoman@gmail.com> w=
+rote:
+
+> A brief search on gnusha.org suggests that it's been over 10 years since =
+the Bitcoin community last discussed adding secp256r1 support (also known a=
+s P256). The most in-depth discussions I found were on BitcoinTalk in 2011 =
+and 2013.
+>=20
+
+> Since then, P256 has gained widespread adoption across the modern interne=
+t and on mobile. Most notably, millions of users now possess mobile devices=
+ capable of generating and storing private keys in secure enclaves (see App=
+le iCloud Keychain and Android Keystore). Millions of users might be able t=
+o immediately use this to start self-custodying bitcoin, except this hardwa=
+re only supports P256 signatures, which is incompatible with the secp256k1 =
+curve that Bitcoin currently uses.
+>=20
+
+> 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 sho=
+uld at least have the option of using P256, if they wish. Native HSM suppor=
+t would significantly improve the onboarding experience for new users, incr=
+ease 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 storag=
+e.
+>=20
+
+> At a technical level, Tapscript makes P256 mechanically straightforward t=
+o 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 sig=
+natures over secp256k1.
+>=20
+
+> 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 fo=
+r a P256 signature. Users can then pre-commit in their script to this addit=
+ional 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 =
+the secure HSM on user's mobile devices, but alone, P256 is insufficient fo=
+r non-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn sign=
+ature, we'd additionally need CSFS and CAT, so we can compute a WebAuthn me=
+ssage from a sighash and the necessary WebAuthn data on the stack. Alternat=
+ively, we could create a dedicated WebAuthn opcode to verify a WebAuthn mes=
+sage without enabling recursive covenants. Regardless, the ability to verif=
+y a P256 signature would be an important primitive.
+>=20
+
+> In summary, given the widespread hardware adoption and industry usage, is=
+ it worth revisiting adding P256 support to Bitcoin?
+>=20
+
+>=20
+
+> Josh Doman
+>=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=
+ email to bitcoindev+unsubscribe@googlegroups.com.
+> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
+v/8fbe1fe3-425d-4056-8387-993f6ecc1been%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/=
+GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrV=
+l24qmyqVgBvrZ8FT0POeomam2qB6-cqk%3D%40proton.me.
+
+-----------------------27fdabd9e2d81625eb76b91397d94845
+Content-Type: multipart/related;boundary=---------------------bac8cedddd21798afd47914c6dd713aa
+
+-----------------------bac8cedddd21798afd47914c6dd713aa
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hey Josh, t=
+hanks for raising the idea.</div><div style=3D"font-family: Arial, sans-ser=
+if; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-seri=
+f; font-size: 14px;">While it's a neat premise, I think the timelines invol=
+ved 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 s=
+pec out and implement a soft fork.</div><div style=3D"font-family: Arial, s=
+ans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sa=
+ns-serif; font-size: 14px;">By itself that'd be OK, but not when you consid=
+er other "new sig algo" projects happening in parallel: BIP360 and other po=
+st-quantum debates which will eventually lead to the addition of at least o=
+ne new signature algorithm to consensus. By the time P256 is standardized a=
+nd available, everyone will likely be moving towards post-quantum opcodes. =
+It may well be obviated if a cryptographically relevant quantum computer co=
+mes 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-s=
+erif; font-size: 14px;">I'm not familiar with the WebAuthn standard, but su=
+rely 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 t=
+o research WebAuthn's post-quantum signature formats. <a href=3D"https://ww=
+w.ietf.org/archive/id/draft-vitap-ml-dsa-webauthn-00.html" title=3D"Possibl=
+e relevant reading">Possible relevant reading</a>. 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 WebAut=
+hn).</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;">Th=
+e next part is just for my own curiosity.&nbsp;</div><div style=3D"font-fam=
+ily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fami=
+ly: Arial, sans-serif; font-size: 14px;">I'm not sure relying on webauthn i=
+s a good idea in the first place. It's a standard suited for web-based auth=
+entication to centralized services, not for long-term cryptographic identit=
+ies or ownership across distributed systems. I've never heard of any WebAut=
+hn authenticator which gives users a deterministic backup seed of any kind,=
+ so how would users recover their bitcoins independently in this context? C=
+ould a hypothetical webauthn wallet handle something like BIP32 without ups=
+tream support in WebAuthn?</div><div style=3D"font-family: Arial, sans-seri=
+f; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif=
+; font-size: 14px;">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?</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: 14=
+px;">regards,</div><div style=3D"font-family: Arial, sans-serif; font-size:=
+ 14px;">conduition</div><div class=3D"protonmail_quote">
+ On Tuesday, July 22nd, 2025 at 3:03 PM, Josh Doman &lt;joshsdoman@g=
+mail.com&gt; wrote:<br>
+ <blockquote class=3D"protonmail_quote" type=3D"cite">
+ A brief search on <a href=3D"https://gnusha.org/pi/bitcoindev/?=
+q=3Dsecp256r1" target=3D"_blank" rel=3D"noreferrer nofollow noopener">gnush=
+a.org</a> 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 <a href=3D"https://bitcoin=
+talk.org/?topic=3D2699.0" target=3D"_blank" rel=3D"noreferrer nofollow noop=
+ener">2011</a> and <a href=3D"https://bitcointalk.org/index.php?topic=3D151=
+120.0" target=3D"_blank" rel=3D"noreferrer nofollow noopener">2013</a>.<br>=
+<br>Since then, P256 has gained widespread adoption across the modern inter=
+net and on mobile. Most notably, millions of users now possess mobile devic=
+es capable of generating and storing private keys in secure enclaves (see A=
+pple iCloud Keychain and Android Keystore). Millions of users might be able=
+ to immediately use this to start self-custodying bitcoin, except this hard=
+ware only supports P256 signatures, which is incompatible with the secp256k=
+1 curve that Bitcoin currently uses.<br><br>Reading through old discussions=
+, it appears that the primary concern the community had with P256 is the po=
+ssibility of a NIST backdoor. Putting the likelihood of this aside, it seem=
+s reasonable to me that in 2025, users should at least have the option of u=
+sing P256, if they wish. Native HSM support would significantly improve the=
+ onboarding experience for new users, increase the security and accessibili=
+ty of hot wallets, and potentially reduce the cost of collaborative multisi=
+gs. Meanwhile, the community can continue to use secp256k1 as the ideal cur=
+ve for private keys secured in cold storage.<br><br>At a technical level, T=
+apscript makes P256 mechanically straightforward to adopt, because it has b=
+uilt-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 continu=
+ing to use 32-bytes for keys requiring Schnorr signatures over secp256k1.<b=
+r><br>A secondary concern that I came across is that P256 can be 2-3x slowe=
+r to validate than secp256k1. Assuming this cannot be improved, we can acco=
+unt for slower validation by doubling or tripling the validation weight cos=
+t for a P256 signature. Users can then pre-commit in their script to this a=
+dditional weight or commit to it in the annex, as intended by <a href=3D"ht=
+tps://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" target=3D"_bl=
+ank" rel=3D"noreferrer nofollow noopener">BIP341</a>.<br><br>P256 support w=
+ould grant apps the ability to use platform APIs to access the secure HSM o=
+n user's mobile devices, but alone, P256 is insufficient for non-custodial =
+WebAuthn / passkey-based wallets. To verify a WebAuthn signature, we'd addi=
+tionally need CSFS and CAT, so we can compute a WebAuthn message from a sig=
+hash and the necessary WebAuthn data on the stack. Alternatively, we could =
+create a dedicated WebAuthn opcode to verify a WebAuthn message without ena=
+bling recursive covenants. Regardless, the ability to verify a P256 signatu=
+re would be an important primitive.<br><br>In summary, <b>given the widespr=
+ead hardware adoption and industry usage, is it worth revisiting adding P25=
+6 support to Bitcoin?</b><br><div><b><br></b></div><div>Josh Doman</div>
+
+<p></p>
+
+-- <br>
+You received this message because you are subscribed to the Google Groups "=
+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" rel=3D"n=
+oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
+r>
+To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
+bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com" target=
+=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.google.com/=
+d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com=
+</a>.<br>
+
+ </blockquote><br>
+ </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/GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTch=
+lGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk%3D%40proton.me?utm_medium=3Dema=
+il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/GVA2lG=
+8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmy=
+qVgBvrZ8FT0POeomam2qB6-cqk%3D%40proton.me</a>.<br />
+
+-----------------------bac8cedddd21798afd47914c6dd713aa--
+-----------------------27fdabd9e2d81625eb76b91397d94845--
+-----------------------68f72579bfe03ee21aa74ea90fdff0da
+Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"
+Content-Transfer-Encoding: base64
+Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"
+
+LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI
+YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO
+dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3
+Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL
+YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox
+K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo
+CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J
+MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr
+T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR
+TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp
+S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag
+UFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
+-----------------------68f72579bfe03ee21aa74ea90fdff0da--
+
+--------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4
+Content-Type: application/pgp-signature; name="signature.asc"
+Content-Description: OpenPGP digital signature
+Content-Disposition: attachment; filename="signature.asc"
+
+-----BEGIN PGP SIGNATURE-----
+Version: ProtonMail
+
+wrsEARYKAG0FgmiBAm0JkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
+b25zLm9wZW5wZ3Bqcy5vcmeNq7aI/CZB2GpK29m19bz8hDGG/grBMEpOTYu6
+ciytlBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB0BAD+IaPCjkmJVhE+bFX/
+6v0XINusqoMvKy7cdKOdvXF+ho8A/jQFghaQtUPUpIVwwAu//pwqIm/Wv/3H
+OriDiB7XLXEN
+=HpPf
+-----END PGP SIGNATURE-----
+
+
+--------4b58605cc550b4429c061363591f2ccb6776aef92e8ab03a47f764e175d32be4--
+
+