From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Feb 2025 20:01:58 -0800 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ti3wj-0007DK-6N for bitcoindev@gnusha.org; Tue, 11 Feb 2025 20:01:58 -0800 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-5fc8f19db03sf1836451eaf.3 for ; Tue, 11 Feb 2025 20:01:57 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1739332911; cv=pass; d=google.com; s=arc-20240605; b=h9CYNcxPcqHHQuUSDB3krgLTkLL+trWEQat0e/usDNR3QbGcRm++5h0JNmzvSTNdmO vNvhKuvze/UrLNfHGGSm7Kx9QaO3zy8D3hz2ranqiFgCp7yTbpQ7BwbjEPzU6cKN/5Bi DkbwJaBKjF5t9/GdtCUcOwNNPIrwUua7IrmDSTNi75wG+BspJ6W1kq09GxndUqn2swfI vk4xfz++97OBE5d4N/E9CIKNv8WPPM69QYDL32rgfsvdpnNisCABfnLZTM1bHnCnQgRp tZEN9tQG/HuQbxnYY7/MfPRhfeVgB0SzaqS3lDYi83b8UdnaZzEj+A+I4zrdeRcz0Pcs GMfQ== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=DVSxOpViHzReHgjsdcnNHcNP60ZSTKzTvg/LrfCEOT4=; fh=1DvqswO+JmHnxNBNej/eg7pSf8cmruq24Sqb5V8pBNE=; b=I3RJWtyZLI7EwnX4tlXTsTBSMwOEwrlE/6oHuo2btX1jKp6Us+xFPTAn5ju3xsXeqz 5K3tYPF1ApSnfulN3MKIvlu/cDBiZXmm7vwc76gUOgaXA+ZpfoJolQNu6UYKaYnVJV8E eWpPFwHP4ugKGshwmxnAKMomjkRnyUuKF9IAZhAhC6VA7v8ZjHkLE8M9e8Gcgz8VIc8j xdty3udBOQoNmZJUpbGsy2PS2H3x++O02rh+WfQyslN2Sv4dBK6GfBeAI8/Xoxdbbf9I vU2sudUjQ+3hwTwguVAK9wEcG1LX2L37SB1dgVE9Pa/ZwBAaR95kfh82TtjJ01JDHkM0 k4/w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=X+rIqHys; spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1739332911; x=1739937711; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=DVSxOpViHzReHgjsdcnNHcNP60ZSTKzTvg/LrfCEOT4=; b=orypI6fVPoSgZxahqBpt3yPiSMwRq4utadE5flPDk+hIXZUI3pVnikoYRERqC07Y9S 1UWU2rBodkqRnKjQxnP5B4hirHu8V0ilBZNHnimxxBNbTHM+Twuj0Ro7lAox8GZDVqtY +VKJQ2/cvqqQFRYDBmHoYdmwrgCdDNx91qFMOpVmazX5+9D6kDTdcaErwwSkbqPZQblu ttQ4BX5unF6NaRCux+6PEhJSrm/UiLiYaEt1eu1GGO5dBhV9ysOgAqqjOuowR6Xiy6lm o8Sjj595JWuY78zMolF8m39yBQbVva6yBgMb2Qjnr7uHelsyG5N0jOXpiWd71RDYet4M NG0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739332911; x=1739937711; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DVSxOpViHzReHgjsdcnNHcNP60ZSTKzTvg/LrfCEOT4=; b=QkkRpiJeYdogbN0LM2U0GqwYu4R2/+RaQ1FF8PygXGRhENAsRS9orKhfafrwSIcC3f 6xuNow0lxXpKivSVSqLgFnRvPpBfLfRnZXXQsqCSme3jP00u86itJZ2Fj2LLpsLsMX88 6Ylm7g59WrI8rXvhH2SRdowDwBeoLiGA2cIEYUJ1zy5KHr8ksoLqyU42HVISkQlmvxdm /mcAMbm/7bWNt3x7mMhPdsT1OJl0s25i7pxP3pITlSK6g59KfNQl94xWq1A3Cx6Gzfiy OxwpTiVy0+rKlOF20AkefQyxsR5mDciLkoPQKan9umVB3T9XM4MBwRFPGIVtRApkc+Mc 5E7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739332911; x=1739937711; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=DVSxOpViHzReHgjsdcnNHcNP60ZSTKzTvg/LrfCEOT4=; b=cdTWNtIWguW3BiBLR2bkonBxCVf8pjPnTpRZO+iFYEn4OW86RhhZ2U6tsa+rYvkd6i AYE7OIiz+vSOSOaDWDoL2wtgyF5KX/rXlqeF1p9u93gnw4s2TYuzIAkzBGWUbr3D1iIh 4Mdimj9tGRqkVrsfj22jf63SnCLROrGCYxAYHe8deHADaa+W0vYcRMBRJVmq1sxU4luR LCOZ427IGt3evnLe+sozrhJjwzLGv/vOK9JtWUOo55NrAJcp4M6xSRhXc6HPY5AhOPY+ GVXhd/XOA+IXW1bj74TePam1XKoVaT5PQf/sifKVBdzyOieAkM0U2+Yz3TYuxyVS2uGy U3AA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCViec6RvI18V7s3f1qsNTHSptCIsFCscWpprHjJ7bQkVIghgWgPZhwAgJHBoo6Y6gJs59f3S9J3pThf@gnusha.org X-Gm-Message-State: AOJu0YwCDFLWsKlW8vpqbifNtqTBb8DH2HXwLY/Q0c9ITZ+8Cybb28Vw 6UCLMFS65EcfKU8AF931z6UabhCmz1f02knnlaQ01X+aZWDc5ITJ X-Google-Smtp-Source: AGHT+IEONu4YBRmH/tKovvMsixpwqACuJhupTqb51ubG5qV0c5PaxItWTOMlfRCBDdbvHiaQDlW2NQ== X-Received: by 2002:a4a:ec49:0:b0:5fc:9cac:1cde with SMTP id 006d021491bc7-5fca18ce4cbmr1195486eaf.5.1739332911183; Tue, 11 Feb 2025 20:01:51 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6820:386:b0:5f2:bbe7:601c with SMTP id 006d021491bc7-5fca1561bc0ls283992eaf.1.-pod-prod-07-us; Tue, 11 Feb 2025 20:01:48 -0800 (PST) X-Received: by 2002:a05:6830:710e:b0:71d:548d:6f76 with SMTP id 46e09a7af769-726f1d18e93mr1442669a34.26.1739332908529; Tue, 11 Feb 2025 20:01:48 -0800 (PST) Received: by 2002:a7b:c84c:0:b0:434:e632:79d with SMTP id 5b1f17b1804b1-43924b20d7ems5e9; Tue, 11 Feb 2025 16:54:24 -0800 (PST) X-Received: by 2002:a05:6000:1849:b0:38d:de38:746d with SMTP id ffacd0b85a97d-38dea2e188amr647997f8f.47.1739321662454; Tue, 11 Feb 2025 16:54:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1739321662; cv=none; d=google.com; s=arc-20240605; b=kooSSiaFPSDOZIDEt93KnohlB4JmMQ3edhy8oBnX0EanS08V1BzB+iWEfqZ0UZwHmw qcIhUzkDZbY+F9nDb7lKHOj2PICnBuwSqBWRo7XQgzQVotozLLLaMOA8UyVmeZDkdqys wiTTpBpYKjw/WfzWkbxJFoGMiFWyHzkmWGd5xjRztW7TH96bMMKyoA1GE2IEocOeb+Ef Auye0qpIcgOwj7XWWNn4AA9/tPBUiZY7Sy4UtidS+JN8eRqDsTbRrMk+GdfN/boOeG1/ f86PsVi65UY/38IPkF5kBu4YUVG50F/tcJCS8eW3SfH6GyySbj8o+y/5He97HE10Pzge 58hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=QfBYqOBzQNhTf1ehpeHaOCZ/j5erB+GngOhmZz1/2E4=; fh=vv17kuNL91X1Cp9SmfPjoxURvR5MiP2YavjpHHGsCzI=; b=XAAslfchV/pZBDsO3PlDFoQva7ha++3P9AIywe9sH35KwVG5IB0BKmSwDRVW9O7vNz u6NK6nX3hlWZGIFw8jsQ9rbWCPHYtujdVZbfSm2s9lSaafm7b0Hk64p1dGR06HIxUZ6m 2cH9m4Dtjo7/cVfA9DT9EmXqxSoDvBuIz5jfWtpILKDqKeb3If4pTrMCYeRYxnTG6j2Y ODsRsERAqVWMKZPZEJ5tss268lDcNySJgVjRVhUxevy2GIwtGkktpfYzHnb7cwcUlvDJ 56QlJ4sewrCLAgrsHTGWtEmDXXlVJq+Wn7H9nJ67Ut9V+vcQottVqaeVC1TlgVO/9MSg OCGQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=X+rIqHys; spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com. [2a00:1450:4864:20::22c]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4394f79df0bsi1411755e9.1.2025.02.11.16.54.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Feb 2025 16:54:22 -0800 (PST) Received-SPF: pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) client-ip=2a00:1450:4864:20::22c; Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-308ef06b4e1so24588461fa.0 for ; Tue, 11 Feb 2025 16:54:22 -0800 (PST) X-Gm-Gg: ASbGnctN0qJD76tmHWF0zF6rymJnkEin35ChU7Bpc7NzjWgmLw7iFv7WrUhvAZ7OXLG QmmxCcMtUukvdd+CPdtDPTtN/jXLln8kMEr2DClSDkgOEDoWPatu4j/nz5rBEJ93vzlZurhmntA == X-Received: by 2002:a05:651c:2104:b0:308:eabd:298a with SMTP id 38308e7fff4ca-30903669271mr4963211fa.15.1739321661201; Tue, 11 Feb 2025 16:54:21 -0800 (PST) MIME-Version: 1.0 References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com> In-Reply-To: From: Agustin Cruz Date: Tue, 11 Feb 2025 21:54:09 -0300 X-Gm-Features: AWEUYZlQdYUiCXYvgP808g6uylFOQc-Gg9h_zsVouSkE5XA6ln1OY1QJdbWFYP0 Message-ID: Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP To: Dustin Ray Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000c42786062de7619a" X-Original-Sender: agustin.cruz@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=X+rIqHys; spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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: -0.5 (/) --000000000000c42786062de7619a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dustin: I understand that the proposal is an extraordinary ask=E2=80=94it would ind= eed 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=E2=80=99t solely about funds in active wallets. Consider th= at if we don=E2=80=99t implement a proactive migration, any Bitcoin in lost wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99s if he is not a= live=E2=80=94will 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=E2=80=94assuming 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=E2=80=AFp. m., Dustin Ray < dustinvonsandwich@gmail.com> escribi=C3=B3: > 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=E2=80=AFPM Agustin Cruz > wrote: > > > > Hi Dustin > > > > To clarify, the intent behind making legacy funds unspendable after a > certain block height is indeed a hard security measure=E2=80=94designed t= o 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 an= d > service providers to transition. > > > > > > El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray < > dustinvonsandwich@gmail.com> escribi=C3=B3: > >> > >> 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 caus= e > serious financial damage to anyone holding legacy funds, if I understand > your proposal correctly. > >> > >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM 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 futur= e > quantum attacks by enforcing a mandatory migration period for funds held = in > legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addresse= s. > >>> > >>> 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=E2=80=99s security. > >>> > >>> Additionally, the proposal addresses common criticisms such as the > risk of permanent fund loss, uncertain quantum timelines, and the potenti= al > 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 GitH= ub > >>> > >>> 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, sen= d > an email to bitcoindev+unsubscribe@googlegroups.com. > >>> To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5b= de8598e7n%40googlegroups.com > . > --=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/= CAJDmzYzUAzoCj3da-3M_ast0_%2BQxf3_J1OXWf88B2D-R70pPrg%40mail.gmail.com. --000000000000c42786062de7619a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Dustin:

I understand that the proposal is an extraordinary ask=E2=80= =94it would indeed void a non-trivial part of the coin supply if users do n= ot migrate in time, and under normal circumstances, many would argue that u= nused P2PKH funds are safe from a quantum adversary. However, the intent he= re is to be proactive rather than reactive.

The concern isn=E2=80=99t solely about funds in active walle= ts. Consider that if we don=E2=80=99t implement a proactive migration, any = Bitcoin in lost wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99= s if he is not alive=E2=80=94will remain vulnerable. In the event of a quan= tum breakthrough, those coins could be hacked and put back into circulation= . Such an outcome would not only disrupt the balance of supply but could al= so 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 quant= um attack scenario might be more acceptable (since funds would likely be co= nsidered lost anyway), waiting until such an emergency arises leaves us wit= h little margin for error. By enforcing a migration now, we create a window= for the entire community to transition safely=E2=80=94assuming we set the = deadline generously and provide ample notifications, auto-migration tools, = and, if necessary, emergency extensions.


El mar, 1= 1 de feb de 2025, 9:48=E2=80=AFp.=C2=A0m., Dustin Ray <dustinvonsandwich@gmail.com> escribi= =C3=B3:
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=E2=80=AFPM Agustin Cruz <agustin.cruz@g= mail.com> wrote:
>
> Hi Dustin
>
> To clarify, the intent behind making legacy funds unspendable after a = certain block height is indeed a hard security measure=E2=80=94designed to = mitigate the potentially catastrophic risk posed by quantum attacks on ECDS= A. The idea is to force a proactive migration of funds to quantum-resistant= addresses before quantum computers become capable of compromising the curr= ent cryptography.
>
> The migration window is intended to be sufficiently long (determined b= y both block height and community input) to provide ample time for users an= d service providers to transition.
>
>
> El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray <dustinvonsandwich@gmail.com> escribi=C3=B3:
>>
>> Right off the bat I notice you are proposing that legacy funds bec= ome unspendable after a certain block height which immediately raises serio= us problems. A migration to quantum hard addresses in this manner would cau= se serious financial damage to anyone holding legacy funds, if I understand= your proposal correctly.
>>
>> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <agu= stin.cruz@gmail.com> wrote:
>>>
>>> Dear Bitcoin Developers,
>>>
>>> I am writing to share my proposal for a new Bitcoin Improvemen= t Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QRAMP= ). The goal of this proposal is to safeguard Bitcoin against potential futu= re quantum attacks by enforcing a mandatory migration period for funds held= in legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addres= ses.
>>>
>>> The proposal outlines:
>>>
>>> Reducing Vulnerabilities: Transitioning funds to quantum-resis= tant schemes preemptively to eliminate the risk posed by quantum attacks on= exposed public keys.
>>> Enforcing Timelines: A hard migration deadline that forces tim= ely action, rather than relying on a gradual, voluntary migration that migh= t 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 a= ttack 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 pote= ntial for chain splits. It also details backwards compatibility measures, c= omprehensive 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 en= gaging 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 Go= ogle Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from = it, send an email to bitcoindev+unsubscribe@googlegr= oups.com.
>>> To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde8598e7n%40googlegrou= ps.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/CAJDmzYzUAzoCj3da-3M_ast0_%2BQxf3_J1OXWf88B2D-R70pPrg%40ma= il.gmail.com.
--000000000000c42786062de7619a--