path: root/8d/43a26e41c901373eed2e57acfa5f1c310f886e

Delivery-date: Tue, 15 Jul 2025 06:57:34 -0700
Received: from mail-yb1-f183.google.com ([209.85.219.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBP543HBQMGQEMOLN3KY@googlegroups.com>)
	id 1ubg9x-0002H2-Q8
	for bitcoindev@gnusha.org; Tue, 15 Jul 2025 06:57:34 -0700
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e8bb30fdd8bsf1435561276.1
        for <bitcoindev@gnusha.org>; Tue, 15 Jul 2025 06:57:29 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752587843; cv=pass;
        d=google.com; s=arc-20240605;
        b=dr+cC9zMAGQTCvtUnmCIiQU4orEZkiOiaBiYK7ZNzM9DiXk0uRhjBLhsuCmSOqQE5A
         Ku4LEpaW23nCI8rtB1n4ACXeSzF+KT6Y5TXGN+avPiRvY3b7IWEggVGi5fsgnDWW2u3i
         DeSXzxewfatZ/yIvKVDJlLqoSg3unWwPgpF2xyLjdXz0Sd2dPAGUwDyIg6U4ddUF8PSh
         WJ2iSdTUocjKmjZh1bhK0FSXm4gx3AEXDXCR0xwMelXaIzFUcS2oKqS3CsvNI2lMEWjg
         aLn+9McuGco91vk42Zl7BwJZsXGOERfrh+Y+u49E+2euYT4V33yqgMBqhf07LrKWz2JU
         0Kqg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=hWFduv76hrAciF7BERZiVxdXnh4SGcwXpLvt+C3LAfA=;
        fh=uKy8Q2BJioGWOJApOi//gVlWtbFYW0kiQQY+mm5IDDY=;
        b=MO2FfT/3YPw0QpB7dBdbkRzuxkxxmA1QwAUkp93WVkphesJkwRk7DnLzucNPuKcpPx
         j3FjgZgpxSCa74Rswmd+6Q9AGkOgvkbWa/U+zWhCBVsdbOWduZEvXXlYcagc9zOUfJqR
         ypIIDu+PyZ2rOXtGrhb6Xv8A78TqEd51W3XI+JYbSOTj3aD364ExEGy9dq3AcYIeb0Ci
         +ArZ6ryasmguQ9eLpZ6SYdd50pRd7eaIHQnczdqbmms4M2Oae/WTSk7fFOyQhtGiYyBl
         e2gjRHISXrbPlOK7rGZ6etr93A4+CN0IW302c1NR8LYAYDz8nPsXrv4lHAAmZm80wLwD
         be7g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=nDLCRd3N;
       spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752587843; x=1753192643; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=hWFduv76hrAciF7BERZiVxdXnh4SGcwXpLvt+C3LAfA=;
        b=NoFwiDOlB666HSyTvj9pMbC0L40emWjOyPLrNJFH1X0SU5HJMKjVKFTdPrxsU+kiiY
         F2gH33mFh8KDhWlDxuMe2cujRq7ngcc9VsJuBnoJmhAgx0RqT7PzfZEqWK9HOfKCzSxw
         DO2eArcFLAMLYn60sd3HNKeJXEFRLtlf0UqYcMPMo9m8S5LBSqfcrjY0PXHh6+SxTik4
         CkoEb0OYAWKwVJFbwV6+lDMLOuZs08YTVChuLWPs7gDnLY6O2s1ZnqDJAQdJh2GCJm4A
         ieeaxy+16rJmTMuscWnWsy+/vaAVQEaUJw4K+hzDHL+xBjcSrXvOBb4jCoPc2LQuQBLI
         Gp8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752587843; x=1753192643;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hWFduv76hrAciF7BERZiVxdXnh4SGcwXpLvt+C3LAfA=;
        b=ZsQz7hv8GVcJlubyILAfgZkporK4PJyEFfqqU74XFmXCiiywXZP/aqkJqIypTVyCHx
         ILisy91HRDMZdN/nEDn2SAuziPCFrRkoiW7QW0fnXV4c6+GkdWfQZtvvEdlss/laSwck
         TWyA9cWgp33gF4C8bkdXV+Ea9/hMVBpun5nQHYQquDz6knHVTEmKf+bJP60jG1zXP4o0
         8B4dYWwL/aFsebDGNoqg4+8VEao7wHV+snGUXGFymEfFxn7WfNKt4hBEmqXrTPWT5Or2
         UadW1AL6koBNGj+fYx1H0Ksz3XmuaC6GBQpgaeLK5Kj6FUSCG8wGpUcO1rpMMWLLhGsk
         BIaA==
X-Forwarded-Encrypted: i=2; AJvYcCVb7Od2hx3ihkFSk/gSi+zF6xxTeGaiTGDKybVZy/M/YRGQF5FlXkduMLuVBb+KgMDpSXRWW805VqWf@gnusha.org
X-Gm-Message-State: AOJu0YztPfgpwhExh2RYbA1CETdGnSKKeIHlZFmB5ohzhYhAw4YqOQiB
	B2NIO4H/rxYeH0qk9LJtE7rS619mLsCm+al9nf2Ry4ECF9DMpbWqR0wB
X-Google-Smtp-Source: AGHT+IE+Tziq0T7gRu3P0IjvK8osm/CMRyYZ3PaSvoYLDcVcX2/PMNfXx7ndNLPs4QLw2G5NRUeYPw==
X-Received: by 2002:a05:6902:1107:b0:e8b:8b4b:7a77 with SMTP id 3f1490d57ef6-e8b8b4b7bbdmr19318795276.38.1752587843385;
        Tue, 15 Jul 2025 06:57:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZetVfGJLqbKoIy+fAHMQn39XkI3gVQQ2oPDCtrFcIMgZQ==
Received: by 2002:a25:b853:0:b0:e87:adad:c527 with SMTP id 3f1490d57ef6-e8b77970c92ls5502147276.1.-pod-prod-04-us;
 Tue, 15 Jul 2025 06:57:19 -0700 (PDT)
X-Received: by 2002:a05:690c:7406:b0:70f:83ef:ddf7 with SMTP id 00721157ae682-717d5bb20b9mr258277317b3.13.1752587839066;
        Tue, 15 Jul 2025 06:57:19 -0700 (PDT)
Received: by 2002:a05:6504:4104:b0:2b1:9db7:3101 with SMTP id a1c4a302cd1d6-2b919166b79msc7a;
        Tue, 15 Jul 2025 06:53:39 -0700 (PDT)
X-Received: by 2002:a05:6512:3f08:b0:553:2fa8:8405 with SMTP id 2adb3069b0e04-55a04646f50mr4746581e87.56.1752587616967;
        Tue, 15 Jul 2025 06:53:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752587616; cv=none;
        d=google.com; s=arc-20240605;
        b=iFPHVx4oIgUaldjqkW/V7Nhc2Ulsr6Qrl6BDwPQER1xJOiKgQffR7g17pK5s48v/yk
         0u2Q5LxPcwV/nnu2qbqgsKLT9wcSxDZu9jDdtKxeGMlo5352oGzLUY4087NBnSrDmm9T
         KTt68/y1eUZMBweP0TnTw+TWGkFq7kJaq1DeGcgPZsPhtdxfLtCC24qYTOhftyvNYvBP
         pLlxfdm1AzfrYCQWc/Cb5M2pycduex0rhww2+a1sImHPfeqHQZWHQrGQxdwryz+d5z6k
         EBf9EG+8Q0XhuebuFgUqmanIX/ZOA7h9K62nZU+TStKtQ3BfzGg+rjs5Rbitxu4PgXjY
         UKaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=TGycckdog3Hm4EHCFNwKIj5l1469z4xcYjkF+GzgDeE=;
        fh=IjJ4Hsku15sQ70LD2KCSw5eS52eUGrJ7LnPNN9faUA8=;
        b=gVLUcuNkeK32XlbM+bYuFg4iJ0q/S/5JINaN8COH/EOV7zssw7Zr2FX5ggs4R65w0O
         DLFR9mDNi6CD848qHILrlJH4UK08eFsmc3tWPKdw4LHJlTyFIzlfvMeDimmiO++NGCpz
         xfnaRIqHFdAcGBM9ADfh6obsFAXeltutLtA1yLS+vLWt2l2IaFGQwsYPdFQMP0EZFmxZ
         EtGUqE/FZNTSyw+owVKDwDPq+IX1Rrxmyb5JlDBszicO6JYLE1JPx9kT8CtEkDFZJu8Z
         Exi23tN0I2n+0qdah0C29SWue18QF5X/CcM0t5rXuDRKVOoofLmBaNdeGuupmgzF+7FJ
         TsAg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=nDLCRd3N;
       spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-55935bbe6f5si269011e87.0.2025.07.15.06.53.36
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 15 Jul 2025 06:53:36 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Tue, 15 Jul 2025 13:53:30 +0000
To: Or Sattath <sattath@gmail.com>
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Against Allowing Quantum Recovery of Bitcoin
Message-ID: <0RX5JBKPTu3wDQH4tN3_CNwZnd6uFDuJ8GfDzx5JI4QriY6YssYmtcJm9WqHheayARK85OzGNVTts8gcLXEQNoF9VZ5ZchSzuD1WAKuPNu0=@proton.me>
In-Reply-To: <f17de19d-a6f5-46b3-abcd-09c056d9bd64n@googlegroups.com>
References: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com> <f17de19d-a6f5-46b3-abcd-09c056d9bd64n@googlegroups.com>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: e20713e3cbd0777d785560592cc7e47e6c420d80
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------2e35b45f1c467867d01e8624a74a1801e3bdee86a0d8b0dc28d3fd5ca1ca4658"; charset=utf-8
X-Original-Sender: conduition@proton.me
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@proton.me header.s=protonmail header.b=nDLCRd3N;       spf=pass
 (google.com: domain of conduition@proton.me designates 185.70.43.22 as
 permitted sender) smtp.mailfrom=conduition@proton.me;       dmarc=pass
 (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------2e35b45f1c467867d01e8624a74a1801e3bdee86a0d8b0dc28d3fd5ca1ca4658
Content-Type: multipart/mixed;boundary=---------------------518cf87f94814a86cfeeac9d59f64d63

-----------------------518cf87f94814a86cfeeac9d59f64d63
Content-Type: multipart/alternative;boundary=---------------------7efa4d59818fa25a4482a23e407dfa74

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

Thanks for pointing this out Or. For those not familiar with Or's approach,=
 it would share many of the same properties as the folklore BIP39 zk-STARK =
approach discussed elsewhere. It uses Picnic in the same way, to prove (in =
zero-knowledge) either:


-   (For UTXOs whose pubkeys are exposed) I know a BIP39 seed that derives =
an EC secret key such that `hash160(pubkey(ec_secret)) =3D=3D <hash>`
-   (For UTXOs whose pubkeys are still secret) I know a public key such tha=
t `hash160(pubkey) =3D=3D <hash>`
   =20



From Or's paper, section 2.5:


> Spending Hashed UTXOs: To spend a hashed UTXO, the user signs it with a k=
ey-lifted=C2=A0signature (see Section 2.2).
>=20

> Spending Derived UTXOs: To spend a derived UTXO, the user signs it with a=
 seed-lifted=C2=A0signature (see Section 2.3).



I see a couple problems with this. We won't be able to straight-up replace =
the EC signature with a Picnic signature without a hard fork. Old Bitcoin c=
lients will still need to see a valid EC signature and verify `hash160(pubk=
ey) =3D=3D <hash>` by classical re-computation. This exposes the EC pubkey,=
 which would let a QC attacker forge new key-lifted signatures. Thus, sadly=
, we can't rely on key-lifted signatures.


That said, we don't=C2=A0always=C2=A0require a hard fork as you note in the=
 paper. It's totally fine to expose the EC signature and pubkey if=C2=A0we =
also have a way to prove honest derivation of the EC secret key from a seed=
, and as long as that proof commits to the same transaction. Either seed-li=
fted Picnic signatures or ZK-STARKs could satisfy this. To get soft-fork ba=
ckwards-compatibility, we'd introduce a new transaction data field to carry=
 the proof, much like segwit added the witness data field. Then we require =
new clients to reject any EC signatures unless accompanied by this "proof-o=
f-seed-derivation". Old clients still see valid EC spend TXs. Soft fork ach=
ieved.

As for the "Lifted FawkesCoin" commit/reveal protocol, it has some issues. =
I think it'd require a hard fork to implement as there are some properties =
of the protocol which we can't enforce without relaxing consensus rules. Fo=
r example, letting miners claim UTXOs using the post-quantum proofs of owne=
rship:


> After the commitment has been posted, the spender has a limited time to p=
ost a reveal of the=C2=A0commitment to the blockchain. If they fail to do s=
o, the miner can post the proof of ownershipto claim the entire UTXO, makin=
g spam attempts costly=C2=A0



This is impossible without relaxing consensus rules on existing UTXOs' scri=
pt pubkeys. Donating half of a TX's mining fees to an unrelated miner would=
 also need a hard fork:


> The fee paid for including tx is split equally between the miner who=C2=
=A0included tx and the miner who included (H(tx))


(though this might be fixable if you modify the protocol to instead require=
 direct payment to the address of the miner who mined the H(tx) commitment.=
)

The other problem is incentives. Why would miners ever mine a Lifted Fawkes=
Coin reveal TX if they could simply wait and claim the pre-quantum UTXO the=
mselves using the proof of ownership? The protocol seems to rely on miners =
ignoring this opportunity, or at least that the major mining pools won't co=
llude to exploit it. The "Restrictive FawkesCoin" protocol would seem to fi=
x this problem though.

Finally, the consensus implementation complexity for any Fawkescoin impleme=
ntation would be enormous. There are so many context-specific validation st=
eps. The modifications described in section 3.3 and section 4 only further =
exacerbate this. Sections 3 thru 5 describe all the various Fawkescoin prot=
ocols and modifications, and in total they are 16 pages long. I don't expec=
t anyone could push that much protocol complexity into consensus in the nex=
t decade.

We're having a hard enough time coming to consensus on the "to freeze or no=
t to freeze" debate, the OP_CTV debate, the OP_CAT debate, etc. I don't see=
 a future where Bitcoin users can even comprehend=C2=A0all the rules and pa=
rameters included in the final FawkesCoin-driven protocol, let alone a worl=
d where we can all agree on=C2=A0them. We need something simpler, more clos=
ely aligned with existing consensus rules, that can be implemented and slot=
ted into existing BIPs and UX neatly.

Personally I think the answer is to require a proof-of-seed-knowledge to sp=
end any EC-signature-locked UTXO, and to implement it as a soft fork. It'd =
be expensive, and throughput would be low, but it'd also be far better than=
 the bikeshed hell which we'd doubtless find ourselves in if we try to push=
 the hulking mass of Fawkescoin into consensus. There'd be no complex timel=
ock conditions, no commit/reveal protocols; just one new encumbrance added =
to old EC script pubkeys. Existing wallets can be upgraded without any time=
-sensitive migration procedures.

So then we're left with this question: What primitive should we use to prov=
e seed knowledge: Seed-lifted=C2=A0Picnic=C2=A0signatures or zk-STARKs?=C2=
=A0

Cards on the table: I'm not very familiar with Picnic, but I am with zk-STA=
RKs. I know zk-STARKs would be very useful to have on-hand as a primitive a=
vailable to consensus, especially in a post-quantum world. They work for an=
y general computation, with arbitrary private and public inputs. They are q=
uick to verify but take a lot of work to produce. They are usually large, m=
easured in tens of kilobytes, but that's similar to Picnic.=C2=A0

Maybe it'd be worthwhile for someone to do some quantitative benchmarking a=
nd qualitative compare/contrast research between zk-STARKs and Picnic signa=
tures (and maybe other alternatives too?), specifically for the case of BIP=
39 seed derivation proofs. I'm especially curious if an optimized zk-STARK =
circuit for BIP39/BIP32 derivation can be designed to reduce proving runtim=
e and proof size. I'd also love to know if Picnic signatures could be reuse=
d for other things like rollups, IBD speedup, etc, as I know zk-STARKs coul=
d be used for.

In any case, while I don't think commit/reveal protocols like Lifted Fawkes=
Coin or its variants are appropriate for a bitcoin consensus upgrade, I do =
really appreciate all the research that went into your paper Or. It is a pe=
rfect resource for anyone interested in PQ commit/reveal protocols and cont=
ains many nuggets of wisdom in that realm.

regards,
conduition







On Sunday, July 13th, 2025 at 9:49 AM, Or Sattath <sattath@gmail.com> wrote=
:

> Hi,
>=20

> Jameson Lopp presented the freeze/not-freeze dilemma. I would like to poi=
nt out that there=E2=80=99s a third approach. The main insight is that even=
 though the quantum attacker knows the digital signature private key, the a=
ttacker and the owner are not symmetric: the owner, in most cases, knows th=
e seed (master secret key), whereas the quantum attacker does not. This app=
roach, which was done in collaboration with Shai Wyborski, is available her=
e: https://eprint.iacr.org/2023/362 (our work was peer reviewed and present=
ed here: https://www.qsmc.org/pqcsm-workshop-2023).
>=20

> Our main technique is called =E2=80=9Csignature lifting=E2=80=9D: it=E2=
=80=99s a way to transform an existing quantum-insecure signature scheme in=
to a quantum-secure signature scheme, while still using the old keys. This =
is possible whenever the function that maps the secret key to the public ke=
y is a quantum-secure one-way function. Informally (and there are some deta=
ils under the rug that I=E2=80=99m not getting into), the quantum-secure on=
e-way function maps the seed to the public key. (Of course, the function th=
at maps the ECDSA signing key to the public key is not a quantum-secure one=
-way function. Therefore, our approach does not apply to pre-2013 wallets, =
which did not use BIP-38.) We use Picnic (https://dl.acm.org/doi/abs/10.114=
5/3133956.3133997) as the underlying primitive that enables signature lifti=
ng.
>=20

> The main drawback of signature lifting is that the signatures are extreme=
ly long. To address this, we also designed an interactive way to transact, =
using a commit-wait-reveal approach, which we called =E2=80=9CLifted Fawkes=
Coin" (our main contribution over the original FawkesCoin approach by Bonne=
au and Miller in https://jbonneau.com/doc/BM14-SPW-fawkescoin.pdf is that w=
e resolve the issue of transaction fees, using lifted signatures). When the=
 spender and the miner are honest, a transaction is roughly the same size a=
s today; only if one of the parties deviates from the honest protocol must =
the long signature be added to the blockchain, and the cheating party is fi=
nancially penalized. The main burden of Lifted FawkesCoin is that users who=
 haven=E2=80=99t transitioned to quantum-secure signatures yet need to occa=
sionally (e.g., once a year) come online and check for fraud attempts. I be=
lieve that even though this burden exists, it is a Pareto improvement over =
both the =E2=80=9Cfreeze=E2=80=9D and =E2=80=9Cnot-freeze=E2=80=9D approach=
es.
>=20

> Best,
> Or
>=20

> On Sunday, March 16, 2025 at 5:22:16=E2=80=AFPM UTC+2 Jameson Lopp wrote:
>=20

> > The quantum computing debate is heating up. There are many controversia=
l aspects to this debate, including whether or not quantum computers will e=
ver actually become a practical threat.
> > I won't tread into the unanswerable question of how worried we should b=
e about quantum computers. I think it's far from a crisis, but given the di=
fficulty in changing Bitcoin it's worth starting to seriously discuss. Toda=
y I wish to focus on a philosophical quandary related to one of the decisio=
ns that would need to be made if and when we implement a quantum safe signa=
ture scheme.
> >=20

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

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

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

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

> >=20

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

> > > - Hunter Beast
> >=20

> >=20

> > On the other hand:
> >=20

> >=20

> > > "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 vuln=
erable 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 th=
eir coins to PQC-protected schemes."
> > > - Pieter Wuille
> >=20

> >=20

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

> > Not freezing user funds is one of Bitcoin's inviolable properties. Howe=
ver, if quantum computing becomes a threat to Bitcoin's elliptic curve cryp=
tography, an inviolable property of Bitcoin will be violated one way or ano=
ther.
> >=20

> > Fundamental Properties at Risk
> > 5 years ago I attempted to comprehensively categorize all of Bitcoin's =
fundamental properties that give it value. https://nakamoto.com/what-are-th=
e-key-properties-of-bitcoin/
> > The particular properties in play with regard to this issue seem to be:
> >=20

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

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

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

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

> >=20

> > > Not your keys, not your coins.
> >=20

> >=20

> > I posit that the corollary to this principle is:
> >=20

> >=20

> > > Your keys, only your coins.
> >=20

> >=20

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

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

> > Who is at Risk?
> > There has long been a narrative that Satoshi's coins and others from th=
e Satoshi era of P2PK locking scripts that exposed the public key directly =
on the blockchain will be those that get scooped up by a quantum "miner." B=
ut unfortunately it's not that simple. If I had a powerful quantum 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 addresses that =
have previously been spent from. You can easily find them at https://bitinf=
ocharts.com/top-100-richest-bitcoin-addresses.html
> >=20

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

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

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

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

> > 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 their unre=
achable funds scooped up by a quantum enabled adversary.
> >=20

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

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

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

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

> > Is Quantum Recovery Good for Anyone?
> >=20

> > Does quantum 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 network. If anything, it greatly decreases the security of the netwo=
rk by allowing funds to be claimed by those who did not earn them.
> >=20

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

> > For example:
> >=20

> > * 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 t=
he system.
> >=20

> > There's no reason to believe that allowing quantum adversaries to recov=
er vulnerable bitcoin will be of benefit to anyone other than the select fe=
w organizations that win the technological arms race to build the first suc=
h computers. Probably nation states and/or the top few largest tech compani=
es.
> >=20

> > One could certainly hope that an organization with quantum 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 s=
ituation creates an insurmountable ethical dilemma of only recovering lost =
bitcoin rather than currently owned bitcoin. There's no way to precisely di=
fferentiate between the two; anyone can claim to have lost their bitcoin bu=
t if they have lost their keys then proving they ever had the keys becomes =
rather difficult. I imagine that any such white hat recovery efforts would =
have to rely upon attestations from trusted third parties like exchanges.
> >=20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> > Quantum Attackers Would Only Steal Small Amounts
> > 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 suspicio=
n and cause a market panic.
> >=20

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

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

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

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

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

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

> > I think this is generally a fair point that "the community" 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 regard to quantum saf=
e Bitcoiners vs quantum vulnerable Bitcoiners. More on that later.
> >=20

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

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

> > Technological Evolution as a Feature, Not a Bug
> > It's well known that cryptography tends to weaken over time and eventua=
lly break. Quantum computing is just the next step in this progression. Use=
rs who fail to adapt (e.g., by adopting quantum-resistant wallets when avai=
lable) are akin to those who ignored technological advancements like multis=
ig or hardware wallets. Allowing quantum theft incentivizes innovation and =
keeps Bitcoin=E2=80=99s ecosystem dynamic, punishing complacency while rewa=
rding vigilance.
> >=20

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

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

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

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

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

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

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

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

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

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

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

> > Bitcoin's DAO Moment
> > This situation has some similarities to The DAO hack of an Ethereum sma=
rt contract in 2016, which resulted in a fork to stop the attacker and retu=
rn funds to their original owners. The game theory is similar because it's =
a situation where 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 mitig=
ate the attack by changing the protocol.
> >=20

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

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

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

> >=20

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

> >=20

> > If true, the corollary is:
> >=20

> >=20

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

> >=20

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

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

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

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

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

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

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

> > Beyond that, it will take at least 6 months worth of block space for al=
l 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 m=
onth. Of course this is a highly optimistic situation where everyone is com=
pletely focused on migrations - in reality it will take far longer.
> >=20

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

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

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

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

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

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

> > I welcome your feedback upon any of the above points, and contribution =
of any arguments I failed to consider.
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com.

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

-----------------------7efa4d59818fa25a4482a23e407dfa74
Content-Type: multipart/related;boundary=---------------------c957d09797fd3476cdb67d7eb0377594

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Thanks for =
pointing this out Or. For those not familiar with Or's approach, it would s=
hare many of the same properties as the folklore BIP39 zk-STARK approach di=
scussed elsewhere. It uses Picnic in the same way, to prove (in zero-knowle=
dge) either:</div><div style=3D"font-family: Arial, sans-serif; font-size: =
14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;"><ul data-editing-info=3D"{&quot;orderedStyleType&quot;:1,&quot;unorde=
redStyleType&quot;:2}" style=3D"margin-top: 0px; margin-bottom: 0px;"><li s=
tyle=3D"list-style-type: &quot;- &quot;;"><span>(For UTXOs whose pubkeys ar=
e exposed) I know a BIP39 seed that derives an EC secret key such that <cod=
e>hash160(pubkey(ec_secret)) =3D=3D &lt;hash&gt;</code></span></li><li styl=
e=3D"list-style-type: &quot;- &quot;;"><span>(For UTXOs whose pubkeys are s=
till secret) I know a public key such that <code>hash160(pubkey) =3D=3D &lt=
;hash&gt;</code>=E2=80=8B<br></span></li></ul></div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px;">From <a href=3D"https://eprint.iacr=
.org/2023/362.pdf" title=3D"Or's paper">Or's paper</a>, section 2.5:</div><=
div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><b=
lockquote style=3D"border-left: 3px solid rgb(200, 200, 200); border-top-co=
lor: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bot=
tom-color: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102=
);"><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><span>S=
pending Hashed UTXOs: To spend a hashed UTXO, the user signs it with a key-=
lifted&nbsp;</span><span>signature (see Section 2.2).</span></div><div styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px;"><div><span><span>Spen=
ding Derived UTXOs: To spend a derived UTXO, the user signs it with a seed-=
lifted&nbsp;</span><span>signature (see Section 2.3).</span></span></div></=
div></blockquote><div><span><span><br></span></span></div><div style=3D"fon=
t-family: Arial, sans-serif; font-size: 14px;"><div><span><span>I see a cou=
ple problems with this. We won't be able to straight-up replace the EC sign=
ature with a Picnic signature without a hard fork. Old Bitcoin clients will=
 still need to see a valid EC signature and verify <code>hash160(pubkey) =
=3D=3D &lt;hash&gt;</code>=E2=80=8B by classical re-computation. This expos=
es the EC pubkey, which would let a QC attacker forge new key-lifted signat=
ures. Thus, sadly, we can't rely on key-lifted signatures.</span></span></d=
iv><div><span><span><br></span></span></div><div>That said, we don't&nbsp;<=
i>always</i>&nbsp;require a hard fork as you note in the paper. It's totall=
y fine to expose the EC signature and pubkey <i>if</i>&nbsp;we also have a =
way to prove honest derivation of the EC secret key from a seed, and as lon=
g as that proof commits to the same transaction. Either seed-lifted Picnic =
signatures or ZK-STARKs could  satisfy this. To get soft-fork backwards-com=
patibility, we'd introduce a new transaction data field to carry the proof,=
 much like segwit added the witness data field. Then we require new clients=
 to reject any EC signatures unless accompanied by this "proof-of-seed-deri=
vation". Old clients still see valid EC spend TXs. Soft fork achieved.</div=
><div><br></div><div><span style=3D"display: inline !important; background-=
color: rgb(255, 255, 255);">As for the "Lifted FawkesCoin" commit/reveal pr=
otocol, it has some issues. I think it'd require a hard fork to implement a=
s there are some properties of the protocol which we can't enforce without =
relaxing consensus rules. For example, letting miners claim UTXOs using the=
 post-quantum proofs of ownership:</span><br></div><div><span style=3D"disp=
lay: inline !important; background-color: rgb(255, 255, 255);"><br></span><=
/div><blockquote style=3D"border-left: 3px solid rgb(200, 200, 200); border=
-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); bor=
der-bottom-color: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 1=
02, 102);"><div><span>After the commitment has been posted, the spender has=
 a limited time to post a reveal of the&nbsp;</span>commitment to the block=
chain. If they fail to do so, the miner can post the proof of ownership<spa=
n>to claim the entire UTXO, making spam attempts costly&nbsp;</span></div><=
/blockquote><div><span><br></span></div><div><span>This is impossible witho=
ut relaxing consensus rules on existing UTXOs' script pubkeys. Donating hal=
f of a TX's mining fees to an unrelated miner would also need a hard fork:<=
/span></div><div><span><br></span></div><blockquote style=3D"border-left: 3=
px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-r=
ight-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); pa=
dding-left: 10px; color: rgb(102, 102, 102);"><div><span><span>The fee paid=
 for including tx is split equally between the miner who&nbsp;</span><span>=
included tx and the miner who included (H(tx))</span><br></span></div></blo=
ckquote><div><br></div><div>(though this might be fixable if you modify the=
 protocol to instead require direct payment to the address of the miner who=
 mined the H(tx) commitment.)</div><div><br></div><div>The other problem is=
 incentives. Why would miners ever mine a Lifted FawkesCoin reveal=E2=80=8B=
 TX if they could simply wait and claim the pre-quantum UTXO themselves usi=
ng the proof of ownership? The protocol seems to rely on miners ignoring th=
is opportunity, or at least that the major mining pools won't collude to ex=
ploit it. The "Restrictive FawkesCoin" protocol would seem to fix this prob=
lem though.</div><div><br></div><div>Finally, the consensus implementation =
complexity for any Fawkescoin implementation would be enormous. There are s=
o many context-specific validation steps. The modifications described in se=
ction 3.3 and section 4 only further exacerbate this. Sections 3 thru 5 des=
cribe all the various Fawkescoin protocols and modifications, and in total =
they are <b>16 pages long</b>. I don't expect anyone could push that much p=
rotocol complexity into consensus in the next decade.</div><div><br></div><=
div>We're having a hard enough time coming to consensus on the "to freeze o=
r not to freeze" debate, the OP_CTV debate, the OP_CAT debate, etc. I don't=
 see a future where Bitcoin users can even <i>comprehend</i>&nbsp;all the r=
ules and parameters included in the final FawkesCoin-driven protocol, <span=
 style=3D"display: inline !important; background-color: rgb(255, 255, 255);=
">let alone a world where we can all agree on<span>&nbsp;them</span></span>=
. We need something simpler, more closely aligned with existing consensus r=
ules, that can be implemented and slotted into existing BIPs and UX neatly.=
</div><div><br></div><div>Personally I think the answer is to require a pro=
of-of-seed-knowledge to spend any EC-signature-locked UTXO, and to implemen=
t it as a soft fork. It'd be expensive, and throughput would be low, but it=
'd also be far better than the bikeshed hell which we'd doubtless find ours=
elves in if we try to push the hulking mass of Fawkescoin into consensus. T=
here'd be no complex timelock conditions, no commit/reveal protocols; just =
one new encumbrance added to old EC script pubkeys. Existing wallets can be=
 upgraded without any time-sensitive migration procedures.</div><div><br></=
div><div>So then we're left with this question: What primitive should we us=
e to prove seed knowledge: Seed-lifted&nbsp;Picnic&nbsp;signatures or zk-ST=
ARKs?&nbsp;</div><div><br></div><div>Cards on the table: I'm not very famil=
iar with Picnic, but I am with zk-STARKs. I know zk-STARKs would be very us=
eful to have on-hand as a primitive available to consensus, especially in a=
 post-quantum world. They work for any general computation, with arbitrary =
private and public inputs. They are quick to verify but take a lot of work =
to produce. They are usually large, measured in tens of kilobytes, but that=
's similar to Picnic.&nbsp;</div><div><br></div><div>Maybe it'd be worthwhi=
le for someone to do some quantitative benchmarking and qualitative compare=
/contrast research between zk-STARKs and Picnic signatures (and maybe other=
 alternatives too?), specifically for the case of BIP39 seed derivation pro=
ofs. I'm especially curious if an optimized zk-STARK circuit for BIP39/BIP3=
2 derivation can be designed to reduce proving runtime and proof size. I'd =
also love to know if Picnic signatures could be reused for other things lik=
e rollups, IBD speedup, etc, as I know zk-STARKs could be used for. </div><=
div><br></div><div>In any case, while I don't think commit/reveal protocols=
 like Lifted FawkesCoin or its variants are appropriate for a bitcoin conse=
nsus upgrade, I do really appreciate all the research that went into your p=
aper Or. It is a perfect resource for anyone interested in PQ commit/reveal=
 protocols and contains many nuggets of wisdom in that realm.</div><div><br=
></div><div>regards,</div><div>conduition</div><div><br></div><div><span st=
yle=3D"display: inline !important; background-color: rgb(255, 255, 255);"><=
span><br></span></span></div><div><span style=3D"display: inline !important=
; background-color: rgb(255, 255, 255);"><span><br></span></span></div><div=
><br></div><div></div></div><div class=3D"protonmail_quote">
        On Sunday, July 13th, 2025 at 9:49 AM, Or Sattath &lt;sattath@gmail=
.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div style=3D"color: rgb(34, 34, 34); font-family: Arial, Helve=
tica, sans-serif; font-size: small;">Hi,<br><br>Jameson Lopp presented the =
freeze/not-freeze dilemma. I would like to point out that there=E2=80=99s a=
 third approach. The main insight is that even though the quantum attacker =
knows the digital signature private key, the attacker and the owner are not=
 symmetric: the owner, in most cases, knows the seed (master secret key), w=
hereas the quantum attacker does not. This approach, which was done in coll=
aboration with Shai Wyborski, is available here: <a href=3D"https://eprint.=
iacr.org/2023/362" target=3D"_blank" style=3D"color: rgb(17, 85, 204);" rel=
=3D"noreferrer nofollow noopener">https://eprint.iacr.org/2023/362</a> (our=
 work was peer reviewed and presented here: <a href=3D"https://www.qsmc.org=
/pqcsm-workshop-2023" target=3D"_blank" style=3D"color: rgb(17, 85, 204);" =
rel=3D"noreferrer nofollow noopener">https://www.qsmc.org/pqcsm-workshop-20=
23</a>).<br><br>Our main technique is called =E2=80=9Csignature lifting=E2=
=80=9D: it=E2=80=99s a way to transform an existing quantum-insecure signat=
ure scheme into a quantum-secure signature scheme, while still using the ol=
d keys. This is possible whenever the function that maps the secret key to =
the public key is a quantum-secure one-way function. Informally (and there =
are some details under the rug that I=E2=80=99m not getting into), the quan=
tum-secure one-way function maps the seed to the public key. (Of course, th=
e function that maps the ECDSA signing key to the public key is not a quant=
um-secure one-way function. Therefore, our approach does not apply to pre-2=
013 wallets, which did not use BIP-38.) We use Picnic (<a href=3D"https://d=
l.acm.org/doi/abs/10.1145/3133956.3133997" target=3D"_blank" style=3D"color=
: rgb(17, 85, 204);" rel=3D"noreferrer nofollow noopener">https://dl.acm.or=
g/doi/abs/10.1145/3133956.3133997</a>) as the underlying primitive that ena=
bles signature lifting.<br><br>The main drawback of signature lifting is th=
at the signatures are extremely long. To address this, we also designed an =
interactive way to transact, using a commit-wait-reveal approach, which we =
called =E2=80=9CLifted FawkesCoin" (our main contribution over the original=
 FawkesCoin approach by Bonneau and Miller in <a href=3D"https://jbonneau.c=
om/doc/BM14-SPW-fawkescoin.pdf" target=3D"_blank" style=3D"color: rgb(17, 8=
5, 204);" rel=3D"noreferrer nofollow noopener">https://jbonneau.com/doc/BM1=
4-SPW-fawkescoin.pdf</a> is that we resolve the issue of transaction fees, =
using lifted signatures). When the spender and the miner are honest, a tran=
saction is roughly the same size as today; only if one of the parties devia=
tes from the honest protocol must the long signature be added to the blockc=
hain, and the cheating party is financially penalized. The main burden of L=
ifted FawkesCoin is that users who haven=E2=80=99t transitioned to quantum-=
secure signatures yet need to occasionally (e.g., once a year) come online =
and check for fraud attempts. I believe that even though this burden exists=
, it is a Pareto improvement over both the =E2=80=9Cfreeze=E2=80=9D and =E2=
=80=9Cnot-freeze=E2=80=9D approaches. </div><div style=3D"color: rgb(34, 34=
, 34); font-family: Arial, Helvetica, sans-serif; font-size: small;"><br>Be=
st,<br>Or</div><br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gm=
ail_attr">On Sunday, March 16, 2025 at 5:22:16=E2=80=AFPM UTC+2 Jameson Lop=
p wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div =
dir=3D"ltr">The quantum computing debate is heating up. There are many cont=
roversial aspects to this debate, including whether or not quantum computer=
s will ever actually become a practical threat.<div><br>I won't tread into =
the unanswerable question of how worried we should be about quantum compute=
rs. I think it's far from a crisis, but given the difficulty in changing Bi=
tcoin it's worth starting to seriously discuss. Today I wish to focus on a =
philosophical quandary related to one of the decisions that would need to b=
e made if and when we implement a quantum safe signature scheme.<br><br><fo=
nt size=3D"6">Several Scenarios<br></font>Because this essay will reference=
 game theory a fair amount, and there are many variables at play that could=
 change the nature of the game, I think it's important to clarify the possi=
ble scenarios up front.<br><br>1. Quantum computing never materializes, nev=
er becomes a threat, and thus everything discussed in this essay is moot.<b=
r>2. A quantum computing threat materializes suddenly and Bitcoin does not =
have quantum safe signatures as part of the protocol. In this scenario it w=
ould likely make the points below moot because Bitcoin would be fundamental=
ly broken and it would take far too long to upgrade the protocol, wallet so=
ftware, and migrate user funds in order to restore confidence in the networ=
k.<br>3. Quantum computing advances slowly enough that we come to consensus=
 about how to upgrade Bitcoin and post quantum security has been minimally =
adopted by the time an attacker appears.<br>4. Quantum computing advances s=
lowly enough that we come to consensus about how to upgrade Bitcoin and pos=
t quantum security has been highly adopted by the time an attacker appears.=
<br><br>For the purposes of this post, I'm envisioning being in situation 3=
 or 4.<br><br><font size=3D"6">To Freeze or not to Freeze?<br></font>I've s=
tarted seeing more people weighing in on what is likely the most contentiou=
s aspect of how a quantum resistance upgrade should be handled in terms of =
migrating user funds. Should quantum vulnerable funds be left open to be sw=
ept by anyone with a sufficiently powerful quantum computer OR should they =
be permanently locked?<br><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">"I don't see why old coins should be confiscated. The better option is=
 to let those with quantum computers free up old coins. While this might ha=
ve an inflationary impact on bitcoin's price, to use a turn of phrase, the =
inflation is transitory. Those with low time preference should support retu=
rning lost coins to circulation." </blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">- Hunter Beast</blockquote><div><br></div>On the othe=
r hand:</div><div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"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 Bitc=
oin ecosystem has no other option than softforking out the ability to spend=
 from signature schemes (including ECDSA and BIP340) that are vulnerable 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 settin=
g. And this affects everyone; even those which diligently moved their coins=
 to PQC-protected schemes."<br>- Pieter Wuille</blockquote><br>I don't thin=
k "confiscation" is the most precise term to use, as the funds are not bein=
g seized and reassigned. Rather, what we're really discussing would be bett=
er described as "burning" - placing the funds <b>out of reach of everyone</=
b>.<br><br>Not freezing user funds is one of Bitcoin's inviolable propertie=
s. However, if quantum computing becomes a threat to Bitcoin's elliptic cur=
ve cryptography, <b>an inviolable property of Bitcoin will be violated one =
way or another</b>.<br><br><font size=3D"6">Fundamental Properties at Risk<=
br></font>5 years ago I attempted to comprehensively categorize all of Bitc=
oin's fundamental properties that give it value. <a href=3D"https://nakamot=
o.com/what-are-the-key-properties-of-bitcoin/" target=3D"_blank" rel=3D"nor=
eferrer nofollow noopener" data-saferedirecturl=3D"https://www.google.com/u=
rl?hl=3Den&amp;q=3Dhttps://nakamoto.com/what-are-the-key-properties-of-bitc=
oin/&amp;source=3Dgmail&amp;ust=3D1752507182310000&amp;usg=3DAOvVaw2WXOREje=
Ne8DXRkOJ4tzen">https://nakamoto.com/what-are-the-key-properties-of-bitcoin=
/<br></a><br>The particular properties in play with regard to this issue se=
em to be:<br><br><b>Censorship Resistance</b> - No one should have the powe=
r to prevent others from using their bitcoin or interacting with the networ=
k.<br><br><b>Forward Compatibility</b> - changing the rules such that certa=
in valid transactions become invalid could undermine confidence in the prot=
ocol.<br><br><b>Conservatism</b> - Users should not be expected to be highl=
y responsive to system issues.<br><br>As a result of the above principles, =
we have developed a strong meme (kudos to Andreas Antonopoulos) that goes a=
s follows:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not you=
r keys, not your coins.</blockquote><br>I posit that the corollary to this =
principle is:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Your=
 keys, only your coins.</blockquote><br>A quantum capable entity breaks the=
 corollary of this foundational principle. We secure our bitcoin with the m=
athematical probabilities related to extremely large random numbers. Your f=
unds are only secure because truly random large numbers should not be guess=
able or discoverable by anyone else in the world.<br><br>This is the princi=
ple behind the motto <i>vires in numeris</i> - strength in numbers. In a wo=
rld with quantum enabled adversaries, this principle is null and void for m=
any types of cryptography, including the elliptic curve digital signatures =
used in Bitcoin.<br><br><font size=3D"6">Who is at Risk?<br></font>There ha=
s long been a narrative that Satoshi's coins and others from the Satoshi er=
a of P2PK locking scripts that exposed the public key directly on the block=
chain will be those that get scooped up by a quantum "miner." But unfortuna=
tely it's not that simple. If I had a powerful quantum computer, which coin=
s 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 addresses that have previou=
sly been spent from. You can easily find them at <a href=3D"https://bitinfo=
charts.com/top-100-richest-bitcoin-addresses.html" target=3D"_blank" rel=3D=
"noreferrer nofollow noopener" data-saferedirecturl=3D"https://www.google.c=
om/url?hl=3Den&amp;q=3Dhttps://bitinfocharts.com/top-100-richest-bitcoin-ad=
dresses.html&amp;source=3Dgmail&amp;ust=3D1752507182310000&amp;usg=3DAOvVaw=
0X5eLgtSvk1Q4u9vUoOTrR">https://bitinfocharts.com/top-100-richest-bitcoin-a=
ddresses.html</a><br><br>Note that a few of these wallets, like Bitfinex / =
Kraken / Tether, would be slightly harder to crack because they are multisi=
g wallets. So a quantum attacker would need to reverse engineer 2 keys for =
Kraken or 3 for Bitfinex / Tether in order to spend funds. But many are sin=
gle signature.<br><br>Point being, it's not only the really old lost BTC th=
at are at risk to a quantum enabled adversary, at least at time of writing.=
 If we add a quantum safe signature scheme, we should expect those wallets =
to be some of the first to upgrade given their incentives.<br><br><font siz=
e=3D"6">The Ethical Dilemma: Quantifying Harm<br></font>Which decision resu=
lts in the most harm?<br><br>By making quantum vulnerable funds unspendable=
 we potentially harm some Bitcoin users who were not paying attention and n=
eglected to migrate their funds to a quantum safe locking script. This viol=
ates the "conservativism" principle stated earlier. On the flip side, we pr=
event those funds plus far more lost funds from falling into the hands of t=
he few privileged folks who gain early access to quantum computers.<br><br>=
By leaving quantum vulnerable funds available to spend, the same set of use=
rs who would otherwise have funds frozen are likely to see them stolen. And=
 many early adopters who lost their keys will eventually see their unreacha=
ble funds scooped up by a quantum enabled adversary.<br><br>Imagine, for ex=
ample, being James Howells, who accidentally threw away a hard drive with 8=
,000 BTC on it, currently worth over $600M USD. He has spent a decade tryin=
g to retrieve it from the landfill where he knows it's buried, but can't ge=
t permission to excavate. I suspect that, given the choice, he'd prefer tho=
se funds be permanently frozen rather than fall into someone else's possess=
ion - I know I would.<br><br>Allowing a quantum computer to access lost fun=
ds 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 economic disruption if =
large amounts of coins fall into new hands. Since a quantum computer is goi=
ng to have a massive up front cost, expect those behind it to desire to rec=
oup their investment. We also know from experience that when someone sudden=
ly finds themselves in possession of 9+ figures worth of highly liquid asse=
ts, they tend to diversify into other things by selling.<br><br>Allowing qu=
antum recovery of bitcoin is <i>tantamount to wealth redistribution</i>. Wh=
at we'd be allowing is for bitcoin to be redistributed from those who are i=
gnorant of quantum computers to those who have won the technological race t=
o acquire quantum computers. It's hard to see a bright side to that scenari=
o.<br><br><font size=3D"6">Is Quantum Recovery Good for Anyone?</font><br><=
br>Does quantum recovery HELP anyone? I've yet to come across an argument t=
hat it's a net positive in any way. It certainly doesn't add any security t=
o the network. If anything, it greatly decreases the security of the networ=
k by allowing funds to be claimed by those who did not earn them.<br><br>Bu=
t wait, you may be thinking, wouldn't quantum "miners" have earned their co=
ins by all the work and resources invested in building a quantum computer? =
I suppose, in the same sense that a burglar earns their spoils by the resou=
rces they 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 othe=
r currencies.<br>* Merchants earn BTC by trading for goods and services.<br=
>* Miners earn BTC by trading thermodynamic security.<br>* Quantum miners d=
on't trade anything, they are vampires feeding upon the system.<br><br>Ther=
e's no reason to believe that allowing quantum adversaries to recover vulne=
rable bitcoin will be of benefit to anyone other than the select few organi=
zations that win the technological arms race to build the first such comput=
ers. Probably nation states and/or the top few largest tech companies.<br><=
br>One could certainly hope that an organization with quantum supremacy is =
benevolent and acts in a "white hat" manner to return lost coins to their o=
wners, but that's incredibly optimistic and foolish to rely upon. Such a si=
tuation creates an insurmountable ethical dilemma of only recovering lost b=
itcoin rather than currently owned bitcoin. There's no way to precisely dif=
ferentiate between the two; anyone can claim to have lost their bitcoin but=
 if they have lost their keys then proving they ever had the keys becomes r=
ather difficult. I imagine that any such white hat recovery efforts would h=
ave to rely upon attestations from trusted third parties like 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 adve=
rsarially about the potential worst case outcomes. Imagine, for example, th=
at North Korea continues scooping up billions of dollars from hacking crypt=
o exchanges and decides to invest some of those proceeds into building a qu=
antum computer for the biggest payday ever...<br><br><font size=3D"6">Downs=
ides to Allowing Quantum Recovery</font><br>Let's think through an exhausti=
ve list of pros and cons for allowing or preventing the seizure of funds by=
 a quantum adversary.<br><br><font size=3D"4">Historical Precedent</font><b=
r>Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair gam=
e" but rather were treated as failures to be remediated. Treating quantum t=
heft differently risks rewriting Bitcoin=E2=80=99s history as a free-for-al=
l rather than a system that seeks to protect its users.<br><br><font size=
=3D"4">Violation of Property Rights</font><br>Allowing a quantum adversary =
to take control of funds undermines the fundamental principle of cryptocurr=
ency - if you keep your keys in your possession, only you should be able to=
 access your money. Bitcoin is built on the idea that private keys secure a=
n individual=E2=80=99s assets, and unauthorized access (even via advanced t=
ech) is theft, not a legitimate transfer.<br><br><font size=3D"4">Erosion o=
f Trust in Bitcoin</font><br>If quantum attackers can exploit vulnerable ad=
dresses, confidence in Bitcoin as a secure store of value would collapse. U=
sers and investors rely on cryptographic integrity, and widespread theft co=
uld drive adoption away from Bitcoin, destabilizing its ecosystem.<br><br>T=
his is essentially the counterpoint to claiming the burning of vulnerable f=
unds is a violation of property rights. While some will certainly see it as=
 such, others will find the apathy toward stopping quantum theft to be simi=
larly concerning.<br><br><font size=3D"4">Unfair Advantage</font><br>Quantu=
m attackers, likely equipped with rare and expensive technology, would have=
 an unjust edge over regular users who lack access to such tools. This crea=
tes an inequitable system where only the technologically elite can exploit =
others, contradicting Bitcoin=E2=80=99s ethos of decentralized power.<br><b=
r>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 ourse=
lves discussing a situation where this asymmetric advantage is compromised =
in favor of a specific class of attackers.<br><br><font size=3D"4">Economic=
 Disruption</font><br>Large-scale theft from vulnerable addresses could cra=
sh Bitcoin=E2=80=99s price as quantum recovered funds are dumped on exchang=
es. This would harm all holders, not just those directly targeted, leading =
to broader financial chaos in the markets.<br><br><font size=3D"4">Moral Re=
sponsibility</font><br>Permitting theft via quantum computing sets a preced=
ent that technological superiority justifies unethical behavior. This is es=
sentially taking a "code is law" stance in which we refuse to admit that bo=
th code and laws can be modified to adapt to previously unforeseen situatio=
ns.<br><br>Burning of coins can certainly be considered a form of theft, th=
us I think it's worth differentiating the two different thefts being discus=
sed:<br><br>1. self-enriching &amp; likely malicious<br>2. harm prevention =
&amp; not necessarily malicious<br><br>Both options lack the consent of the=
 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 d=
own into the details of each.<br><br><font size=3D"4">Incentives Drive Secu=
rity</font><br>I can tell you from a decade of working in Bitcoin security =
- the average user is lazy and is a procrastinator. If Bitcoiners are given=
 a "drop dead date" after which they know vulnerable funds will be burned, =
this pressure accelerates the adoption of post-quantum cryptography and str=
engthens Bitcoin long-term. Allowing vulnerable users to delay upgrading in=
definitely will result in more laggards, leaving the network more exposed w=
hen quantum tech becomes available.<br><br><font size=3D"6">Steel Manning<b=
r></font>Clearly this is a complex and controversial topic, thus it's worth=
 thinking through the opposing arguments.<br><br><font size=3D"4">Protectin=
g Property Rights</font><br>Allowing quantum computers to take vulnerable b=
itcoin could potentially be spun as a hard money narrative - we care so gre=
atly about not violating someone's access to their coins that we allow them=
 to be stolen!<br><br>But I think the flip side to the property rights narr=
ative is that burning vulnerable coins prevents said property from falling =
into undeserving hands. If the entire Bitcoin ecosystem just stands around =
and allows quantum adversaries to claim funds that rightfully belong to oth=
er users, is that really a "win" in the "protecting property rights" catego=
ry? It feels more like apathy to me.<br><br>As such, I think the "protectin=
g property rights" argument is a wash.<br><br><font size=3D"4">Quantum Comp=
uters Won't Attack Bitcoin</font><br>There is a great deal of skepticism th=
at sufficiently powerful quantum computers will ever exist, so we shouldn't=
 bother preparing for a non-existent threat. Others have argued that even i=
f such a computer was built, a quantum attacker would not go after bitcoin =
because they wouldn't want to reveal their hand by doing so, and would inst=
ead attack other infrastructure.<br><br>It's quite difficult to quantify ex=
actly how valuable attacking other infrastructure would be. It also really =
depends upon when an entity gains quantum supremacy and thus if by that tim=
e most of the world's systems have already been upgraded. While I think you=
 could argue that certain entities gaining quantum capability might not att=
ack Bitcoin, it would only delay the inevitable - eventually somebody will =
achieve the capability who decides to use it for such an attack.<br><br><fo=
nt size=3D"4">Quantum Attackers Would Only Steal Small Amounts</font><br>So=
me have argued that even if a quantum attacker targeted bitcoin, they'd onl=
y 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 BT=
C at a time when you could take 250,000 BTC with the same effort as 50 BTC?=
 This is a classic "zero day exploit" game theory in which an attacker know=
s they have a limited amount of time before someone else discovers the expl=
oit and either benefits from it or patches it. Take, for example, the recen=
t ByBit attack - the highest value crypto hack of all time. Lazarus Group h=
ad 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 i=
nteracting with their wallet. But instead they chose to only specifically t=
arget ByBit's wallet with $1.5 billion in it because they wanted to maximiz=
e their extractable value. If Lazarus had started stealing from every walle=
t, they would have been discovered quickly and the Safe web app would likel=
y have been patched well before any billion dollar wallets executed the mal=
icious code.<br><br>I think the "only stealing small amounts" argument is s=
trongest for Situation #2 described earlier, where a quantum attacker arriv=
es before quantum safe cryptography has been deployed across the Bitcoin ec=
osystem. Because if it became clear that Bitcoin's cryptography was broken =
AND there was nowhere safe for vulnerable users to migrate, the only logica=
l option would be for everyone to liquidate their bitcoin as quickly as pos=
sible. As such, I don't think it applies as strongly for situations in whic=
h we have a migration path available.<br><br><font size=3D"4">The 21 Millio=
n Coin Supply Should be in Circulation</font><br>Some folks are arguing tha=
t 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 i=
s a strong memetic narrative, I don't think anyone has ever expected that i=
t would all be in circulation. It has always been understood that many coin=
s will be lost, and that's actually part of the game theory of owning bitco=
in!<br><br>And remember, the 21M number in and of itself is not a particula=
rly important detail - it's not even mentioned in the whitepaper. What's im=
portant is that the supply is well known and not subject to change.<br><br>=
<font size=3D"4">Self-Sovereignty and Personal Responsibility</font><br>Bit=
coin=E2=80=99s design empowers individuals to control their own wealth, fre=
e from centralized intervention. This freedom comes with the burden of secu=
ring one's private keys. If quantum computing can break obsolete cryptograp=
hy, the fault lies with users who didn't move their funds to quantum safe l=
ocking scripts. Expecting the network to shield users from their own neglig=
ence undermines the principle that you, and not a third party, are accounta=
ble for your assets.<br><br>I think this is generally a fair point that "th=
e community" 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 wi=
th regard to quantum safe Bitcoiners vs quantum vulnerable Bitcoiners. More=
 on that later.<br><br><font size=3D"4">Code is Law</font><br>Bitcoin opera=
tes 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 - they're simply following what's =
mathematically permissible within the current code. Altering the protocol t=
o stop this introduces subjective human intervention, which clashes with th=
e objective, deterministic nature of blockchain.<br><br>While I tend to agr=
ee that code is law, one of the entire points of laws is that they can be a=
mended to improve their efficacy in reducing harm. Leaning on this point se=
ems more like a pro-ossification stance that it's better to do nothing and =
allow harm to occur rather than take action to stop an attack that was fore=
seen far in advance.<br><br><font size=3D"4">Technological Evolution as a F=
eature, Not a Bug</font><br>It's well known that cryptography tends to weak=
en 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-res=
istant wallets when available) are akin to those who ignored technological =
advancements like multisig or hardware wallets. Allowing quantum theft ince=
ntivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic, punishin=
g complacency while rewarding vigilance.<br><br><font size=3D"4">Market Sig=
nals Drive Security</font><br>If quantum attackers start stealing funds, it=
 sends a clear signal to the market: upgrade your security or lose everythi=
ng. This pressure accelerates the adoption of post-quantum cryptography and=
 strengthens Bitcoin long-term. Coddling vulnerable users delays this neces=
sary evolution, potentially leaving the network more exposed when quantum t=
ech becomes widely accessible. Theft is a brutal but effective teacher.<br>=
<br><font size=3D"4">Centralized Blacklisting Power</font><br>Burning vulne=
rable funds requires centralized decision-making - a soft fork to invalidat=
e certain transactions. This sets a dangerous precedent for future interven=
tions, eroding Bitcoin=E2=80=99s decentralization. If quantum theft is bloc=
ked, what=E2=80=99s next - reversing exchange hacks? The system must remain=
 neutral, 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 size=3D"4">Fairness in Competitio=
n</font><br>Quantum attackers aren't cheating; they're using publicly avail=
able physics and math. Anyone with the resources and foresight can build or=
 access quantum tech, just as anyone could 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 nev=
er promised equality of outcome - only equality of opportunity within its r=
ules.<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 e=
ach ASIC costs millions if not billions of dollars. This is out of reach fr=
om all but the wealthiest organizations.<br><br><font size=3D"4">Economic R=
esilience</font><br>Bitcoin has weathered thefts before (MTGOX, Bitfinex, F=
TX, etc) and emerged stronger. The market can absorb quantum losses, with u=
naffected users continuing to hold and new entrants buying in at lower pric=
es. Fear of economic collapse overestimates the impact - the network=E2=80=
=99s antifragility thrives on such challenges.<br><br>This is a big grey ar=
ea because we don't know when a quantum computer will come online and we do=
n't know how quickly said computers would be able to steal bitcoin. If, for=
 example, the first generation of sufficiently powerful quantum computers w=
ere stealing less volume than the current block reward then of course it wi=
ll 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 notice=
able market impact as it absorbs the new supply.<br><br>This is where the c=
ircumstances will really matter. If a quantum attacker appears AFTER the Bi=
tcoin protocol has been upgraded to support quantum resistant cryptography =
then we should expect the most valuable active wallets will have upgraded a=
nd the juiciest target would be the 31,000 BTC in the address 12ib7dApVFvg8=
2TXKycWBNpN8kFyiAN1dr which has been dormant since 2010. In general I'd exp=
ect that the amount of BTC re-entering the circulating supply would look so=
mewhat similar to the mining emission curve: volume would start off very hi=
gh as the most valuable addresses are drained and then it would fall off as=
 quantum computers went down the list targeting addresses with less and les=
s BTC.<br><br>Why is economic impact a factor worth considering? Miners and=
 businesses in general. More coins being liquidated will push down the pric=
e, which will negatively impact miner revenue. Similarly, I can attest from=
 working in the industry for a decade, that lower prices result in less dem=
and from businesses across the entire industry. As such, burning quantum vu=
lnerable bitcoin is good for the entire industry.<br><br><font size=3D"4">P=
racticality &amp; Neutrality of Non-Intervention</font><br>There=E2=80=99s =
no reliable way to distinguish =E2=80=9Ctheft=E2=80=9D from legitimate "whi=
te hat" key recovery. If someone loses their private key and a quantum comp=
uter recovers it, is that stealing or reclaiming? Policing quantum actions =
requires invasive assumptions about intent, which Bitcoin=E2=80=99s trustle=
ss design can=E2=80=99t accommodate. Letting the chips fall where they may =
avoids this mess.<br><br><font size=3D"4">Philosophical Purity</font><br>Bi=
tcoin rejects bailouts. It=E2=80=99s a cold, hard system where outcomes ref=
lect preparation and skill, not sentimentality. If quantum computing upends=
 the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t meant to be saf=
e or fair in a nanny-state sense; it=E2=80=99s meant to be free. Users who =
lose funds to quantum attacks are casualties of liberty and their own ignor=
ance, not victims of injustice.<br><br><font size=3D"6">Bitcoin's DAO Momen=
t</font><br>This situation has some similarities to The DAO hack of an Ethe=
reum smart contract in 2016, which resulted in a fork to stop the attacker =
and return funds to their original owners. The game theory is similar becau=
se it's a situation where 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 by changing the protocol.<br><br>It also created a s=
chism in the community 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 ce=
rtainly result in a hard fork if there are enough miners who reject the sof=
t fork and continue including transactions.<br><br><font size=3D"6">Incenti=
ves Matter</font><br>We can wax philosophical until the cows come home, but=
 what are the actual incentives for existing Bitcoin holders regarding this=
 decision?<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Lost c=
oins only make everyone else's coins worth slightly more. Think of it as a =
donation to everyone." - Satoshi Nakamoto</blockquote><br>If true, the coro=
llary is:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Quantum=
 recovered coins only make everyone else's coins worth less. Think of it as=
 a theft from everyone." - Jameson Lopp</blockquote><br>Thus, assuming we g=
et to a point where quantum resistant signatures are supported within the B=
itcoin protocol, what's the incentive to let vulnerable coins remain spenda=
ble?<br><br>* It's not good for the actual owners of those coins. It disinc=
entivizes owners from upgrading until perhaps it's too late.<br>* It's not =
good for the more attentive / responsible owners of coins who have quantum =
secured their stash. Allowing the circulating supply to balloon will assure=
dly reduce the purchasing power of all bitcoin holders.<br><br><font size=
=3D"6">Forking Game Theory</font><br>From a game theory point of view, I se=
e this as incentivizing users to upgrade their wallets. If you disagree wit=
h the burning of vulnerable coins, all you have to do is move your funds to=
 a quantum safe signature scheme. Point being, I don't see there being an e=
conomic majority (or even more than a tiny minority) of users who would fig=
ht such a soft fork. Why expend significant resources fighting a fork when =
you can just move your coins to a new address?<br><br>Remember that blockin=
g spending of certain classes of locking scripts is a tightening of the rul=
es - a soft fork. As such, it can be meaningfully enacted and enforced by a=
 mere majority of hashpower. If miners generally agree that it's in their b=
est interest to burn vulnerable coins, 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 size=3D"6">How to Execute Burning</font>=
<br>In order to be as objective as possible, the goal would be to announce =
to the world that after a specific block height / timestamp, Bitcoin nodes =
will no longer accept transactions (or blocks containing such transactions)=
 that spend funds from any scripts other than the newly instituted quantum =
safe schemes.<br><br>It could take a staggered approach to first freeze fun=
ds 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 address=
es, but I expect the additional complexity would drive further controversy.=
<br><br>How long should the grace period be in order to give the ecosystem =
time to upgrade? I'd say a minimum of 1 year for software wallets to upgrad=
e. We can only hope that hardware wallet manufacturers are able to implemen=
t post quantum cryptography on their existing hardware with only 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. T=
hough if you exclude dust UTXOs you could probably get 95% of BTC value mig=
rated in 1 month. Of course this is a highly optimistic situation where eve=
ryone is completely focused on migrations - in reality it will take far lon=
ger.<br><br>Regardless, I'd think that in order to reasonably uphold Bitcoi=
n's conservatism it would be preferable to allow a 4 year migration window.=
 In the meantime, mining pools could coordinate emergency soft forking logi=
c such that if quantum attackers materialized, they could accelerate the co=
untdown to the quantum vulnerable funds burn.<br><br><font size=3D"6">Rando=
m Tangential Benefits</font><br>On the plus side, burning all quantum vulne=
rable bitcoin would allow us to prune all of those UTXOs out of the UTXO se=
t, which would also clean up a lot of dust. Dust UTXOs are a bit of an anno=
yance and there has even been a recent proposal for how to incentivize clea=
ning them up.<br><br>We should also expect that incentivizing migration of =
the entire UTXO set will create substantial demand for block space that wil=
l sustain a fee market for a fairly lengthy amount of time.<br><br><font si=
ze=3D"6">In Summary</font><br>While the moral quandary of violating any of =
Bitcoin's inviolable properties can make this a very complex issue to discu=
ss, the game theory and incentives between burning vulnerable coins versus =
allowing them to be claimed by entities with quantum supremacy appears to b=
e a much simpler issue.<br><br>I, for one, am not interested in rewarding q=
uantum capable entities by inflating the circulating money supply just beca=
use some people lost their keys long ago and some laggards are not upgradin=
g their bitcoin wallet's security.<br><br>We can hope that this scenario ne=
ver comes to pass, but hope is not a strategy.<br><br>I welcome your feedba=
ck upon any of the above points, and contribution of any arguments I failed=
 to consider.</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"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.google.com/=
d/msgid/bitcoindev/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </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/0RX5JBKPTu3wDQH4tN3_CNwZnd6uFDuJ8GfDzx5JI4QriY6YssYmtcJm9WqHheay=
ARK85OzGNVTts8gcLXEQNoF9VZ5ZchSzuD1WAKuPNu0%3D%40proton.me?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/0RX5JB=
KPTu3wDQH4tN3_CNwZnd6uFDuJ8GfDzx5JI4QriY6YssYmtcJm9WqHheayARK85OzGNVTts8gcL=
XEQNoF9VZ5ZchSzuD1WAKuPNu0%3D%40proton.me</a>.<br />

-----------------------c957d09797fd3476cdb67d7eb0377594--
-----------------------7efa4d59818fa25a4482a23e407dfa74--
-----------------------518cf87f94814a86cfeeac9d59f64d63
Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI
YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO
dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3
Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL
YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox
K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo
CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J
MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr
T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR
TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp
S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag
UFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
-----------------------518cf87f94814a86cfeeac9d59f64d63--

--------2e35b45f1c467867d01e8624a74a1801e3bdee86a0d8b0dc28d3fd5ca1ca4658
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0Fgmh2XUgJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmetz/UYKh+7plTgSWP/f+zAa7xO+yA+2TlKNpQI
h1pechYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAKUQD+IBEzj7Ja58XAH8sw
UVSXEvMQsNb90jwpbwrZAA4JxHIBAPK9x6x/69U9ywDxE0/AExcNHKcMyVkf
8FD3sNnEjIUO
=hfDd
-----END PGP SIGNATURE-----


--------2e35b45f1c467867d01e8624a74a1801e3bdee86a0d8b0dc28d3fd5ca1ca4658--