Delivery-date: Wed, 19 Feb 2025 13:54:59 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::234 as permitted sender) client-ip=2a00:1450:4864:20::234;
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>
 <CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ@mail.gmail.com>
In-Reply-To: <CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ@mail.gmail.com>
From: Agustin Cruz <agustin.cruz@gmail.com>
Date: Wed, 19 Feb 2025 18:07:25 -0300
Message-ID: <CAJDmzYzvYkm8At6yMrn+mAXnXbk=-R36SL5WneaDT9-Y-d=11w@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration
 Protocol (QRAMP) BIP
To: Dustin Ray <dustinvonsandwich@gmail.com>
Cc: Hunter Beast <hunter@surmount.systems>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000a29f0f062e85253a"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Hi Dustin,

I remain convinced that a forced migration mechanism=E2=80=94with a clear b=
lock
height deadline after which quantum-unsafe funds become unspendable=E2=80=
=94is the
more robust and secure approach. Here=E2=80=99s why:

A forced migration approach is unambiguous. By establishing a definitive
deadline, we eliminate the need for an additional transitional transaction
type, thereby reducing complexity and potential attack vectors. Additional
complexity could inadvertently open up new vulnerabilities that a more
straightforward deadline avoids.

If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost wallets=
=E2=80=94including
coins in addresses that no longer have active private key management, such
as potentially Satoshi=E2=80=99s=E2=80=94could eventually be compromised by=
 quantum
adversaries. If these coins were hacked and put back into circulation, the
resulting market shock would be catastrophic. The forced migration
mechanism is designed to preempt such a scenario by ensuring that only
quantum-safe funds can be spent once the deadline is reached.

El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp. m., Dustin Ray <
dustinvonsandwich@gmail.com> escribi=C3=B3:

> 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 whi=
ch
> 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 use=
d
> 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 preven=
ts
> 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=
.com>
> wrote:
>
>> Hi Hunter,
>>
>> I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. Your p=
oint
>> about not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those wi=
th quantum
>> 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 hav=
e
>> unintended consequences that go beyond transient inflation. It could
>> 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 sud=
den 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 m=
oment. 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 =
an
>> emergency scramble the moment a capable quantum machine appears. A force=
d
>> or proactive migration is an admittedly strong measure, but it attempts =
to
>> 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 =
isn=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 t=
o
>>> let those with quantum computers free up old coins. While this might ha=
ve
>>> 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 =
will
>>> also be rarer early on since a CRQC capable of a long exposure attack i=
s
>>> 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 =
MARA
>>> services.
>>>
>>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz =
wrote:
>>>
>>>> Hi Dustin:
>>>>
>>>> I understand that the proposal is an extraordinary ask=E2=80=94it woul=
d indeed
>>>> void a non-trivial part of the coin supply if users do not migrate in =
time,
>>>> and under normal circumstances, many would argue that unused P2PKH fun=
ds
>>>> 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. Consid=
er that
>>>> if we don=E2=80=99t implement a proactive migration, any Bitcoin in lo=
st
>>>> wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99s if he is =
not alive=E2=80=94will remain
>>>> vulnerable. In the event of a quantum breakthrough, those coins could =
be
>>>> 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 consequenc=
es of
>>>> a reactive measure in a quantum emergency could be far more catastroph=
ic.
>>>>
>>>> While I agree that a forced migration during an active quantum attack
>>>> scenario might be more acceptable (since funds would likely be conside=
red
>>>> lost anyway), waiting until such an emergency arises leaves us with li=
ttle
>>>> 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 dead=
line
>>>> 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 quantu=
m
>>>>> 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=94desi=
gned to
>>>>> mitigate the potentially catastrophic risk posed by quantum attacks o=
n
>>>>> ECDSA. The idea is to force a proactive migration of funds to
>>>>> quantum-resistant addresses before quantum computers become capable o=
f
>>>>> compromising the current cryptography.
>>>>> >
>>>>> > The migration window is intended to be sufficiently long (determine=
d
>>>>> by both block height and community input) to provide ample time for u=
sers
>>>>> 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 rai=
ses
>>>>> serious problems. A migration to quantum hard addresses in this manne=
r
>>>>> would cause serious financial damage to anyone holding legacy funds, =
if I
>>>>> understand your proposal correctly.
>>>>> >>
>>>>> >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <agusti...@gm=
ail.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 (Q=
RAMP).
>>>>> The goal of this proposal is to safeguard Bitcoin against potential f=
uture
>>>>> quantum attacks by enforcing a mandatory migration period for funds h=
eld in
>>>>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addr=
esses.
>>>>> >>>
>>>>> >>> The proposal outlines:
>>>>> >>>
>>>>> >>> Reducing Vulnerabilities: Transitioning funds to quantum-resistan=
t
>>>>> schemes preemptively to eliminate the risk posed by quantum attacks o=
n
>>>>> exposed public keys.
>>>>> >>> Enforcing Timelines: A hard migration deadline that forces timely
>>>>> action, rather than relying on a gradual, voluntary migration that mi=
ght
>>>>> leave many users at risk.
>>>>> >>> Balancing Risks: Weighing the non-trivial risk of funds being
>>>>> permanently locked against the potential catastrophic impact of a qua=
ntum
>>>>> attack on Bitcoin=E2=80=99s security.
>>>>> >>>
>>>>> >>> Additionally, the proposal addresses common criticisms such as th=
e
>>>>> risk of permanent fund loss, uncertain quantum timelines, and the pot=
ential
>>>>> for chain splits. It also details backwards compatibility measures,
>>>>> comprehensive security considerations, an extensive suite of test cas=
es,
>>>>> 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 secu=
rity
>>>>> 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 Googl=
e
>>>>> 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-=
8c5bde8598e7n%40googlegroups.com
>>>>> .
>>>>
>>>>
>>>>> --
>>> 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/f9e233e0-9d87-4e71-9a9f-33=
10ea242194n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-3=
310ea242194n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
>> 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/CAJDmzYz%3D52MGGLE0ZWm5tmfL=
UAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmf=
LUAZEo2tYQutHb4sMvjKbayOAHg%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/=
CAJDmzYzvYkm8At6yMrn%2BmAXnXbk%3D-R36SL5WneaDT9-Y-d%3D11w%40mail.gmail.com.

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

<div dir=3D"auto"><p dir=3D"ltr">Hi Dustin,</p><p dir=3D"ltr">I remain conv=
inced that a forced migration mechanism=E2=80=94with a clear block height d=
eadline after which quantum-unsafe funds become unspendable=E2=80=94is the =
more robust and secure approach. Here=E2=80=99s why:</p><p dir=3D"ltr">
A forced migration approach is unambiguous. By establishing a definitive de=
adline, we eliminate the need for an additional transitional transaction ty=
pe, thereby reducing complexity and potential attack vectors. Additional co=
mplexity could inadvertently open up new vulnerabilities that a more straig=
htforward deadline avoids.</p><p dir=3D"ltr">
If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost wallets=
=E2=80=94including coins in addresses that no longer have active private ke=
y management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventuall=
y be compromised by quantum adversaries. If these coins were hacked and put=
 back into circulation, the resulting market shock would be catastrophic. T=
he forced migration mechanism is designed to preempt such a scenario by ens=
uring that only quantum-safe funds can be spent once the deadline is reache=
d.</p></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AF=
p.=C2=A0m., Dustin Ray &lt;<a href=3D"mailto:dustinvonsandwich@gmail.com">d=
ustinvonsandwich@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"auto">It&#39;s worth considering a hypothetical =
but as of yet unknown middle ground solution, again nothing like this exist=
s currently but conceptually it would be interesting to explore:</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">1. At some block height deemed app=
ropriate, modify consensus so that any pre-quantum unspent funds are restri=
cted from being spent as normal.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">2. Develop a new transaction type whose sole purpose is to migrat=
e funds from a quantum 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 signature, but here&#39;s the hypothetical: It is satisfied by dev=
eloping 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 possib=
le that since we know the hash of the public key, perhaps we can invent som=
e mechanism whereby a quantum safe signature is created from an ecdsa priva=
te key that directly implies knowledge of a secret key that derived the kno=
wn public key.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In this w=
ay, we create a kind of turnstile that can safely transition funds from uns=
afe 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 s=
hielded funds.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">The=
re are likely hidden complexities in this idea that may cause it to be comp=
letely unworkable, but a theoretical transition mechanism both prevents a h=
eavy handed confiscation 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, anythin=
g prior to this is immediately vulnerable to key inversion, but Satoshi own=
s most of those coins as far as we know, so confiscating them might not be =
as controversial.</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 t=
hink the core idea is clear though.</div><div><br><div class=3D"gmail_quote=
"><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" target=3D"=
_blank" rel=3D"noreferrer">agustin.cruz@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg=
b(204,204,204)"><div dir=3D"auto"><p dir=3D"ltr">Hi Hunter,</p><p dir=3D"lt=
r">I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. Your p=
oint about not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those =
with quantum capabilities to free them up is certainly a valid one, and I u=
nderstand 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 noreferre=
r">dustinvo...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">=
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 rel=3D"noreferr=
er nofollow noreferrer 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 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 noreferrer">agusti...@gmail.com</a>&gt; wro=
te:<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 noreferrer">b=
itcoindev+...@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 noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2=
-8303-8c5bde8598e7n%40googlegroups.com</a>.</blockquote></div></blockquote>=
</div></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1e=
x;border-left-color:rgb(204,204,204)"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_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 noreferrer" target=3D"_blank">bitcoindev+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&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71=
-9a9f-3310ea242194n%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" rel=3D"noreferrer">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" rel=3D=
"noreferrer">https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGL=
E0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com</a>.<br>
</blockquote></div></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/CAJDmzYzvYkm8At6yMrn%2BmAXnXbk%3D-R36SL5WneaDT9-Y-d%3D11w%40mail=
.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.co=
m/d/msgid/bitcoindev/CAJDmzYzvYkm8At6yMrn%2BmAXnXbk%3D-R36SL5WneaDT9-Y-d%3D=
11w%40mail.gmail.com</a>.<br />

--000000000000a29f0f062e85253a--