public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Agustin Cruz <agustin.cruz@gmail.com>
To: Hunter Beast <hunter@surmount.systems>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP
Date: Wed, 19 Feb 2025 13:42:02 -0300	[thread overview]
Message-ID: <CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com> (raw)
In-Reply-To: <f9e233e0-9d87-4e71-9a9f-3310ea242194n@googlegroups.com>

[-- Attachment #1: Type: text/plain, Size: 10173 bytes --]

Hi Hunter,

I appreciate the work you’re doing on BIP-360 for Anduro. Your point about
not “confiscating” 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.

From my viewpoint, allowing quantum-capable adversaries to reintroduce
dormant coins (e.g., Satoshi’s if those keys are lost) could have
unintended consequences that go beyond transient inflation. It could
fundamentally alter trust in Bitcoin’s fixed supply and disrupt economic
assumptions built around the current distribution of coins. While some
might view these dormant coins as “fair game,” their sudden 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’t necessarily be a single, catastrophic moment. It
will likely be gradual and subtle, giving the network some time to adapt.
That said, one challenge is ensuring we don’t find ourselves in an
emergency scramble the moment a capable quantum machine appears. A forced
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, “rushing” isn’t ideal, but
neither is waiting until the threat is undeniably present.

El mié, 19 de feb de 2025, 1:31 p. m., Hunter Beast <hunter@surmount.systems>
escribió:

> 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 have
> 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 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 MARA
> services.
>
> On Tuesday, February 11, 2025 at 9:01:51 PM UTC-7 Agustin Cruz wrote:
>
>> Hi Dustin:
>>
>> I understand that the proposal is an extraordinary ask—it would 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 funds
>> are safe from a quantum adversary. However, the intent here is to be
>> proactive rather than reactive.
>>
>> The concern isn’t solely about funds in active wallets. Consider that if
>> we don’t implement a proactive migration, any Bitcoin in lost
>> wallets—including, hypothetically, Satoshi’s if he is not alive—will 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 consequences of
>> a reactive measure in a quantum emergency could be far more catastrophic.
>>
>> While I agree that a forced migration during an active quantum attack
>> scenario might be more acceptable (since funds would likely be considered
>> lost anyway), waiting until such an emergency arises leaves us with little
>> margin for error. By enforcing a migration now, we create a window for the
>> entire community to transition safely—assuming we set the deadline
>> generously and provide ample notifications, auto-migration tools, and, if
>> necessary, emergency extensions.
>>
>> El mar, 11 de feb de 2025, 9:48 p. m., Dustin Ray <dustinvo...@gmail.com>
>> escribió:
>>
>>> 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 PM 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—designed to mitigate
>>> the potentially catastrophic risk posed by quantum attacks on ECDSA. The
>>> 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 users
>>> and service providers to transition.
>>> >
>>> >
>>> > El mar, 11 de feb de 2025, 9:15 p. m., Dustin Ray <
>>> dustinvo...@gmail.com> escribió:
>>> >>
>>> >> Right off the bat I notice you are proposing that legacy funds become
>>> unspendable after a certain block height which immediately raises serious
>>> problems. A migration to quantum hard addresses in this manner would cause
>>> serious financial damage to anyone holding legacy funds, if I understand
>>> your proposal correctly.
>>> >>
>>> >> On Tue, Feb 11, 2025 at 4:10 PM Agustin Cruz <agusti...@gmail.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 (QRAMP).
>>> The goal of this proposal is to safeguard Bitcoin against potential future
>>> quantum attacks by enforcing a mandatory migration period for funds held in
>>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addresses.
>>> >>>
>>> >>> 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 might
>>> leave many users at risk.
>>> >>> Balancing Risks: Weighing the non-trivial risk of funds being
>>> permanently locked against the potential catastrophic impact of a quantum
>>> attack on Bitcoin’s security.
>>> >>>
>>> >>> Additionally, the proposal addresses common criticisms such as the
>>> risk of permanent fund loss, uncertain quantum timelines, and the potential
>>> for chain splits. It also details backwards compatibility measures,
>>> comprehensive 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.
>>> >>>
>>> >>> 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 security 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-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-3310ea242194n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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%3D52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 11853 bytes --]

  reply	other threads:[~2025-02-19 18:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-11 22:36 [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP Agustin Cruz
2025-02-12  0:15 ` Dustin Ray
2025-02-12  0:37   ` Agustin Cruz
2025-02-12  0:47     ` Dustin Ray
2025-02-12  0:54       ` Agustin Cruz
2025-02-19 16:06         ` Hunter Beast
2025-02-19 16:42           ` Agustin Cruz [this message]
2025-02-19 20:10             ` Dustin Ray
2025-02-19 21:07               ` Agustin Cruz
2025-02-19 21:35                 ` Dustin Ray
2025-02-19 21:49                   ` Agustin Cruz
2025-02-19 22:05                     ` Dustin Ray
2025-02-19 17:56           ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com' \
    --to=agustin.cruz@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    --cc=hunter@surmount.systems \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox