path: root/a6/b5828dfb234328134f1bc534968a3c5b8e154a

Delivery-date: Wed, 19 Feb 2025 08:31:19 -0800
Received: from mail-yb1-f191.google.com ([209.85.219.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD3YNWFH7IHBBTMO3C6QMGQEORZ3ZWQ@googlegroups.com>)
	id 1tkmyk-00055O-DO
	for bitcoindev@gnusha.org; Wed, 19 Feb 2025 08:31:19 -0800
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e5dac3d1147sf1023276.1
        for <bitcoindev@gnusha.org>; Wed, 19 Feb 2025 08:31:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1739982672; x=1740587472; 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=raRc8OgOxPExLHfXC53FJE7hUWsQrAnXbXgzwyHukF4=;
        b=hKJyV6mQppj1Bn2yblKsce5q34VjZ28h8Jpp1CS0m5m4/u6Sx4kN4TBV28tbfBJaaC
         LxvjWymIGrITsbifuRpBqPmZzu2ajwSgydsh8439fNhXQSvWSxt92/orYg2XGdTCBE1l
         uFjEGtw6tfrtk+2ooGmfXyFo5puhddnSWidsyI27/JcIU/swpVujkAbfiuRq8ri4WGA9
         GCzNFaJ7e+0sEqQ7FBN6X/kxMSXhrxi94ta81C9vq76n83yUicGxK2u2ES/sKxMETZA+
         DkJZY+ksz9q4X765OB/NBlAP/RfcAavUKgBvrd7MBiu3gSUaMrUhg2si8WOsywhAbXo9
         yfqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1739982672; x=1740587472;
        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=raRc8OgOxPExLHfXC53FJE7hUWsQrAnXbXgzwyHukF4=;
        b=PeaOm3dCRJKX8lU2hnVs+A05mCxiGi1AHJw7B/Nh6H12BZudJC4p9xgVZITU0cQOLf
         KtBdhqAf/7tXxKQxkRGt2qDqG5C5OeqAJbvnz4znSlWlEICOOSrXTUpdNdokqPxH4d2G
         wMHNw5D4hTy6psspmo1QvH/e59/AjE1k617FgCQ3NlkZFXT/tPtKuhtpP+a2lTWRTBPD
         RpQQARIeKQ4V8TntizsXpfHQ4ozOmWNrcj6k0qBvAijtCnPtxkrR1JxbRA59yeCSWC+Z
         9FX1RXG0YPMXAnlT2/9II3/Y3AjRyNMqZrCNAo0HYmT2urBD6D810oLskuUj5NKLs2XX
         ZQYQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVgkrtzpILhHUv3TCApBSQwgZwxpwHpRaAwQkKonhArDqu+E+Drq/eee0zKNWR8QxbEQKQkk6zw92lR@gnusha.org
X-Gm-Message-State: AOJu0YzE182mVTzTyVoypJqeaSLtSjlW4o04AArEECtpbe8NL963C5zn
	9Sn8q1s2aRxCIONuts5HfTXv3ub4i2+mPIL1oMFLC29ArKinGLBZ
X-Google-Smtp-Source: AGHT+IHQ3b/FiQttYl2aF6z0DUeS3I3j20eIFpxn+9bfBNfFtoOS0UjIt5XWYsTYLZNmVZ3jv/U9tA==
X-Received: by 2002:a05:6902:27c7:b0:e58:1112:c3d3 with SMTP id 3f1490d57ef6-e5dc90497dfmr6205314276.4.1739982672579;
        Wed, 19 Feb 2025 08:31:12 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGmRvnXUcqdWQMrS9mDmszQ016sEuForjQyZOIu2jeryw==
Received: by 2002:a25:5f11:0:b0:e5b:423e:3be6 with SMTP id 3f1490d57ef6-e5e18de4daels706276.1.-pod-prod-08-us;
 Wed, 19 Feb 2025 08:31:09 -0800 (PST)
X-Received: by 2002:a05:690c:317:b0:6f7:409c:f645 with SMTP id 00721157ae682-6fba5658c0emr40805057b3.4.1739982669568;
        Wed, 19 Feb 2025 08:31:09 -0800 (PST)
Received: by 2002:a81:be1a:0:b0:6f9:77a0:782b with SMTP id 00721157ae682-6fb44a6cc88ms7b3;
        Wed, 19 Feb 2025 08:06:59 -0800 (PST)
X-Received: by 2002:a05:690c:498d:b0:6fb:9445:d28e with SMTP id 00721157ae682-6fba517324fmr39851627b3.10.1739981217550;
        Wed, 19 Feb 2025 08:06:57 -0800 (PST)
Date: Wed, 19 Feb 2025 08:06:57 -0800 (PST)
From: Hunter Beast <hunter@surmount.systems>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f9e233e0-9d87-4e71-9a9f-3310ea242194n@googlegroups.com>
In-Reply-To: <CAJDmzYzUAzoCj3da-3M_ast0_+Qxf3_J1OXWf88B2D-R70pPrg@mail.gmail.com>
References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com>
 <CAC3UE4+kme2N6D_Xx8+VaH1BJnkVEfntPmnLQzaqTQfK4D5QhQ@mail.gmail.com>
 <CAJDmzYxJzFs=myecyMS6iJwSni1sDwUVq3kMnNGg=dK5kULRJg@mail.gmail.com>
 <CAC3UE4K=T8BmOeLW9s=x+TBauK+M5Z3MaSicD42+rOj_jZ2Ugw@mail.gmail.com>
 <CAJDmzYzUAzoCj3da-3M_ast0_+Qxf3_J1OXWf88B2D-R70pPrg@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration
 Protocol (QRAMP) BIP
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_234746_846143868.1739981217114"
X-Original-Sender: hunter@surmount.systems
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: -0.7 (/)

------=_Part_234746_846143868.1739981217114
Content-Type: multipart/alternative; 
	boundary="----=_Part_234747_1231912761.1739981217114"

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

I don't see why old coins should be confiscated. The better option is to=20
let those with quantum computers free up old coins. While this might have=
=20
an inflationary impact on bitcoin's price, to use a turn of phrase, the=20
inflation is transitory. Those with low time preference should support=20
returning lost coins to circulation.

Also, I don't see the urgency, considering the majority of coins are in=20
either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signatures aren't=
=20
added, such as with BIP-360, there will be some concern around long=20
exposure attacks on P2TR coins. For large amounts, it would be smart to=20
modify wallets to support broadcasting transactions to private mempool=20
services such as Slipstream, to mitigate short exposure attacks. Those will=
=20
also be rarer early on since a CRQC capable of a long exposure attack is=20
much simpler than one capable of pulling off a short exposure attack=20
against a transaction in the mempool.

Bitcoin's Q-day likely won't be sudden and obvious. It will also take time=
=20
to coordinate a soft fork activation. This shouldn't be rushed.

In the interest of transparency, it's worth mentioning that I'm working on=
=20
a BIP-360 implementation for Anduro. Both Anduro and Slipstream are MARA=20
services.

On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz wrot=
e:

> Hi Dustin:
>
> I understand that the proposal is an extraordinary ask=E2=80=94it would i=
ndeed=20
> void a non-trivial part of the coin supply if users do not migrate in tim=
e,=20
> and under normal circumstances, many would argue that unused P2PKH funds=
=20
> are safe from a quantum adversary. However, the intent here is to be=20
> proactive rather than reactive.
>
> The concern isn=E2=80=99t solely about funds in active wallets. Consider =
that if=20
> we don=E2=80=99t implement a proactive migration, any Bitcoin in lost=20
> wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99s if he is not=
 alive=E2=80=94will remain=20
> vulnerable. In the event of a quantum breakthrough, those coins could be=
=20
> hacked and put back into circulation. Such an outcome would not only=20
> disrupt the balance of supply but could also undermine the trust and=20
> security that Bitcoin has built over decades. In short, the consequences =
of=20
> a reactive measure in a quantum emergency could be far more catastrophic.
>
> While I agree that a forced migration during an active quantum attack=20
> scenario might be more acceptable (since funds would likely be considered=
=20
> lost anyway), waiting until such an emergency arises leaves us with littl=
e=20
> margin for error. By enforcing a migration now, we create a window for th=
e=20
> entire community to transition safely=E2=80=94assuming we set the deadlin=
e=20
> generously and provide ample notifications, auto-migration tools, and, if=
=20
> necessary, emergency extensions.
>
> El mar, 11 de feb de 2025, 9:48=E2=80=AFp. m., Dustin Ray <dustinvo...@gm=
ail.com>=20
> escribi=C3=B3:
>
>> I think youre going to have a tough time getting consensus on this
>> proposal. It is an extraordinary ask of the community to instill a
>> change that will essentially void out a non-trivial part of the coin
>> supply, especially when funds behind unused P2PKH addresses are at
>> this point considered safe from a quantum adversary.
>>
>> In my opinion, where parts of this proposal make sense is in a quantum
>> emergency in which an adversary is actively extracting private keys
>> from known public keys and a transition must be made quickly and
>> decisively. In that case, we might as well consider funds to be lost
>> anyways. In any other scenario prior to this hypothetical emergency
>> however, I have serious doubts that the community is going to consent
>> to this proposal as it stands.
>>
>> On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz <agusti...@gmail.co=
m> wrote:
>> >
>> > Hi Dustin
>> >
>> > To clarify, the intent behind making legacy funds unspendable after a=
=20
>> certain block height is indeed a hard security measure=E2=80=94designed =
to mitigate=20
>> the potentially catastrophic risk posed by quantum attacks on ECDSA. The=
=20
>> idea is to force a proactive migration of funds to quantum-resistant=20
>> addresses before quantum computers become capable of compromising the=20
>> current cryptography.
>> >
>> > The migration window is intended to be sufficiently long (determined b=
y=20
>> both block height and community input) to provide ample time for users a=
nd=20
>> service providers to transition.
>> >
>> >
>> > El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray <
>> dustinvo...@gmail.com> escribi=C3=B3:
>> >>
>> >> Right off the bat I notice you are proposing that legacy funds become=
=20
>> unspendable after a certain block height which immediately raises seriou=
s=20
>> problems. A migration to quantum hard addresses in this manner would cau=
se=20
>> serious financial damage to anyone holding legacy funds, if I understand=
=20
>> your proposal correctly.
>> >>
>> >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <agusti...@gmail=
.com>=20
>> wrote:
>> >>>
>> >>> Dear Bitcoin Developers,
>> >>>
>> >>> I am writing to share my proposal for a new Bitcoin Improvement=20
>> Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QRAM=
P).=20
>> The goal of this proposal is to safeguard Bitcoin against potential futu=
re=20
>> quantum attacks by enforcing a mandatory migration period for funds held=
 in=20
>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant address=
es.
>> >>>
>> >>> The proposal outlines:
>> >>>
>> >>> Reducing Vulnerabilities: Transitioning funds to quantum-resistant=
=20
>> schemes preemptively to eliminate the risk posed by quantum attacks on=
=20
>> exposed public keys.
>> >>> Enforcing Timelines: A hard migration deadline that forces timely=20
>> action, rather than relying on a gradual, voluntary migration that might=
=20
>> leave many users at risk.
>> >>> Balancing Risks: Weighing the non-trivial risk of funds being=20
>> permanently locked against the potential catastrophic impact of a quantu=
m=20
>> attack on Bitcoin=E2=80=99s security.
>> >>>
>> >>> Additionally, the proposal addresses common criticisms such as the=
=20
>> risk of permanent fund loss, uncertain quantum timelines, and the potent=
ial=20
>> for chain splits. It also details backwards compatibility measures,=20
>> comprehensive security considerations, an extensive suite of test cases,=
=20
>> and a reference implementation plan that includes script interpreter=20
>> changes, wallet software updates, and network monitoring tools.
>> >>>
>> >>> For your convenience, I have published the full proposal on my GitHu=
b=20
>> repository. You can review it at the following link:
>> >>>
>> >>> Quantum-Resistant Address Migration Protocol (QRAMP) Proposal on=20
>> GitHub
>> >>>
>> >>> I welcome your feedback and suggestions and look forward to engaging=
=20
>> in a constructive discussion on how best to enhance the security and=20
>> resilience of the Bitcoin network in the quantum computing era.
>> >>>
>> >>> Thank you for your time and consideration.
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Agustin Cruz
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google=
=20
>> Groups "Bitcoin Development Mailing List" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,=20
>> send an email to bitcoindev+...@googlegroups.com.
>> >>> To view this discussion visit=20
>> https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5=
bde8598e7n%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/=
f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com.

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

I don't see why old coins should be confiscated. The better option is to le=
t those with quantum computers free up old coins. While this might have an =
inflationary impact on bitcoin's price, to use a turn of phrase, the inflat=
ion is transitory. Those with low time preference should support returning =
lost coins to circulation.<div><br /></div><div>Also, I don't see the urgen=
cy, considering the majority of coins are in either P2PKH, P2WPKH, P2SH, an=
d P2WSH addresses. If PQC signatures aren't added, such as with BIP-360, th=
ere will be some concern around long exposure attacks on P2TR coins. For la=
rge amounts, it would be smart to modify wallets to support broadcasting tr=
ansactions to private mempool services such as Slipstream, to mitigate shor=
t exposure attacks. Those will also be rarer early on since a CRQC capable =
of a long exposure attack is much simpler than one capable of pulling off a=
 short exposure attack against a transaction in the mempool.</div><div><br =
/></div><div>Bitcoin's Q-day likely won't be sudden and obvious. It will al=
so take time to coordinate a soft fork activation. This shouldn't be rushed=
.</div><div><br /></div><div>In the interest of transparency, it's worth me=
ntioning that I'm working on a BIP-360 implementation for Anduro. Both Andu=
ro and Slipstream are MARA services.</div><div><br /></div><div class=3D"gm=
ail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, February 11, =
2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz wrote:<br/></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"auto"><p dir=3D"ltr">Hi=
 Dustin:</p>
<p dir=3D"ltr">I understand that the proposal is an extraordinary ask=E2=80=
=94it would indeed void a non-trivial part of the coin supply if users do n=
ot migrate in time, and under normal circumstances, many would argue that u=
nused P2PKH funds are safe from a quantum adversary. However, the intent he=
re is to be proactive rather than reactive.</p>
<p dir=3D"ltr">The concern isn=E2=80=99t solely about funds in active walle=
ts. Consider that if we don=E2=80=99t implement a proactive migration, any =
Bitcoin in lost wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99=
s if he is not alive=E2=80=94will remain vulnerable. In the event of a quan=
tum breakthrough, those coins could be hacked and put back into circulation=
. Such an outcome would not only disrupt the balance of supply but could al=
so undermine the trust and security that Bitcoin has built over decades. In=
 short, the consequences of a reactive measure in a quantum emergency could=
 be far more catastrophic.</p>
<p dir=3D"ltr">While I agree that a forced migration during an active quant=
um attack scenario might be more acceptable (since funds would likely be co=
nsidered lost anyway), waiting until such an emergency arises leaves us wit=
h little margin for error. By enforcing a migration now, we create a window=
 for the entire community to transition safely=E2=80=94assuming we set the =
deadline generously and provide ample notifications, auto-migration tools, =
and, if necessary, emergency extensions.</p></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">El mar, 11 de feb de 2025, 9:48=
=E2=80=AFp.=C2=A0m., Dustin Ray &lt;<a href data-email-masked rel=3D"nofoll=
ow">dustinvo...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I think youre going to have a tough time getting consensus on=
 this<br>
proposal. It is an extraordinary ask of the community to instill a<br>
change that will essentially void out a non-trivial part of the coin<br>
supply, especially when funds behind unused P2PKH addresses are at<br>
this point considered safe from a quantum adversary.<br>
<br>
In my opinion, where parts of this proposal make sense is in a quantum<br>
emergency in which an adversary is actively extracting private keys<br>
from known public keys and a transition must be made quickly and<br>
decisively. In that case, we might as well consider funds to be lost<br>
anyways. In any other scenario prior to this hypothetical emergency<br>
however, I have serious doubts that the community is going to consent<br>
to this proposal as it stands.<br>
<br>
On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz &lt;<a href rel=3D"nor=
eferrer nofollow" data-email-masked>agusti...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi Dustin<br>
&gt;<br>
&gt; To clarify, the intent behind making legacy funds unspendable after a =
certain block height is indeed a hard security measure=E2=80=94designed to =
mitigate the potentially catastrophic risk posed by quantum attacks on ECDS=
A. The idea is to force a proactive migration of funds to quantum-resistant=
 addresses before quantum computers become capable of compromising the curr=
ent cryptography.<br>
&gt;<br>
&gt; The migration window is intended to be sufficiently long (determined b=
y both block height and community input) to provide ample time for users an=
d service providers to transition.<br>
&gt;<br>
&gt;<br>
&gt; El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray &lt;<a href =
rel=3D"noreferrer nofollow" data-email-masked>dustinvo...@gmail.com</a>&gt;=
 escribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt; Right off the bat I notice you are proposing that legacy funds bec=
ome unspendable after a certain block height which immediately raises serio=
us problems. A migration to quantum hard addresses in this manner would cau=
se serious financial damage to anyone holding legacy funds, if I understand=
 your proposal correctly.<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz &lt;<a href r=
el=3D"noreferrer nofollow" data-email-masked>agusti...@gmail.com</a>&gt; wr=
ote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Dear Bitcoin Developers,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I am writing to share my proposal for a new Bitcoin Improvemen=
t Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QRAMP=
). The goal of this proposal is to safeguard Bitcoin against potential futu=
re quantum attacks by enforcing a mandatory migration period for funds held=
 in legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addres=
ses.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The proposal outlines:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Reducing Vulnerabilities: Transitioning funds to quantum-resis=
tant schemes preemptively to eliminate the risk posed by quantum attacks on=
 exposed public keys.<br>
&gt;&gt;&gt; Enforcing Timelines: A hard migration deadline that forces tim=
ely action, rather than relying on a gradual, voluntary migration that migh=
t leave many users at risk.<br>
&gt;&gt;&gt; Balancing Risks: Weighing the non-trivial risk of funds being =
permanently locked against the potential catastrophic impact of a quantum a=
ttack on Bitcoin=E2=80=99s security.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Additionally, the proposal addresses common criticisms such as=
 the risk of permanent fund loss, uncertain quantum timelines, and the pote=
ntial for chain splits. It also details backwards compatibility measures, c=
omprehensive security considerations, an extensive suite of test cases, and=
 a reference implementation plan that includes script interpreter changes, =
wallet software updates, and network monitoring tools.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For your convenience, I have published the full proposal on my=
 GitHub repository. You can review it at the following link:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Quantum-Resistant Address Migration Protocol (QRAMP) Proposal =
on GitHub<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I welcome your feedback and suggestions and look forward to en=
gaging in a constructive discussion on how best to enhance the security and=
 resilience of the Bitcoin network in the quantum computing era.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thank you for your time and consideration.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Best regards,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Agustin Cruz<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt;&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an email to <a href rel=3D"noreferrer nofollow" data-email-masked>=
bitcoindev+...@googlegroups.com</a>.<br>
&gt;&gt;&gt; To view this discussion visit <a href=3D"https://groups.google=
.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde8598e7n%40googlegroup=
s.com" rel=3D"noreferrer noreferrer nofollow" target=3D"_blank" data-safere=
directurl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.goog=
le.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde8598e7n%2540googleg=
roups.com&amp;source=3Dgmail&amp;ust=3D1740066729281000&amp;usg=3DAOvVaw3UO=
I4K5wKSzAElSWDPITT8">https://groups.google.com/d/msgid/bitcoindev/08a544fa-=
a29b-45c2-8303-8c5bde8598e7n%40googlegroups.com</a>.<br>
</blockquote></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/f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com</a>.<br />

------=_Part_234747_1231912761.1739981217114--

------=_Part_234746_846143868.1739981217114--