path: root/d2/9b4f2f4f3c7ffe3764075637204881f49646c8

Delivery-date: Wed, 19 Feb 2025 13:55:11 -0800
Received: from mail-oa1-f60.google.com ([209.85.160.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCQ6XM4A6IDBBNNG3G6QMGQE3DPRC5A@googlegroups.com>)
	id 1tks29-0001aN-J7
	for bitcoindev@gnusha.org; Wed, 19 Feb 2025 13:55:11 -0800
Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-2bc63274bd5sf370792fac.1
        for <bitcoindev@gnusha.org>; Wed, 19 Feb 2025 13:55:09 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1740002104; cv=pass;
        d=google.com; s=arc-20240605;
        b=ltf/OEKbEKSMgXxyW5ZCPiDyl1wGH8YqKTOT+06SHPPIoW7YPXmmS2xR34DxCIN8WN
         XYAXmV6/gL/+J3z4DlCXZBKxJAdce/3vKNqyzo8q79fgWn+9w98R1ogLz/rpA1vQIZk/
         amktGTH7VEjvvez4RVE+hS49Hoe8/0+iK17iORvm2zpdxtny0u9BIoBOXZ6KDymBKXm3
         TlZ+1InKSexB0jABGGaPNfrezosdlZExq7AHgcJTKWn3ZgNYOkkz0ZH4mFnFlNlgtIqq
         q+/qV72OpfpJYFQjjbQc63FYuv5jkRzd0ys3atOAscrdjejQcPT1pqmuHyCXenBtYCL4
         k+RQ==
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=SU7hth8lhe6ze+a9zI7U72koIXtZP8E/9pZot97vLeI=;
        fh=r6rnbgDDkyoDdhRgSm2bKLq+QBOjrARPppjU9S1TuCs=;
        b=Jo2t9zx5gygFHvAwdxBNVXm7YZ47Xkkqmk3cIamElaPAlabA5IvfNNLfDkrb5ylCR2
         CPrgeV3AstZlOzWtDr3cGWGFVqrol7icnHJ+gLWV4pQkVwNl1DspWvIC2w8CQyMSni7T
         /C4kJ2r3MJIAa1buTlM9GV390JTVrOtdceoAlSjYfstEU+ZWcN20ULCsfSXimpHf5pIB
         2W31a8SkK7ixC91vU0cVBb1y0B8g7dyNsr7b09bCW8yCn0lxxS9GKVGXyiF5DkZPZCOA
         dKEf/PRGerltBoRmrMKdneasKCW9rttKUKNyFuPXcuv9kVNTYzvWl+XATpeU3KVqHov1
         XC7g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=C7bQLuX5;
       spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::234 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=1740002104; x=1740606904; 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=SU7hth8lhe6ze+a9zI7U72koIXtZP8E/9pZot97vLeI=;
        b=rVVL9qefwQQ9aA4u3Yvy5S0tMZFxFVGlHudobwOiGOhOWgR9GMIvJ3bJLq/SegWySr
         yrF8uZK/PDwwGhQt4cxySbSn2F6hX8oDHUOYuo37+o0N/NvPI5KOVjkBRn97c24+Ippq
         557diurDoWJ8RyAqt1e//p1+RkpBp3visPMUP18LkXOrw5Qi13LsCK2kC940FILc2rHt
         DuKCEC48TfuJRkSi23YdOubJW+5B667JtCgJJCu0eHpcef6uzTkrt99CJ0hFccdd2APl
         +MyGGYpAWI2XtrssazcnOkBNzgzgqxMYNuZySGSSmj7DWigfIPC4cxBqTwMR9KBkOmH6
         OehA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1740002104; x=1740606904; 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=SU7hth8lhe6ze+a9zI7U72koIXtZP8E/9pZot97vLeI=;
        b=i8x9+4tK/QzgbgS+kfFWfV9eJVjgIlL4jzpzo3gkTM2IUzcSmOYIrJkZ49cdd8x+/d
         vBSbWUymJoysKaXs1kxOu+i5NGUvclKi6z9NQnRekzcgitMzh8IDQ8joarcqgWJa2+aD
         VYVcvY3fs8d0yiwmMuw0i8VE7PdFAoW/TCEkOdzSTjFlOa3pw/FIwe8QBeEqKwdlJYfI
         QmZqjldY6aFMGMCjyPSxN1o3xDNAfpDPwivnIhkOqhS+idM6KyxWIdtWqNpmBoE1AcEf
         zUv7ZO0IFLhbGbTF0BIMEZfveGlzIxgfl32dZAm8BIixFnEUsdSx0g4oYUbm1FS7/Gf5
         H2dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740002104; x=1740606904;
        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=SU7hth8lhe6ze+a9zI7U72koIXtZP8E/9pZot97vLeI=;
        b=OPG+2AmgpEt5QM9vRruYavLAEBuapPN5wZ3nQBiaDbzwxdLEz9Rw65Mq1lmmfEqxFL
         ZWEjeWHTmJ1NQAEaPYUnYOI3WwjfTs/yr0MO/WarZ4FdfKinMg9dnUJx7Z2ffxwxHALA
         y2t5xd/Tz0ThSJmQ2wCKsO9Pjqh/lvjTE1mnH8lrK8YLSLHUzPdds1gHkHKPUgVagI3G
         2xEtfTbjZ+VvEH8U9e2w0JADnOcsrXyjk+iB70kpyMzN+RPpej+0QIsOycspLLn0VMKl
         rMYiXSEtdNleggKP4uD4wUp6ueeJxPzWL80wtcDvnCxWBQUpbqz74flU8B+Vi7B9P01H
         jnQg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUJ7V/q+ujf+eXAQ30w1MUXTFansexB9q8UFtra+1Zo92RF3YIBzVv1bp7Wjli1paSeydNfFLtVJUaI@gnusha.org
X-Gm-Message-State: AOJu0YzV9HuretsvFa/QbFkjYiF0qycT1GC9W25mPK3p30edpBc2t6L/
	tAmSVbXFDi1GUbaFXvVq83JY3nClJ6g2ANUISFTXaNSdCOQIgqKI
X-Google-Smtp-Source: AGHT+IF3gMHD6fhCvbbsKo1P6n72O+VM/hdpOBUVOVC+CYNFUoAXLh7258k4c3/L0NMDQxofckhPfw==
X-Received: by 2002:a05:6870:ebcb:b0:296:5928:7a42 with SMTP id 586e51a60fabf-2bc99b5d687mr12205238fac.22.1740002103905;
        Wed, 19 Feb 2025 13:55:03 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVHkun6FZvA8VBKEVytXrsqmx1bJA9W6MXDkdjgFGMqvQA==
Received: by 2002:a05:6871:6a1:b0:2b8:a567:be4 with SMTP id
 586e51a60fabf-2bd353a13e8ls23434fac.2.-pod-prod-01-us; Wed, 19 Feb 2025
 13:55:01 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCXDjyuVvAPb+c299hSV00TzX/bPYsOdPtMHc7Dv2TOp6Qo1AjMmCcDwB+e7sNrafrO64GEkUwvR+0Pe@googlegroups.com
X-Received: by 2002:a05:6808:80c6:b0:3f4:b29:2407 with SMTP id 5614622812f47-3f41b8e362bmr47837b6e.17.1740002101506;
        Wed, 19 Feb 2025 13:55:01 -0800 (PST)
Received: by 2002:ab3:5b13:0:b0:290:34b3:7e37 with SMTP id a1c4a302cd1d6-29034b37fefmsc7a;
        Wed, 19 Feb 2025 13:50:14 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCU2IaKcVFoHtRTU6w7EN1iqfXWBYpH1jFtZzfnbt4eCITJZ6oCfDNdTUtx7hcGGH3n8gZ9uXb9ciQlm@googlegroups.com
X-Received: by 2002:a2e:380f:0:b0:308:ffa1:890b with SMTP id 38308e7fff4ca-30927a429e1mr58541351fa.2.1740001812621;
        Wed, 19 Feb 2025 13:50:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1740001812; cv=none;
        d=google.com; s=arc-20240605;
        b=is+Kp2u58MFuB2GQTCn/LHWZjAHR6+1L9zfKIwhra/ujEToArWwPnSFvMsZ62fvL9e
         JPQGUmj504GJP3r1ua6fHaycfx9H/kAJb6MbLBxicmw8o84ivao98xE29kdPoMWszn4Y
         +P7QhOKYe8M/C5v0GUOAdE2AStrNOzCMRgulkZPuRHy/vtwdApCgHtUMGUY2IHthvj8U
         MAxia4ghOFSr/Fc/+TzXm/zxV98MyrD7DvtMxVChf+FnavAsqQKfragLBAs0Y8lmYjCD
         1upNZYfjTj0WVVtqT0HHTir814B+qicKOTVcT1P5wxXT7+KQtEg/rqyCLXvRGyuvPgVf
         pc6g==
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=JbHICjOTLALWS3bwM6JW+XU6tFQfooiTWxIHxcHFotU=;
        fh=hlmXNDwT5/KGG2qsIw/HUx3yJtV57K/4g1OuF82q3U4=;
        b=XNu5S51xDEkXACr/p5BnH5hzFQeSr7nox9KW3Br5h4/bGPrwyTua2VIT2H9PMJXxmn
         nz4FsTj/LL16XvY0dzp7F95+LJs8VmgwozGEZmKogXKyX0BnwBiJjUxCU92QTXwon0WV
         ECYW2Oc+kLnuHAS7j4ZKzGTM0YfPsMxQrtgNohWB8zfJeLJNxDo+G5Zfnx0VZbZJWzFd
         K75m0ZyP88gCzZVvCG+lsBocv8AQsagh1jiGKsk3OIeyngzYmEXJIgKYDcwHNq1EqJRd
         53C3qceHIP63AehA7Yc0qhKgqT/cEyYJFN1QkiUCpQKM0JcjDQ/ZthJL6Oqh5zhltx61
         TLVg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=C7bQLuX5;
       spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::234 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-x234.google.com (mail-lj1-x234.google.com. [2a00:1450:4864:20::234])
        by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-309101f98fdsi3418871fa.5.2025.02.19.13.50.12
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 19 Feb 2025 13:50:12 -0800 (PST)
Received-SPF: pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::234 as permitted sender) client-ip=2a00:1450:4864:20::234;
Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-30918c29da2so2497461fa.0
        for <bitcoindev@googlegroups.com>; Wed, 19 Feb 2025 13:50:12 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCWE5OSNBtygrYXpaRb9OAlskzhmT2Uwqc0yEzovbMk6v2PhHguXohkwrJIjPTJl6p8/Wy9dvKg18fih@googlegroups.com
X-Gm-Gg: ASbGncvNEGOcAJyIoYrY+ESGRAKZRMp/3xHR7yryOAdfZDc0bCruyfaIR7CNIQgkHMq
	1BIEnOE5amGhs900xX3MaYIETCJ78Ue5sac+2gHUXykdgPuEPEtn6KaP+FiQrDzu5sulafT0n
X-Received: by 2002:a2e:b608:0:b0:309:1ec5:fcbe with SMTP id
 38308e7fff4ca-30927a704b4mr64509101fa.22.1740001811907; Wed, 19 Feb 2025
 13:50:11 -0800 (PST)
MIME-Version: 1.0
References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com>
 <CAC3UE4+kme2N6D_Xx8+VaH1BJnkVEfntPmnLQzaqTQfK4D5QhQ@mail.gmail.com>
 <CAJDmzYxJzFs=myecyMS6iJwSni1sDwUVq3kMnNGg=dK5kULRJg@mail.gmail.com>
 <CAC3UE4K=T8BmOeLW9s=x+TBauK+M5Z3MaSicD42+rOj_jZ2Ugw@mail.gmail.com>
 <CAJDmzYzUAzoCj3da-3M_ast0_+Qxf3_J1OXWf88B2D-R70pPrg@mail.gmail.com>
 <f9e233e0-9d87-4e71-9a9f-3310ea242194n@googlegroups.com> <CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com>
 <CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ@mail.gmail.com>
 <CAJDmzYzvYkm8At6yMrn+mAXnXbk=-R36SL5WneaDT9-Y-d=11w@mail.gmail.com> <CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ@mail.gmail.com>
In-Reply-To: <CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ@mail.gmail.com>
From: Agustin Cruz <agustin.cruz@gmail.com>
Date: Wed, 19 Feb 2025 18:49:39 -0300
X-Gm-Features: AWEUYZlqdjI5AlKj8ZZel2oduowHcqvu2royGg8HQ6tLFmrJ0kgJOLW0Go3rwnk
Message-ID: <CAJDmzYzPGz9Xd=kdaGkkL+r1zh5y1cBHNh7SQXJEzg7YUX--PA@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration
 Protocol (QRAMP) BIP
To: Dustin Ray <dustinvonsandwich@gmail.com>
Cc: Hunter Beast <hunter@surmount.systems>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000e855c5062e85bdd8"
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=C7bQLuX5;       spf=pass
 (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::234
 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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--000000000000e855c5062e85bdd8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dustin,

My proposal is not about locking down or confiscating funds. It is about
ensuring that vulnerable pre-P2PKH funds are migrated to quantum-safe
addresses before any quantum adversary can exploit them. Even though P2PKH
addresses are secured by hashes that are currently considered safe, relying
solely on that safety may leave us exposed in the future, especially as
quantum capabilities continue to evolve. Without a forced migration, we
risk leaving a significant portion of the coin supply vulnerable. Consider
the possibility that if we don=E2=80=99t act, any Bitcoin in lost wallets c=
ould
eventually be hacked and put back into circulation. Such a scenario would
be catastrophic for the network.

I believe that by enforcing a deadline for migration, we provide rightful
owners with a clear, non-negotiable opportunity to secure their funds. This
approach is not merely hypothetical. It is a proactive measure that
addresses the imminent risk of quantum attacks. While turnstile mechanisms
have been considered and might have merit under certain conditions, I
remain committed to the idea that a forced migration, with sufficient
notice and robust safeguards, is both realistic and necessary to protect
the long-term security of Bitcoin.

On Wed, Feb 19, 2025 at 6:35=E2=80=AFPM Dustin Ray <dustinvonsandwich@gmail=
.com>
wrote:

> To be clear, the turnstile approach is definitely a forced migration. It
> just means that instead of permanently confiscating funds and removing th=
em
> from circulation, you force the rightful owners of those funds to move th=
em
> into quantum safe addresses, assuming the existence of a hypothetical
> turnstile mechanism. There's too many hypotheticals with this idea right
> now to give it any more than a cursory glance, but turnstiles have been
> built before and could potentially be built again in this scenario.
>
> For further clarification, I'm suggesting that we enforce migration of
> unspent funds in p2pkh addresses because they are already secured by hash=
es
> which are currently conjectured to remain safe against a quantum adversar=
y.
> Pre-p2pkh addresses are probably the most vulnerable but few of these had
> seen use comparatively and may require confiscation.
>
> If your idea is to simply lock down and confiscate any pre-pq safe funds,
> I resolutely disagree with that decision and I am fairly confident that
> consensus will fail to materialize around that. What I'm suggesting howev=
er
> is that your idea is realistic and sound if we assume the existence of so=
me
> mechanism that allows rightful owners of pre-pq funds the opportunity to =
do
> nothing except migrate to safe addresses which then resolves the issue.
>
> On Wed, Feb 19, 2025 at 1:07=E2=80=AFPM Agustin Cruz <agustin.cruz@gmail.=
com>
> wrote:
>
>> Hi Dustin,
>>
>> I remain convinced that a forced migration mechanism=E2=80=94with a clea=
r block
>> height deadline after which quantum-unsafe funds become unspendable=E2=
=80=94is the
>> more robust and secure approach. Here=E2=80=99s why:
>>
>> A forced migration approach is unambiguous. By establishing a definitive
>> deadline, we eliminate the need for an additional transitional transacti=
on
>> type, thereby reducing complexity and potential attack vectors. Addition=
al
>> complexity could inadvertently open up new vulnerabilities that a more
>> straightforward deadline avoids.
>>
>> If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost
>> wallets=E2=80=94including coins in addresses that no longer have active =
private key
>> management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventual=
ly be compromised
>> by quantum adversaries. If these coins were hacked and put back into
>> circulation, the resulting market shock would be catastrophic. The force=
d
>> migration mechanism is designed to preempt such a scenario by ensuring t=
hat
>> only quantum-safe funds can be spent once the deadline is reached.
>>
>> El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp. m., Dustin Ray <
>> dustinvonsandwich@gmail.com> escribi=C3=B3:
>>
>>> It's worth considering a hypothetical but as of yet unknown middle
>>> ground solution, again nothing like this exists currently but conceptua=
lly
>>> it would be interesting to explore:
>>>
>>> 1. At some block height deemed appropriate, modify consensus so that an=
y
>>> pre-quantum unspent funds are restricted from being spent as normal.
>>>
>>> 2. Develop a new transaction type whose sole purpose is to migrate fund=
s
>>> from a quantum unsafe address to a safe one.
>>>
>>> 3. This new transaction type is a quantum safe digital signature, but
>>> here's the hypothetical: It is satisfied by developing a mechanism by w=
hich
>>> a private key from a quantum-unsafe scheme can be repurposed as a priva=
te
>>> key for a pq-safe scheme. It may also be possible that since we know th=
e
>>> hash of the public key, perhaps we can invent some mechanism whereby a
>>> quantum safe signature is created from an ecdsa private key that direct=
ly
>>> implies knowledge of a secret key that derived the known public key.
>>>
>>> In this way, we create a kind of turnstile that can safely transition
>>> funds from unsafe addresses into safe ones. Such turnstiles have been u=
sed
>>> in blockchains before, a notable example is in the zcash network as par=
t of
>>> an audit of shielded funds.
>>>
>>> There are likely hidden complexities in this idea that may cause it to
>>> be completely unworkable, but a theoretical transition mechanism both
>>> prevents a heavy handed confiscation of funds and also prevents funds f=
rom
>>> being stolen and injected back into the supply under illegitimate prete=
nses.
>>>
>>> This only works for p2pkh, anything prior to this is immediately
>>> vulnerable to key inversion, but Satoshi owns most of those coins as fa=
r as
>>> we know, so confiscating them might not be as controversial.
>>>
>>> I'm typing this on my phone so sorry for the lack of detailed
>>> references. I think the core idea is clear though.
>>>
>>> On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cruz <agustin.cruz@gma=
il.com>
>>> wrote:
>>>
>>>> Hi Hunter,
>>>>
>>>> I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. Your=
 point
>>>> about not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those =
with quantum
>>>> capabilities to free them up is certainly a valid one, and I understan=
d the
>>>> argument that any inflationary impact could be transitory.
>>>>
>>>> From my viewpoint, allowing quantum-capable adversaries to reintroduce
>>>> dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) could h=
ave
>>>> unintended consequences that go beyond transient inflation. It could
>>>> fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disrup=
t economic
>>>> assumptions built around the current distribution of coins. While some
>>>> might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their s=
udden reappearance
>>>> could cause lasting market shocks and undermine confidence. The goal o=
f a
>>>> proactive migration is to close the door on such a scenario before it
>>>> becomes imminent.
>>>>
>>>> I agree that Q-day won=E2=80=99t necessarily be a single, catastrophic=
 moment.
>>>> It will likely be gradual and subtle, giving the network some time to
>>>> adapt. That said, one challenge is ensuring we don=E2=80=99t find ours=
elves in an
>>>> emergency scramble the moment a capable quantum machine appears. A for=
ced
>>>> or proactive migration is an admittedly strong measure, but it attempt=
s to
>>>> address the scenario where a slow, creeping capability becomes a sudde=
n
>>>> attack vector once it matures. In that sense, =E2=80=9Crushing=E2=80=
=9D isn=E2=80=99t ideal, but
>>>> neither is waiting until the threat is undeniably present.
>>>>
>>>> El mi=C3=A9, 19 de feb de 2025, 1:31=E2=80=AFp. m., Hunter Beast
>>>> <hunter@surmount.systems> escribi=C3=B3:
>>>>
>>>>> I don't see why old coins should be confiscated. The better option is
>>>>> to let those with quantum computers free up old coins. While this mig=
ht
>>>>> have an inflationary impact on bitcoin's price, to use a turn of phra=
se,
>>>>> the inflation is transitory. Those with low time preference should su=
pport
>>>>> returning lost coins to circulation.
>>>>>
>>>>> Also, I don't see the urgency, considering the majority of coins are
>>>>> in either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signatures
>>>>> aren't added, such as with BIP-360, there will be some concern around=
 long
>>>>> exposure attacks on P2TR coins. For large amounts, it would be smart =
to
>>>>> modify wallets to support broadcasting transactions to private mempoo=
l
>>>>> services such as Slipstream, to mitigate short exposure attacks. Thos=
e will
>>>>> also be rarer early on since a CRQC capable of a long exposure attack=
 is
>>>>> much simpler than one capable of pulling off a short exposure attack
>>>>> against a transaction in the mempool.
>>>>>
>>>>> Bitcoin's Q-day likely won't be sudden and obvious. It will also take
>>>>> time to coordinate a soft fork activation. This shouldn't be rushed.
>>>>>
>>>>> In the interest of transparency, it's worth mentioning that I'm
>>>>> working on a BIP-360 implementation for Anduro. Both Anduro and Slips=
tream
>>>>> are MARA services.
>>>>>
>>>>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cru=
z wrote:
>>>>>
>>>>>> Hi Dustin:
>>>>>>
>>>>>> I understand that the proposal is an extraordinary ask=E2=80=94it wo=
uld
>>>>>> indeed void a non-trivial part of the coin supply if users do not mi=
grate
>>>>>> in time, and under normal circumstances, many would argue that unuse=
d 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. Cons=
ider that
>>>>>> 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 i=
s not alive=E2=80=94will remain
>>>>>> vulnerable. In the event of a quantum breakthrough, those coins coul=
d 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 conseque=
nces of
>>>>>> a reactive measure in a quantum emergency could be far more catastro=
phic.
>>>>>>
>>>>>> While I agree that a forced migration during an active quantum attac=
k
>>>>>> scenario might be more acceptable (since funds would likely be consi=
dered
>>>>>> lost anyway), waiting until such an emergency arises leaves us with =
little
>>>>>> margin for error. By enforcing a migration now, we create a window f=
or the
>>>>>> entire community to transition safely=E2=80=94assuming we set the de=
adline
>>>>>> generously and provide ample notifications, auto-migration tools, an=
d, if
>>>>>> necessary, emergency extensions.
>>>>>>
>>>>>> El mar, 11 de feb de 2025, 9:48=E2=80=AFp. m., Dustin Ray <
>>>>>> dustinvo...@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 coi=
n
>>>>>>> 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 los=
t
>>>>>>> anyways. In any other scenario prior to this hypothetical emergency
>>>>>>> however, I have serious doubts that the community is going to conse=
nt
>>>>>>> to this proposal as it stands.
>>>>>>>
>>>>>>> On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz <agusti...@gma=
il.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
>>>>>>> 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 am=
ple time
>>>>>>> for users and service providers to transition.
>>>>>>> >
>>>>>>> >
>>>>>>> > El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray <
>>>>>>> dustinvo...@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 r=
aises
>>>>>>> serious problems. A migration to quantum hard addresses in this man=
ner
>>>>>>> would cause 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 <agusti...@=
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 ad=
dresses.
>>>>>>> >>>
>>>>>>> >>> 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 migratio=
n 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 q=
uantum
>>>>>>> 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 t=
he
>>>>>>> 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 int=
erpreter
>>>>>>> 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 o=
n
>>>>>>> GitHub
>>>>>>> >>>
>>>>>>> >>> I welcome your feedback and suggestions and look forward to
>>>>>>> engaging in a constructive discussion on how best to enhance the se=
curity
>>>>>>> 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+...@googlegroups.com.
>>>>>>> >>> To view this discussion visit
>>>>>>> https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-830=
3-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, sen=
d
>>>>> an email to bitcoindev+unsubscribe@googlegroups.com.
>>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-=
3310ea242194n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f=
-3310ea242194n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>> --
>>>> 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/CAJDmzYz%3D52MGGLE0ZWm5tm=
fLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5t=
mfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com?utm_medium=3Demail&utm_sourc=
e=3Dfooter>
>>>> .
>>>>
>>>

--=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/=
CAJDmzYzPGz9Xd%3DkdaGkkL%2Br1zh5y1cBHNh7SQXJEzg7YUX--PA%40mail.gmail.com.

--000000000000e855c5062e85bdd8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dustin,</div><br>My proposal is not about locking =
down or confiscating funds. It is about ensuring that vulnerable pre-P2PKH =
funds are migrated to quantum-safe addresses before any quantum adversary c=
an exploit them. Even though P2PKH addresses are secured by hashes that are=
 currently considered safe, relying solely on that safety may leave us expo=
sed in the future, especially as quantum capabilities continue to evolve. W=
ithout a forced migration, we risk leaving a significant portion of the coi=
n supply vulnerable. Consider the possibility that if we don=E2=80=99t act,=
 any Bitcoin in lost wallets could eventually be hacked and put back into c=
irculation. Such a scenario would be catastrophic for the network.<br><br>I=
 believe that by enforcing a deadline for migration, we provide rightful ow=
ners with a clear, non-negotiable opportunity to secure their funds. This a=
pproach is not merely hypothetical. It is a proactive measure that addresse=
s the imminent risk of quantum attacks. While turnstile mechanisms have bee=
n considered and might have merit under certain conditions, I remain commit=
ted to the idea that a forced migration, with sufficient notice and robust =
safeguards, is both realistic and necessary to protect the long-term securi=
ty of Bitcoin.<br></div><br><div class=3D"gmail_quote gmail_quote_container=
"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 6:35=E2=80=
=AFPM Dustin Ray &lt;<a href=3D"mailto:dustinvonsandwich@gmail.com">dustinv=
onsandwich@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div></div><div><div dir=3D"auto" style=3D"font-family:=
-apple-system,&quot;helvetica neue&quot;;font-size:1rem;font-style:normal;f=
ont-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:1px;text-decoration:none;background-color:rgb=
a(0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)">To be clear, the=
 turnstile approach is definitely a forced migration. It just means that in=
stead of permanently confiscating funds and removing them from circulation,=
 you force the rightful owners of those funds to move them into quantum saf=
e addresses, assuming the existence of a hypothetical turnstile mechanism. =
There&#39;s too many hypotheticals with this idea right now to give it any =
more than a cursory glance, but turnstiles have been built before and could=
 potentially be built again in this scenario.</div><div dir=3D"auto" style=
=3D"font-family:-apple-system,&quot;helvetica neue&quot;;font-size:16px;fon=
t-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-t=
ransform:none;white-space:normal;word-spacing:1px;text-decoration:none;back=
ground-color:rgba(0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)">=
<br></div><div dir=3D"auto" style=3D"font-family:-apple-system,&quot;helvet=
ica neue&quot;;font-size:1rem;font-style:normal;font-weight:400;letter-spac=
ing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:1px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rg=
b(49,49,49);color:rgb(49,49,49)">For further clarification, I&#39;m suggest=
ing that we enforce migration of unspent funds in p2pkh addresses because t=
hey are already secured by hashes which are currently conjectured to remain=
 safe against a quantum adversary. Pre-p2pkh addresses are probably the mos=
t vulnerable but few of these had seen use comparatively and may require co=
nfiscation.</div><div dir=3D"auto" style=3D"font-family:-apple-system,&quot=
;helvetica neue&quot;;font-size:16px;font-style:normal;font-weight:400;lett=
er-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:1px;text-decoration:none;background-color:rgba(0,0,0,0);border-c=
olor:rgb(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=
=3D"font-family:-apple-system,&quot;helvetica neue&quot;;font-size:1rem;fon=
t-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-t=
ransform:none;white-space:normal;word-spacing:1px;text-decoration:none;back=
ground-color:rgba(0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)">=
If your idea is to simply lock down and confiscate any pre-pq safe funds, I=
 resolutely disagree with that decision and I am fairly confident that cons=
ensus will fail to materialize around that. What I&#39;m suggesting however=
 is that your idea is realistic and sound if we assume the existence of som=
e mechanism that allows rightful owners of pre-pq funds the opportunity to =
do nothing except migrate to safe addresses which then resolves the issue.<=
/div><div dir=3D"auto" style=3D"font-family:-apple-system,&quot;helvetica n=
eue&quot;;font-size:1rem;font-style:normal;font-weight:400;letter-spacing:n=
ormal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:1=
px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(49,=
49,49);color:rgb(49,49,49)"><br></div></div><div><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 1:07=E2=80=
=AFPM Agustin Cruz &lt;<a href=3D"mailto:agustin.cruz@gmail.com" target=3D"=
_blank">agustin.cruz@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"auto"><p dir=3D"ltr">Hi Dustin,</=
p><p dir=3D"ltr">I remain convinced that a forced migration mechanism=E2=80=
=94with a clear block height deadline after which quantum-unsafe funds beco=
me unspendable=E2=80=94is the more robust and secure approach. Here=E2=80=
=99s why:</p><p dir=3D"ltr">
A forced migration approach is unambiguous. By establishing a definitive de=
adline, we eliminate the need for an additional transitional transaction ty=
pe, thereby reducing complexity and potential attack vectors. Additional co=
mplexity could inadvertently open up new vulnerabilities that a more straig=
htforward deadline avoids.</p><p dir=3D"ltr">
If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost wallets=
=E2=80=94including coins in addresses that no longer have active private ke=
y management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventuall=
y be compromised by quantum adversaries. If these coins were hacked and put=
 back into circulation, the resulting market shock would be catastrophic. T=
he forced migration mechanism is designed to preempt such a scenario by ens=
uring that only quantum-safe funds can be spent once the deadline is reache=
d.</p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp.=C2=A0m., Dustin Ray &=
lt;<a href=3D"mailto:dustinvonsandwich@gmail.com" target=3D"_blank">dustinv=
onsandwich@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"auto">It&#39;s worth considering a =
hypothetical but as of yet unknown middle ground solution, again nothing li=
ke this exists currently but conceptually it would be interesting to explor=
e:</div><div dir=3D"auto"><br></div><div dir=3D"auto">1. At some block heig=
ht deemed appropriate, modify consensus so that any pre-quantum unspent fun=
ds are restricted from being spent as normal.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">2. Develop a new transaction type whose sole purpose =
is to migrate funds from a quantum unsafe address to a safe one.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">3. This new transaction type is a =
quantum safe digital signature, but here&#39;s the hypothetical: It is sati=
sfied by developing a mechanism by which a private key from a quantum-unsaf=
e scheme can be repurposed as a private key for a pq-safe scheme. It may al=
so be possible that since we know the hash of the public key, perhaps we ca=
n invent some mechanism whereby a quantum safe signature is created from an=
 ecdsa private key that directly implies knowledge of a secret key that der=
ived the known public key.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">In this way, we create a kind of turnstile that can safely transition fu=
nds from unsafe addresses into safe ones. Such turnstiles have been used in=
 blockchains before, a notable example is in the zcash network as part of a=
n audit of shielded funds.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">There are likely hidden complexities in this idea that may cause =
it to be completely unworkable, but a theoretical transition mechanism both=
 prevents a heavy handed confiscation of funds and also prevents funds from=
 being stolen and injected back into the supply under illegitimate pretense=
s.</div><div dir=3D"auto"><br></div><div dir=3D"auto">This only works for p=
2pkh, anything prior to this is immediately vulnerable to key inversion, bu=
t Satoshi owns most of those coins as far as we know, so confiscating them =
might not be as controversial.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I&#39;m typing this on my phone so sorry for the lack of detailed re=
ferences. I think the core idea is clear though.</div><div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025=
 at 10:47=E2=80=AFAM Agustin Cruz &lt;<a href=3D"mailto:agustin.cruz@gmail.=
com" rel=3D"noreferrer" target=3D"_blank">agustin.cruz@gmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"auto"><p dir=3D"ltr">Hi Hunter,</p><p dir=3D"ltr">I appreciate the work yo=
u=E2=80=99re doing on BIP-360 for Anduro. Your point about not =E2=80=9Ccon=
fiscating=E2=80=9D old coins and allowing those with quantum capabilities t=
o free them up is certainly a valid one, and I understand the argument that=
 any inflationary impact could be transitory.</p>
<p dir=3D"ltr">From my viewpoint, allowing quantum-capable adversaries to r=
eintroduce dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) c=
ould have unintended consequences that go beyond transient inflation. It co=
uld fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disrupt=
 economic assumptions built around the current distribution of coins. While=
 some might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their =
sudden reappearance could cause lasting market shocks and undermine confide=
nce. The goal of a proactive migration is to close the door on such a scena=
rio before it becomes imminent.</p><p dir=3D"ltr">I agree that Q-day won=E2=
=80=99t necessarily be a single, catastrophic moment. It will likely be gra=
dual and subtle, giving the network some time to adapt. That said, one chal=
lenge is ensuring we don=E2=80=99t find ourselves in an emergency scramble =
the moment a capable quantum machine appears. A forced or proactive migrati=
on is an admittedly strong measure, but it attempts to address the scenario=
 where a slow, creeping capability becomes a sudden attack vector once it m=
atures. In that sense, =E2=80=9Crushing=E2=80=9D isn=E2=80=99t ideal, but n=
either is waiting until the threat is undeniably present.</p></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">El mi=C3=A9, 1=
9 de feb de 2025, 1:31=E2=80=AFp.=C2=A0m., Hunter Beast &lt;hunter@surmount=
.systems&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">I don&#39;t see why old coins should be confiscated. The better=
 option is to let those with quantum computers free up old coins. While thi=
s might have an inflationary impact on bitcoin&#39;s price, to use a turn o=
f phrase, the inflation is transitory. Those with low time preference shoul=
d support returning lost coins to circulation.<div><br></div><div>Also, I d=
on&#39;t see the urgency, considering the majority of coins are in either P=
2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signatures aren&#39;t added=
, such as with BIP-360, there will be some concern around long exposure att=
acks on P2TR coins. For large amounts, it would be smart to modify wallets =
to support broadcasting transactions to private mempool services such as Sl=
ipstream, to mitigate short exposure attacks. Those will also be rarer earl=
y on since a CRQC capable of a long exposure attack is much simpler than on=
e capable of pulling off a short exposure attack against a transaction in t=
he mempool.</div><div><br></div><div>Bitcoin&#39;s Q-day likely won&#39;t b=
e sudden and obvious. It will also take time to coordinate a soft fork acti=
vation. This shouldn&#39;t be rushed.</div><div><br></div><div>In the inter=
est of transparency, it&#39;s worth mentioning that I&#39;m working on a BI=
P-360 implementation for Anduro. Both Anduro and Slipstream are MARA servic=
es.</div><div><br></div><div class=3D"gmail_quote"><div dir=3D"auto" class=
=3D"gmail_attr">On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 A=
gustin Cruz wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"auto"><p dir=3D"ltr">Hi Dustin:</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">El mar, 11 de feb de 2025, 9:48=
=E2=80=AFp.=C2=A0m., Dustin Ray &lt;<a rel=3D"nofollow noreferrer noreferre=
r">dustinvo...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">I think youre going to have a tough time g=
etting consensus on this<br>
proposal. It is an extraordinary ask of the community to instill a<br>
change that will essentially void out a non-trivial part of the coin<br>
supply, especially when funds behind unused P2PKH addresses are at<br>
this point considered safe from a quantum adversary.<br>
<br>
In my opinion, where parts of this proposal make sense is in a quantum<br>
emergency in which an adversary is actively extracting private keys<br>
from known public keys and a transition must be made quickly and<br>
decisively. In that case, we might as well consider funds to be lost<br>
anyways. In any other scenario prior to this hypothetical emergency<br>
however, I have serious doubts that the community is going to consent<br>
to this proposal as it stands.<br>
<br>
On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz &lt;<a rel=3D"noreferr=
er nofollow noreferrer noreferrer">agusti...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi Dustin<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;<br>
&gt; El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray &lt;<a rel=
=3D"noreferrer nofollow noreferrer noreferrer">dustinvo...@gmail.com</a>&gt=
; escribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt; 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.<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz &lt;<a rel=3D=
"noreferrer nofollow noreferrer noreferrer">agusti...@gmail.com</a>&gt; wro=
te:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Dear Bitcoin Developers,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The proposal outlines:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Reducing Vulnerabilities: Transitioning funds to quantum-resis=
tant schemes preemptively to eliminate the risk posed by quantum attacks on=
 exposed public keys.<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For your convenience, I have published the full proposal on my=
 GitHub repository. You can review it at the following link:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Quantum-Resistant Address Migration Protocol (QRAMP) Proposal =
on GitHub<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thank you for your time and consideration.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Best regards,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Agustin Cruz<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt;&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an email to <a rel=3D"noreferrer nofollow noreferrer noreferrer">b=
itcoindev+...@googlegroups.com</a>.<br>
&gt;&gt;&gt; To view this discussion visit <a href=3D"https://groups.google=
.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde8598e7n%40googlegroup=
s.com" rel=3D"noreferrer noreferrer nofollow noreferrer noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2=
-8303-8c5bde8598e7n%40googlegroups.com</a>.</blockquote></div></blockquote>=
</div></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br></blockquote></div></blockquote></div>=
</blockquote></div></blockquote></div></div></blockquote></div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups=
.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71=
-9a9f-3310ea242194n%40googlegroups.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gma=
il.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer" targe=
t=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGL=
E0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com</a>.<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJDmzYzPGz9Xd%3DkdaGkkL%2Br1zh5y1cBHNh7SQXJEzg7YUX--PA%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAJDmzYzPGz9Xd%3DkdaGkkL%2Br1zh5y1cBHNh7SQXJEzg7YUX--PA%=
40mail.gmail.com</a>.<br />

--000000000000e855c5062e85bdd8--