public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Michal Kolesár" <michal@zeleny-ctverec.cz>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP
Date: Wed, 5 Mar 2025 05:40:17 -0800 (PST)	[thread overview]
Message-ID: <83e89408-a20c-4297-96eb-3ca353be02abn@googlegroups.com> (raw)
In-Reply-To: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com>


[-- Attachment #1.1: Type: text/plain, Size: 3665 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 5831 bytes --]

  parent reply	other threads:[~2025-03-09  0:22 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 ` Michal Kolesár [this message]
2025-03-09  0:53   ` [bitcoindev] " Agustin Cruz
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=83e89408-a20c-4297-96eb-3ca353be02abn@googlegroups.com \
    --to=michal@zeleny-ctverec.cz \
    --cc=bitcoindev@googlegroups.com \
    /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