From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 09 Mar 2025 01:30:33 -0800 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1trCzQ-00063J-2K for bitcoindev@gnusha.org; Sun, 09 Mar 2025 01:30:33 -0800 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-6015b5d1bdesf92815eaf.2 for ; Sun, 09 Mar 2025 01:30:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1741512626; cv=pass; d=google.com; s=arc-20240605; b=HYXAJ4QsxaKcrk2VnNxkoCqmIGuC/2n8y/e0yGeJEFJPC9R7TMiAxoQR2f/5U8+WEt Vj5Mf0SjWn5y3q2yPqdpZAe49By2h7w1CUUgPofXEW8rbgn/ee5IAM4m89p/JSo6XQk2 ku80ydScjNpf5t5DnpacBxMtSLOO6BLX4iAaw4jbU4vcuORdaTfK2hNLrURwcejacLHS QYAkihskiQFlXltR5zoxJ0ECcisEFSKfXqLAClFPMfP0yVYnEGilfK9u5E6Re1COvpqL RLw7bk0SXvAfC/wmyaMgbOZp9WXUmjMMODYTJXtipZqhM/AVB5ry5OsCIwONXWGuelFM l8Mg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:from:to:date :dkim-signature; bh=7WC9za2urk3VXl6nh8Ig8eaOvHyWaF8Ffeu02b50+2k=; fh=ifa8DoF/firQPnl5mPBVTMUTqY+tAaValgTrb4gPO+U=; b=k9wKRO3YFHjDtwBApqdhyP1ga2IK4rjXAe5sl3upsp+1dAy/bfqFrAaH9vZG1RoSXX o/0uUuqNy7AOjX1LVWJlZVdzH8gI9vPVHmAIJQePwqen/ybCQxEJ42Kzf3g8wouVvHcK dk58MADORAZjEIiQH+iAA9NKTOBZUbEwtugKRpENHo9UhND38gJkUeA4bWpW96Ql9TjE wPO4Dll2yAFZJZWyvnhZGpKq1u4dnRy7ip7lsrX3UoyF1yF6BkkJg7Q16Qh7e+cRs8rY z2PKvqvrhtVpvB0YFmIKpMzemVUrsmun8Gc++xXZHSCn8vtRasKC7GOmJ+ya3/jBcah4 tkFw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=K76ejj6V; spf=pass (google.com: domain of armchaircryptologist@protonmail.com designates 79.135.106.30 as permitted sender) smtp.mailfrom=ArmchairCryptologist@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741512626; x=1742117426; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :from:to:cc:subject:date:message-id:reply-to; bh=7WC9za2urk3VXl6nh8Ig8eaOvHyWaF8Ffeu02b50+2k=; b=mwnTuCJBqCmENJmvxIihcCMR/4U77w4JIzH6ZvbyBJZe3z569sdX09M8NFy39wumDy XdgVGAmB3V+4GJ8t20T8H/7vI27OhsBcDtJdN1vKLr6DizRsMiBCcfBOqk86R60L97Ck hRth0FR54sJO3shhTNX5mAvZvslJKiaFiNzSCbn8JAJgqWsE7VbMGSbatUrQXp2bpJOR uFR4Vp7CzluofnIqSp7MBx0ZUJws5VkDIQv4ACnrBOZtszm5q9JaKiXIBrQPsxDbb+GI LQe/jOsAaDGHafyk2GHK7AEZc4dokS5Zq3ZHSjEdxaL5pjM5k4mn+H0+YY8h57U0Oq4l lIag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741512626; x=1742117426; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7WC9za2urk3VXl6nh8Ig8eaOvHyWaF8Ffeu02b50+2k=; b=a+PnjLRX9wBcy47BlIj9eTxkuhBnaZYYtPmROhSX+umeTgjU50N1g7SHSCum0cohw6 O+jnPlkFa87/HmhkD7nSaZiE1PLNYYjS7cvRpBtG0h1CBn8uvOq07yGQGnyejWfaNmu/ Y6uEmuLc2IHq4KR5+eK5fFpfFVMXKSgY3AEIvbNr1qbiWDxCOQDPgMWGZZAu3v0GaXdP z36+PE6KO9slOyvLeGDjo7eovY/RpJLVaFHfN0tSKYByLUkSz9adPYvXdG4Wy4ZJFiCb giv+r7F1LK3sk9mPbhgaydk6AkL4MYGYMZyN2GtgxuSFO69mBrHKyd6Y0pC4TOMeFh/x rn4g== X-Forwarded-Encrypted: i=2; AJvYcCWpSFh5BjzC/Qh4mUHNJa2L1tmIR+0LtGECfPcHhU8gP9bjEOeiXix2es29sZjxmfPO7fKTjy661OhC@gnusha.org X-Gm-Message-State: AOJu0YyAUD9/DKFWd0jZlpW/mxu8dEwQPRxXCwq8cKy/HEsKDkt4D/EK 21ANrrzksbLOb1vdf6IjmV4DOifOiwXhR9TRxcwhzRVspcgMuRf3 X-Google-Smtp-Source: AGHT+IFulT2Z/zyuFO5dOM+Kllv5qahRShS5NCS7zqUb+xViymGXP1TEZnmm+kOIG9XBXV8pdbDHug== X-Received: by 2002:a05:6808:144c:b0:3f4:fc5:d2b4 with SMTP id 5614622812f47-3f697b1b189mr5230518b6e.2.1741512625872; Sun, 09 Mar 2025 01:30:25 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGTMgmuuJJoXeKFx69irf1+4w4tyOY6IuOPxI4dtYsuMA== Received: by 2002:a4a:dbda:0:b0:600:34a8:4c70 with SMTP id 006d021491bc7-6003eab747dls766136eaf.2.-pod-prod-04-us; Sun, 09 Mar 2025 01:30:22 -0800 (PST) X-Received: by 2002:a05:6808:2e93:b0:3f6:d59c:6a2d with SMTP id 5614622812f47-3f6d59c6ca4mr1743526b6e.39.1741512622815; Sun, 09 Mar 2025 01:30:22 -0800 (PST) Received: by 2002:ab3:6bd2:0:b0:293:23eb:d65a with SMTP id a1c4a302cd1d6-29323ebdc08msc7a; Sun, 9 Mar 2025 01:20:08 -0800 (PST) X-Received: by 2002:a2e:a99f:0:b0:30b:d543:5a71 with SMTP id 38308e7fff4ca-30bf44d9818mr24895741fa.1.1741512006600; Sun, 09 Mar 2025 01:20:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1741512006; cv=none; d=google.com; s=arc-20240605; b=fEx52n6pf6mFp7rcxQo7hGiNsoA2eZ/szS/sAq31Br+SloTRsXHH8r+iK7bDsGvjfP 3pYqENwqTBIGSle8Twv6facNcKwq/tz1eEJevDdv1f7/FtZhQbVVaqjbzt7VACBFTE/+ 4CCS8/w35A+Qbr7FtEA+205AmVOkCDE6S/zXvrtSIkSfHWp7k7OKC++Qaz0Y2x6zilQa 25AZ9BRt6pCaB8MsY73BccnXloYX9Hru95YSfIb40nZwRHsSrcNuV+3yGJoLGZiT0LIX Pk5F/swHFPyB2t16P3is5a9UX42rbU+l0+2wCX68lgynYEguFhk0O9VaOT2C85CVt6Rr /UTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:dkim-signature; bh=X+IQDOy+VjgI3PHPa+gmfeYbtVQEcW11v8BElcXFc+Y=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=kfa11IKhZZE64Qbcwn53PZLmxrizyr4VKZ/OEfmvd+4SPgVik0tQ+pzK5P8+jIFcNI CvCEfWUYnsy7aO6kzXK8Rb8U6zPOvN3VYqkNs/2zwD81gPY9CAMAeeVB2qWraei/8x53 jewiRfgrAOxG8vzzSS/v3DhrUK5AZPtFD8eOcCJueQ6QlTMS45pz6ls6CL0K1SRuqQFL bcCSkV/2c5gQxdga9WuLlyviZ2/75GoMHe7SQ2XAXUlU73w+HM5qPiN7zEyyXQCfEv8r 1EkM1qS9NgNmwaego1wQwvUyQNqt6GLYTHuEw+pp4aQYWQVuU8ZTpYBxDtNa534JSlSs 1+VQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=K76ejj6V; spf=pass (google.com: domain of armchaircryptologist@protonmail.com designates 79.135.106.30 as permitted sender) smtp.mailfrom=ArmchairCryptologist@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch. [79.135.106.30]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-30be99c911dsi1325841fa.5.2025.03.09.01.20.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Mar 2025 01:20:06 -0800 (PST) Received-SPF: pass (google.com: domain of armchaircryptologist@protonmail.com designates 79.135.106.30 as permitted sender) client-ip=79.135.106.30; Date: Sun, 09 Mar 2025 09:19:59 +0000 To: Bitcoin Development Mailing List From: "'ArmchairCryptologist' via Bitcoin Development Mailing List" Subject: Re: [bitcoindev] Re: Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP Message-ID: In-Reply-To: References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com> <83e89408-a20c-4297-96eb-3ca353be02abn@googlegroups.com> Feedback-ID: 24244585:user:proton X-Pm-Message-ID: 79b93cf62912cd686b1006a3dfea46dea9b47b8d MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_9oou56Y5i9ixeKojLOHOoTPRTuF8aBwrw1m5flfNrhQ" X-Original-Sender: armchaircryptologist@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=K76ejj6V; spf=pass (google.com: domain of armchaircryptologist@protonmail.com designates 79.135.106.30 as permitted sender) smtp.mailfrom=ArmchairCryptologist@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: ArmchairCryptologist Reply-To: ArmchairCryptologist Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_9oou56Y5i9ixeKojLOHOoTPRTuF8aBwrw1m5flfNrhQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One major issue with a mandatory transition to quantum-resistant addresses = that I haven't seen brought up is that block size is limited. In such a sce= nario, it could be highly beneficial for parties that benefit from high fee= s to flood the network with bogus transactions to force the fees arbitraril= y high, since people would then be forced to either pay exorbitant fees to = move their funds by the deadline, or lose their funds entirely. As such, th= is does not seem like a good idea in general, at least unless the transitio= n period is extremely long (say 10 years or more). A less drastic proposal could be to (at least initially) only disable spend= ing from the less common outputs that have no inherent quantum resistance b= y virtue of having a hashed public key, such as P2PK and P2TR, while leavin= g the safer variants with hashed public keys like P2PKH and P2WPKH spendabl= e. Most analyses of quantum algorithms I have read suggest that at least in= itially, they would take a significant amount of time to calculate a privat= e key even if the public key is known, which means that even if there were = a quantum breakthrough, there should be a relatively low chance of having f= unds intercepted between broadcasting it (which would of course reveal the = public key) and having it included in a block. Furthermore, there would alw= ays be the option of only revealing the transaction to a trusted miner rath= er than broadcasting it, foregoing the risk entirely. UTXOs with hashed public keys might still need to be disabled at some point= , seeing as a non-insignificant number of them have a revealed public key d= ue to address reuse, and that quantum computers might eventually reach the = point where the chance of breaking a private key after broadcasting but bef= ore block inclusion is non-insignificant, but this should at least alleviat= e the initial rush of disabling everything at once. -- Best, ArmchairCryptologist On Sunday, March 9th, 2025 at 1:53 AM, Agustin Cruz wrote: > Hi Michal, > > I completely understand your point of view. However, the concern with QRA= MP isn=E2=80=99t about arbitrarily punishing users or confiscating assets w= ithout reason. Rather, it=E2=80=99s about mitigating a very real, systemic = risk. If a significant amount of funds remains in legacy addresses and a qu= antum breakthrough occurs, the attack wouldn=E2=80=99t be a one-off inciden= t targeting a few unlucky individuals. Instead, it could compromise the sec= urity of the entire network, affecting countless users and shaking confiden= ce in Bitcoin as a whole. > > The enforcement aspect of QRAMP is intended as a last-resort safety mecha= nism after a long and well-communicated migration period. It=E2=80=99s desi= gned to ensure that by the time any quantum-capable adversary comes along, = almost everyone=E2=80=99s funds are protected by quantum-resistant cryptogr= aphy. The goal is to preempt a scenario where the vulnerability becomes so = widespread that a malicious actor could trigger a massive, destabilizing re= allocation of wealth. > > The enforced migration is less about penalizing users and more about pres= erving the long-term security and stability of the network for everyone. > > Best regards, > Agustin > > El s=C3=A1b, 8 de mar de 2025, 9:22=E2=80=AFp. m., Michal Koles=C3=A1r escribi=C3=B3: > >> Dear Agustin, >> >> enforcement in general doesn=E2=80=99t seem like a good choice to me. If= I were to compare it to the real world, it=E2=80=99s as if people had mone= y or jewelry in bank vaults that were unbreakable at the time they were sto= red. After a certain period, it=E2=80=99s discovered that these vaults coul= d be breached, and we=E2=80=99d tell everyone they have to buy new vaults a= nd move their diamonds, gold, and banknotes into them. If they don=E2=80=99= t do it, everything in their old vaults would be confiscated and destroyed.= Surely, it=E2=80=99s normal that people would naturally buy new vaults (or= move to safer ones) if they=E2=80=99re 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 o= f their "wealth." That=E2=80=99s how it works in the real world, after all.= Yes, perhaps if someone steals a large amount of Bitcoin en masse, it migh= t temporarily lower its value. But that=E2=80=99s fine=E2=80=94it would jus= t redistribute old, lost, or unused Bitcoins into new ownership, where some= one would start using them. It=E2=80=99s 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=E2=80=AFAM UTC+1 Agustin Cruz= wrote: >> >>> Dear Bitcoin Developers, >>> >>> I am writing to share my proposal for a new Bitcoin Improvement Proposa= l (BIP) titled Quantum-Resistant Address Migration Protocol (QRAMP). The go= al of this proposal is to safeguard Bitcoin against potential future quantu= m attacks by enforcing a mandatory migration period for funds held in legac= y Bitcoin addresses (secured by ECDSA) to quantum-resistant addresses. >>> >>> The proposal outlines: >>> >>> - Reducing Vulnerabilities: Transitioning funds to quantum-resistant sc= hemes preemptively to eliminate the risk posed by quantum attacks on expose= d public keys. >>> - Enforcing Timelines: A hard migration deadline that forces timely act= ion, 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 permane= ntly locked against the potential catastrophic impact of a quantum attack o= n Bitcoin=E2=80=99s 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, comprehens= ive security considerations, an extensive suite of test cases, and a refere= nce implementation plan that includes script interpreter changes, wallet so= ftware updates, and network monitoring tools. >>> >>> For your convenience, I have published the full proposal on my GitHub r= epository. You can review it at the following link: >>> >>> [Quantum-Resistant Address Migration Protocol (QRAMP) Proposal on GitHu= b](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 resilien= ce 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 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/bitcoind= ev/83e89408-a20c-4297-96eb-3ca353be02abn%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/bitcoinde= v/CAJDmzYxAv8ahPOoTVryqy6oE8nUX0%2B49BHHhO%3D%3DM1HpZCuMNbQ%40mail.gmail.co= m. --=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/= ExSOriyqgy0FlVg3j_ZU9jMNQo5rgPRp2mVlp50gJEAtEy79NgFVMBOxchgG2mi6OVJWNN5UM5o= XgrPrML_OAhT6v2-S1KVZ1oI14PjSEcw%3D%40protonmail.com. --b1=_9oou56Y5i9ixeKojLOHOoTPRTuF8aBwrw1m5flfNrhQ Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One major i= ssue with a mandatory transition to quantum-resistant addresses that I have= n't seen brought up is that block size is limited. In such a scenario, it c= ould be highly beneficial for parties that benefit from high fees to flood = the network with bogus transactions to force the fees arbitrarily high, sin= ce people would then be forced to either pay exorbitant fees to move their = funds by the deadline, or lose their funds entirely. As such, this does not= seem like a good idea in general, at least unless the transition period is= extremely long (say 10 years or more).

A less drastic proposal could be to (at le= ast initially) only disable spending from the less common outputs that have= no inherent quantum resistance by virtue of having a hashed public key, su= ch as P2PK and P2TR, while leaving the safer variants with hashed public ke= ys like P2PKH and P2WPKH spendable. Most analyses of quantum algorithms I have read suggest that at least=20 initially, they would take a significant amount of time to calculate a priv= ate key even if the public key is known, which means that even if there wer= e a quantum breakthrough, there should be a relatively low chance of having= funds intercepted between broadcasting it (which would of course reveal th= e public key) and having it included in a block. Furthermore, there would a= lways be the option of only revealing the transaction to a trusted miner ra= ther than broadcasting it, foregoing the risk entirely.

UTXOs with hashed = public keys might still need to be disabled at some point, seeing as a non-= insignificant number of them have a revealed public key due to address reus= e, and that quantum computers might eventually reach the point where the ch= ance of breaking a private key after broadcasting but before block inclusio= n is non-insignificant, but this should at least alleviate the initial rush= of disabling everything at once.

--
Best,
ArmchairCryptologist

On Sunday, March 9th, 2025 at 1:53 AM, Agustin Cruz <agustin.cru= z@gmail.com> wrote:

Hi Michal,

I completely understand your point of view. However, the con= cern with QRAMP isn=E2=80=99t about arbitrarily punishing users or confisca= ting assets without reason. Rather, it=E2=80=99s about mitigating a very re= al, systemic risk. If a significant amount of funds remains in legacy addre= sses and a quantum breakthrough occurs, the attack wouldn=E2=80=99t be a on= e-off incident targeting a few unlucky individuals. Instead, it could compr= omise the security of the entire network, affecting countless users and sha= king 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= =E2=80=99s designed to ensure that by the time any quantum-capable adversar= y comes along, almost everyone=E2=80=99s funds are protected by quantum-res= istant cryptography. The goal is to preempt a scenario where the vulnerabil= ity becomes so widespread that a malicious actor could trigger a massive, d= estabilizing reallocation of wealth.

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

Best regards,
Agustin


El s=C3=A1b, 8 de mar de 2025, 9:22=E2=80= =AFp. m., Michal Koles=C3=A1r <michal@zeleny-ctverec.cz> es= cribi=C3=B3:
Dear Agustin= ,

enforcement in general doesn=E2=80=99t= seem like a good choice to me. If I were to compare it to the real world, = it=E2=80=99s as if people had money or jewelry in bank vaults that were unb= reakable at the time they were stored. After a certain period, it=E2=80=99s= discovered that these vaults could be breached, and we=E2=80=99d tell ever= yone they have to buy new vaults and move their diamonds, gold, and banknot= es into them. If they don=E2=80=99t do it, everything in their old vaults w= ould be confiscated and destroyed. Surely, it=E2=80=99s normal that people = would naturally buy new vaults (or move to safer ones) if they=E2=80=99re i= nformed well in advance and loudly enough about the outdated vaults. And if= they decide not to replace them, someone will eventually break in sooner o= r later and become the new owner of their "wealth." That=E2=80=99s how it w= orks in the real world, after all. Yes, perhaps if someone steals a large a= mount of Bitcoin en masse, it might temporarily lower its value. But that= =E2=80=99s fine=E2=80=94it would just redistribute old, lost, or unused Bit= coins into new ownership, where someone would start using them. It=E2=80=99= s like finding a lost treasure from the past at the bottom of the ocean.

Best regards,
Michal
<= br>
On Wednesday, February 12, 2025 at 1:10:17=E2=80= =AFAM UTC+1 Agustin Cruz wrote:

Dear Bitcoin Developers,

I am wr= iting to share my proposal for a new Bitcoin Improvement Proposal (BIP) tit= led 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 eliminat= e the risk posed by quantum attacks on exposed public keys.
  • Enforcing Timelines: A hard migratio= n deadline that forces timely action, rather than relying on a gradual, vol= untary migration that might leave many users at risk.
  • Balancing Risks: Weighing the non-trivial ri= sk of funds being permanently locked against the potential catastrophic imp= act of a quantum attack on Bitcoin=E2=80=99s security.

Additionally, the proposal addresses common criticisms such as = the risk of permanent fund loss, uncertain quantum timelines, and the poten= tial for chain splits. It also details backwards compatibility measures, co= mprehensive security considerations, an extensive suite of test cases, and = a reference implementation plan that includes script interpreter changes, w= allet 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 suggest= ions and look forward to engaging in a constructive discussion on how best = to enhance the security and resilience of the Bitcoin network in the quantu= m computing era.

Thank you for your time and cons= ideration.

Best regards,

To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/83e89408-a20c-4297-96eb-3ca353be02abn%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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://= groups.google.com/d/msgid/bitcoindev/CAJDmzYxAv8ahPOoTVryqy6oE8nUX0%2B49BHH= hO%3D%3DM1HpZCuMNbQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= ExSOriyqgy0FlVg3j_ZU9jMNQo5rgPRp2mVlp50gJEAtEy79NgFVMBOxchgG2mi6OVJWNN5UM5o= XgrPrML_OAhT6v2-S1KVZ1oI14PjSEcw%3D%40protonmail.com.
--b1=_9oou56Y5i9ixeKojLOHOoTPRTuF8aBwrw1m5flfNrhQ--