diff options
| -rw-r--r-- | b4/648d11e6487def3a9204054abf8fe08f23543a | 449 |
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. </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 <joshsdoman@g= +mail.com> 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" 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-- + + |