Delivery-date: Wed, 19 Feb 2025 12:21:23 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) client-ip=2607:f8b0:4864:20::c31;
MIME-Version: 1.0
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>
 <f9e233e0-9d87-4e71-9a9f-3310ea242194n@googlegroups.com> <CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com>
In-Reply-To: <CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com>
From: Dustin Ray <dustinvonsandwich@gmail.com>
Date: Wed, 19 Feb 2025 12:10:11 -0800
Message-ID: <CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration
 Protocol (QRAMP) BIP
To: Agustin Cruz <agustin.cruz@gmail.com>
Cc: Hunter Beast <hunter@surmount.systems>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000eb9af3062e8458f0"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--000000000000eb9af3062e8458f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It's worth considering a hypothetical but as of yet unknown middle ground
solution, again nothing like this exists currently but conceptually it
would be interesting to explore:

1. At some block height deemed appropriate, modify consensus so that any
pre-quantum unspent funds are restricted from being spent as normal.

2. Develop a new transaction type whose sole purpose is to migrate funds
from a quantum unsafe address to a safe one.

3. This new transaction type is a quantum safe digital signature, but
here's the hypothetical: It is satisfied by developing a mechanism by which
a private key from a quantum-unsafe scheme can be repurposed as a private
key for a pq-safe scheme. It may also be possible that since we know the
hash of the public key, perhaps we can invent some mechanism whereby a
quantum safe signature is created from an ecdsa private key that directly
implies knowledge of a secret key that derived the known public key.

In this way, we create a kind of turnstile that can safely transition funds
from unsafe addresses into safe ones. Such turnstiles have been used in
blockchains before, a notable example is in the zcash network as part of an
audit of shielded funds.

There are likely hidden complexities in this idea that may cause it to be
completely unworkable, but a theoretical transition mechanism both prevents
a heavy handed confiscation of funds and also prevents funds from being
stolen and injected back into the supply under illegitimate pretenses.

This only works for p2pkh, anything prior to this is immediately vulnerable
to key inversion, but Satoshi owns most of those coins as far as we know,
so confiscating them might not be as controversial.

I'm typing this on my phone so sorry for the lack of detailed references. I
think the core idea is clear though.

On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cruz <agustin.cruz@gmail.c=
om>
wrote:

> Hi Hunter,
>
> I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. Your po=
int about
> not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those with quan=
tum capabilities
> to free them up is certainly a valid one, and I understand the argument
> that any inflationary impact could be transitory.
>
> From my viewpoint, allowing quantum-capable adversaries to reintroduce
> dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) could have
> unintended consequences that go beyond transient inflation. It could
> fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disrupt e=
conomic
> assumptions built around the current distribution of coins. While some
> might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their sudd=
en reappearance
> could cause lasting market shocks and undermine confidence. The goal of a
> proactive migration is to close the door on such a scenario before it
> becomes imminent.
>
> I agree that Q-day won=E2=80=99t necessarily be a single, catastrophic mo=
ment. It
> will likely be gradual and subtle, giving the network some time to adapt.
> That said, one challenge is ensuring we don=E2=80=99t find ourselves in a=
n
> emergency scramble the moment a capable quantum machine appears. A forced
> or proactive migration is an admittedly strong measure, but it attempts t=
o
> address the scenario where a slow, creeping capability becomes a sudden
> attack vector once it matures. In that sense, =E2=80=9Crushing=E2=80=9D i=
sn=E2=80=99t ideal, but
> neither is waiting until the threat is undeniably present.
>
> El mi=C3=A9, 19 de feb de 2025, 1:31=E2=80=AFp. m., Hunter Beast
> <hunter@surmount.systems> escribi=C3=B3:
>
>> I don't see why old coins should be confiscated. The better option is to
>> let those with quantum computers free up old coins. While this might hav=
e
>> an inflationary impact on bitcoin's price, to use a turn of phrase, the
>> inflation is transitory. Those with low time preference should support
>> returning lost coins to circulation.
>>
>> Also, I don't see the urgency, considering the majority of coins are in
>> either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signatures aren'=
t
>> added, such as with BIP-360, there will be some concern around long
>> exposure attacks on P2TR coins. For large amounts, it would be smart to
>> modify wallets to support broadcasting transactions to private mempool
>> services such as Slipstream, to mitigate short exposure attacks. Those w=
ill
>> 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.
>>
>> Bitcoin's Q-day likely won't be sudden and obvious. It will also take
>> time 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 a BIP-360 implementation for Anduro. Both Anduro and Slipstream are M=
ARA
>> services.
>>
>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz w=
rote:
>>
>>> Hi Dustin:
>>>
>>> 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 not migrate in t=
ime,
>>> and under normal circumstances, many would argue that unused P2PKH fund=
s
>>> are safe from a quantum adversary. However, the intent here is to be
>>> proactive rather than reactive.
>>>
>>> The concern isn=E2=80=99t solely about funds in active wallets. Conside=
r that if
>>> we don=E2=80=99t implement a proactive migration, any Bitcoin in lost
>>> wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99s if he is n=
ot alive=E2=80=94will remain
>>> vulnerable. In the event of a quantum breakthrough, those coins could b=
e
>>> hacked and put back into circulation. Such an outcome would not only
>>> disrupt the balance of supply but could also undermine the trust and
>>> security that Bitcoin has built over decades. In short, the consequence=
s of
>>> a reactive measure in a quantum emergency could be far more catastrophi=
c.
>>>
>>> While I agree that a forced migration during an active quantum attack
>>> scenario might be more acceptable (since funds would likely be consider=
ed
>>> lost anyway), waiting until such an emergency arises leaves us with lit=
tle
>>> 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 deadl=
ine
>>> generously and provide ample notifications, auto-migration tools, and, =
if
>>> necessary, emergency extensions.
>>>
>>> El mar, 11 de feb de 2025, 9:48=E2=80=AFp. m., Dustin Ray <dustinvo...@=
gmail.com>
>>> 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.=
com>
>>>> wrote:
>>>> >
>>>> > Hi Dustin
>>>> >
>>>> > To clarify, the intent behind making legacy funds unspendable after =
a
>>>> certain block height is indeed a hard security measure=E2=80=94designe=
d to mitigate
>>>> the potentially catastrophic risk posed by quantum attacks on ECDSA. T=
he
>>>> idea is to force a proactive migration of funds to quantum-resistant
>>>> addresses before quantum computers become capable of compromising the
>>>> current cryptography.
>>>> >
>>>> > The migration window is intended to be sufficiently long (determined
>>>> by both block height and community input) to provide ample time for us=
ers
>>>> and 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 unspendable after a certain block height which immediately rais=
es
>>>> serious problems. A migration to quantum hard addresses in this manner
>>>> would cause serious financial damage to anyone holding legacy funds, i=
f I
>>>> understand your proposal correctly.
>>>> >>
>>>> >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <agusti...@gma=
il.com>
>>>> wrote:
>>>> >>>
>>>> >>> Dear Bitcoin Developers,
>>>> >>>
>>>> >>> I am writing to share my proposal for a new Bitcoin Improvement
>>>> Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QR=
AMP).
>>>> The goal of this proposal is to safeguard Bitcoin against potential fu=
ture
>>>> quantum attacks by enforcing a mandatory migration period for funds he=
ld in
>>>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addre=
sses.
>>>> >>>
>>>> >>> The proposal outlines:
>>>> >>>
>>>> >>> Reducing Vulnerabilities: Transitioning funds to quantum-resistant
>>>> schemes preemptively to eliminate the risk posed by quantum attacks on
>>>> exposed public keys.
>>>> >>> Enforcing Timelines: A hard migration deadline that forces timely
>>>> action, rather than relying on a gradual, voluntary migration that mig=
ht
>>>> leave many users at risk.
>>>> >>> Balancing Risks: Weighing the non-trivial risk of funds being
>>>> permanently locked against the potential catastrophic impact of a quan=
tum
>>>> attack on Bitcoin=E2=80=99s security.
>>>> >>>
>>>> >>> 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,
>>>> comprehensive security considerations, an extensive suite of test case=
s,
>>>> and a reference implementation plan that includes script interpreter
>>>> changes, wallet software updates, and network monitoring tools.
>>>> >>>
>>>> >>> For your convenience, I have published the full proposal on my
>>>> GitHub repository. You can review it at the following link:
>>>> >>>
>>>> >>> Quantum-Resistant Address Migration Protocol (QRAMP) Proposal on
>>>> GitHub
>>>> >>>
>>>> >>> I welcome your feedback and suggestions and look forward to
>>>> engaging in a constructive discussion on how best to enhance the secur=
ity
>>>> and 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
>>>> Groups "Bitcoin Development Mailing List" group.
>>>> >>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to bitcoindev+...@googlegroups.com.
>>>> >>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8=
c5bde8598e7n%40googlegroups.com
>>>> .
>>>
>>>
>>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-331=
0ea242194n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-33=
10ea242194n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfLU=
AZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfL=
UAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter>
> .
>

--=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/=
CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ%40mail.gmail.com.

--000000000000eb9af3062e8458f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">It&#39;s worth considering a hypothetical but as of yet u=
nknown middle ground solution, again nothing like this exists currently but=
 conceptually it would be interesting to explore:</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">1. At some block height deemed appropriate, modif=
y consensus so that any pre-quantum unspent funds are restricted from being=
 spent as normal.</div><div dir=3D"auto"><br></div><div dir=3D"auto">2. Dev=
elop a new transaction type whose sole purpose is to migrate funds from a q=
uantum unsafe address to a safe one.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">3. This new transaction type is a quantum safe digital signatu=
re, but here&#39;s the hypothetical: It is satisfied by developing a mechan=
ism by which a private key from a quantum-unsafe scheme can be repurposed a=
s a private key for a pq-safe scheme. It may also be possible that since we=
 know the hash of the public key, perhaps we can invent some mechanism wher=
eby a quantum safe signature is created from an ecdsa private key that dire=
ctly implies knowledge of a secret key that derived the known public key.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">In this way, we create a =
kind of turnstile that can safely transition funds from unsafe addresses in=
to safe ones. Such turnstiles have been used in blockchains before, a notab=
le example is in the zcash network as part of an audit of shielded funds.=
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">There are likely =
hidden complexities in this idea that may cause it to be completely unworka=
ble, but a theoretical transition mechanism both prevents a heavy handed co=
nfiscation of funds and also prevents funds from being stolen and injected =
back into the supply under illegitimate pretenses.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">This only works for p2pkh, anything prior to thi=
s is immediately vulnerable to key inversion, but Satoshi owns most of thos=
e coins as far as we know, so confiscating them might not be as controversi=
al.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m typing this =
on my phone so sorry for the lack of detailed references. I think the core =
idea is clear though.</div><div><br><div class=3D"gmail_quote gmail_quote_c=
ontainer"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 10:=
47=E2=80=AFAM Agustin Cruz &lt;<a href=3D"mailto:agustin.cruz@gmail.com">ag=
ustin.cruz@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir=3D"a=
uto"><p dir=3D"ltr">Hi Hunter,</p><p dir=3D"ltr">I appreciate the work you=
=E2=80=99re doing on BIP-360 for Anduro. Your point about not =E2=80=9Cconf=
iscating=E2=80=9D old coins and allowing those with quantum capabilities to=
 free them up is certainly a valid one, and I understand the argument that =
any inflationary impact could be transitory.</p>
<p dir=3D"ltr">From my viewpoint, allowing quantum-capable adversaries to r=
eintroduce dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) c=
ould have unintended consequences that go beyond transient inflation. It co=
uld fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disrupt=
 economic assumptions built around the current distribution of coins. While=
 some might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their =
sudden reappearance could cause lasting market shocks and undermine confide=
nce. The goal of a proactive migration is to close the door on such a scena=
rio before it becomes imminent.</p><p dir=3D"ltr">I agree that Q-day won=E2=
=80=99t necessarily be a single, catastrophic moment. It will likely be gra=
dual and subtle, giving the network some time to adapt. That said, one chal=
lenge is ensuring we don=E2=80=99t find ourselves in an emergency scramble =
the moment a capable quantum machine appears. A forced or proactive migrati=
on is an admittedly strong measure, but it attempts to address the scenario=
 where a slow, creeping capability becomes a sudden attack vector once it m=
atures. In that sense, =E2=80=9Crushing=E2=80=9D isn=E2=80=99t ideal, but n=
either is waiting until the threat is undeniably present.</p></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">El mi=C3=A9, 1=
9 de feb de 2025, 1:31=E2=80=AFp.=C2=A0m., Hunter Beast &lt;hunter@surmount=
.systems&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;padding-left:1ex;border-left-color:rgb(204,204,204)">I don&#39;t see why o=
ld coins should be confiscated. The better option is to let those with quan=
tum computers free up old coins. While this might have an inflationary impa=
ct on bitcoin&#39;s price, to use a turn of phrase, the inflation is transi=
tory. Those with low time preference should support returning lost coins to=
 circulation.<div><br></div><div>Also, I don&#39;t see the urgency, conside=
ring the majority of coins are in either P2PKH, P2WPKH, P2SH, and P2WSH add=
resses. If PQC signatures aren&#39;t added, such as with BIP-360, there wil=
l be some concern around long exposure attacks on P2TR coins. For large amo=
unts, it would be smart to modify wallets to support broadcasting transacti=
ons to private mempool services such as Slipstream, to mitigate short expos=
ure attacks. Those will also be rarer early on since a CRQC capable of a lo=
ng 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&#39;s Q-day likely won&#39;t be sudden and obvious. It will als=
o take time to coordinate a soft fork activation. This shouldn&#39;t be rus=
hed.</div><div><br></div><div>In the interest of transparency, it&#39;s wor=
th mentioning that I&#39;m working on a BIP-360 implementation for Anduro. =
Both Anduro and Slipstream are MARA services.</div><div><br></div><div clas=
s=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, Februa=
ry 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204=
,204,204)"><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 rel=3D"nofollow noreferrer">dustinvo=
...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">I think your=
e 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 rel=3D"noreferr=
er nofollow noreferrer">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 rel=
=3D"noreferrer nofollow noreferrer">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 rel=3D=
"noreferrer nofollow noreferrer">agusti...@gmail.com</a>&gt; wrote:<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 rel=3D"noreferrer nofollow noreferrer">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 noreferrer" target=3D"_blank">=
https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde=
8598e7n%40googlegroups.com</a>.</blockquote></div></blockquote></div></bloc=
kquote></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-lef=
t-color:rgb(204,204,204)"><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><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" rel=3D"n=
oreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
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&amp;utm_source=3Dfooter" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-3310ea2=
42194n%40googlegroups.com</a>.<br>
</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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gma=
il.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https:=
//groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfLUAZEo2tYQ=
utHb4sMvjKbayOAHg%40mail.gmail.com</a>.<br>
</blockquote></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/CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ%40mail.g=
mail.com</a>.<br />

--000000000000eb9af3062e8458f0--