path: root/63/df40d4db29bafd8d9322c4b2db226619655f5d

Delivery-date: Fri, 08 Aug 2025 19:06:37 -0700
Received: from mail-oa1-f62.google.com ([209.85.160.62])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDDJX3VKZACRBIW23LCAMGQECXAVXCY@googlegroups.com>)
	id 1ukYyi-0005ki-AZ
	for bitcoindev@gnusha.org; Fri, 08 Aug 2025 19:06:37 -0700
Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-30c4b40d872sf11675fac.3
        for <bitcoindev@gnusha.org>; Fri, 08 Aug 2025 19:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1754705190; x=1755309990; 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=voYmq5+Zx2FoRlcmva6bQfmbyhn3HOgXj+eI4V0cFaU=;
        b=DQuFOo+2ah0N1fAAeF9jiwxJk9f8cyuRgNOZLCnlOv4YNN1q37YQ/uU7DP+PhMtHC+
         jixxYc90zYIdJS2SrRYwkz2pE/KZQemymSjV8wCYeJSxD58hf1xO/Ra8wI7V7KD8C9c0
         p5DNCihWbxv2RUL1r+KFo269ewS6uvsCvvrD9OD85wef8bGCpbrMX0V5yshxQSHHuF4j
         /tjsuiummZke89mQeTjdeOLq4uamuJTA0l16kZ7R1ykku0XV/3psHrfWb3ijROyE40tw
         R855Yi0vsT9TdubvxbGagwNohHHGnSWeNSP+TV8QwrB46fjPRXtMmj02s6Lfv5r30STE
         NsAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1754705190; x=1755309990; 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=voYmq5+Zx2FoRlcmva6bQfmbyhn3HOgXj+eI4V0cFaU=;
        b=N7aIDJ0DiHS6zSxEskzhkM7/pO29c3QW/Dtw6n9/dN2hZBFErn1LohflZClbLb6Pba
         WF0xUBYdoU68CMLWfwGCyYVy1HgKBPoJRnPHlOMcs8nte4oBb9iktE3/1rzbotQUrskz
         VlJN4CYDqrRuE5unyPn44Y3PqJIRuYH9EteWhZUndmDtf0xjphGTdHXD5N+Srk+cKw1R
         1t0+DWXcuEuXZu6RVmjenf6CbUO6w85LnfhcLm7DsTqXJzC7tLCbsidyBGB5qvgpkGnY
         5jo3QVrcWwm8chMP8y+OdppgkoQ+YogNX8/Gi9aanquO9Bv936sBsZ2S3PxofYworwnk
         +RNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1754705190; x=1755309990;
        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=voYmq5+Zx2FoRlcmva6bQfmbyhn3HOgXj+eI4V0cFaU=;
        b=ZbddNGDBxGi3dKjQUfgIJ3CxjpQs7szR0YRwU7o2Fr5+TpursTBuv6DIEWkcDoV+dv
         Juw0zabKb2Oih9ycY1yu8Usl48cMGAdhfUb1Utjzl68/UV+03IJUVNTo07sCGGqc4zVY
         YtBYhq9VyBgBGfgURGhwcmUOKx+rePGmvL90WBZBn+juGRdLs45awz/urcIO26ZYSExA
         uydZJw+kyO7w2C5j9VCQAn0gSdhGlUCgTLoyGPfhSqDRxGZgD60eI6GYW5HfC5PFm4YN
         jY9ap6pS4yIKsWM13rvgfrIZPX8U72KLk2RI5WHs2J0SrOcDqev6P02Y1jMYR4B0no+K
         G4cg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWxUjFYHzONblyQ879bid3ic9+RUUBsUHiKAkfnSm7qzKKMLwTnC6XOH3aLMkW5L3l51fsQ6CK5JjB3@gnusha.org
X-Gm-Message-State: AOJu0YwrRE8frq4XdEQ05zG/TWgzomNxx694AhXqF8N6O3XGqXcSmePN
	wLZmxnUIHlz6Mo6mu5HXBifVwM/QYEd1OjFoRT00f1dcleUDVFVGO2uk
X-Google-Smtp-Source: AGHT+IFtczdsIYx4sa2+yr+aygNA3LO8uSGzNugugDlay3X1At66QnhGVRrl2YuP8A16afD/5/f1LQ==
X-Received: by 2002:a9d:6448:0:b0:741:dffb:13fa with SMTP id 46e09a7af769-7432c8a0fa4mr3385167a34.21.1754705189653;
        Fri, 08 Aug 2025 19:06:29 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd0o3EEOt0eDx/tb0rKSgsyt0Cpg4ZurqZAiZ6ExmKAIA==
Received: by 2002:a05:6820:3288:b0:611:fdca:b1b1 with SMTP id
 006d021491bc7-61b6e4949ccls685757eaf.0.-pod-prod-04-us; Fri, 08 Aug 2025
 19:06:25 -0700 (PDT)
X-Received: by 2002:a05:6808:30a8:b0:40c:fc48:33b5 with SMTP id 5614622812f47-43597ba6564mr2718091b6e.12.1754705185789;
        Fri, 08 Aug 2025 19:06:25 -0700 (PDT)
Received: by 2002:a05:690c:2605:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71bf1a7df88ms7b3;
        Fri, 8 Aug 2025 13:48:52 -0700 (PDT)
X-Received: by 2002:a05:690c:5504:10b0:71b:f755:bbab with SMTP id 00721157ae682-71bf759a9a1mr27621977b3.14.1754686131269;
        Fri, 08 Aug 2025 13:48:51 -0700 (PDT)
Date: Fri, 8 Aug 2025 13:48:50 -0700 (PDT)
From: Josh Doman <joshsdoman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6221341a-fea7-42ff-aabf-0ce3a783986en@googlegroups.com>
In-Reply-To: <GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk=@proton.me>
References: <8fbe1fe3-425d-4056-8387-993f6ecc1been@googlegroups.com>
 <GVA2lG8TET5qUPOU8JlHttBNLbTskqr_dbhzK9aOe_ZsPsNDyk2kWIPwmx3ngTchlGrsAIpubrVl24qmyqVgBvrZ8FT0POeomam2qB6-cqk=@proton.me>
Subject: Re: [bitcoindev] Revisiting secp256r1 signatures (i.e. P256, mobile
 HSM support)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_2662_727612150.1754686130835"
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_2662_727612150.1754686130835
Content-Type: multipart/alternative; 
	boundary="----=_Part_2663_1323640421.1754686130835"

------=_Part_2663_1323640421.1754686130835
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi conduition, thanks for the thoughtful reply. I think you're right. Given=
=20
the apparent lack of interest, it's probably better to wait and see which=
=20
quantum-resistant signature scheme becomes standard. At that point, if=20
Bitcoin adopts the same standard as mobile devices, Bitcoin will also gain=
=20
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 alternative=
=20
script paths, but the addresses would be easily linked once spent. Neither=
=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 which=
=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 earlier=
=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>. I'd=
=20
suggest you research a way to make WebAuthn's signing flow compatible with=
=20
the post-quantum sig verification opcodes being developed for bitcoin (or=
=20
vice-versa, talk with Ethan Heilman and try to make the Bitcoin standards=
=20
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 wallet=
=20
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 <https://gnusha.org/pi/bitcoindev/?q=3Dsecp256=
r1>=20
suggests that it's been over 10 years since the Bitcoin community last=20
discussed adding secp256r1 support (also known as P256). The most in-depth=
=20
discussions I found were on BitcoinTalk in 2011=20
<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 internet=
=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 this=
=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 the=
=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 keys=
=20
secured in cold storage.

At a technical level, Tapscript makes P256 mechanically straightforward to=
=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 ECDSA=
=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 verify=
=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, is=
=20
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-993f6e=
cc1been%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/=
6221341a-fea7-42ff-aabf-0ce3a783986en%40googlegroups.com.

------=_Part_2663_1323640421.1754686130835
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi conduition, thanks for the thoughtful reply. I think you're right. Given=
 the apparent lack of interest, it's probably better to wait and see which =
quantum-resistant signature scheme becomes standard. At that point, if Bitc=
oin adopts the same standard as mobile devices, Bitcoin will also gain nati=
ve mobile support.<div><br /></div><div>You're correct that the present Web=
Authn signing flow does not support BIP32 or exporting a seed from the secu=
re enclave. With taproot, users could create multiple addresses using deter=
ministic unspendable alternative script paths, but the addresses would be e=
asily linked once spent. Neither of those limitations are ideal for Bitcoin=
, though they may be acceptable for certain users.<br /><div><br /></div><d=
iv>Josh<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"ma=
rgin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; =
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px;">Hey Josh, thanks for raisin=
g the idea.</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;">While it's a neat premise, I think the timelines involved will not m=
esh well. It'd take several years to get community consensus (the fact it h=
asn't been discussed suggests not many people are interested), to build a h=
igh-quality implementation on-par with libsecp256k1, and to spec out and im=
plement a soft fork.</div><div style=3D"font-family: Arial, sans-serif; fon=
t-size: 14px;"><br /></div><div style=3D"font-family: Arial, sans-serif; fo=
nt-size: 14px;">By itself that'd be OK, but not when you consider other "ne=
w sig algo" projects happening in parallel: BIP360 and other post-quantum d=
ebates which will eventually lead to the addition of at least one new signa=
ture algorithm to 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 earl=
ier 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'm not familiar with the WebAuthn standard, but surely its a=
uthors are themselves 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 post-quantum signature formats. <a href=3D"https://www.ietf.org=
/archive/id/draft-vitap-ml-dsa-webauthn-00.html" title=3D"Possible relevant=
 reading" target=3D"_blank" rel=3D"nofollow">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 standar=
ds compatible with WebAuthn).</div><div style=3D"font-family: Arial, sans-s=
erif; font-size: 14px;"><br /></div><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px;">The next part is just for my own curiosity.=C2=A0<=
/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'm n=
ot sure relying on webauthn is a good idea in the first place. It's a stand=
ard suited for web-based authentication to centralized services, not for lo=
ng-term cryptographic identities or ownership across distributed systems. I=
've never heard of any WebAuthn authenticator which gives users a determini=
stic backup seed of any kind, so how would users recover their bitcoins ind=
ependently in this context? Could a hypothetical webauthn wallet handle som=
ething like BIP32 without upstream support in 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;">And how would multi-addr=
ess 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: 14px;"><br /></div><div style=3D"font-family:=
 Arial, sans-serif; font-size: 14px;">regards,</div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;">conduition</div><div></div><div>
        On Tuesday, July 22nd, 2025 at 3:03 PM, Josh Doman &lt;<a href=3D""=
 rel=3D"nofollow">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">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" rel=3D"noreferrer nofollow noopener" target=3D"_b=
lank">2011</a> and <a href=3D"https://bitcointalk.org/index.php?topic=3D151=
120.0" rel=3D"noreferrer nofollow noopener" target=3D"_blank">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 dis=
cussions, it appears that the primary concern the community had with P256 i=
s 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 opt=
ion of using P256, if they wish. Native HSM support would significantly imp=
rove the onboarding experience for new users, increase the security and acc=
essibility of hot wallets, and potentially reduce the cost of collaborative=
 multisigs. Meanwhile, the community can continue to use secp256k1 as the i=
deal curve for private keys secured in cold storage.<br /><br />At a techni=
cal level, Tapscript makes P256 mechanically straightforward to adopt, beca=
use it has built-in support for new types of public keys. For example, we c=
ould define a 33-byte public key as one requiring a P256 ECDSA signature, w=
hile continuing to use 32-bytes for keys requiring Schnorr signatures over =
secp256k1.<br /><br />A secondary concern that I came across is that P256 c=
an be 2-3x slower to validate than secp256k1. Assuming this cannot be impro=
ved, we can account for slower validation by doubling or tripling the valid=
ation 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 <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0341.mediawik=
i" rel=3D"noreferrer nofollow noopener" target=3D"_blank">BIP341</a>.<br />=
<br />P256 support would grant apps the ability to use platform APIs to acc=
ess the secure HSM on user's mobile devices, but alone, P256 is insufficien=
t for non-custodial WebAuthn / passkey-based wallets. To verify a WebAuthn =
signature, we'd additionally need CSFS and CAT, so we can compute a WebAuth=
n message from a sighash and the necessary WebAuthn data on the stack. Alte=
rnatively, we could create a dedicated WebAuthn opcode to verify a WebAuthn=
 message without enabling recursive covenants. Regardless, the ability to v=
erify a P256 signature would be an important primitive.<br /><br />In summa=
ry, <b>given the widespread hardware adoption and industry usage, is it wor=
th revisiting adding P256 support to Bitcoin?</b><br /><div><b><br /></b></=
div><div>Josh Doman</div>

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

-- <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"" rel=3D"noreferrer nofollow noopener">bitcoindev+...@go=
oglegroups.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">https://groups.google.com/=
d/msgid/bitcoindev/8fbe1fe3-425d-4056-8387-993f6ecc1been%40googlegroups.com=
</a>.<br />

        </blockquote><br />
    </div></blockquote></div></div></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/6221341a-fea7-42ff-aabf-0ce3a783986en%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/6221341a-fea7-42ff-aabf-0ce3a783986en%40googlegroups.com</a>.<br />

------=_Part_2663_1323640421.1754686130835--

------=_Part_2662_727612150.1754686130835--