path: root/15/2e84b99150a6b470e4372d81542e3e4b735e26

Delivery-date: Sat, 12 Jul 2025 18:49:12 -0700
Received: from mail-yb1-f192.google.com ([209.85.219.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCYMD7OS6ECBBCFBZTBQMGQEX7VBOHA@googlegroups.com>)
	id 1ualpz-0005QN-MN
	for bitcoindev@gnusha.org; Sat, 12 Jul 2025 18:49:12 -0700
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e8420d8a129sf3616838276.0
        for <bitcoindev@gnusha.org>; Sat, 12 Jul 2025 18:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752371341; x=1752976141; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=+hQun1jZn3m+y3QxJt9w4358qN9n0uWcjMhbDiDSIYo=;
        b=BLV8YwmsqGsIe8BkT4WDvkruXj/IHUINC27UbKTzPZuPMrt3Ou+krlkvOinHhu7gHs
         Szm1enJp5/i9+w5/dvV2MrV+Yv5KnuSU7K2DAmX/B34we3L2IeSucdMyOnOgZG3aoxzA
         RVvqPccRj8lrTexpLntUFscSsNFRAEdmGUuMZjnn5QHU/EGgOEqSLBO6G2ajOxSIMTDC
         wjRvR5xJhPHTwwkm+Hr9VRI19Lsl1JuXHMWwwjk1/QrtrFukk0da4FjGgaJeQB38rfix
         1jcgXkiGer/OqzvNT5KcvKFSWu0TNvFqw9hHUyD5hC4U6w21XnoNh8VpO+GyJ73hiq4f
         DoAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1752371341; x=1752976141; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+hQun1jZn3m+y3QxJt9w4358qN9n0uWcjMhbDiDSIYo=;
        b=Rr1yZJj1CvOPOVRgfGFn0aqC1/Qc69HgomE0YfiWb/HkXoSWvk/FX3EXstVTyRCIWa
         qgP6CE4RhMUrfOrXX+UEKQvbOQiSRxz28uoBTR5nXJkjYhhbIbQ9p/Z0qwcGtMLrZR1u
         k9RRaxMeKFSAdLTMcp8lyJk6hieRB/syHd2PvLbjQPnnNq4cJHTSfckG0CWrS3KBlil3
         bYhQnUZIZENn6V3hOE57lMiAY+8iG5Yf9NzlcQOI5dt3FjFAJAkK1uhjNWwn6FrWJZGT
         8utDaNZgm79LC0AF+nCZzcH+WL7NO3fuTs6+i4p/hsQ/l72Cd3SBZMtMUVlfbDlb7E3J
         /WIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752371341; x=1752976141;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+hQun1jZn3m+y3QxJt9w4358qN9n0uWcjMhbDiDSIYo=;
        b=f8aHdGdePatRRdu4tDzRc5HEjVwoboMmH8ejOXixvDZaC3JifCIUoqXkN2ELOqQe5l
         8S0cX0AdDyLwxNaqKxvysF82pHIZTGrMiI6hY7onD4EkSu97OvsTAdefgOkhVZxmu3/j
         jB7x4CfUvVgzi8igrJFgCjnapbkQtJNwVIYatm/aQtWmfbi6VEV6TY9mnxRN0MR7lb6f
         ZHkFVEuDHUwcRofrBzgfWhTAb8h7EVe+6OJjMGs2AsIzHfCZsfO38RTgLN93uSu/Jr/A
         1+0SEXG7X/OS63fM5QOT9J8xDbzVJ4Ge6ei2U4RbTNMxeNGZTguuu0MOJThmeQ/wDIw3
         aL0g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWBL2KOjF26izvEFZzMEytT4BHokbr/Y91SzJLwz+0UcoPtY6+iEOMLLFwziQ7fRjyya8hObyIFz7ZX@gnusha.org
X-Gm-Message-State: AOJu0YygShoAnrzqtmdp7ABUo7ntwJCOEPtKYddWZeBhg6fw9hNY2ray
	VZvTv30XAiu2G2xekYOKCGoscGyDSDyMj6J/toBcrHlfnkzMpVw+m0Wq
X-Google-Smtp-Source: AGHT+IGKuUklVRkQFXV8c3gzCKb3aV3R+5vUhnNhbJ9ChW1zOcatLKUeYzATYlQ+ad4t5yJ0tF2ysA==
X-Received: by 2002:a05:6902:12cd:b0:e8b:4c49:725e with SMTP id 3f1490d57ef6-e8b859ee336mr9746585276.6.1752371340866;
        Sat, 12 Jul 2025 18:49:00 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeLJXXGnGdRsjy3ceNjLxdOmah9YiRCWTPLug5Hmx5/YA==
Received: by 2002:a25:df57:0:b0:e87:c996:a10 with SMTP id 3f1490d57ef6-e8b778de239ls418383276.1.-pod-prod-07-us;
 Sat, 12 Jul 2025 18:48:56 -0700 (PDT)
X-Received: by 2002:a05:690c:319:b0:711:4fbe:e475 with SMTP id 00721157ae682-717d7902d71mr123807427b3.12.1752371336252;
        Sat, 12 Jul 2025 18:48:56 -0700 (PDT)
Received: by 2002:a05:690c:2f05:b0:710:f35d:a3b2 with SMTP id 00721157ae682-71801389965ms7b3;
        Sat, 12 Jul 2025 18:39:03 -0700 (PDT)
X-Received: by 2002:a05:690c:ec8:b0:70d:f15d:b18f with SMTP id 00721157ae682-717d7a5f280mr136804797b3.26.1752370741564;
        Sat, 12 Jul 2025 18:39:01 -0700 (PDT)
Date: Sat, 12 Jul 2025 18:39:01 -0700 (PDT)
From: Boris Nagaev <bnagaev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1ae281cd-20a8-4b50-98b7-c228f090ad7an@googlegroups.com>
In-Reply-To: <CADL_X_dz6Zuoh6T=p+531kQkgVUbr5iKHeLNe01s5=QDp6iw9g@mail.gmail.com>
References: <E8269A1A-1899-46D2-A7CD-4D9D2B732364@astrotown.de>
 <CAJDmzYxw+mXQKjS+h+r6mCoe1rwWUpa_yZDwmwx6U_eO5JhZLg@mail.gmail.com>
 <zyx7G6H1TyB2sWVEKAfIYmCCvfXniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuHMjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXLmiCJOY=@proton.me>
 <CAC3UE4+DR=DQqtT+X0SYvH1XCVnmatD7frcHC5dtdVAef39UnQ@mail.gmail.com>
 <CAJDmzYycnXODG_e9ATqTkooUu3C-RS703P1-RQLW5CdcCehsqg@mail.gmail.com>
 <ZVSyhRF6sP5xZxzih0EUn-_35mQxiVXYzrvxZ_Dz7tTygUqTmxxyVhFfXswTUmIquzCR6XNGbgLlNUCkHucTAliQf7aesPZBLRFoceu_9BY=@protonmail.com>
 <893891ea-34ec-4d60-9941-9f636be0d747n@googlegroups.com>
 <CADL_X_dz6Zuoh6T=p+531kQkgVUbr5iKHeLNe01s5=QDp6iw9g@mail.gmail.com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_56916_2133222854.1752370741011"
X-Original-Sender: bnagaev@gmail.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.0 (/)

------=_Part_56916_2133222854.1752370741011
Content-Type: multipart/alternative; 
	boundary="----=_Part_56917_1482186618.1752370741011"

------=_Part_56917_1482186618.1752370741011
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> If a supermajority of sovereign actors decide they need to protect=20
themselves from negative consequences of quantum capable adversaries, I=20
wouldn't expect the threat of lawsuits to stop them.

Given that a PQ address type exists, individuals forming such a=20
supermajority are free to move their funds to PQ addresses. At that point,=
=20
the remaining minority of vulnerable funds no longer poses a systemic risk.

That said, I believe it would be better to first implement a PQ address=20
type and evaluate its fee costs. Current NIST-approved schemes are quite=20
expensive in terms of block space. Whether a broad adoption of PQ addresses=
=20
is justified depends on trade-offs users face. Without concrete data on=20
those trade-offs, it's premature to discuss enforcing such a move.

Even if PQ addresses turn out to be as space-efficient as P2TR, enforcing=
=20
their use would still constitute a form of central planning, imposing a=20
particular choice on all users. The situation becomes even more problematic=
=20
if these addresses are more expensive. It risks resembling scenarios where=
=20
governments mandate actions like mandatory insurance in the name of=20
collective safety. In this case, users who don't view quantum computing as=
=20
a credible threat would be compelled not only to move their funds (at some=
=20
cost) but also to pay more for each subsequent transaction. That feels=20
contrary to Bitcoin's foundational principles.

If a secure and efficient PQ address format becomes available, I will=20
personally move my funds to it. But I don't believe I (or anyone else) have=
=20
the right to force others to do the same. A group of individuals has no=20
more rights than the sum of the individuals within it. This is a=20
fundamental principle of individual liberty and runs counter to=20
collectivism. Even a majority shouldn't be able to impose such a=20
requirement. What we can do is offer tools and economic incentives (like=20
the segwit discount) to encourage voluntary adoption.

On Sunday, June 8, 2025 at 11:08:58=E2=80=AFAM UTC-3 Jameson Lopp wrote:

> if developers make a conscious decision to make a code change that=20
confiscates funds, even with a reasonable heads-up, I feel like some=20
lawyers might be tempted to make an argument that those developers should=
=20
be held responsible for any losses.

Anyone can sue anyone for anything, so the mere potential for a lawsuit=20
isn't something that I believe should be taken into consideration with=20
regard to protocol changes.

But such an argument would be fundamentally flawed, because developers=20
don't actually enforce changes to the protocol. Enforcement must be=20
performed by miners and node operators. I suspect lawyers would have a=20
tough time finding and suing all of them. Suing someone for running=20
software you dislike also sounds like a pretty weak position; at least in=
=20
America I'd expect to be protected by freedom of speech. Remember that=20
anyone who might desire to do so is still free to write and run software=20
that rejects those changes.

Bitcoin is "trustless" if you validate the state of the network with your=
=20
own independently controlled full node. But, on the flip side, you must=20
"trust" the rest of the network not to coordinate changes to the network=20
that are to your personal detriment. If a supermajority of sovereign actors=
=20
decide they need to protect themselves from negative consequences of=20
quantum capable adversaries, I wouldn't expect the threat of lawsuits to=20
stop them.

On Sat, Jun 7, 2025 at 9:55=E2=80=AFAM waxwing/ AdamISZ <ekag...@gmail.com>=
 wrote:

> I'm not a lawyer, but if developers make a conscious decision to make a=
=20
code change that confiscates funds, even with a reasonable heads-up, I feel=
=20
like some lawyers might be tempted to make an argument that those=20
developers should be held responsible for any losses. As everyone knows,=20
Bitcoin has been under legal attacks before, and I'm not sure that anyone=
=20
would (or should) be willing to sign off on a change that might potentially=
=20
open them up to several billion dollars worth of personal responsibility -=
=20
especially if the "bonded courier" actually shows up and reveals a private=
=20
key that would have unlocked funds under the pre-QC scheme.

Coincidentally, Peter Todd has just made the same point in another=20
(apparently unrelated) thread, here:=20
https://groups.google.com/g/bitcoindev/c/bmV1QwYEN4k/m/kkHQZd_BAwAJ

For me it's very clear, that it's not an accident that such "unexpected"=20
side effects exist. It's a feature that I'd whimsically call "ethical=20
impedance-mismatch" (the term impedance mismatch has been used in=20
computing/programming, which itself borrowed it from the real meaning, in=
=20
physics). People have a moral/ethical desire to make bitcoin function as=20
well as possible, and see a failure mode in those using it for other=20
purposes, but that line of thought clashes with the essential, basic=20
principle of censorship-resistance.

So we see technical borked-ness like failure to get accurate fee rates and=
=20
the like, from doing something (attempting to filter at p2p level) that it=
=20
is intrinsically counter to the foundational ethical, functional purpose of=
=20
the system: censorship-resistance. And then we see "cascading failures" of=
=20
the type discussed here: if the devs are working to break bitcoin's ethical=
=20
promise of censorship-resistance, then thugs^H^H politicians and lawyers,=
=20
will seek to take control of that "break" for their own purposes.

That's why I'm not against "quantum recovery" as per the title of this=20
thread. Recovery, independent of outside control, *is* bitcoin's function.=
=20
If half a million btc get spent by someone who has "recovered" in an=20
unexpected way, tough titties. If the entire system collapses because we=20
can't get our act together before 2085 (OK I know some think it's 2035, I=
=20
don't, but whatever), then it is what it is. That is a huge unknown. But=20
Bitcoin will 100% fail if confiscation of *any* type becomes a thing.

Cheers,
AdamISZ/waxwing
On Wednesday, June 4, 2025 at 4:56:53=E2=80=AFAM UTC-3 ArmchairCryptologist=
 wrote:

Hi,

With the longer grace period and selective deactivation, this seems more=20
sensible, but there is one elephant in the room that I haven't seen=20
mentioned here - namely, the legal aspect. (If it was, sorry I missed it.)

I'm not a lawyer, but if developers make a conscious decision to make a=20
code change that confiscates funds, even with a reasonable heads-up, I feel=
=20
like some lawyers might be tempted to make an argument that those=20
developers should be held responsible for any losses. As everyone knows,=20
Bitcoin has been under legal attacks before, and I'm not sure that anyone=
=20
would (or should) be willing to sign off on a change that might potentially=
=20
open them up to several billion dollars worth of personal responsibility -=
=20
especially if the "bonded courier" actually shows up and reveals a private=
=20
key that would have unlocked funds under the pre-QC scheme.

The only safe-ish way I can see to do this is to have it only affect funds=
=20
that are very likely to be lost in the first place. So at the very least,=
=20
it could not affect UTXOs that could potentially be encumbered with a=20
timelock (i.e. P2SH/P2WSH), and it could only affect UTXOs that have not=20
moved for a very long time (say 15-20 years).=20

If quantum computers capable of practical attacks against Bitcoin are ever=
=20
known to actually exist, *sending*=E2=80=8B to non-PQC addresses should of =
course=20
be disabled immediately. But I feel that the nature of a permissionless=20
system implies a large degree of self-responsibility, so if someone chooses=
=20
to keep using non-PQC addresses even after PQC addresses have become=20
available and practical quantum attacks are suspected to be an imminent=20
danger, it's not necessarily up to the developers to tell them they can't,=
=20
only that they really shouldn't.

--
Regards,
ArmchairCryptologist

Sent with Proton Mail <https://proton.me/mail/home> secure email.=20

On Monday, May 26th, 2025 at 2:48 AM, Agustin Cruz <agusti...@gmail.com>=20
wrote:

Hi everyone,

QRAMP proposal aims to manage the quantum transition responsibly without=20
disrupting Bitcoin=E2=80=99s core principles.

QRAMP has three phases:

1. Allow wallets to optionally include PQC keys in Taproot outputs. This=20
enables early adoption without forcing anyone.

2. Announce a soft fork to disable vulnerable scripts, with a long=20
(~4-year) grace period. This gives ample time to migrate and avoids sudden=
=20
shocks.

3. Gradually deactivate vulnerable outputs based on age or inactivity. This=
=20
avoids a harsh cutoff and gives time for adaptation.

We can also allow exceptions via proof-of-possession, and delay=20
restrictions on timelocked outputs to avoid harming future spenders.

QRAMP is not about confiscation or control. It=E2=80=99s about aligning inc=
entives,=20
maintaining security, and offering a clear, non-coercive upgrade path.

Best,
Agustin Cruz



El dom, 25 de may de 2025, 7:03=E2=80=AFp.m., Dustin Ray <dustinvo...@gmail=
.com>=20
escribi=C3=B3:

The difference between the ETH/ETC split though was that no one had=20
anything confiscated except the DAO hacker, everyone retained an identical=
=20
number of tokens on each chain. The proposal for BTC is very different in=
=20
that some holders will lose access to their coins during the PQ migration=
=20
under the confiscation approach. Just wanted to point that out.

On Sun, May 25, 2025 at 3:06=E2=80=AFPM 'conduition' via Bitcoin Developmen=
t=20
Mailing List <bitco...@googlegroups.com> wrote:

Hey Saulo,

You're right about the possibility of an ugly split. Laggards who don't=20
move coins to PQ address schemes will be incentivized to follow any chain=
=20
where they keep their coins. But those who do migrate will be incentivized=
=20
to follow the chain where unmigrated pre-quantum coins are frozen.=20

While you're comparing this event to the ETH/ETC split, we should remember=
=20
that ETH remained the dominant chain despite their heavy-handed rollback.=
=20
Just goes to show, confusion and face-loss is a lesser evil than allowing=
=20
an adversary to pwn the network.=20

This is the free-market way to solve problems without imposing rules on=20
everyone.


It'd still be a free market even if quantum-vulnerable coins are frozen.=20
The only way to test the relative value of quantum-safe vs=20
quantum-vulnerable coins is to split the chain and see how the market=20
reacts.=20

IMO, the "free market way" is to give people options and let their money=20
flow to where it works best. That means people should be able to choose=20
whether they want their money to be part of a system that allows quantum=20
attack, or part of one which does not. I know which I would choose, but=20
neither you nor I can make that choice for everyone.

regards,
conduition
On Monday, March 24th, 2025 at 7:19 AM, Agustin Cruz <agusti...@gmail.com>=
=20
wrote:

I=E2=80=99m against letting quantum computers scoop up funds from addresses=
 that=20
don=E2=80=99t upgrade to quantum-resistant.=20
Saulo=E2=80=99s idea of a free-market approach, leaving old coins up for gr=
abs if=20
people don=E2=80=99t move them, sounds fair at first. Let luck decide, righ=
t? But I=20
worry it=E2=80=99d turn into a mess. If quantum machines start cracking key=
s and=20
snagging coins, it=E2=80=99s not just lost Satoshi-era stuff at risk. Plent=
y of=20
active wallets, like those on the rich list Jameson mentioned, could get=20
hit too. Imagine millions of BTC flooding the market. Prices tank, trust in=
=20
Bitcoin takes a dive, and we all feel the pain. Freezing those vulnerable=
=20
funds keeps that chaos in check.
Plus, =E2=80=9Cyour keys, your coins=E2=80=9D is Bitcoin=E2=80=99s heart. I=
f quantum tech can steal=20
from you just because you didn=E2=80=99t upgrade fast enough, that promise =
feels=20
shaky. Freezing funds after a heads-up period (say, four years) protects=20
that idea better than letting tech giants or rogue states play vampire with=
=20
our network. It also nudges people to get their act together and move to=20
safer addresses, which strengthens Bitcoin long-term.
Saulo=E2=80=99s right that freezing coins could confuse folks or spark a sp=
lit like=20
Ethereum Classic. But I=E2=80=99d argue quantum theft would look worse. Bit=
coin=20
would seem broken, not just strict. A clear plan and enough time to migrate=
=20
could smooth things over. History=E2=80=99s on our side too. Bitcoin=E2=80=
=99s fixed bugs=20
before, like SegWit. This feels like that, not a bailout.
So yeah, I=E2=80=99d rather see vulnerable coins locked than handed to whoe=
ver=20
builds the first quantum rig. It=E2=80=99s less about coddling people and m=
ore=20
about keeping Bitcoin solid for everyone. What do you all think?
Cheers,
Agust=C3=ADn


On Sun, Mar 23, 2025 at 10:29=E2=80=AFPM AstroTown <sa...@astrotown.de> wro=
te:

I believe that having some entity announce the decision to freeze old UTXOs=
=20
would be more damaging to Bitcoin=E2=80=99s image (and its value) than havi=
ng them=20
gathered by QC. This would create another version of Bitcoin, similar to=20
Ethereum Classic, causing confusion in the market.

It would be better to simply implement the possibility of moving funds to a=
=20
PQC address without a deadline, allowing those who fail to do so to rely on=
=20
luck to avoid having their coins stolen. Most coins would be migrated to=20
PQC anyway, and in most cases, only the lost ones would remain vulnerable.=
=20
This is the free-market way to solve problems without imposing rules on=20
everyone.

Saulo Fonseca


On 16. Mar 2025, at 15:15, Jameson Lopp <jameso...@gmail.com> wrote:

The quantum computing debate is heating up. There are many controversial=20
aspects to this debate, including whether or not quantum computers will=20
ever actually become a practical threat.

I won't tread into the unanswerable question of how worried we should be=20
about quantum computers. I think it's far from a crisis, but given the=20
difficulty in changing Bitcoin it's worth starting to seriously discuss.=20
Today I wish to focus on a philosophical quandary related to one of the=20
decisions that would need to be made if and when we implement a quantum=20
safe signature scheme.

Several Scenarios
Because this essay will reference game theory a fair amount, and there are=
=20
many variables at play that could change the nature of the game, I think=20
it's important to clarify the possible scenarios up front.

1. Quantum computing never materializes, never becomes a threat, and thus=
=20
everything discussed in this essay is moot.
2. A quantum computing threat materializes suddenly and Bitcoin does not=20
have quantum safe signatures as part of the protocol. In this scenario it=
=20
would likely make the points below moot because Bitcoin would be=20
fundamentally broken and it would take far too long to upgrade the=20
protocol, wallet software, and migrate user funds in order to restore=20
confidence in the network.
3. Quantum computing advances slowly enough that we come to consensus about=
=20
how to upgrade Bitcoin and post quantum security has been minimally adopted=
=20
by the time an attacker appears.
4. Quantum computing advances slowly enough that we come to consensus about=
=20
how to upgrade Bitcoin and post quantum security has been highly adopted by=
=20
the time an attacker appears.

For the purposes of this post, I'm envisioning being in situation 3 or 4.

To Freeze or not to Freeze?
I've started seeing more people weighing in on what is likely the most=20
contentious aspect of how a quantum resistance upgrade should be handled in=
=20
terms of migrating user funds. Should quantum vulnerable funds be left open=
=20
to be swept by anyone with a sufficiently powerful quantum computer OR=20
should they be permanently locked?

"I don't see why old coins should be confiscated. The better option is to=
=20
let those with quantum computers free up old coins. While this might have=
=20
an inflationary impact on bitcoin's price, to use a turn of phrase, the=20
inflation is transitory. Those with low time preference should support=20
returning lost coins to circulation."=20

- Hunter Beast


On the other hand:

"Of course they have to be confiscated. If and when (and that's a big if)=
=20
the existence of a cryptography-breaking QC becomes a credible threat, the=
=20
Bitcoin ecosystem has no other option than softforking out the ability to=
=20
spend from signature schemes (including ECDSA and BIP340) that are=20
vulnerable to QCs. The alternative is that millions of BTC become=20
vulnerable to theft; I cannot see how the currency can maintain any value=
=20
at all in such a setting. And this affects everyone; even those which=20
diligently moved their coins to PQC-protected schemes."
- Pieter Wuille


I don't think "confiscation" is the most precise term to use, as the funds=
=20
are not being seized and reassigned. Rather, what we're really discussing=
=20
would be better described as "burning" - placing the funds *out of reach of=
=20
everyone*.

Not freezing user funds is one of Bitcoin's inviolable properties. However,=
=20
if quantum computing becomes a threat to Bitcoin's elliptic curve=20
cryptography, *an inviolable property of Bitcoin will be violated one way=
=20
or another*.

Fundamental Properties at Risk
5 years ago I attempted to comprehensively categorize all of Bitcoin's=20
fundamental properties that give it value.=20
https://nakamoto.com/what-are-the-key-properties-of-bitcoin/

The particular properties in play with regard to this issue seem to be:

*Censorship Resistance* - No one should have the power to prevent others=20
from using their bitcoin or interacting with the network.

*Forward Compatibility* - changing the rules such that certain valid=20
transactions become invalid could undermine confidence in the protocol.

*Conservatism* - Users should not be expected to be highly responsive to=20
system issues.

As a result of the above principles, we have developed a strong meme (kudos=
=20
to Andreas Antonopoulos) that goes as follows:

Not your keys, not your coins.


I posit that the corollary to this principle is:

Your keys, only your coins.


A quantum capable entity breaks the corollary of this foundational=20
principle. We secure our bitcoin with the mathematical probabilities=20
related to extremely large random numbers. Your funds are only secure=20
because truly random large numbers should not be guessable or discoverable=
=20
by anyone else in the world.

This is the principle behind the motto *vires in numeris* - strength in=20
numbers. In a world with quantum enabled adversaries, this principle is=20
null and void for many types of cryptography, including the elliptic curve=
=20
digital signatures used in Bitcoin.

Who is at Risk?
There has long been a narrative that Satoshi's coins and others from the=20
Satoshi era of P2PK locking scripts that exposed the public key directly on=
=20
the blockchain will be those that get scooped up by a quantum "miner." But=
=20
unfortunately it's not that simple. If I had a powerful quantum computer,=
=20
which coins would I target? I'd go to the Bitcoin rich list and find the=20
wallets that have exposed their public keys due to re-using addresses that=
=20
have previously been spent from. You can easily find them at=20
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html

Note that a few of these wallets, like Bitfinex / Kraken / Tether, would be=
=20
slightly harder to crack because they are multisig wallets. So a quantum=20
attacker would need to reverse engineer 2 keys for Kraken or 3 for Bitfinex=
=20
/ Tether in order to spend funds. But many are single signature.

Point being, it's not only the really old lost BTC that are at risk to a=20
quantum enabled adversary, at least at time of writing. If we add a quantum=
=20
safe signature scheme, we should expect those wallets to be some of the=20
first to upgrade given their incentives.

The Ethical Dilemma: Quantifying Harm
Which decision results in the most harm?

By making quantum vulnerable funds unspendable we potentially harm some=20
Bitcoin users who were not paying attention and neglected to migrate their=
=20
funds to a quantum safe locking script. This violates the "conservativism"=
=20
principle stated earlier. On the flip side, we prevent those funds plus far=
=20
more lost funds from falling into the hands of the few privileged folks who=
=20
gain early access to quantum computers.

By leaving quantum vulnerable funds available to spend, the same set of=20
users who would otherwise have funds frozen are likely to see them stolen.=
=20
And many early adopters who lost their keys will eventually see their=20
unreachable funds scooped up by a quantum enabled adversary.

Imagine, for example, being James Howells, who accidentally threw away a=20
hard drive with 8,000 BTC on it, currently worth over $600M USD. He has=20
spent a decade trying to retrieve it from the landfill where he knows it's=
=20
buried, but can't get permission to excavate. I suspect that, given the=20
choice, he'd prefer those funds be permanently frozen rather than fall into=
=20
someone else's possession - I know I would.

Allowing a quantum computer to access lost funds doesn't make those users=
=20
any worse off than they were before, however it *would*have a negative=20
impact upon everyone who is currently holding bitcoin.

It's prudent to expect significant economic disruption if large amounts of=
=20
coins fall into new hands. Since a quantum computer is going to have a=20
massive up front cost, expect those behind it to desire to recoup their=20
investment. We also know from experience that when someone suddenly finds=
=20
themselves in possession of 9+ figures worth of highly liquid assets, they=
=20
tend to diversify into other things by selling.

Allowing quantum recovery of bitcoin is *tantamount to wealth=20
redistribution*. What we'd be allowing is for bitcoin to be redistributed=
=20
from those who are ignorant of quantum computers to those who have won the=
=20
technological race to acquire quantum computers. It's hard to see a bright=
=20
side to that scenario.

Is Quantum Recovery Good for Anyone?

Does quantum recovery HELP anyone? I've yet to come across an argument that=
=20
it's a net positive in any way. It certainly doesn't add any security to=20
the network. If anything, it greatly decreases the security of the network=
=20
by allowing funds to be claimed by those who did not earn them.

But wait, you may be thinking, wouldn't quantum "miners" have earned their=
=20
coins by all the work and resources invested in building a quantum=20
computer? I suppose, in the same sense that a burglar earns their spoils by=
=20
the resources they invest into surveilling targets and learning the skills=
=20
needed to break into buildings. What I say "earned" I mean through=20
productive mutual trade.

For example:

* Investors earn BTC by trading for other currencies.
* Merchants earn BTC by trading for goods and services.
* Miners earn BTC by trading thermodynamic security.
* Quantum miners don't trade anything, they are vampires feeding upon the=
=20
system.

There's no reason to believe that allowing quantum adversaries to recover=
=20
vulnerable bitcoin will be of benefit to anyone other than the select few=
=20
organizations that win the technological arms race to build the first such=
=20
computers. Probably nation states and/or the top few largest tech companies=
.

One could certainly hope that an organization with quantum supremacy is=20
benevolent and acts in a "white hat" manner to return lost coins to their=
=20
owners, but that's incredibly optimistic and foolish to rely upon. Such a=
=20
situation creates an insurmountable ethical dilemma of only recovering lost=
=20
bitcoin rather than currently owned bitcoin. There's no way to precisely=20
differentiate between the two; anyone can claim to have lost their bitcoin=
=20
but if they have lost their keys then proving they ever had the keys=20
becomes rather difficult. I imagine that any such white hat recovery=20
efforts would have to rely upon attestations from trusted third parties=20
like exchanges.

Even if the first actor with quantum supremacy is benevolent, we must=20
assume the technology could fall into adversarial hands and thus think=20
adversarially about the potential worst case outcomes. Imagine, for=20
example, that North Korea continues scooping up billions of dollars from=20
hacking crypto exchanges and decides to invest some of those proceeds into=
=20
building a quantum computer for the biggest payday ever...

Downsides to Allowing Quantum Recovery
Let's think through an exhaustive list of pros and cons for allowing or=20
preventing the seizure of funds by a quantum adversary.

Historical Precedent
Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair game"=
 but=20
rather were treated as failures to be remediated. Treating quantum theft=20
differently risks rewriting Bitcoin=E2=80=99s history as a free-for-all rat=
her than=20
a system that seeks to protect its users.

Violation of Property Rights
Allowing a quantum adversary to take control of funds undermines the=20
fundamental principle of cryptocurrency - if you keep your keys in your=20
possession, only you should be able to access your money. Bitcoin is built=
=20
on the idea that private keys secure an individual=E2=80=99s assets, and=20
unauthorized access (even via advanced tech) is theft, not a legitimate=20
transfer.

Erosion of Trust in Bitcoin
If quantum attackers can exploit vulnerable addresses, confidence in=20
Bitcoin as a secure store of value would collapse. Users and investors rely=
=20
on cryptographic integrity, and widespread theft could drive adoption away=
=20
from Bitcoin, destabilizing its ecosystem.

This is essentially the counterpoint to claiming the burning of vulnerable=
=20
funds is a violation of property rights. While some will certainly see it=
=20
as such, others will find the apathy toward stopping quantum theft to be=20
similarly concerning.

Unfair Advantage
Quantum attackers, likely equipped with rare and expensive technology,=20
would have an unjust edge over regular users who lack access to such tools.=
=20
This creates an inequitable system where only the technologically elite can=
=20
exploit others, contradicting Bitcoin=E2=80=99s ethos of decentralized powe=
r.

Bitcoin is designed to create an asymmetric advantage for DEFENDING one's=
=20
wealth. It's supposed to be impractically expensive for attackers to crack=
=20
the entropy and cryptography protecting one's coins. But now we find=20
ourselves discussing a situation where this asymmetric advantage is=20
compromised in favor of a specific class of attackers.

Economic Disruption
Large-scale theft from vulnerable addresses could crash Bitcoin=E2=80=99s p=
rice as=20
quantum recovered funds are dumped on exchanges. This would harm all=20
holders, not just those directly targeted, leading to broader financial=20
chaos in the markets.

Moral Responsibility
Permitting theft via quantum computing sets a precedent that technological=
=20
superiority justifies unethical behavior. This is essentially taking a=20
"code is law" stance in which we refuse to admit that both code and laws=20
can be modified to adapt to previously unforeseen situations.

Burning of coins can certainly be considered a form of theft, thus I think=
=20
it's worth differentiating the two different thefts being discussed:

1. self-enriching & likely malicious
2. harm prevention & not necessarily malicious

Both options lack the consent of the party whose coins are being burnt or=
=20
transferred, thus I think the simple argument that theft is immoral becomes=
=20
a wash and it's important to drill down into the details of each.

Incentives Drive Security
I can tell you from a decade of working in Bitcoin security - the average=
=20
user is lazy and is a procrastinator. If Bitcoiners are given a "drop dead=
=20
date" after which they know vulnerable funds will be burned, this pressure=
=20
accelerates the adoption of post-quantum cryptography and strengthens=20
Bitcoin long-term. Allowing vulnerable users to delay upgrading=20
indefinitely will result in more laggards, leaving the network more exposed=
=20
when quantum tech becomes available.

Steel Manning
Clearly this is a complex and controversial topic, thus it's worth thinking=
=20
through the opposing arguments.

Protecting Property Rights
Allowing quantum computers to take vulnerable bitcoin could potentially be=
=20
spun as a hard money narrative - we care so greatly about not violating=20
someone's access to their coins that we allow them to be stolen!

But I think the flip side to the property rights narrative is that burning=
=20
vulnerable coins prevents said property from falling into undeserving=20
hands. If the entire Bitcoin ecosystem just stands around and allows=20
quantum adversaries to claim funds that rightfully belong to other users,=
=20
is that really a "win" in the "protecting property rights" category? It=20
feels more like apathy to me.

As such, I think the "protecting property rights" argument is a wash.

Quantum Computers Won't Attack Bitcoin
There is a great deal of skepticism that sufficiently powerful quantum=20
computers will ever exist, so we shouldn't bother preparing for a=20
non-existent threat. Others have argued that even if such a computer was=20
built, a quantum attacker would not go after bitcoin because they wouldn't=
=20
want to reveal their hand by doing so, and would instead attack other=20
infrastructure.

It's quite difficult to quantify exactly how valuable attacking other=20
infrastructure would be. It also really depends upon when an entity gains=
=20
quantum supremacy and thus if by that time most of the world's systems have=
=20
already been upgraded. While I think you could argue that certain entities=
=20
gaining quantum capability might not attack Bitcoin, it would only delay=20
the inevitable - eventually somebody will achieve the capability who=20
decides to use it for such an attack.

Quantum Attackers Would Only Steal Small Amounts
Some have argued that even if a quantum attacker targeted bitcoin, they'd=
=20
only go after old, likely lost P2PK outputs so as to not arouse suspicion=
=20
and cause a market panic.

I'm not so sure about that; why go after 50 BTC at a time when you could=20
take 250,000 BTC with the same effort as 50 BTC? This is a classic "zero=20
day exploit" game theory in which an attacker knows they have a limited=20
amount of time before someone else discovers the exploit and either=20
benefits from it or patches it. Take, for example, the recent ByBit attack=
=20
- the highest value crypto hack of all time. Lazarus Group had compromised=
=20
the Safe wallet front end JavaScript app and they could have simply had it=
=20
reassign ownership of everyone's Safe wallets as they were interacting with=
=20
their wallet. But instead they chose to only specifically target ByBit's=20
wallet with $1.5 billion in it because they wanted to maximize their=20
extractable value. If Lazarus had started stealing from every wallet, they=
=20
would have been discovered quickly and the Safe web app would likely have=
=20
been patched well before any billion dollar wallets executed the malicious=
=20
code.

I think the "only stealing small amounts" argument is strongest for=20
Situation #2 described earlier, where a quantum attacker arrives before=20
quantum safe cryptography has been deployed across the Bitcoin ecosystem.=
=20
Because if it became clear that Bitcoin's cryptography was broken AND there=
=20
was nowhere safe for vulnerable users to migrate, the only logical option=
=20
would be for everyone to liquidate their bitcoin as quickly as possible. As=
=20
such, I don't think it applies as strongly for situations in which we have=
=20
a migration path available.

The 21 Million Coin Supply Should be in Circulation
Some folks are arguing that it's important for the "circulating /=20
spendable" supply to be as close to 21M as possible and that having a=20
significant portion of the supply out of circulation is somehow undesirable=
.

While the "21M BTC" attribute is a strong memetic narrative, I don't think=
=20
anyone has ever expected that it would all be in circulation. It has always=
=20
been understood that many coins will be lost, and that's actually part of=
=20
the game theory of owning bitcoin!

And remember, the 21M number in and of itself is not a particularly=20
important detail - it's not even mentioned in the whitepaper. What's=20
important is that the supply is well known and not subject to change.

Self-Sovereignty and Personal Responsibility
Bitcoin=E2=80=99s design empowers individuals to control their own wealth, =
free=20
from centralized intervention. This freedom comes with the burden of=20
securing one's private keys. If quantum computing can break obsolete=20
cryptography, the fault lies with users who didn't move their funds to=20
quantum safe locking scripts. Expecting the network to shield users from=20
their own negligence undermines the principle that you, and not a third=20
party, are accountable for your assets.

I think this is generally a fair point that "the community" doesn't owe you=
=20
anything in terms of helping you. I think that we do, however, need to=20
consider the incentives and game theory in play with regard to quantum safe=
=20
Bitcoiners vs quantum vulnerable Bitcoiners. More on that later.

Code is Law
Bitcoin operates on transparent, immutable rules embedded in its protocol.=
=20
If a quantum attacker uses superior technology to derive private keys from=
=20
public keys, they=E2=80=99re not "hacking" the system - they're simply foll=
owing=20
what's mathematically permissible within the current code. Altering the=20
protocol to stop this introduces subjective human intervention, which=20
clashes with the objective, deterministic nature of blockchain.

While I tend to agree that code is law, one of the entire points of laws is=
=20
that they can be amended to improve their efficacy in reducing harm.=20
Leaning on this point seems more like a pro-ossification stance that it's=
=20
better to do nothing and allow harm to occur rather than take action to=20
stop an attack that was foreseen far in advance.

Technological Evolution as a Feature, Not a Bug
It's well known that cryptography tends to weaken over time and eventually=
=20
break. Quantum computing is just the next step in this progression. Users=
=20
who fail to adapt (e.g., by adopting quantum-resistant wallets when=20
available) are akin to those who ignored technological advancements like=20
multisig or hardware wallets. Allowing quantum theft incentivizes=20
innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic, punishing complac=
ency=20
while rewarding vigilance.

Market Signals Drive Security
If quantum attackers start stealing funds, it sends a clear signal to the=
=20
market: upgrade your security or lose everything. This pressure accelerates=
=20
the adoption of post-quantum cryptography and strengthens Bitcoin=20
long-term. Coddling vulnerable users delays this necessary evolution,=20
potentially leaving the network more exposed when quantum tech becomes=20
widely accessible. Theft is a brutal but effective teacher.

Centralized Blacklisting Power
Burning vulnerable funds requires centralized decision-making - a soft fork=
=20
to invalidate certain transactions. This sets a dangerous precedent for=20
future interventions, eroding Bitcoin=E2=80=99s decentralization. If quantu=
m theft=20
is blocked, what=E2=80=99s next - reversing exchange hacks? The system must=
 remain=20
neutral, even if it means some lose out.

I think this could be a potential slippery slope if the proposal was to=20
only burn specific addresses. Rather, I'd expect a neutral proposal to burn=
=20
all funds in locking script types that are known to be quantum vulnerable.=
=20
Thus, we could eliminate any subjectivity from the code.

Fairness in Competition
Quantum attackers aren't cheating; they're using publicly available physics=
=20
and math. Anyone with the resources and foresight can build or access=20
quantum tech, just as anyone could mine Bitcoin in 2009 with a CPU. Early=
=20
adopters took risks and reaped rewards; quantum innovators are doing the=20
same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin has never pr=
omised equality=20
of outcome - only equality of opportunity within its rules.

I find this argument to be a mischaracterization because we're not talking=
=20
about CPUs. This is more akin to talking about ASICs, except each ASIC=20
costs millions if not billions of dollars. This is out of reach from all=20
but the wealthiest organizations.

Economic Resilience
Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and emerged=
=20
stronger. The market can absorb quantum losses, with unaffected users=20
continuing to hold and new entrants buying in at lower prices. Fear of=20
economic collapse overestimates the impact - the network=E2=80=99s antifrag=
ility=20
thrives on such challenges.

This is a big grey area because we don't know when a quantum computer will=
=20
come online and we don't know how quickly said computers would be able to=
=20
steal bitcoin. If, for example, the first generation of sufficiently=20
powerful quantum computers were stealing less volume than the current block=
=20
reward then of course it will have minimal economic impact. But if they're=
=20
taking thousands of BTC per day and bringing them back into circulation,=20
there will likely be a noticeable market impact as it absorbs the new=20
supply.

This is where the circumstances will really matter. If a quantum attacker=
=20
appears AFTER the Bitcoin protocol has been upgraded to support quantum=20
resistant cryptography then we should expect the most valuable active=20
wallets will have upgraded and the juiciest target would be the 31,000 BTC=
=20
in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant=20
since 2010. In general I'd expect that the amount of BTC re-entering the=20
circulating supply would look somewhat similar to the mining emission=20
curve: volume would start off very high as the most valuable addresses are=
=20
drained and then it would fall off as quantum computers went down the list=
=20
targeting addresses with less and less BTC.

Why is economic impact a factor worth considering? Miners and businesses in=
=20
general. More coins being liquidated will push down the price, which will=
=20
negatively impact miner revenue. Similarly, I can attest from working in=20
the industry for a decade, that lower prices result in less demand from=20
businesses across the entire industry. As such, burning quantum vulnerable=
=20
bitcoin is good for the entire industry.

Practicality & Neutrality of Non-Intervention
There=E2=80=99s no reliable way to distinguish =E2=80=9Ctheft=E2=80=9D from=
 legitimate "white hat"=20
key recovery. If someone loses their private key and a quantum computer=20
recovers it, is that stealing or reclaiming? Policing quantum actions=20
requires invasive assumptions about intent, which Bitcoin=E2=80=99s trustle=
ss=20
design can=E2=80=99t accommodate. Letting the chips fall where they may avo=
ids this=20
mess.

Philosophical Purity
Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system where outcomes r=
eflect=20
preparation and skill, not sentimentality. If quantum computing upends the=
=20
game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t meant to be safe or =
fair in a=20
nanny-state sense; it=E2=80=99s meant to be free. Users who lose funds to q=
uantum=20
attacks are casualties of liberty and their own ignorance, not victims of=
=20
injustice.

Bitcoin's DAO Moment
This situation has some similarities to The DAO hack of an Ethereum smart=
=20
contract in 2016, which resulted in a fork to stop the attacker and return=
=20
funds to their original owners. The game theory is similar because it's a=
=20
situation where a threat is known but there's some period of time before=20
the attacker can actually execute the theft. As such, there's time to=20
mitigate the attack by changing the protocol.

It also created a schism in the community around the true meaning of "code=
=20
is law," resulting in Ethereum Classic, which decided to allow the attacker=
=20
to retain control of the stolen funds.

A soft fork to burn vulnerable bitcoin could certainly result in a hard=20
fork if there are enough miners who reject the soft fork and continue=20
including transactions.

Incentives Matter
We can wax philosophical until the cows come home, but what are the actual=
=20
incentives for existing Bitcoin holders regarding this decision?

"Lost coins only make everyone else's coins worth slightly more. Think of=
=20
it as a donation to everyone." - Satoshi Nakamoto


If true, the corollary is:

"Quantum recovered coins only make everyone else's coins worth less. Think=
=20
of it as a theft from everyone." - Jameson Lopp


Thus, assuming we get to a point where quantum resistant signatures are=20
supported within the Bitcoin protocol, what's the incentive to let=20
vulnerable coins remain spendable?

* It's not good for the actual owners of those coins. It disincentivizes=20
owners from upgrading until perhaps it's too late.
* It's not good for the more attentive / responsible owners of coins who=20
have quantum secured their stash. Allowing the circulating supply to=20
balloon will assuredly reduce the purchasing power of all bitcoin holders.

Forking Game Theory
From a game theory point of view, I see this as incentivizing users to=20
upgrade their wallets. If you disagree with the burning of vulnerable=20
coins, all you have to do is move your funds to a quantum safe signature=20
scheme. Point being, I don't see there being an economic majority (or even=
=20
more than a tiny minority) of users who would fight such a soft fork. Why=
=20
expend significant resources fighting a fork when you can just move your=20
coins to a new address?

Remember that blocking spending of certain classes of locking scripts is a=
=20
tightening of the rules - a soft fork. As such, it can be meaningfully=20
enacted and enforced by a mere majority of hashpower. If miners generally=
=20
agree that it's in their best interest to burn vulnerable coins, are other=
=20
users going to care enough to put in the effort to run new node software=20
that resists the soft fork? Seems unlikely to me.

How to Execute Burning
In order to be as objective as possible, the goal would be to announce to=
=20
the world that after a specific block height / timestamp, Bitcoin nodes=20
will no longer accept transactions (or blocks containing such transactions)=
=20
that spend funds from any scripts other than the newly instituted quantum=
=20
safe schemes.

It could take a staggered approach to first freeze funds that are=20
susceptible to long-range attacks such as those in P2PK scripts or those=20
that exposed their public keys due to previously re-using addresses, but I=
=20
expect the additional complexity would drive further controversy.

How long should the grace period be in order to give the ecosystem time to=
=20
upgrade? I'd say a minimum of 1 year for software wallets to upgrade. We=20
can only hope that hardware wallet manufacturers are able to implement post=
=20
quantum cryptography on their existing hardware with only a firmware update=
.

Beyond that, it will take at least 6 months worth of block space for all=20
users to migrate their funds, even in a best case scenario. Though if you=
=20
exclude dust UTXOs you could probably get 95% of BTC value migrated in 1=20
month. Of course this is a highly optimistic situation where everyone is=20
completely focused on migrations - in reality it will take far longer.

Regardless, I'd think that in order to reasonably uphold Bitcoin's=20
conservatism it would be preferable to allow a 4 year migration window. In=
=20
the meantime, mining pools could coordinate emergency soft forking logic=20
such that if quantum attackers materialized, they could accelerate the=20
countdown to the quantum vulnerable funds burn.

Random Tangential Benefits
On the plus side, burning all quantum vulnerable bitcoin would allow us to=
=20
prune all of those UTXOs out of the UTXO set, which would also clean up a=
=20
lot of dust. Dust UTXOs are a bit of an annoyance and there has even been a=
=20
recent proposal for how to incentivize cleaning them up.

We should also expect that incentivizing migration of the entire UTXO set=
=20
will create substantial demand for block space that will sustain a fee=20
market for a fairly lengthy amount of time.

In Summary
While the moral quandary of violating any of Bitcoin's inviolable=20
properties can make this a very complex issue to discuss, the game theory=
=20
and incentives between burning vulnerable coins versus allowing them to be=
=20
claimed by entities with quantum supremacy appears to be a much simpler=20
issue.

I, for one, am not interested in rewarding quantum capable entities by=20
inflating the circulating money supply just because some people lost their=
=20
keys long ago and some laggards are not upgrading their bitcoin wallet's=20
security.

We can hope that this scenario never comes to pass, but hope is not a=20
strategy.

I welcome your feedback upon any of the above points, and contribution of=
=20
any arguments I failed to consider.

--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.
To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq8nA_4=
RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com
.

--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.
To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/E8269A1A-1899-46D2-A7CD-4D9D2B=
732364%40astrotown.de
.


--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.
To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/CAJDmzYxw%2BmXQKjS%2Bh%2Br6mCo=
e1rwWUpa_yZDwmwx6U_eO5JhZLg%40mail.gmail.com
.


--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.
To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/zyx7G6H1TyB2sWVEKAfIYmCCvfXnia=
zvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuHMjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXLmiCJ=
OY%3D%40proton.me
.

--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.

To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/CAJDmzYycnXODG_e9ATqTkooUu3C-R=
S703P1-RQLW5CdcCehsqg%40mail.gmail.com
.


--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.

To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/893891ea-34ec-4d60-9941-9f636b=
e0d747n%40googlegroups.com=20
<https://groups.google.com/d/msgid/bitcoindev/893891ea-34ec-4d60-9941-9f636=
be0d747n%40googlegroups.com?utm_medium=3Demail&utm_source=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/=
1ae281cd-20a8-4b50-98b7-c228f090ad7an%40googlegroups.com.

------=_Part_56917_1482186618.1752370741011
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt;=C2=A0<span style=3D"font-family: Arial, sans-serif; font-size: 14=
px;">If a=20
supermajority of sovereign actors decide they need to protect themselves
 from negative consequences of quantum capable adversaries, I wouldn't=20
expect the threat of lawsuits to stop them.</span></div><div><span style=3D=
"font-family: Arial, sans-serif; font-size: 14px;"><br /></span></div><div>=
Given that a PQ address type exists, individuals forming such a supermajori=
ty are free to move their funds to PQ addresses. At that point, the remaini=
ng minority of vulnerable funds no longer poses a systemic risk.<br /><br /=
>That said, I believe it would be better to first implement a PQ address ty=
pe and evaluate its fee costs. Current NIST-approved schemes are quite expe=
nsive in terms of block space. Whether a broad adoption of PQ addresses is =
justified depends on trade-offs users face. Without concrete data on those =
trade-offs, it's premature to discuss enforcing such a move.<br /><br />Eve=
n if PQ addresses turn out to be as space-efficient as P2TR, enforcing thei=
r use would still constitute a form of central planning, imposing a particu=
lar choice on all users. The situation becomes even more problematic if the=
se addresses are more expensive. It risks resembling scenarios where govern=
ments mandate actions like mandatory insurance in the name of collective sa=
fety. In this case, users who don't view quantum computing as a credible th=
reat would be compelled not only to move their funds (at some cost) but als=
o to pay more for each subsequent transaction. That feels contrary to Bitco=
in's foundational principles.<br /><br />If a secure and efficient PQ addre=
ss format becomes available, I will personally move my funds to it. But I d=
on't believe I (or anyone else) have the right to force others to do the sa=
me. A group of individuals has no more rights than the sum of the individua=
ls within it. This is a fundamental principle of individual liberty and run=
s counter to collectivism. Even a majority shouldn't be able to impose such=
 a requirement. What we can do is offer tools and economic incentives (like=
 the segwit discount) to encourage voluntary adoption.</div><br /><div><div=
 dir=3D"auto">On Sunday, June 8, 2025 at 11:08:58=E2=80=AFAM UTC-3 Jameson =
Lopp wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"=
>&gt;=C2=A0<span style=3D"font-family: Arial, sans-serif; font-size: 14px;"=
>if developers make a conscious decision to make a code change that confisc=
ates funds, even with a reasonable heads-up, I feel like some lawyers might=
 be tempted to make an argument that those developers should be held respon=
sible for any losses.</span><div><span style=3D"font-family: Arial, sans-se=
rif; font-size: 14px;"><br /></span></div></div><div dir=3D"ltr"><div><span=
 style=3D"font-family: Arial, sans-serif; font-size: 14px;">Anyone can sue =
anyone for anything, so the mere potential for a lawsuit isn't something th=
at I believe should be taken into consideration with regard to protocol cha=
nges.</span></div><div><span style=3D"font-family: Arial, sans-serif; font-=
size: 14px;"><br /></span></div><div><span style=3D"font-family: Arial, san=
s-serif; font-size: 14px;">But such an argument would be fundamentally flaw=
ed, because developers don't actually enforce changes to the protocol. Enfo=
rcement must be performed by miners and node operators. I suspect lawyers w=
ould have a tough time finding and suing all of them. Suing someone for run=
ning software you dislike also sounds like a pretty weak position; at least=
 in America I'd expect to be protected by freedom of speech. Remember that =
anyone who might desire to do so is still free to write and run software th=
at rejects those changes.</span></div><div><span style=3D"font-family: Aria=
l, sans-serif; font-size: 14px;"><br /></span></div><div><span style=3D"fon=
t-family: Arial, sans-serif; font-size: 14px;">Bitcoin is "trustless" if yo=
u validate the state of the network with your own independently controlled =
full node. But, on the flip side, you must "trust" the rest of the network =
not to coordinate changes to the network that are to your personal detrimen=
t. If a supermajority of sovereign actors decide they need to protect thems=
elves from negative consequences of quantum capable adversaries, I wouldn't=
 expect the threat of lawsuits to stop them.</span></div></div><br /><div><=
/div><div><div dir=3D"ltr">On Sat, Jun 7, 2025 at 9:55=E2=80=AFAM waxwing/ =
AdamISZ &lt;<a href=3D"" rel=3D"nofollow">ekag...@gmail.com</a>&gt; wrote:<=
br /></div></div><div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>&gt; I'm not=
 a lawyer, but if developers make a conscious decision to make a=20
code change that confiscates funds, even with a reasonable heads-up, I=20
feel like some lawyers might be tempted to make an argument that those=20
developers should be held responsible for any losses. As everyone knows,
 Bitcoin has been under legal attacks before, and I'm not sure that=20
anyone would (or should) be willing to sign off on a change that might=20
potentially open them up to several billion dollars worth of personal=20
responsibility - especially if the "bonded courier" actually shows up=20
and reveals a private key that would have unlocked funds under the=20
pre-QC scheme.</div><div><br /></div><div>Coincidentally, Peter Todd has ju=
st made the same point in another (apparently unrelated) thread, here: <a h=
ref=3D"https://groups.google.com/g/bitcoindev/c/bmV1QwYEN4k/m/kkHQZd_BAwAJ"=
 target=3D"_blank" rel=3D"nofollow">https://groups.google.com/g/bitcoindev/=
c/bmV1QwYEN4k/m/kkHQZd_BAwAJ</a></div><div><br /></div><div>For me it's ver=
y clear, that it's not an accident that such "unexpected" side effects exis=
t. It's a feature that I'd whimsically call "ethical impedance-mismatch" (t=
he term impedance mismatch has been used in computing/programming, which it=
self borrowed it from the real meaning, in physics). People have a moral/et=
hical desire to make bitcoin function as well as possible, and see a failur=
e mode in those using it for other purposes, but that line of thought clash=
es with the essential, basic principle of censorship-resistance.</div><div>=
<br /></div><div>So we see technical borked-ness like failure to get accura=
te fee rates and the like, from doing something (attempting to filter at p2=
p level) that it is intrinsically counter to the foundational ethical, func=
tional purpose of the system: censorship-resistance. And then we see "casca=
ding failures" of the type discussed here: if the devs are working to break=
 bitcoin's ethical promise of censorship-resistance, then thugs^H^H politic=
ians and lawyers, will seek to take control of that "break" for their own p=
urposes.</div><div><br /></div><div>That's why I'm not against "quantum rec=
overy" as per the title of this thread. Recovery, independent of outside co=
ntrol, *is* bitcoin's function. If half a million btc get spent by someone =
who has "recovered" in an unexpected way, tough titties. If the entire syst=
em collapses because we can't get our act together before 2085 (OK I know s=
ome think it's 2035, I don't, but whatever), then it is what it is. That is=
 a huge unknown. But Bitcoin will 100% fail if confiscation of *any* type b=
ecomes a thing.</div><br /><div>Cheers,</div>AdamISZ/waxwing<div><div dir=
=3D"auto">On Wednesday, June 4, 2025 at 4:56:53=E2=80=AFAM UTC-3 ArmchairCr=
yptologist wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px;">Hi,</div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px;"><br /></div><div styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px;">With the longer grac=
e period and selective deactivation, this seems more sensible, but there is=
 one elephant in the room that I haven't seen mentioned here - namely, the =
legal aspect. (If it was, sorry I missed it.)</div><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px;"><br /></div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;">I'm not a lawyer, but if developer=
s make a conscious decision to make a code change that confiscates funds, e=
ven with a reasonable heads-up, I feel like some lawyers might be tempted t=
o make an argument that those developers should be held responsible for any=
 losses. As everyone knows, Bitcoin has been under legal attacks before, an=
d I'm not sure that anyone would (or should) be willing to sign off on a ch=
ange that might potentially open them up to several billion dollars worth o=
f personal responsibility - especially if the "bonded courier" actually sho=
ws up and reveals a private key that would have unlocked funds under the pr=
e-QC scheme.</div><div style=3D"font-family: Arial, sans-serif; font-size: =
14px;"><br /></div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;">The only safe-ish way I can see to do this is to have it only affec=
t funds that are very likely to be lost in
 the first place. So at the very least, it could not affect UTXOs that coul=
d potentially be encumbered with a timelock (i.e. P2SH/P2WSH), and it could=
 only affect UTXOs that have not moved for a very long time (say 15-20 year=
s). </div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><=
br /></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">=
If quantum computers capable of practical attacks against Bitcoin are ever =
known to actually exist, <b>sending</b>=E2=80=8B to non-PQC addresses shoul=
d of course be disabled immediately. But I feel that the nature of a permis=
sionless system implies a large degree of self-responsibility, so if someon=
e chooses to keep using non-PQC addresses even after PQC addresses have bec=
ome available and practical quantum attacks are suspected to be an imminent=
 danger, it's not necessarily up to the developers to tell them they can't,=
 only that they really shouldn't.</div><div style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px;"><br /></div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px;">--</div><div style=3D"font-family: Arial, sans=
-serif; font-size: 14px;">Regards,</div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px;">ArmchairCryptologist</div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;"><br /></div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div>
       =20
            </div>
   =20
            <div>
        Sent with <a href=3D"https://proton.me/mail/home" rel=3D"nofollow" =
target=3D"_blank">Proton Mail</a> secure email.
    </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br /><div>=
</div></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"=
><div>
        On Monday, May 26th, 2025 at 2:48 AM, Agustin Cruz &lt;<a rel=3D"no=
follow">agusti...@gmail.com</a>&gt; wrote:<br />
        </div></div><div style=3D"font-family: Arial, sans-serif; font-size=
: 14px;"><div><blockquote type=3D"cite">
            <div dir=3D"auto">Hi everyone,<div dir=3D"auto"><br /></div><di=
v dir=3D"auto">QRAMP proposal aims to manage the quantum transition respons=
ibly without disrupting Bitcoin=E2=80=99s core principles.</div><div dir=3D=
"auto"><br /></div><div dir=3D"auto">QRAMP has three phases:</div><div dir=
=3D"auto"><br /></div><div dir=3D"auto">1. Allow wallets to optionally incl=
ude PQC keys in Taproot outputs. This enables early adoption without forcin=
g anyone.</div><div dir=3D"auto"><br /></div><div dir=3D"auto">2. Announce =
a soft fork to disable vulnerable scripts, with a long (~4-year) grace peri=
od. This gives ample time to migrate and avoids sudden shocks.</div><div di=
r=3D"auto"><br /></div><div dir=3D"auto">3. Gradually deactivate vulnerable=
 outputs based on age or inactivity. This avoids a harsh cutoff and gives t=
ime for adaptation.</div><div dir=3D"auto"></div><div dir=3D"auto"><br /></=
div><div dir=3D"auto">We can also allow exceptions via proof-of-possession,=
 and delay restrictions on timelocked outputs to avoid harming future spend=
ers.</div><div dir=3D"auto"><br /></div><div dir=3D"auto">QRAMP is not abou=
t confiscation or control. It=E2=80=99s about aligning incentives, maintain=
ing security, and offering a clear, non-coercive upgrade path.</div><div di=
r=3D"auto"><br /></div><div dir=3D"auto">Best,</div><div dir=3D"auto">Agust=
in Cruz</div><div dir=3D"auto"><br /></div><div dir=3D"auto"><br /></div></=
div><br /><div><div dir=3D"ltr">El dom, 25 de may de 2025, 7:03=E2=80=AFp.m=
., Dustin Ray &lt;<a rel=3D"noreferrer nofollow noopener">dustinvo...@gmail=
.com</a>&gt; escribi=C3=B3:<br /></div><blockquote style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
<div dir=3D"auto">The difference between the ETH/ETC split though was that =
no one had anything confiscated except the DAO hacker, everyone retained an=
 identical number of tokens on each chain. The proposal for BTC is very dif=
ferent in that some holders will lose access to their coins during the PQ m=
igration under the confiscation approach. Just wanted to point that out.</d=
iv><div><br /><div><div dir=3D"ltr">On Sun, May 25, 2025 at 3:06=E2=80=AFPM=
 'conduition' via Bitcoin Development Mailing List &lt;<a rel=3D"noreferrer=
 nofollow noopener">bitco...@googlegroups.com</a>&gt; wrote:<br /></div><bl=
ockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;"><div style=3D"font-family: Arial, sans-ser=
if; font-size: 14px;">Hey Saulo,</div><div style=3D"font-family: Arial, san=
s-serif; font-size: 14px;"><br /></div><div style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px;">You're right about the possibility of an ugly s=
plit. Laggards who don't move coins to PQ address schemes will be incentivi=
zed to follow any chain where they keep their coins. But those who do migra=
te will be incentivized to follow the chain where unmigrated pre-quantum co=
ins are frozen. </div><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 14px;"><br /></div><div style=3D"font-family: Arial, sans-serif; font-s=
ize: 14px;">While you're comparing this event to the ETH/ETC split, we shou=
ld remember that ETH remained the dominant chain despite their heavy-handed=
 rollback. Just goes to show, confusion and face-loss is a lesser evil than=
 allowing an adversary to pwn the network. </div><div style=3D"font-family:=
 Arial, sans-serif; font-size: 14px;"><br /></div><blockquote style=3D"bord=
er-left: 3px solid rgb(200, 200, 200); padding-left: 10px; border-color: rg=
b(200, 200, 200); color: rgb(102, 102, 102);"><div style=3D"font-family: Ar=
ial, sans-serif; font-size: 14px;">This is the free-market way to solve pro=
blems without imposing rules on everyone.<br /></div></blockquote><div styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px;"><br /></div><div sty=
le=3D"font-family: Arial, sans-serif; font-size: 14px;">It'd still be a fre=
e market even if quantum-vulnerable coins are frozen. The only way to test =
the relative value of quantum-safe vs quantum-vulnerable coins is to split =
the chain and see how the market reacts. </div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px;"><br /></div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px;">IMO, the "free market way" is to give =
people options and let their money flow to where it works best. That means =
people should be able to choose whether they want their money to be part of=
 a system that allows quantum attack, or part of one which does not. I know=
 which I would choose, but neither you nor I can make that choice for every=
one.</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><=
br /></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">=
regards,</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px=
;">conduition</div><div>
        On Monday, March 24th, 2025 at 7:19 AM, Agustin Cruz &lt;<a rel=3D"=
noreferrer nofollow noopener">agusti...@gmail.com</a>&gt; wrote:<br />
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div dir=3D"ltr">I=E2=80=99m against letting q=
uantum computers scoop up funds from addresses that don=E2=80=99t upgrade t=
o quantum-resistant. <br />Saulo=E2=80=99s idea of a free-market approach, =
leaving old coins up for grabs if people don=E2=80=99t move them, sounds fa=
ir at first. Let luck decide, right? But I worry it=E2=80=99d turn into a m=
ess. If quantum machines start cracking keys and snagging coins, it=E2=80=
=99s not just lost Satoshi-era stuff at risk. Plenty of active wallets, lik=
e those on the rich list Jameson mentioned, could get hit too. Imagine mill=
ions of BTC flooding the market. Prices tank, trust in Bitcoin takes a dive=
, and we all feel the pain. Freezing those vulnerable funds keeps that chao=
s in check.<br />Plus, =E2=80=9Cyour keys, your coins=E2=80=9D is Bitcoin=
=E2=80=99s heart. If quantum tech can steal from you just because you didn=
=E2=80=99t upgrade fast enough, that promise feels shaky. Freezing funds af=
ter a heads-up period (say, four years) protects that idea better than lett=
ing tech giants or rogue states play vampire with our network. It also nudg=
es people to get their act together and move to safer addresses, which stre=
ngthens Bitcoin long-term.<br />Saulo=E2=80=99s right that freezing coins c=
ould confuse folks or spark a split like Ethereum Classic. But I=E2=80=99d =
argue quantum theft would look worse. Bitcoin would seem broken, not just s=
trict. A clear plan and enough time to migrate could smooth things over. Hi=
story=E2=80=99s on our side too. Bitcoin=E2=80=99s fixed bugs before, like =
SegWit. This feels like that, not a bailout.<br />So yeah, I=E2=80=99d rath=
er see vulnerable coins locked than handed to whoever builds the first quan=
tum rig. It=E2=80=99s less about coddling people and more about keeping Bit=
coin solid for everyone. What do you all think?<br />Cheers,<br />Agust=C3=
=ADn<br /><br /></div><br /><div><div dir=3D"ltr">On Sun, Mar 23, 2025 at 1=
0:29=E2=80=AFPM AstroTown &lt;<a rel=3D"noreferrer nofollow noopener">sa...=
@astrotown.de</a>&gt; wrote:<br /></div><blockquote style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=
><div dir=3D"auto"><div dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0);">I =
believe that having some entity announce the decision to freeze old UTXOs w=
ould be more damaging to Bitcoin=E2=80=99s image (and its value) than havin=
g them gathered by QC. This would create another version of Bitcoin, simila=
r to Ethereum Classic, causing confusion in the market.</span><div dir=3D"l=
tr"><div style=3D"color: rgb(0, 0, 0);"><br /></div><div style=3D"color: rg=
b(0, 0, 0);">It would be better to simply implement the possibility of movi=
ng funds to a PQC address without a deadline, allowing those who fail to do=
 so to rely on luck to avoid having their coins stolen. Most coins would be=
 migrated to PQC anyway, and in most cases, only the lost ones would remain=
 vulnerable. This is the free-market way to solve problems without imposing=
 rules on everyone.</div><div style=3D"color: rgb(0, 0, 0);"><br /></div><d=
iv style=3D"color: rgb(0, 0, 0);">Saulo Fonseca</div><div style=3D"color: r=
gb(0, 0, 0);"><br /></div><div style=3D"color: rgb(0, 0, 0);"><br /><blockq=
uote type=3D"cite"><div>On 16. Mar 2025, at 15:15, Jameson Lopp &lt;<span d=
ir=3D"ltr"><a rel=3D"noreferrer nofollow noopener">jameso...@gmail.com</a><=
/span>&gt; wrote:</div><br /><div><div dir=3D"ltr">The quantum computing de=
bate is heating up. There are many controversial aspects to this debate, in=
cluding whether or not quantum computers will ever actually become a practi=
cal threat.<div><br />I won't tread into the unanswerable question of how w=
orried we should be about quantum computers. I think it's far from a crisis=
, but given the difficulty in changing Bitcoin it's worth starting to serio=
usly discuss. Today I wish to focus on a philosophical quandary related to =
one of the decisions that would need to be made if and when we implement a =
quantum safe signature scheme.<br /><br /><font style=3D"color: rgb(0, 0, 0=
);" size=3D"6">Several Scenarios<br /></font>Because this essay will refere=
nce game theory a fair amount, and there are many variables at play that co=
uld change the nature of the game, I think it's important to clarify the po=
ssible scenarios up front.<br /><br />1. Quantum computing never materializ=
es, never becomes a threat, and thus everything discussed in this essay is =
moot.<br />2. A quantum computing threat materializes suddenly and Bitcoin =
does not have quantum safe signatures as part of the protocol. In this scen=
ario it would likely make the points below moot because Bitcoin would be fu=
ndamentally broken and it would take far too long to upgrade the protocol, =
wallet software, and migrate user funds in order to restore confidence in t=
he network.<br />3. Quantum computing advances slowly enough that we come t=
o consensus about how to upgrade Bitcoin and post quantum security has been=
 minimally adopted by the time an attacker appears.<br />4. Quantum computi=
ng advances slowly enough that we come to consensus about how to upgrade Bi=
tcoin and post quantum security has been highly adopted by the time an atta=
cker appears.<br /><br />For the purposes of this post, I'm envisioning bei=
ng in situation 3 or 4.<br /><br /><font style=3D"color: rgb(0, 0, 0);" siz=
e=3D"6">To Freeze or not to Freeze?<br /></font>I've started seeing more pe=
ople weighing in on what is likely the most contentious aspect of how a qua=
ntum resistance upgrade should be handled in terms of migrating user funds.=
 Should quantum vulnerable funds be left open to be swept by anyone with a =
sufficiently powerful quantum computer OR should they be permanently locked=
?<br /><br /><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204);">"I don't see why old coins sho=
uld be confiscated. The better option is to let those with quantum computer=
s free up old coins. While this might have an inflationary impact on bitcoi=
n's price, to use a turn of phrase, the inflation is transitory. Those with=
 low time preference should support returning lost coins to circulation." <=
/blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204);">- Hunter Beast</blockquote><div=
><br /></div>On the other hand:</div><div><br /><blockquote style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4);">"Of course they have to be confiscated. If and when (and that's a big =
if) the existence of a cryptography-breaking QC becomes a credible threat, =
the Bitcoin ecosystem has no other option than softforking out the ability =
to spend from signature schemes (including ECDSA and BIP340) that are vulne=
rable to QCs. The alternative is that millions of BTC become vulnerable to =
theft; I cannot see how the currency can maintain any value at all in such =
a setting. And this affects everyone; even those which diligently moved the=
ir coins to PQC-protected schemes."<br />- Pieter Wuille</blockquote><br />=
I don't think "confiscation" is the most precise term to use, as the funds =
are not being seized and reassigned. Rather, what we're really discussing w=
ould be better described as "burning" - placing the funds <b>out of reach o=
f everyone</b>.<br /><br />Not freezing user funds is one of Bitcoin's invi=
olable properties. However, if quantum computing becomes a threat to Bitcoi=
n's elliptic curve cryptography, <b>an inviolable property of Bitcoin will =
be violated one way or another</b>.<br /><br /><font style=3D"color: rgb(0,=
 0, 0);" size=3D"6">Fundamental Properties at Risk<br /></font>5 years ago =
I attempted to comprehensively categorize all of Bitcoin's fundamental prop=
erties that give it value. <a rel=3D"noreferrer nofollow noopener" href=3D"=
https://nakamoto.com/what-are-the-key-properties-of-bitcoin/" target=3D"_bl=
ank">https://nakamoto.com/what-are-the-key-properties-of-bitcoin/<br /></a>=
<br />The particular properties in play with regard to this issue seem to b=
e:<br /><br /><b>Censorship Resistance</b> - No one should have the power t=
o prevent others from using their bitcoin or interacting with the network.<=
br /><br /><b>Forward Compatibility</b> - changing the rules such that cert=
ain valid transactions become invalid could undermine confidence in the pro=
tocol.<br /><br /><b>Conservatism</b> - Users should not be expected to be =
highly responsive to system issues.<br /><br />As a result of the above pri=
nciples, we have developed a strong meme (kudos to Andreas Antonopoulos) th=
at goes as follows:<br /><br /><blockquote style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);">Not your key=
s, not your coins.</blockquote><br />I posit that the corollary to this pri=
nciple is:<br /><br /><blockquote style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204);">Your keys, only your =
coins.</blockquote><br />A quantum capable entity breaks the corollary of t=
his foundational principle. We secure our bitcoin with the mathematical pro=
babilities related to extremely large random numbers. Your funds are only s=
ecure because truly random large numbers should not be guessable or discove=
rable by anyone else in the world.<br /><br />This is the principle behind =
the motto <i>vires in numeris</i> - strength in numbers. In a world with qu=
antum enabled adversaries, this principle is null and void for many types o=
f cryptography, including the elliptic curve digital signatures used in Bit=
coin.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"6">Who is at =
Risk?<br /></font>There has long been a narrative that Satoshi's coins and =
others from the Satoshi era of P2PK locking scripts that exposed the public=
 key directly on the blockchain will be those that get scooped up by a quan=
tum "miner." But unfortunately it's not that simple. If I had a powerful qu=
antum computer, which coins would I target? I'd go to the Bitcoin rich list=
 and find the wallets that have exposed their public keys due to re-using a=
ddresses that have previously been spent from. You can easily find them at =
<a rel=3D"noreferrer nofollow noopener" href=3D"https://bitinfocharts.com/t=
op-100-richest-bitcoin-addresses.html" target=3D"_blank">https://bitinfocha=
rts.com/top-100-richest-bitcoin-addresses.html</a><br /><br />Note that a f=
ew of these wallets, like Bitfinex / Kraken / Tether, would be slightly har=
der to crack because they are multisig wallets. So a quantum attacker would=
 need to reverse engineer 2 keys for Kraken or 3 for Bitfinex / Tether in o=
rder to spend funds. But many are single signature.<br /><br />Point being,=
 it's not only the really old lost BTC that are at risk to a quantum enable=
d adversary, at least at time of writing. If we add a quantum safe signatur=
e scheme, we should expect those wallets to be some of the first to upgrade=
 given their incentives.<br /><br /><font style=3D"color: rgb(0, 0, 0);" si=
ze=3D"6">The Ethical Dilemma: Quantifying Harm<br /></font>Which decision r=
esults in the most harm?<br /><br />By making quantum vulnerable funds unsp=
endable we potentially harm some Bitcoin users who were not paying attentio=
n and neglected to migrate their funds to a quantum safe locking script. Th=
is violates the "conservativism" principle stated earlier. On the flip side=
, we prevent those funds plus far more lost funds from falling into the han=
ds of the few privileged folks who gain early access to quantum computers.<=
br /><br />By leaving quantum vulnerable funds available to spend, the same=
 set of users who would otherwise have funds frozen are likely to see them =
stolen. And many early adopters who lost their keys will eventually see the=
ir unreachable funds scooped up by a quantum enabled adversary.<br /><br />=
Imagine, for example, being James Howells, who accidentally threw away a ha=
rd drive with 8,000 BTC on it, currently worth over $600M USD. He has spent=
 a decade trying to retrieve it from the landfill where he knows it's burie=
d, but can't get permission to excavate. I suspect that, given the choice, =
he'd prefer those funds be permanently frozen rather than fall into someone=
 else's possession - I know I would.<br /><br />Allowing a quantum computer=
 to access lost funds doesn't make those users any worse off than they were=
 before, however it <i>would</i>have a negative impact upon everyone who is=
 currently holding bitcoin.<br /><br />It's prudent to expect significant e=
conomic disruption if large amounts of coins fall into new hands. Since a q=
uantum computer is going to have a massive up front cost, expect those behi=
nd it to desire to recoup their investment. We also know from experience th=
at when someone suddenly finds themselves in possession of 9+ figures worth=
 of highly liquid assets, they tend to diversify into other things by selli=
ng.<br /><br />Allowing quantum recovery of bitcoin is <i>tantamount to wea=
lth redistribution</i>. What we'd be allowing is for bitcoin to be redistri=
buted from those who are ignorant of quantum computers to those who have wo=
n the technological race to acquire quantum computers. It's hard to see a b=
right side to that scenario.<br /><br /><font style=3D"color: rgb(0, 0, 0);=
" size=3D"6">Is Quantum Recovery Good for Anyone?</font><br /><br />Does qu=
antum recovery HELP anyone? I've yet to come across an argument that it's a=
 net positive in any way. It certainly doesn't add any security to the netw=
ork. If anything, it greatly decreases the security of the network by allow=
ing funds to be claimed by those who did not earn them.<br /><br />But wait=
, you may be thinking, wouldn't quantum "miners" have earned their coins by=
 all the work and resources invested in building a quantum computer? I supp=
ose, in the same sense that a burglar earns their spoils by the resources t=
hey invest into surveilling targets and learning the skills needed to break=
 into buildings. What I say "earned" I mean through productive mutual trade=
.<br /><br />For example:<br /><br />* Investors earn BTC by trading for ot=
her currencies.<br />* Merchants earn BTC by trading for goods and services=
.<br />* Miners earn BTC by trading thermodynamic security.<br />* Quantum =
miners don't trade anything, they are vampires feeding upon the system.<br =
/><br />There's no reason to believe that allowing quantum adversaries to r=
ecover vulnerable bitcoin will be of benefit to anyone other than the selec=
t few organizations that win the technological arms race to build the first=
 such computers. Probably nation states and/or the top few largest tech com=
panies.<br /><br />One could certainly hope that an organization with quant=
um supremacy is benevolent and acts in a "white hat" manner to return lost =
coins to their owners, but that's incredibly optimistic and foolish to rely=
 upon. Such a situation creates an insurmountable ethical dilemma of only r=
ecovering lost bitcoin rather than currently owned bitcoin. There's no way =
to precisely differentiate between the two; anyone can claim to have lost t=
heir bitcoin but if they have lost their keys then proving they ever had th=
e keys becomes rather difficult. I imagine that any such white hat recovery=
 efforts would have to rely upon attestations from trusted third parties li=
ke exchanges.<br /><br />Even if the first actor with quantum supremacy is =
benevolent, we must assume the technology could fall into adversarial hands=
 and thus think adversarially about the potential worst case outcomes. Imag=
ine, for example, that North Korea continues scooping up billions of dollar=
s from hacking crypto exchanges and decides to invest some of those proceed=
s into building a quantum computer for the biggest payday ever...<br /><br =
/><font style=3D"color: rgb(0, 0, 0);" size=3D"6">Downsides to Allowing Qua=
ntum Recovery</font><br />Let's think through an exhaustive list of pros an=
d cons for allowing or preventing the seizure of funds by a quantum adversa=
ry.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Historical P=
recedent</font><br />Previous protocol vulnerabilities weren=E2=80=99t cele=
brated as "fair game" but rather were treated as failures to be remediated.=
 Treating quantum theft differently risks rewriting Bitcoin=E2=80=99s histo=
ry as a free-for-all rather than a system that seeks to protect its users.<=
br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Violation of Pro=
perty Rights</font><br />Allowing a quantum adversary to take control of fu=
nds undermines the fundamental principle of cryptocurrency - if you keep yo=
ur keys in your possession, only you should be able to access your money. B=
itcoin is built on the idea that private keys secure an individual=E2=80=99=
s assets, and unauthorized access (even via advanced tech) is theft, not a =
legitimate transfer.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=
=3D"4">Erosion of Trust in Bitcoin</font><br />If quantum attackers can exp=
loit vulnerable addresses, confidence in Bitcoin as a secure store of value=
 would collapse. Users and investors rely on cryptographic integrity, and w=
idespread theft could drive adoption away from Bitcoin, destabilizing its e=
cosystem.<br /><br />This is essentially the counterpoint to claiming the b=
urning of vulnerable funds is a violation of property rights. While some wi=
ll certainly see it as such, others will find the apathy toward stopping qu=
antum theft to be similarly concerning.<br /><br /><font style=3D"color: rg=
b(0, 0, 0);" size=3D"4">Unfair Advantage</font><br />Quantum attackers, lik=
ely equipped with rare and expensive technology, would have an unjust edge =
over regular users who lack access to such tools. This creates an inequitab=
le system where only the technologically elite can exploit others, contradi=
cting Bitcoin=E2=80=99s ethos of decentralized power.<br /><br />Bitcoin is=
 designed to create an asymmetric advantage for DEFENDING one's wealth. It'=
s supposed to be impractically expensive for attackers to crack the entropy=
 and cryptography protecting one's coins. But now we find ourselves discuss=
ing a situation where this asymmetric advantage is compromised in favor of =
a specific class of attackers.<br /><br /><font style=3D"color: rgb(0, 0, 0=
);" size=3D"4">Economic Disruption</font><br />Large-scale theft from vulne=
rable addresses could crash Bitcoin=E2=80=99s price as quantum recovered fu=
nds are dumped on exchanges. This would harm all holders, not just those di=
rectly targeted, leading to broader financial chaos in the markets.<br /><b=
r /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Moral Responsibility</f=
ont><br />Permitting theft via quantum computing sets a precedent that tech=
nological superiority justifies unethical behavior. This is essentially tak=
ing a "code is law" stance in which we refuse to admit that both code and l=
aws can be modified to adapt to previously unforeseen situations.<br /><br =
/>Burning of coins can certainly be considered a form of theft, thus I thin=
k it's worth differentiating the two different thefts being discussed:<br /=
><br />1. self-enriching &amp; likely malicious<br />2. harm prevention &am=
p; not necessarily malicious<br /><br />Both options lack the consent of th=
e party whose coins are being burnt or transferred, thus I think the simple=
 argument that theft is immoral becomes a wash and it's important to drill =
down into the details of each.<br /><br /><font style=3D"color: rgb(0, 0, 0=
);" size=3D"4">Incentives Drive Security</font><br />I can tell you from a =
decade of working in Bitcoin security - the average user is lazy and is a p=
rocrastinator. If Bitcoiners are given a "drop dead date" after which they =
know vulnerable funds will be burned, this pressure accelerates the adoptio=
n of post-quantum cryptography and strengthens Bitcoin long-term. Allowing =
vulnerable users to delay upgrading indefinitely will result in more laggar=
ds, leaving the network more exposed when quantum tech becomes available.<b=
r /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"6">Steel Manning<br =
/></font>Clearly this is a complex and controversial topic, thus it's worth=
 thinking through the opposing arguments.<br /><br /><font style=3D"color: =
rgb(0, 0, 0);" size=3D"4">Protecting Property Rights</font><br />Allowing q=
uantum computers to take vulnerable bitcoin could potentially be spun as a =
hard money narrative - we care so greatly about not violating someone's acc=
ess to their coins that we allow them to be stolen!<br /><br />But I think =
the flip side to the property rights narrative is that burning vulnerable c=
oins prevents said property from falling into undeserving hands. If the ent=
ire Bitcoin ecosystem just stands around and allows quantum adversaries to =
claim funds that rightfully belong to other users, is that really a "win" i=
n the "protecting property rights" category? It feels more like apathy to m=
e.<br /><br />As such, I think the "protecting property rights" argument is=
 a wash.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Quantum=
 Computers Won't Attack Bitcoin</font><br />There is a great deal of skepti=
cism that sufficiently powerful quantum computers will ever exist, so we sh=
ouldn't bother preparing for a non-existent threat. Others have argued that=
 even if such a computer was built, a quantum attacker would not go after b=
itcoin because they wouldn't want to reveal their hand by doing so, and wou=
ld instead attack other infrastructure.<br /><br />It's quite difficult to =
quantify exactly how valuable attacking other infrastructure would be. It a=
lso really depends upon when an entity gains quantum supremacy and thus if =
by that time most of the world's systems have already been upgraded. While =
I think you could argue that certain entities gaining quantum capability mi=
ght not attack Bitcoin, it would only delay the inevitable - eventually som=
ebody will achieve the capability who decides to use it for such an attack.=
<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Quantum Attacke=
rs Would Only Steal Small Amounts</font><br />Some have argued that even if=
 a quantum attacker targeted bitcoin, they'd only go after old, likely lost=
 P2PK outputs so as to not arouse suspicion and cause a market panic.<br />=
<br />I'm not so sure about that; why go after 50 BTC at a time when you co=
uld take 250,000 BTC with the same effort as 50 BTC? This is a classic "zer=
o day exploit" game theory in which an attacker knows they have a limited a=
mount of time before someone else discovers the exploit and either benefits=
 from it or patches it. Take, for example, the recent ByBit attack - the hi=
ghest value crypto hack of all time. Lazarus Group had compromised the Safe=
 wallet front end JavaScript app and they could have simply had it reassign=
 ownership of everyone's Safe wallets as they were interacting with their w=
allet. But instead they chose to only specifically target ByBit's wallet wi=
th $1.5 billion in it because they wanted to maximize their extractable val=
ue. If Lazarus had started stealing from every wallet, they would have been=
 discovered quickly and the Safe web app would likely have been patched wel=
l before any billion dollar wallets executed the malicious code.<br /><br /=
>I think the "only stealing small amounts" argument is strongest for Situat=
ion #2 described earlier, where a quantum attacker arrives before quantum s=
afe cryptography has been deployed across the Bitcoin ecosystem. Because if=
 it became clear that Bitcoin's cryptography was broken AND there was nowhe=
re safe for vulnerable users to migrate, the only logical option would be f=
or everyone to liquidate their bitcoin as quickly as possible. As such, I d=
on't think it applies as strongly for situations in which we have a migrati=
on path available.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"=
4">The 21 Million Coin Supply Should be in Circulation</font><br />Some fol=
ks are arguing that it's important for the "circulating / spendable" supply=
 to be as close to 21M as possible and that having a significant portion of=
 the supply out of circulation is somehow undesirable.<br /><br />While the=
 "21M BTC" attribute is a strong memetic narrative, I don't think anyone ha=
s ever expected that it would all be in circulation. It has always been und=
erstood that many coins will be lost, and that's actually part of the game =
theory of owning bitcoin!<br /><br />And remember, the 21M number in and of=
 itself is not a particularly important detail - it's not even mentioned in=
 the whitepaper. What's important is that the supply is well known and not =
subject to change.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"=
4">Self-Sovereignty and Personal Responsibility</font><br />Bitcoin=E2=80=
=99s design empowers individuals to control their own wealth, free from cen=
tralized intervention. This freedom comes with the burden of securing one's=
 private keys. If quantum computing can break obsolete cryptography, the fa=
ult lies with users who didn't move their funds to quantum safe locking scr=
ipts. Expecting the network to shield users from their own negligence under=
mines the principle that you, and not a third party, are accountable for yo=
ur assets.<br /><br />I think this is generally a fair point that "the comm=
unity" doesn't owe you anything in terms of helping you. I think that we do=
, however, need to consider the incentives and game theory in play with reg=
ard to quantum safe Bitcoiners vs quantum vulnerable Bitcoiners. More on th=
at later.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Code i=
s Law</font><br />Bitcoin operates on transparent, immutable rules embedded=
 in its protocol. If a quantum attacker uses superior technology to derive =
private keys from public keys, they=E2=80=99re not "hacking" the system - t=
hey're simply following what's mathematically permissible within the curren=
t code. Altering the protocol to stop this introduces subjective human inte=
rvention, which clashes with the objective, deterministic nature of blockch=
ain.<br /><br />While I tend to agree that code is law, one of the entire p=
oints of laws is that they can be amended to improve their efficacy in redu=
cing harm. Leaning on this point seems more like a pro-ossification stance =
that it's better to do nothing and allow harm to occur rather than take act=
ion to stop an attack that was foreseen far in advance.<br /><br /><font st=
yle=3D"color: rgb(0, 0, 0);" size=3D"4">Technological Evolution as a Featur=
e, Not a Bug</font><br />It's well known that cryptography tends to weaken =
over time and eventually break. Quantum computing is just the next step in =
this progression. Users who fail to adapt (e.g., by adopting quantum-resist=
ant wallets when available) are akin to those who ignored technological adv=
ancements like multisig or hardware wallets. Allowing quantum theft incenti=
vizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic, punishing c=
omplacency while rewarding vigilance.<br /><br /><font style=3D"color: rgb(=
0, 0, 0);" size=3D"4">Market Signals Drive Security</font><br />If quantum =
attackers start stealing funds, it sends a clear signal to the market: upgr=
ade your security or lose everything. This pressure accelerates the adoptio=
n of post-quantum cryptography and strengthens Bitcoin long-term. Coddling =
vulnerable users delays this necessary evolution, potentially leaving the n=
etwork more exposed when quantum tech becomes widely accessible. Theft is a=
 brutal but effective teacher.<br /><br /><font style=3D"color: rgb(0, 0, 0=
);" size=3D"4">Centralized Blacklisting Power</font><br />Burning vulnerabl=
e funds requires centralized decision-making - a soft fork to invalidate ce=
rtain transactions. This sets a dangerous precedent for future intervention=
s, eroding Bitcoin=E2=80=99s decentralization. If quantum theft is blocked,=
 what=E2=80=99s next - reversing exchange hacks? The system must remain neu=
tral, even if it means some lose out.<br /><br />I think this could be a po=
tential slippery slope if the proposal was to only burn specific addresses.=
 Rather, I'd expect a neutral proposal to burn all funds in locking script =
types that are known to be quantum vulnerable. Thus, we could eliminate any=
 subjectivity from the code.<br /><br /><font style=3D"color: rgb(0, 0, 0);=
" size=3D"4">Fairness in Competition</font><br />Quantum attackers aren't c=
heating; they're using publicly available physics and math. Anyone with the=
 resources and foresight can build or access quantum tech, just as anyone c=
ould mine Bitcoin in 2009 with a CPU. Early adopters took risks and reaped =
rewards; quantum innovators are doing the same. Calling it =E2=80=9Cunfair=
=E2=80=9D ignores that Bitcoin has never promised equality of outcome - onl=
y equality of opportunity within its rules.<br /><br />I find this argument=
 to be a mischaracterization because we're not talking about CPUs. This is =
more akin to talking about ASICs, except each ASIC costs millions if not bi=
llions of dollars. This is out of reach from all but the wealthiest organiz=
ations.<br /><br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Economic=
 Resilience</font><br />Bitcoin has weathered thefts before (MTGOX, Bitfine=
x, FTX, etc) and emerged stronger. The market can absorb quantum losses, wi=
th unaffected users continuing to hold and new entrants buying in at lower =
prices. Fear of economic collapse overestimates the impact - the network=E2=
=80=99s antifragility thrives on such challenges.<br /><br />This is a big =
grey area because we don't know when a quantum computer will come online an=
d we don't know how quickly said computers would be able to steal bitcoin. =
If, for example, the first generation of sufficiently powerful quantum comp=
uters were stealing less volume than the current block reward then of cours=
e it will have minimal economic impact. But if they're taking thousands of =
BTC per day and bringing them back into circulation, there will likely be a=
 noticeable market impact as it absorbs the new supply.<br /><br />This is =
where the circumstances will really matter. If a quantum attacker appears A=
FTER the Bitcoin protocol has been upgraded to support quantum resistant cr=
yptography then we should expect the most valuable active wallets will have=
 upgraded and the juiciest target would be the 31,000 BTC in the address 12=
ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant since 2010. In gene=
ral I'd expect that the amount of BTC re-entering the circulating supply wo=
uld look somewhat similar to the mining emission curve: volume would start =
off very high as the most valuable addresses are drained and then it would =
fall off as quantum computers went down the list targeting addresses with l=
ess and less BTC.<br /><br />Why is economic impact a factor worth consider=
ing? Miners and businesses in general. More coins being liquidated will pus=
h down the price, which will negatively impact miner revenue. Similarly, I =
can attest from working in the industry for a decade, that lower prices res=
ult in less demand from businesses across the entire industry. As such, bur=
ning quantum vulnerable bitcoin is good for the entire industry.<br /><br /=
><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Practicality &amp; Neutral=
ity of Non-Intervention</font><br />There=E2=80=99s no reliable way to dist=
inguish =E2=80=9Ctheft=E2=80=9D from legitimate "white hat" key recovery. I=
f someone loses their private key and a quantum computer recovers it, is th=
at stealing or reclaiming? Policing quantum actions requires invasive assum=
ptions about intent, which Bitcoin=E2=80=99s trustless design can=E2=80=99t=
 accommodate. Letting the chips fall where they may avoids this mess.<br />=
<br /><font style=3D"color: rgb(0, 0, 0);" size=3D"4">Philosophical Purity<=
/font><br />Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system wher=
e outcomes reflect preparation and skill, not sentimentality. If quantum co=
mputing upends the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t m=
eant to be safe or fair in a nanny-state sense; it=E2=80=99s meant to be fr=
ee. Users who lose funds to quantum attacks are casualties of liberty and t=
heir own ignorance, not victims of injustice.<br /><br /><font style=3D"col=
or: rgb(0, 0, 0);" size=3D"6">Bitcoin's DAO Moment</font><br />This situati=
on has some similarities to The DAO hack of an Ethereum smart contract in 2=
016, which resulted in a fork to stop the attacker and return funds to thei=
r original owners. The game theory is similar because it's a situation wher=
e a threat is known but there's some period of time before the attacker can=
 actually execute the theft. As such, there's time to mitigate the attack b=
y changing the protocol.<br /><br />It also created a schism in the communi=
ty around the true meaning of "code is law," resulting in Ethereum Classic,=
 which decided to allow the attacker to retain control of the stolen funds.=
<br /><br />A soft fork to burn vulnerable bitcoin could certainly result i=
n a hard fork if there are enough miners who reject the soft fork and conti=
nue including transactions.<br /><br /><font style=3D"color: rgb(0, 0, 0);"=
 size=3D"6">Incentives Matter</font><br />We can wax philosophical until th=
e cows come home, but what are the actual incentives for existing Bitcoin h=
olders regarding this decision?<br /><br /><blockquote style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);">=
"Lost coins only make everyone else's coins worth slightly more. Think of i=
t as a donation to everyone." - Satoshi Nakamoto</blockquote><br />If true,=
 the corollary is:<br /><br /><blockquote style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204);">"Quantum reco=
vered coins only make everyone else's coins worth less. Think of it as a th=
eft from everyone." - Jameson Lopp</blockquote><br />Thus, assuming we get =
to a point where quantum resistant signatures are supported within the Bitc=
oin protocol, what's the incentive to let vulnerable coins remain spendable=
?<br /><br />* It's not good for the actual owners of those coins. It disin=
centivizes owners from upgrading until perhaps it's too late.<br />* It's n=
ot good for the more attentive / responsible owners of coins who have quant=
um secured their stash. Allowing the circulating supply to balloon will ass=
uredly reduce the purchasing power of all bitcoin holders.<br /><br /><font=
 style=3D"color: rgb(0, 0, 0);" size=3D"6">Forking Game Theory</font><br />=
From a game theory point of view, I see this as incentivizing users to upgr=
ade their wallets. If you disagree with the burning of vulnerable coins, al=
l you have to do is move your funds to a quantum safe signature scheme. Poi=
nt being, I don't see there being an economic majority (or even more than a=
 tiny minority) of users who would fight such a soft fork. Why expend signi=
ficant resources fighting a fork when you can just move your coins to a new=
 address?<br /><br />Remember that blocking spending of certain classes of =
locking scripts is a tightening of the rules - a soft fork. As such, it can=
 be meaningfully enacted and enforced by a mere majority of hashpower. If m=
iners generally agree that it's in their best interest to burn vulnerable c=
oins, are other users going to care enough to put in the effort to run new =
node software that resists the soft fork? Seems unlikely to me.<br /><br />=
<font style=3D"color: rgb(0, 0, 0);" size=3D"6">How to Execute Burning</fon=
t><br />In order to be as objective as possible, the goal would be to annou=
nce to the world that after a specific block height / timestamp, Bitcoin no=
des will no longer accept transactions (or blocks containing such transacti=
ons) that spend funds from any scripts other than the newly instituted quan=
tum safe schemes.<br /><br />It could take a staggered approach to first fr=
eeze funds that are susceptible to long-range attacks such as those in P2PK=
 scripts or those that exposed their public keys due to previously re-using=
 addresses, but I expect the additional complexity would drive further cont=
roversy.<br /><br />How long should the grace period be in order to give th=
e ecosystem time to upgrade? I'd say a minimum of 1 year for software walle=
ts to upgrade. We can only hope that hardware wallet manufacturers are able=
 to implement post quantum cryptography on their existing hardware with onl=
y a firmware update.<br /><br />Beyond that, it will take at least 6 months=
 worth of block space for all users to migrate their funds, even in a best =
case scenario. Though if you exclude dust UTXOs you could probably get 95% =
of BTC value migrated in 1 month. Of course this is a highly optimistic sit=
uation where everyone is completely focused on migrations - in reality it w=
ill take far longer.<br /><br />Regardless, I'd think that in order to reas=
onably uphold Bitcoin's conservatism it would be preferable to allow a 4 ye=
ar migration window. In the meantime, mining pools could coordinate emergen=
cy soft forking logic such that if quantum attackers materialized, they cou=
ld accelerate the countdown to the quantum vulnerable funds burn.<br /><br =
/><font style=3D"color: rgb(0, 0, 0);" size=3D"6">Random Tangential Benefit=
s</font><br />On the plus side, burning all quantum vulnerable bitcoin woul=
d allow us to prune all of those UTXOs out of the UTXO set, which would als=
o clean up a lot of dust. Dust UTXOs are a bit of an annoyance and there ha=
s even been a recent proposal for how to incentivize cleaning them up.<br /=
><br />We should also expect that incentivizing migration of the entire UTX=
O set will create substantial demand for block space that will sustain a fe=
e market for a fairly lengthy amount of time.<br /><br /><font style=3D"col=
or: rgb(0, 0, 0);" size=3D"6">In Summary</font><br />While the moral quanda=
ry of violating any of Bitcoin's inviolable properties can make this a very=
 complex issue to discuss, the game theory and incentives between burning v=
ulnerable coins versus allowing them to be claimed by entities with quantum=
 supremacy appears to be a much simpler issue.<br /><br />I, for one, am no=
t interested in rewarding quantum capable entities by inflating the circula=
ting money supply just because some people lost their keys long ago and som=
e laggards are not upgrading their bitcoin wallet's security.<br /><br />We=
 can hope that this scenario never comes to pass, but hope is not a strateg=
y.<br /><br />I welcome your feedback upon any of the above points, and con=
tribution of any arguments I failed to consider.</div></div><div><br /></di=
v>-- <br />You received this message because you are subscribed to the Goog=
le Groups "Bitcoin Development Mailing List" group.<br />To unsubscribe fro=
m this group and stop receiving emails from it, send an email to <a rel=3D"=
noreferrer nofollow noopener">bitcoindev+...@googlegroups.com</a>.<br />To =
view this discussion visit <a rel=3D"noreferrer nofollow noopener" href=3D"=
https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq8nA_4=
RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com" target=3D"_blank">https://g=
roups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%=
3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com</a>.</div></blockquote></div><div dir=
=3D"ltr"></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br />
To view this discussion visit <a rel=3D"noreferrer nofollow noopener" href=
=3D"https://groups.google.com/d/msgid/bitcoindev/E8269A1A-1899-46D2-A7CD-4D=
9D2B732364%40astrotown.de" target=3D"_blank">https://groups.google.com/d/ms=
gid/bitcoindev/E8269A1A-1899-46D2-A7CD-4D9D2B732364%40astrotown.de</a>.</bl=
ockquote></div></div></blockquote></div><div><blockquote type=3D"cite"><div=
 dir=3D"ltr"><div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br />
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br />
To view this discussion visit <a rel=3D"noreferrer nofollow noopener" href=
=3D"https://groups.google.com/d/msgid/bitcoindev/CAJDmzYxw%2BmXQKjS%2Bh%2Br=
6mCoe1rwWUpa_yZDwmwx6U_eO5JhZLg%40mail.gmail.com" target=3D"_blank">https:/=
/groups.google.com/d/msgid/bitcoindev/CAJDmzYxw%2BmXQKjS%2Bh%2Br6mCoe1rwWUp=
a_yZDwmwx6U_eO5JhZLg%40mail.gmail.com</a>.<br />

        </blockquote><br />
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br />
To view this discussion visit <a rel=3D"noreferrer nofollow noopener" href=
=3D"https://groups.google.com/d/msgid/bitcoindev/zyx7G6H1TyB2sWVEKAfIYmCCvf=
XniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuHMjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXL=
miCJOY%3D%40proton.me" target=3D"_blank">https://groups.google.com/d/msgid/=
bitcoindev/zyx7G6H1TyB2sWVEKAfIYmCCvfXniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuH=
Mjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXLmiCJOY%3D%40proton.me</a>.<br />
</blockquote></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br /></blockquote></div></div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px;"><div><blockquote type=3D"cite">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJDmzYycnXODG_e9ATqTkooUu3C-RS703P1-RQLW5CdcCehsqg%40mail.gmail=
.com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://groups=
.google.com/d/msgid/bitcoindev/CAJDmzYycnXODG_e9ATqTkooUu3C-RS703P1-RQLW5Cd=
cCehsqg%40mail.gmail.com</a>.<br />

        </blockquote><br />
    </div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"" rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.<=
br /></blockquote></div><div><blockquote style=3D"margin: 0px 0px 0px 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/893891ea-34ec-4d60-9941-9f636be0d747n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow">htt=
ps://groups.google.com/d/msgid/bitcoindev/893891ea-34ec-4d60-9941-9f636be0d=
747n%40googlegroups.com</a>.<br />
</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">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/1ae281cd-20a8-4b50-98b7-c228f090ad7an%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/1ae281cd-20a8-4b50-98b7-c228f090ad7an%40googlegroups.com</a>.<br />

------=_Part_56917_1482186618.1752370741011--

------=_Part_56916_2133222854.1752370741011--