From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Against Allowing Quantum Recovery of Bitcoin Message-ID: <0RX5JBKPTu3wDQH4tN3_CNwZnd6uFDuJ8GfDzx5JI4QriY6YssYmtcJm9WqHheayARK85OzGNVTts8gcLXEQNoF9VZ5ZchSzuD1WAKuPNu0=@proton.me> In-Reply-To: References: 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 Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) 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 ` - (For UTXOs whose pubkeys are still secret) I know a public key such tha= t `hash160(pubkey) =3D=3D ` =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 ` 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 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
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:

  • (For UTXOs whose pubkeys ar= e 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 s= till secret) I know a public key such that hash160(pubkey) =3D=3D <= ;hash>=E2=80=8B

From Or's paper, section 2.5:
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
S= pending Hashed UTXOs: To spend a hashed UTXO, the user signs it with a key-= lifted signature (see Section 2.2).

Spen= ding Derived UTXOs: To spend a derived UTXO, the user signs it with a seed-= lifted signature (see Section 2.3).

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 hash160(pubkey) = =3D=3D <hash>=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.

That said, we don't <= i>always require a hard fork as you note in the paper. It's totall= y fine to expose the EC signature and pubkey if 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.

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:

<= /div>
After the commitment has been posted, the spender has= a limited time to post a reveal of the commitment to the block= chain. If they fail to do so, the miner can post the proof of ownershipto claim the entire UTXO, making spam attempts costly 
<= /blockquote>

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>

The fee paid= for including tx is split equally between the miner who = included 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 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.

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 16 pages long. I don't expect anyone could push that much p= rotocol complexity into consensus in the next decade.

<= 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 comprehend all the r= ules and parameters included in the final FawkesCoin-driven protocol, <= span>


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

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: https://eprint.iacr.org/2023/362 (our= work was peer reviewed and presented here: https://www.qsmc.org/pqcsm-workshop-20= 23).

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 (https://dl.acm.or= g/doi/abs/10.1145/3133956.3133997) as the underlying primitive that ena= bles signature lifting.

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 https://jbonneau.com/doc/BM1= 4-SPW-fawkescoin.pdf 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.

Be= st,
Or

On Sunday, March 16, 2025 at 5:22:16=E2=80=AFPM UTC+2 Jameson Lop= p wrote:
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.

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.

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 think it's important to clarify the possi= ble scenarios up front.

1. Quantum computing never materializes, nev= er becomes a threat, and thus everything discussed in this essay is moot.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.
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.
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.=

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

To Freeze or not to Freeze?
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?

"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."
- Hunter Beast

On the othe= r hand:

"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."
- Pieter Wuille

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 out of reach of everyone.

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, an inviolable property of Bitcoin will be violated one = way or another.

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

The particular properties in play with regard to this issue se= em to be:

Censorship Resistance - No one should have the powe= r to prevent others from using their bitcoin or interacting with the networ= k.

Forward Compatibility - changing the rules such that certa= in valid transactions become invalid could undermine confidence in the prot= ocol.

Conservatism - Users should not be expected to be highl= y responsive to system issues.

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

Not you= r keys, not your coins.

I posit that the corollary to this = principle is:

Your= keys, only your coins.

A quantum capable entity breaks the= corollary of this foundational 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.

This is the princi= ple behind the motto vires in numeris - 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.

Who is at Risk?
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 https://bitinfocharts.com/top-100-richest-bitcoin-a= ddresses.html

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.

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.

The Ethical Dilemma: Quantifying Harm
Which decision resu= lts in the most harm?

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.

= 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.

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.

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

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.

Allowing qu= antum recovery of bitcoin is tantamount to wealth redistribution. 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.

Is Quantum Recovery Good for Anyone?
<= 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.

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.

For example:

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

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>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.
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...

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

Historical PrecedentPrevious 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.

Violation of Property Rights
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.

Erosion o= f Trust in Bitcoin
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.

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.

Unfair Advantage
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.
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.

Economic= Disruption
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.

Moral Re= sponsibility
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.

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:

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

Both options lack the consent of the= party whose coins are being burnt or 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.

Incentives Drive Secu= rity
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.

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

Protectin= g Property Rights
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!

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.

As such, I think the "protectin= g property rights" argument is a wash.

Quantum Comp= uters Won't Attack Bitcoin
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.

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.

Quantum Attackers Would Only Steal Small Amounts
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.

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.

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.

The 21 Millio= n Coin Supply Should be in Circulation
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.

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!

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.

= Self-Sovereignty and Personal Responsibility
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.

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.

Code is Law
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.

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.

Technological Evolution as a F= eature, Not a Bug
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.

Market Sig= nals Drive Security
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.
=
Centralized Blacklisting Power
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.

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.

Fairness in Competitio= n
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.

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.

Economic R= esilience
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.

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.

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.

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.

P= racticality & Neutrality of Non-Intervention
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.

Philosophical Purity
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.

Bitcoin's DAO Momen= t
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.

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.

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.

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

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

If true, the coro= llary is:

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

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?

* It's not good for the actual owners of those coins. It disinc= entivizes owners from upgrading until perhaps it's too late.
* 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.

Forking Game Theory
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?

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.

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.

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.=

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.

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.

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.

Rando= m Tangential Benefits
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.

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.

In Summary
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.

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.

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

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

--
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/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com= .

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0RX5JB= KPTu3wDQH4tN3_CNwZnd6uFDuJ8GfDzx5JI4QriY6YssYmtcJm9WqHheayARK85OzGNVTts8gcL= XEQNoF9VZ5ZchSzuD1WAKuPNu0%3D%40proton.me.
-----------------------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--