From: Dustin Ray <dustinvonsandwich@gmail.com>
To: Agustin Cruz <agustin.cruz@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP
Date: Tue, 11 Feb 2025 16:47:57 -0800 [thread overview]
Message-ID: <CAC3UE4K=T8BmOeLW9s=x+TBauK+M5Z3MaSicD42+rOj_jZ2Ugw@mail.gmail.com> (raw)
In-Reply-To: <CAJDmzYxJzFs=myecyMS6iJwSni1sDwUVq3kMnNGg=dK5kULRJg@mail.gmail.com>
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 <agustin.cruz@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 <dustinvonsandwich@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 <agustin.cruz@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+unsubscribe@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/CAC3UE4K%3DT8BmOeLW9s%3Dx%2BTBauK%2BM5Z3MaSicD42%2BrOj_jZ2Ugw%40mail.gmail.com.
next prev parent reply other threads:[~2025-02-12 4:01 UTC|newest]
Thread overview: 5+ 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 [this message]
2025-02-12 0:54 ` Agustin Cruz
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='CAC3UE4K=T8BmOeLW9s=x+TBauK+M5Z3MaSicD42+rOj_jZ2Ugw@mail.gmail.com' \
--to=dustinvonsandwich@gmail.com \
--cc=agustin.cruz@gmail.com \
--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