public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Agustin Cruz <agustin.cruz@gmail.com>
To: "Michal Kolesár" <michal@zeleny-ctverec.cz>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP
Date: Sat, 8 Mar 2025 21:53:58 -0300	[thread overview]
Message-ID: <CAJDmzYxAv8ahPOoTVryqy6oE8nUX0+49BHHhO==M1HpZCuMNbQ@mail.gmail.com> (raw)
In-Reply-To: <83e89408-a20c-4297-96eb-3ca353be02abn@googlegroups.com>

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

Hi Michal,

I completely understand your point of view. However, the concern with QRAMP
isn’t about arbitrarily punishing users or confiscating assets without
reason. Rather, it’s about mitigating a very real, systemic risk. If a
significant amount of funds remains in legacy addresses and a quantum
breakthrough occurs, the attack wouldn’t be a one-off incident targeting a
few unlucky individuals. Instead, it could compromise the security of the
entire network, affecting countless users and shaking confidence in Bitcoin
as a whole.

The enforcement aspect of QRAMP is intended as a last-resort safety
mechanism after a long and well-communicated migration period. It’s
designed to ensure that by the time any quantum-capable adversary comes
along, almost everyone’s funds are protected by quantum-resistant
cryptography. The goal is to preempt a scenario where the vulnerability
becomes so widespread that a malicious actor could trigger a massive,
destabilizing reallocation of wealth.

The enforced migration is less about penalizing users and more about
preserving the long-term security and stability of the network for everyone.

Best regards,
Agustin

El sáb, 8 de mar de 2025, 9:22 p. m., Michal Kolesár <
michal@zeleny-ctverec.cz> escribió:

> Dear Agustin,
>
> enforcement in general doesn’t seem like a good choice to me. If I were to
> compare it to the real world, it’s as if people had money or jewelry in
> bank vaults that were unbreakable at the time they were stored. After a
> certain period, it’s discovered that these vaults could be breached, and
> we’d tell everyone they have to buy new vaults and move their diamonds,
> gold, and banknotes into them. If they don’t do it, everything in their old
> vaults would be confiscated and destroyed. Surely, it’s normal that people
> would naturally buy new vaults (or move to safer ones) if they’re informed
> well in advance and loudly enough about the outdated vaults. And if they
> decide not to replace them, someone will eventually break in sooner or
> later and become the new owner of their "wealth." That’s how it works in
> the real world, after all. Yes, perhaps if someone steals a large amount of
> Bitcoin en masse, it might temporarily lower its value. But that’s fine—it
> would just redistribute old, lost, or unused Bitcoins into new ownership,
> where someone would start using them. It’s like finding a lost treasure
> from the past at the bottom of the ocean.
>
> Best regards,
> Michal
>
> On Wednesday, February 12, 2025 at 1:10:17 AM UTC+1 Agustin Cruz 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
> <https://github.com/chucrut/bips/blob/master/bip-xxxxx.md>
>
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/83e89408-a20c-4297-96eb-3ca353be02abn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/83e89408-a20c-4297-96eb-3ca353be02abn%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/CAJDmzYxAv8ahPOoTVryqy6oE8nUX0%2B49BHHhO%3D%3DM1HpZCuMNbQ%40mail.gmail.com.

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

  reply	other threads:[~2025-03-09  0:57 UTC|newest]

Thread overview: 17+ 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
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
     [not found]                       ` <CAJDmzYyF1g+gfeM4+YJgQxMw-cr6Ktx_q7LgptbNxpyAuV6wEg@mail.gmail.com>
2025-03-07 18:42                         ` Agustin Cruz
2025-02-19 17:56           ` Pieter Wuille
2025-03-05 13:40 ` [bitcoindev] " Michal Kolesár
2025-03-09  0:53   ` Agustin Cruz [this message]
2025-03-09  9:19     ` 'ArmchairCryptologist' via Bitcoin Development Mailing List

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='CAJDmzYxAv8ahPOoTVryqy6oE8nUX0+49BHHhO==M1HpZCuMNbQ@mail.gmail.com' \
    --to=agustin.cruz@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    --cc=michal@zeleny-ctverec.cz \
    /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