From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Apr 2026 13:47:16 -0700 Received: from mail-qv1-f64.google.com ([209.85.219.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wHpKp-00015F-2b for bitcoindev@gnusha.org; Tue, 28 Apr 2026 13:47:16 -0700 Received: by mail-qv1-f64.google.com with SMTP id 6a1803df08f44-8aca6f796d5sf69490236d6.0 for ; Tue, 28 Apr 2026 13:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777409225; x=1778014025; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=XxGdUI5QOiz3tJvbcfRWfMq47vaGb1aMWM3V4uCkBwI=; b=aS3ibqb6YpcK7pVvukQrBsk7K9NyDT05F8bB8NqpsTLJ1/TKQbX9HgvMqnTmpd4zzV Nsx78PC9wIbGxddsBOwxAjd42wnV4/nWCAlTDdsCrCvPZEvOzY8BW8qfAAUpXBnr6m9e 5nfL7GCd0mcN14C33GimLVE4tADAnISIBn/K59NxdRrca2s09zLc5qeeyf9iYdK1APFj 9Rg7ALNcrJf2lPcWG+NaYhgWrcnqqt5c4adqJsyp0etmai5O6jxAM6dDQl/4MYu/GAl0 3vef8+Q6mv51gseQg0bADTEX1CT29tjqk1aBmlrEg3rzW7Gk2OsvRf09K4dmTzmP7bDJ sh4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777409225; x=1778014025; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=XxGdUI5QOiz3tJvbcfRWfMq47vaGb1aMWM3V4uCkBwI=; b=TLYFgY+K0RHIHMJa8WzH8GzM5yrKZx3Iell8VW+kq1hl8UVRrhXp2fVP/ehpVsz6IO kO/1GMLr2dt3H/2wQiNb8chC439Cb0EoXZYRtLqthEJHO+B4oa7Ruzks6Okar8dDkz7s 0wOwiKDe9bWCetGJlPWLduJ0oSB5nYzHs0ZdaSiZ9VqzGY+XRC1FCw4u63iULJ0+bDMe FhVb9XqRT/SfVWkrYPjkYJ8qSeHraSMZl46Rx6QhXZQ/rUskZHxcPClxr5VAN85xwoW/ 2OjNkInB1rWslp6gUkuihF0RJwAzkT3kraOGFyoNQ+eovR7uRvaHukCtJScU80LAyu2y t4+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777409225; x=1778014025; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=XxGdUI5QOiz3tJvbcfRWfMq47vaGb1aMWM3V4uCkBwI=; b=JpEVv+keeAe04rw28WmBcIyveJ4WLzroTPATgkDutAm34AXhEb8r0/BMjvobKmPNG2 xEgFXZKgB6+zMpr9UDplD7D4REmEGB+W04xYUG1EfBhadGYWRGbj7wmBrX6IO+7dAz4X zAg43fdUgG2AMFm3bIllZr1mKe3s2aXelnLflguuUVjGsz288os3l+sVLBMqzHWTbOs+ bXLQRdHzh/qGIFsMW1/IJ/76qCHV+uPTqpsVeP/ZVGM4fIpcsGjNihAkL6OjLjL4wKK9 JtXj6g5eVxNeNAVw35zLC0umiPq4bpPtejtZJpOn9axI4PECqLLMu3kBM7BO5SVMBtUq YEBQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8d5uB2lNi3ltFdytBBSYl4a7Qh9oBZP9lRIo/SYMoZ6Z1KXaFCPo+hHiPsGh+mkXhnlRa4XJjn3Ijd@gnusha.org X-Gm-Message-State: AOJu0Yz8+ZhqMduAG2A3oqcX6RSIZ0+hAOfftPbhtLvrphdEKmNTFMcn iAtesJce7FG7ePdqfX2huQ/AcUF1ioMNI0pG9kJv90WRnrDdDHQyvuXS X-Received: by 2002:a05:6214:29c9:b0:8a7:31ea:9d29 with SMTP id 6a1803df08f44-8b3e2ff6dc3mr70756046d6.17.1777409224578; Tue, 28 Apr 2026 13:47:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPxfCLNRvSeBSDDxWAnbDVOqj7fLDg3qOby5Cp/tKBkcA==" Received: by 2002:a05:6214:762:b0:89c:5962:3077 with SMTP id 6a1803df08f44-8ae820aff77ls312547486d6.2.-pod-prod-09-us; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) X-Received: by 2002:a05:620a:404a:b0:8ea:addd:894c with SMTP id af79cd13be357-8f8f686c288mr183670585a.53.1777409217486; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) Received: by 2002:a05:690c:d19:b0:7b3:443:26a9 with SMTP id 00721157ae682-7b9ed99b113ms7b3; Sat, 18 Apr 2026 07:17:46 -0700 (PDT) X-Received: by 2002:a05:690c:c248:b0:79a:dae4:5832 with SMTP id 00721157ae682-7b9ecef861amr71676417b3.22.1776521865548; Sat, 18 Apr 2026 07:17:45 -0700 (PDT) Date: Sat, 18 Apr 2026 07:17:45 -0700 (PDT) From: Thomas Suau To: Bitcoin Development Mailing List Message-Id: <3fec8fc3-efa1-49c5-8bab-592e0138d31dn@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_693750_1173719507.1776521865074" X-Original-Sender: tomeclair@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 0.0 (/) ------=_Part_693750_1173719507.1776521865074 Content-Type: multipart/alternative; boundary="----=_Part_693751_1904856168.1776521865074" ------=_Part_693751_1904856168.1776521865074 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 Against freezing. A vulnerable user post-CRQC is someone who made two active choices: reusing= =20 addresses, and not migrating once a standard is available. That's the user= =20 breaking the social contract, not the protocol. P2PKH, P2WPKH, P2SH, P2WSH= =20 outputs which have never spent are not at risk =E2=80=94 pubkey is hashed, = not=20 exposed. P2PK, reused addresses, and P2TR key path are. Bitcoin isn't=20 globally broken =E2=80=94 specific address types are, and users holding the= m after=20 a migration path exists are accepting the risk. A script-type freeze applies uniformly to weak output types, not to=20 specific transactions =E2=80=94 categorically different from reversing exch= ange=20 hacks. But once the protocol starts deciding which coins are safe enough to= =20 spend, that logic is hard to contain. Either way, the freeze debate is a signal, not the goal. It tells us we=20 need a standard urgently. That's where the energy should go =E2=80=94 Matt'= s thread=20 is asking the right question What's our goal?=20 . Regards, Thomas Le jeudi 9 avril 2026 =C3=A0 10:36:50 UTC+2, Jameson Lopp a =C3=A9crit : > Scratch that; nodes should already be storing the block for which a UTXO= =20 > was confirmed in order to calculate relative timelock validity. So it=20 > should be implementable. > > Still, there are several vague statements that could use more explanation= . > > "predictable cliffs invite adversarial behavior." - such as? > > "This avoids retroactively invalidating old transactions while still=20 > phasing out insecure constructions." - how so? If you chose a relative ma= x=20 > age that's less than the total age of Bitcoin itself, it will by default= =20 > invalidate extremely old UTXOs. > > "If the protocol begins to distinguish between =E2=80=9Clegitimate=E2=80= =9D and=20 > =E2=80=9Cquantum=E2=80=91recovered=E2=80=9D spends" - not sure what this = means. It's not possible=20 > to know if a transaction was made by a quantum attacker. > > On Thu, Apr 9, 2026 at 9:04=E2=80=AFAM Jameson Lopp = wrote: > >> While an implied age timelock is interesting in theory, I don't think=20 >> it's practical in reality. >> >> The reason that current styles of timelocks work well is because they ar= e=20 >> explicit: the actual block height / timestamp of the lock is contained= =20 >> somewhere inside of the transaction itself. >> >> In order to implement an "implied" scheme as you propose, it would=20 >> require all nodes to start indexing UTXOs by block height in order to av= oid=20 >> a massive performance drop when evaluating whether or not the UTXO is=20 >> spendable. >> >> On Thu, Apr 9, 2026 at 3:01=E2=80=AFAM Bitcoin wro= te: >> >>> The protocol should not assume that future participants will be able to= =20 >>> coordinate around a single deadline without distortion. A fixed height = at=20 >>> which old outputs become invalid would create a predictable cliff, and= =20 >>> predictable cliffs invite adversarial behavior. Markets tend to rush to= ward=20 >>> the edge. >>> >>> Bitcoin works best when incentives are continuous rather than abrupt. >>> >>> A staggered expiration of vulnerable script types is more consistent=20 >>> with the system=E2=80=99s long=E2=80=91term stability. If a class of ou= tputs is known to be=20 >>> weak against new computation, then the network can define a rule that s= uch=20 >>> outputs must be spent within a certain number of blocks after creation.= =20 >>> This avoids retroactively invalidating old transactions while still pha= sing=20 >>> out insecure constructions. >>> >>> The network already treats some script forms as discouraged. Extending= =20 >>> this to prohibit creation of new vulnerable forms is a natural evolutio= n.=20 >>> Nodes can continue to validate the old chain history while refusing to= =20 >>> relay or mine new transactions that expose public keys directly. >>> >>> The idea of forcing quantum=E2=80=91recovered coins into long timelocks= is=20 >>> interesting, but it introduces a new class of special=E2=80=91case beha= vior.=20 >>> Bitcoin=E2=80=99s rules should be simple, general, and predictable. If = the protocol=20 >>> begins to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2=80= =9Cquantum=E2=80=91recovered=E2=80=9D spends,=20 >>> it implies an authority deciding which coins are morally valid. That is= a=20 >>> precedent the system should avoid. >>> >>> The safest rule is the one that does not require judging intent. >>> >>> A relative or absolute timelock applied uniformly to all vulnerable=20 >>> outputs, triggered only by their age, is neutral. It does not ask who i= s=20 >>> spending the coins or why. It only enforces that insecure forms must be= =20 >>> migrated in time. >>> >>> The network cannot prevent advances in mathematics or computation. It= =20 >>> can only ensure that the incentives remain aligned so that users upgrad= e=20 >>> their security before adversaries can exploit weaknesses. The protocol= =20 >>> should encourage timely movement without confiscation. >>> >>> The principle remains: >>> >>> Your keys, your coins =E2=80=94 but only as long as the key is strong. >>> >>> If a key type becomes weak, the system must give ample time to move=20 >>> funds to stronger constructions, and then retire the weak form graduall= y so=20 >>> the chain does not become a liability. >>> >>> =E2=80=94 S. >>> >>> On Mon, Apr 7, 2025, 6:34=E2=80=AFAM Nadav Ivgi wro= te: >>> >>>> One possible alternative to freezing/burning the coins entirely is=20 >>>> letting quantum attackers keep some small percent as a reward, but for= ce=20 >>>> them to stage the rest to future miners as an additional security budg= et=20 >>>> subsidy. >>>> >>>> This can be implemented as a soft fork, by requiring transactions=20 >>>> spending QC-vulnerable coins to allocate some funds to an OP_CLTV[0]-o= nly=20 >>>> encumbered output timelocked far into the future. Miners would then mo= nitor=20 >>>> these outputs and claim them as they become available. >>>> >>>> For example, allow a 1% reward to be spent freely to any address but= =20 >>>> require 99% to be sent to an OP_CLTV output timelocked to a=20 >>>> deterministically random height between 10-100 years from now. >>>> >>>> The 1% reward could also be required to be sent to a script that=20 >>>> enforces a timelock (in addition to other conditions), to avoid floodi= ng=20 >>>> the markets with the rewarded coins all at once. Probably a shorter=20 >>>> timelock duration though, say picked randomly between 10-30 months. >>>> >>>> To further smooth out variance in the release schedule, coins could be= =20 >>>> split into up-to-N-BTC outputs, each staggered with a different=20 >>>> deterministic timelock. So for example, a single tx spending 10,000 BT= C=20 >>>> won't release 9,900 BTC to the miners in a single far-future block (wh= ich=20 >>>> may cause chain instability if the miners get into a reorg war over it= ),=20 >>>> but rather as 9,900 separate outputs of 1 BTC each released gradually= =20 >>>> time.[1] >>>> >>>> I'm still not sure what I think about this. This is not necessarily an= =20 >>>> endorsement, just a thought. :) >>>> >>>> - shesek >>>> >>>> [0] OP_CSV only supports relative timelocks of up to 65535 blocks (~15= =20 >>>> months), which is too short for that purpose. OP_CLTV supports longer= =20 >>>> (absolute) timelocks. >>>> >>>> [1] This can be made more efficient with CTV, by having a single UTXO= =20 >>>> carrying the full amount that slowly unrolls rather than 9,900 separat= e=20 >>>> UTXO entries. >>>> >>>> >>>> On Sun, Mar 16, 2025 at 5:22=E2=80=AFPM Jameson Lopp =20 >>>> wrote: >>>> >>>>> The quantum computing debate is heating up. There are many=20 >>>>> controversial aspects to this debate, including whether or not quantu= m=20 >>>>> computers will ever actually become a practical threat. >>>>> >>>>> I won't tread into the unanswerable question of how worried we should= =20 >>>>> be about quantum computers. I think it's far from a crisis, but given= the=20 >>>>> difficulty in changing Bitcoin it's worth starting to seriously discu= ss.=20 >>>>> Today I wish to focus on a philosophical quandary related to one of t= he=20 >>>>> decisions that would need to be made if and when we implement a quant= um=20 >>>>> safe signature scheme. >>>>> >>>>> Several Scenarios >>>>> Because this essay will reference game theory a fair amount, and ther= e=20 >>>>> are many variables at play that could change the nature of the game, = I=20 >>>>> think it's important to clarify the possible scenarios up front. >>>>> >>>>> 1. Quantum computing never materializes, never becomes a threat, and= =20 >>>>> thus everything discussed in this essay is moot. >>>>> 2. A quantum computing threat materializes suddenly and Bitcoin does= =20 >>>>> not have quantum safe signatures as part of the protocol. In this sce= nario=20 >>>>> it would likely make the points below moot because Bitcoin would be= =20 >>>>> fundamentally broken and it would take far too long to upgrade the=20 >>>>> protocol, wallet software, and migrate user funds in order to restore= =20 >>>>> confidence in the network. >>>>> 3. Quantum computing advances slowly enough that we come to consensus= =20 >>>>> about how to upgrade Bitcoin and post quantum security has been minim= ally=20 >>>>> adopted by the time an attacker appears. >>>>> 4. Quantum computing advances slowly enough that we come to consensus= =20 >>>>> about how to upgrade Bitcoin and post quantum security has been highl= y=20 >>>>> adopted by the time an attacker appears. >>>>> >>>>> For the purposes of this post, I'm envisioning being in situation 3 o= r=20 >>>>> 4. >>>>> >>>>> To Freeze or not to Freeze? >>>>> I've started seeing more people weighing in on what is likely the mos= t=20 >>>>> contentious aspect of how a quantum resistance upgrade should be hand= led in=20 >>>>> terms of migrating user funds. Should quantum vulnerable funds be lef= t open=20 >>>>> to be swept by anyone with a sufficiently powerful quantum computer O= R=20 >>>>> should they be permanently locked? >>>>> >>>>> "I don't see why old coins should be confiscated. The better option i= s=20 >>>>>> to let those with quantum computers free up old coins. While this mi= ght=20 >>>>>> have an inflationary impact on bitcoin's price, to use a turn of phr= ase,=20 >>>>>> the inflation is transitory. Those with low time preference should s= upport=20 >>>>>> returning lost coins to circulation."=20 >>>>> >>>>> - Hunter Beast >>>>> >>>>> >>>>> On the other hand: >>>>> >>>>> "Of course they have to be confiscated. If and when (and that's a big= =20 >>>>>> if) the existence of a cryptography-breaking QC becomes a credible t= hreat,=20 >>>>>> the Bitcoin ecosystem has no other option than softforking out the a= bility=20 >>>>>> to spend from signature schemes (including ECDSA and BIP340) that ar= e=20 >>>>>> vulnerable to QCs. The alternative is that millions of BTC become=20 >>>>>> vulnerable to theft; I cannot see how the currency can maintain any = value=20 >>>>>> at all in such a setting. And this affects everyone; even those whic= h=20 >>>>>> diligently moved their coins to PQC-protected schemes." >>>>>> - Pieter Wuille >>>>> >>>>> >>>>> I don't think "confiscation" is the most precise term to use, as the= =20 >>>>> funds are not being seized and reassigned. Rather, what we're really= =20 >>>>> discussing would be better described as "burning" - placing the funds= *out=20 >>>>> of reach of everyone*. >>>>> >>>>> Not freezing user funds is one of Bitcoin's inviolable properties.=20 >>>>> However, if quantum computing becomes a threat to Bitcoin's elliptic = curve=20 >>>>> cryptography, *an inviolable property of Bitcoin will be violated one= =20 >>>>> way or another*. >>>>> >>>>> Fundamental Properties at Risk >>>>> 5 years ago I attempted to comprehensively categorize all of Bitcoin'= s=20 >>>>> fundamental properties that give it value.=20 >>>>> https://nakamoto.com/what-are-the-key-properties-of-bitcoin/ >>>>> >>>>> The particular properties in play with regard to this issue seem to b= e: >>>>> >>>>> *Censorship Resistance* - No one should have the power to prevent=20 >>>>> others from using their bitcoin or interacting with the network. >>>>> >>>>> *Forward Compatibility* - changing the rules such that certain valid= =20 >>>>> transactions become invalid could undermine confidence in the protoco= l. >>>>> >>>>> *Conservatism* - Users should not be expected to be highly responsive= =20 >>>>> to system issues. >>>>> >>>>> As a result of the above principles, we have developed a strong meme= =20 >>>>> (kudos to Andreas Antonopoulos) that goes as follows: >>>>> >>>>> Not your keys, not your coins. >>>>> >>>>> >>>>> I posit that the corollary to this principle is: >>>>> >>>>> Your keys, only your coins. >>>>> >>>>> >>>>> A quantum capable entity breaks the corollary of this foundational=20 >>>>> principle. We secure our bitcoin with the mathematical probabilities= =20 >>>>> related to extremely large random numbers. Your funds are only secure= =20 >>>>> because truly random large numbers should not be guessable or discove= rable=20 >>>>> by anyone else in the world. >>>>> >>>>> This is the principle behind the motto *vires in numeris* - strength= =20 >>>>> in numbers. In a world with quantum enabled adversaries, this princip= le is=20 >>>>> null and void for many types of cryptography, including the elliptic = curve=20 >>>>> digital signatures used in Bitcoin. >>>>> >>>>> Who is at Risk? >>>>> There has long been a narrative that Satoshi's coins and others from= =20 >>>>> the Satoshi era of P2PK locking scripts that exposed the public key= =20 >>>>> directly on the blockchain will be those that get scooped up by a qua= ntum=20 >>>>> "miner." But unfortunately it's not that simple. If I had a powerful= =20 >>>>> quantum computer, which coins would I target? I'd go to the Bitcoin r= ich=20 >>>>> list and find the wallets that have exposed their public keys due to= =20 >>>>> re-using addresses that have previously been spent from. You can easi= ly=20 >>>>> find them at=20 >>>>> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html >>>>> >>>>> Note that a few of these wallets, like Bitfinex / Kraken / Tether,=20 >>>>> would be slightly harder to crack because they are multisig wallets. = So a=20 >>>>> quantum attacker would need to reverse engineer 2 keys for Kraken or = 3 for=20 >>>>> Bitfinex / Tether in order to spend funds. But many are single signat= ure. >>>>> >>>>> Point being, it's not only the really old lost BTC that are at risk t= o=20 >>>>> a quantum enabled adversary, at least at time of writing. If we add a= =20 >>>>> quantum safe signature scheme, we should expect those wallets to be s= ome of=20 >>>>> the first to upgrade given their incentives. >>>>> >>>>> The Ethical Dilemma: Quantifying Harm >>>>> Which decision results in the most harm? >>>>> >>>>> By making quantum vulnerable funds unspendable we potentially harm=20 >>>>> some Bitcoin users who were not paying attention and neglected to mig= rate=20 >>>>> their funds to a quantum safe locking script. This violates the=20 >>>>> "conservativism" principle stated earlier. On the flip side, we preve= nt=20 >>>>> those funds plus far more lost funds from falling into the hands of t= he few=20 >>>>> privileged folks who gain early access to quantum computers. >>>>> >>>>> By leaving quantum vulnerable funds available to spend, the same set= =20 >>>>> of users who would otherwise have funds frozen are likely to see them= =20 >>>>> stolen. And many early adopters who lost their keys will eventually s= ee=20 >>>>> their unreachable funds scooped up by a quantum enabled adversary. >>>>> >>>>> Imagine, for example, being James Howells, who accidentally threw awa= y=20 >>>>> a hard drive with 8,000 BTC on it, currently worth over $600M USD. He= has=20 >>>>> spent a decade trying to retrieve it from the landfill where he knows= it's=20 >>>>> buried, but can't get permission to excavate. I suspect that, given t= he=20 >>>>> choice, he'd prefer those funds be permanently frozen rather than fal= l into=20 >>>>> someone else's possession - I know I would. >>>>> >>>>> Allowing a quantum computer to access lost funds doesn't make those= =20 >>>>> users any worse off than they were before, however it *would* have a= =20 >>>>> negative impact upon everyone who is currently holding bitcoin. >>>>> >>>>> It's prudent to expect significant economic disruption if large=20 >>>>> amounts of coins fall into new hands. Since a quantum computer is goi= ng to=20 >>>>> have a massive up front cost, expect those behind it to desire to rec= oup=20 >>>>> their investment. We also know from experience that when someone sudd= enly=20 >>>>> finds themselves in possession of 9+ figures worth of highly liquid a= ssets,=20 >>>>> they tend to diversify into other things by selling. >>>>> >>>>> Allowing quantum recovery of bitcoin is *tantamount to wealth=20 >>>>> redistribution*. What we'd be allowing is for bitcoin to be=20 >>>>> redistributed from those who are ignorant of quantum computers to tho= se who=20 >>>>> have won the technological race to acquire quantum computers. It's ha= rd to=20 >>>>> see a bright side to that scenario. >>>>> >>>>> Is Quantum Recovery Good for Anyone? >>>>> >>>>> Does quantum recovery HELP anyone? I've yet to come across an argumen= t=20 >>>>> that it's a net positive in any way. It certainly doesn't add any sec= urity=20 >>>>> to the network. If anything, it greatly decreases the security of the= =20 >>>>> network by allowing funds to be claimed by those who did not earn the= m. >>>>> >>>>> But wait, you may be thinking, wouldn't quantum "miners" have earned= =20 >>>>> their coins by all the work and resources invested in building a quan= tum=20 >>>>> computer? I suppose, in the same sense that a burglar earns their spo= ils by=20 >>>>> the resources they invest into surveilling targets and learning the s= kills=20 >>>>> needed to break into buildings. What I say "earned" I mean through=20 >>>>> productive mutual trade. >>>>> >>>>> For example: >>>>> >>>>> * Investors earn BTC by trading for other currencies. >>>>> * Merchants earn BTC by trading for goods and services. >>>>> * Miners earn BTC by trading thermodynamic security. >>>>> * Quantum miners don't trade anything, they are vampires feeding upon= =20 >>>>> the system. >>>>> >>>>> There's no reason to believe that allowing quantum adversaries to=20 >>>>> recover vulnerable bitcoin will be of benefit to anyone other than th= e=20 >>>>> select few organizations that win the technological arms race to buil= d the=20 >>>>> first such computers. Probably nation states and/or the top few large= st=20 >>>>> tech companies. >>>>> >>>>> One could certainly hope that an organization with quantum supremacy= =20 >>>>> is benevolent and acts in a "white hat" manner to return lost coins t= o=20 >>>>> their owners, but that's incredibly optimistic and foolish to rely up= on.=20 >>>>> Such a situation creates an insurmountable ethical dilemma of only=20 >>>>> recovering lost bitcoin rather than currently owned bitcoin. There's = no way=20 >>>>> to precisely differentiate between the two; anyone can claim to have = lost=20 >>>>> their bitcoin but if they have lost their keys then proving they ever= had=20 >>>>> the keys becomes rather difficult. I imagine that any such white hat= =20 >>>>> recovery efforts would have to rely upon attestations from trusted th= ird=20 >>>>> parties like exchanges. >>>>> >>>>> Even if the first actor with quantum supremacy is benevolent, we must= =20 >>>>> assume the technology could fall into adversarial hands and thus thin= k=20 >>>>> adversarially about the potential worst case outcomes. Imagine, for= =20 >>>>> example, that North Korea continues scooping up billions of dollars f= rom=20 >>>>> hacking crypto exchanges and decides to invest some of those proceeds= into=20 >>>>> building a quantum computer for the biggest payday ever... >>>>> >>>>> Downsides to Allowing Quantum Recovery >>>>> Let's think through an exhaustive list of pros and cons for allowing= =20 >>>>> or preventing the seizure of funds by a quantum adversary. >>>>> >>>>> Historical Precedent >>>>> Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair= game"=20 >>>>> but rather were treated as failures to be remediated. Treating quantu= m=20 >>>>> theft differently risks rewriting Bitcoin=E2=80=99s history as a free= -for-all=20 >>>>> 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= =20 >>>>> fundamental principle of cryptocurrency - if you keep your keys in yo= ur=20 >>>>> possession, only you should be able to access your money. Bitcoin is = built=20 >>>>> on the idea that private keys secure an individual=E2=80=99s assets, = and=20 >>>>> unauthorized access (even via advanced tech) is theft, not a legitima= te=20 >>>>> transfer. >>>>> >>>>> Erosion of Trust in Bitcoin >>>>> If quantum attackers can exploit vulnerable addresses, confidence in= =20 >>>>> Bitcoin as a secure store of value would collapse. Users and investor= s rely=20 >>>>> on cryptographic integrity, and widespread theft could drive adoption= away=20 >>>>> from Bitcoin, destabilizing its ecosystem. >>>>> >>>>> This is essentially the counterpoint to claiming the burning of=20 >>>>> vulnerable funds is a violation of property rights. While some will= =20 >>>>> certainly see it as such, others will find the apathy toward stopping= =20 >>>>> quantum theft to be similarly concerning. >>>>> >>>>> Unfair Advantage >>>>> Quantum attackers, likely equipped with rare and expensive technology= ,=20 >>>>> would have an unjust edge over regular users who lack access to such = tools.=20 >>>>> This creates an inequitable system where only the technologically eli= te can=20 >>>>> exploit others, contradicting Bitcoin=E2=80=99s ethos of decentralize= d power. >>>>> >>>>> Bitcoin is designed to create an asymmetric advantage for DEFENDING= =20 >>>>> one's wealth. It's supposed to be impractically expensive for attacke= rs to=20 >>>>> crack the entropy and cryptography protecting one's coins. But now we= find=20 >>>>> ourselves discussing a situation where this asymmetric advantage is= =20 >>>>> compromised in favor of a specific class of attackers. >>>>> >>>>> Economic Disruption >>>>> Large-scale theft from vulnerable addresses could crash Bitcoin=E2=80= =99s=20 >>>>> price as quantum recovered funds are dumped on exchanges. This would = harm=20 >>>>> all holders, not just those directly targeted, leading to broader fin= ancial=20 >>>>> chaos in the markets. >>>>> >>>>> Moral Responsibility >>>>> Permitting theft via quantum computing sets a precedent that=20 >>>>> technological superiority justifies unethical behavior. This is essen= tially=20 >>>>> taking a "code is law" stance in which we refuse to admit that both c= ode=20 >>>>> and laws can be modified to adapt to previously unforeseen situations= . >>>>> >>>>> Burning of coins can certainly be considered a form of theft, thus I= =20 >>>>> think it's worth differentiating the two different thefts being discu= ssed: >>>>> >>>>> 1. self-enriching & likely malicious >>>>> 2. harm prevention & not necessarily malicious >>>>> >>>>> Both options lack the consent of the party whose coins are being burn= t=20 >>>>> or transferred, thus I think the simple argument that theft is immora= l=20 >>>>> becomes a wash and it's important to drill down into the details of e= ach. >>>>> >>>>> Incentives Drive Security >>>>> I can tell you from a decade of working in Bitcoin security - the=20 >>>>> average user is lazy and is a procrastinator. If Bitcoiners are given= a=20 >>>>> "drop dead date" after which they know vulnerable funds will be burne= d,=20 >>>>> this pressure accelerates the adoption of post-quantum cryptography a= nd=20 >>>>> strengthens Bitcoin long-term. Allowing vulnerable users to delay upg= rading=20 >>>>> indefinitely will result in more laggards, leaving the network more e= xposed=20 >>>>> when quantum tech becomes available. >>>>> >>>>> Steel Manning >>>>> Clearly this is a complex and controversial topic, thus it's worth=20 >>>>> thinking through the opposing arguments. >>>>> >>>>> Protecting Property Rights >>>>> Allowing quantum computers to take vulnerable bitcoin could=20 >>>>> potentially be spun as a hard money narrative - we care so greatly ab= out=20 >>>>> not violating someone's access to their coins that we allow them to b= e=20 >>>>> stolen! >>>>> >>>>> But I think the flip side to the property rights narrative is that=20 >>>>> burning vulnerable coins prevents said property from falling into=20 >>>>> undeserving hands. If the entire Bitcoin ecosystem just stands around= and=20 >>>>> allows quantum adversaries to claim funds that rightfully belong to o= ther=20 >>>>> users, is that really a "win" in the "protecting property rights" cat= egory?=20 >>>>> It feels more like apathy to me. >>>>> >>>>> As such, I think the "protecting property rights" argument is a wash. >>>>> >>>>> Quantum Computers Won't Attack Bitcoin >>>>> There is a great deal of skepticism that sufficiently powerful quantu= m=20 >>>>> computers will ever exist, so we shouldn't bother preparing for a=20 >>>>> non-existent threat. Others have argued that even if such a computer = was=20 >>>>> built, a quantum attacker would not go after bitcoin because they wou= ldn't=20 >>>>> want to reveal their hand by doing so, and would instead attack other= =20 >>>>> infrastructure. >>>>> >>>>> It's quite difficult to quantify exactly how valuable attacking other= =20 >>>>> infrastructure would be. It also really depends upon when an entity g= ains=20 >>>>> quantum supremacy and thus if by that time most of the world's system= s have=20 >>>>> already been upgraded. While I think you could argue that certain ent= ities=20 >>>>> gaining quantum capability might not attack Bitcoin, it would only de= lay=20 >>>>> the inevitable - eventually somebody will achieve the capability who= =20 >>>>> decides to use it for such an attack. >>>>> >>>>> Quantum Attackers Would Only Steal Small Amounts >>>>> Some have argued that even if a quantum attacker targeted bitcoin,=20 >>>>> they'd only go after old, likely lost P2PK outputs so as to not arous= e=20 >>>>> suspicion and cause a market panic. >>>>> >>>>> I'm not so sure about that; why go after 50 BTC at a time when you=20 >>>>> could take 250,000 BTC with the same effort as 50 BTC? This is a clas= sic=20 >>>>> "zero day exploit" game theory in which an attacker knows they have a= =20 >>>>> limited amount of time before someone else discovers the exploit and = either=20 >>>>> benefits from it or patches it. Take, for example, the recent ByBit a= ttack=20 >>>>> - the highest value crypto hack of all time. Lazarus Group had compro= mised=20 >>>>> the Safe wallet front end JavaScript app and they could have simply h= ad it=20 >>>>> reassign ownership of everyone's Safe wallets as they were interactin= g with=20 >>>>> their wallet. But instead they chose to only specifically target ByBi= t's=20 >>>>> wallet with $1.5 billion in it because they wanted to maximize their= =20 >>>>> extractable value. If Lazarus had started stealing from every wallet,= they=20 >>>>> would have been discovered quickly and the Safe web app would likely = have=20 >>>>> been patched well before any billion dollar wallets executed the mali= cious=20 >>>>> code. >>>>> >>>>> I think the "only stealing small amounts" argument is strongest for= =20 >>>>> Situation #2 described earlier, where a quantum attacker arrives befo= re=20 >>>>> quantum safe cryptography has been deployed across the Bitcoin ecosys= tem.=20 >>>>> Because if it became clear that Bitcoin's cryptography was broken AND= there=20 >>>>> was nowhere safe for vulnerable users to migrate, the only logical op= tion=20 >>>>> would be for everyone to liquidate their bitcoin as quickly as possib= le. As=20 >>>>> such, I don't think it applies as strongly for situations in which we= have=20 >>>>> a migration path available. >>>>> >>>>> The 21 Million Coin Supply Should be in Circulation >>>>> Some folks are arguing that it's important for the "circulating /=20 >>>>> spendable" supply to be as close to 21M as possible and that having a= =20 >>>>> significant portion of the supply out of circulation is somehow undes= irable. >>>>> >>>>> While the "21M BTC" attribute is a strong memetic narrative, I don't= =20 >>>>> think anyone has ever expected that it would all be in circulation. I= t has=20 >>>>> always been understood that many coins will be lost, and that's actua= lly=20 >>>>> part of the game theory of owning bitcoin! >>>>> >>>>> And remember, the 21M number in and of itself is not a particularly= =20 >>>>> important detail - it's not even mentioned in the whitepaper. What's= =20 >>>>> important is that the supply is well known and not subject to change. >>>>> >>>>> Self-Sovereignty and Personal Responsibility >>>>> Bitcoin=E2=80=99s design empowers individuals to control their own we= alth,=20 >>>>> free from centralized intervention. This freedom comes with the burde= n of=20 >>>>> securing one's private keys. If quantum computing can break obsolete= =20 >>>>> cryptography, the fault lies with users who didn't move their funds t= o=20 >>>>> quantum safe locking scripts. Expecting the network to shield users f= rom=20 >>>>> their own negligence undermines the principle that you, and not a thi= rd=20 >>>>> party, are accountable for your assets. >>>>> >>>>> I think this is generally a fair point that "the community" doesn't= =20 >>>>> owe you anything in terms of helping you. I think that we do, however= , need=20 >>>>> to consider the incentives and game theory in play with regard to qua= ntum=20 >>>>> safe Bitcoiners vs quantum vulnerable Bitcoiners. More on that later. >>>>> >>>>> Code is Law >>>>> Bitcoin operates on transparent, immutable rules embedded in its=20 >>>>> protocol. If a quantum attacker uses superior technology to derive pr= ivate=20 >>>>> keys from public keys, they=E2=80=99re not "hacking" the system - the= y're simply=20 >>>>> following what's mathematically permissible within the current code.= =20 >>>>> Altering the protocol to stop this introduces subjective human=20 >>>>> intervention, which clashes with the objective, deterministic nature = of=20 >>>>> blockchain. >>>>> >>>>> While I tend to agree that code is law, one of the entire points of= =20 >>>>> laws is that they can be amended to improve their efficacy in reducin= g=20 >>>>> harm. Leaning on this point seems more like a pro-ossification stance= that=20 >>>>> it's better to do nothing and allow harm to occur rather than take ac= tion=20 >>>>> to stop an attack that was foreseen far in advance. >>>>> >>>>> Technological Evolution as a Feature, Not a Bug >>>>> It's well known that cryptography tends to weaken over time and=20 >>>>> eventually break. Quantum computing is just the next step in this=20 >>>>> progression. Users who fail to adapt (e.g., by adopting quantum-resis= tant=20 >>>>> wallets when available) are akin to those who ignored technological= =20 >>>>> advancements like multisig or hardware wallets. Allowing quantum thef= t=20 >>>>> incentivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic= , punishing=20 >>>>> complacency while rewarding vigilance. >>>>> >>>>> Market Signals Drive Security >>>>> If quantum attackers start stealing funds, it sends a clear signal to= =20 >>>>> the market: upgrade your security or lose everything. This pressure= =20 >>>>> accelerates the adoption of post-quantum cryptography and strengthens= =20 >>>>> Bitcoin long-term. Coddling vulnerable users delays this necessary=20 >>>>> evolution, potentially leaving the network more exposed when quantum = tech=20 >>>>> becomes widely accessible. Theft is a brutal but effective teacher. >>>>> >>>>> Centralized Blacklisting Power >>>>> Burning vulnerable funds requires centralized decision-making - a sof= t=20 >>>>> fork to invalidate certain transactions. This sets a dangerous preced= ent=20 >>>>> for future interventions, eroding Bitcoin=E2=80=99s decentralization.= If quantum=20 >>>>> theft is blocked, what=E2=80=99s next - reversing exchange hacks? The= system must=20 >>>>> remain neutral, even if it means some lose out. >>>>> >>>>> I think this could be a potential slippery slope if the proposal was= =20 >>>>> to only burn specific addresses. Rather, I'd expect a neutral proposa= l to=20 >>>>> burn all funds in locking script types that are known to be quantum= =20 >>>>> vulnerable. Thus, we could eliminate any subjectivity from the code. >>>>> >>>>> Fairness in Competition >>>>> Quantum attackers aren't cheating; they're using publicly available= =20 >>>>> physics and math. Anyone with the resources and foresight can build o= r=20 >>>>> access quantum tech, just as anyone could mine Bitcoin in 2009 with a= CPU.=20 >>>>> Early adopters took risks and reaped rewards; quantum innovators are = doing=20 >>>>> the same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin ha= s never promised=20 >>>>> equality of outcome - only equality of opportunity within its rules. >>>>> >>>>> I find this argument to be a mischaracterization because we're not=20 >>>>> talking about CPUs. This is more akin to talking about ASICs, except = each=20 >>>>> ASIC costs millions if not billions of dollars. This is out of reach = from=20 >>>>> all but the wealthiest organizations. >>>>> >>>>> Economic Resilience >>>>> Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and= =20 >>>>> emerged stronger. The market can absorb quantum losses, with unaffect= ed=20 >>>>> users continuing to hold and new entrants buying in at lower prices. = Fear=20 >>>>> of economic collapse overestimates the impact - the network=E2=80=99s= antifragility=20 >>>>> thrives on such challenges. >>>>> >>>>> This is a big grey area because we don't know when a quantum computer= =20 >>>>> will come online and we don't know how quickly said computers would b= e able=20 >>>>> to steal bitcoin. If, for example, the first generation of sufficient= ly=20 >>>>> powerful quantum computers were stealing less volume than the current= block=20 >>>>> reward then of course it will have minimal economic impact. But if th= ey're=20 >>>>> taking thousands of BTC per day and bringing them back into circulati= on,=20 >>>>> there will likely be a noticeable market impact as it absorbs the new= =20 >>>>> supply. >>>>> >>>>> This is where the circumstances will really matter. If a quantum=20 >>>>> attacker appears AFTER the Bitcoin protocol has been upgraded to supp= ort=20 >>>>> quantum resistant cryptography then we should expect the most valuabl= e=20 >>>>> active wallets will have upgraded and the juiciest target would be th= e=20 >>>>> 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which ha= s been=20 >>>>> dormant since 2010. In general I'd expect that the amount of BTC=20 >>>>> re-entering the circulating supply would look somewhat similar to the= =20 >>>>> mining emission curve: volume would start off very high as the most= =20 >>>>> valuable addresses are drained and then it would fall off as quantum= =20 >>>>> computers went down the list targeting addresses with less and less B= TC. >>>>> >>>>> Why is economic impact a factor worth considering? Miners and=20 >>>>> businesses in general. More coins being liquidated will push down the= =20 >>>>> price, which will negatively impact miner revenue. Similarly, I can a= ttest=20 >>>>> from working in the industry for a decade, that lower prices result i= n less=20 >>>>> demand from businesses across the entire industry. As such, burning q= uantum=20 >>>>> vulnerable bitcoin is good for the entire industry. >>>>> >>>>> Practicality & Neutrality of Non-Intervention >>>>> There=E2=80=99s no reliable way to distinguish =E2=80=9Ctheft=E2=80= =9D from legitimate "white=20 >>>>> hat" key recovery. If someone loses their private key and a quantum= =20 >>>>> computer recovers it, is that stealing or reclaiming? Policing quantu= m=20 >>>>> actions requires invasive assumptions about intent, which Bitcoin=E2= =80=99s=20 >>>>> trustless design can=E2=80=99t accommodate. Letting the chips fall wh= ere they may=20 >>>>> avoids this mess. >>>>> >>>>> Philosophical Purity >>>>> Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system where outc= omes=20 >>>>> reflect preparation and skill, not sentimentality. If quantum computi= ng=20 >>>>> upends the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t mea= nt to be safe or fair=20 >>>>> in a nanny-state sense; it=E2=80=99s meant to be free. Users who lose= funds to=20 >>>>> quantum attacks are casualties of liberty and their own ignorance, no= t=20 >>>>> victims of injustice. >>>>> >>>>> Bitcoin's DAO Moment >>>>> This situation has some similarities to The DAO hack of an Ethereum= =20 >>>>> smart contract in 2016, which resulted in a fork to stop the attacker= and=20 >>>>> return funds to their original owners. The game theory is similar bec= ause=20 >>>>> it's a situation where a threat is known but there's some period of t= ime=20 >>>>> before the attacker can actually execute the theft. As such, there's = time=20 >>>>> to mitigate the attack by changing the protocol. >>>>> >>>>> It also created a schism in the community around the true meaning of= =20 >>>>> "code is law," resulting in Ethereum Classic, which decided to allow = the=20 >>>>> attacker to retain control of the stolen funds. >>>>> >>>>> A soft fork to burn vulnerable bitcoin could certainly result in a=20 >>>>> hard fork if there are enough miners who reject the soft fork and con= tinue=20 >>>>> including transactions. >>>>> >>>>> Incentives Matter >>>>> We can wax philosophical until the cows come home, but what are the= =20 >>>>> actual incentives for existing Bitcoin holders regarding this decisio= n? >>>>> >>>>> "Lost coins only make everyone else's coins worth slightly more. Thin= k=20 >>>>>> of it as a donation to everyone." - Satoshi Nakamoto >>>>> >>>>> >>>>> If true, the corollary is: >>>>> >>>>> "Quantum recovered coins only make everyone else's coins worth less.= =20 >>>>>> Think of it as a theft from everyone." - Jameson Lopp >>>>> >>>>> >>>>> Thus, assuming we get to a point where quantum resistant signatures= =20 >>>>> are supported within the Bitcoin protocol, what's the incentive to le= t=20 >>>>> vulnerable coins remain spendable? >>>>> >>>>> * It's not good for the actual owners of those coins. It=20 >>>>> disincentivizes owners from upgrading until perhaps it's too late. >>>>> * It's not good for the more attentive / responsible owners of coins= =20 >>>>> who have quantum secured their stash. Allowing the circulating supply= to=20 >>>>> balloon will assuredly reduce the purchasing power of all bitcoin hol= ders. >>>>> >>>>> Forking Game Theory >>>>> From a game theory point of view, I see this as incentivizing users t= o=20 >>>>> upgrade their wallets. If you disagree with the burning of vulnerable= =20 >>>>> coins, all you have to do is move your funds to a quantum safe signat= ure=20 >>>>> scheme. Point being, I don't see there being an economic majority (or= even=20 >>>>> more than a tiny minority) of users who would fight such a soft fork.= Why=20 >>>>> expend significant resources fighting a fork when you can just move y= our=20 >>>>> coins to a new address? >>>>> >>>>> Remember that blocking spending of certain classes of locking scripts= =20 >>>>> is a tightening of the rules - a soft fork. As such, it can be meanin= gfully=20 >>>>> enacted and enforced by a mere majority of hashpower. If miners gener= ally=20 >>>>> agree that it's in their best interest to burn vulnerable coins, are = other=20 >>>>> users going to care enough to put in the effort to run new node softw= are=20 >>>>> that resists the soft fork? Seems unlikely to me. >>>>> >>>>> How to Execute Burning >>>>> In order to be as objective as possible, the goal would be to announc= e=20 >>>>> to the world that after a specific block height / timestamp, Bitcoin = nodes=20 >>>>> will no longer accept transactions (or blocks containing such transac= tions)=20 >>>>> that spend funds from any scripts other than the newly instituted qua= ntum=20 >>>>> safe schemes. >>>>> >>>>> It could take a staggered approach to first freeze funds that are=20 >>>>> susceptible to long-range attacks such as those in P2PK scripts or th= ose=20 >>>>> that exposed their public keys due to previously re-using addresses, = but I=20 >>>>> expect the additional complexity would drive further controversy. >>>>> >>>>> How long should the grace period be in order to give the ecosystem=20 >>>>> time to upgrade? I'd say a minimum of 1 year for software wallets to= =20 >>>>> upgrade. We can only hope that hardware wallet manufacturers are able= to=20 >>>>> implement post quantum cryptography on their existing hardware with o= nly a=20 >>>>> firmware update. >>>>> >>>>> Beyond that, it will take at least 6 months worth of block space for= =20 >>>>> all users to migrate their funds, even in a best case scenario. Thoug= h if=20 >>>>> you exclude dust UTXOs you could probably get 95% of BTC value migrat= ed in=20 >>>>> 1 month. Of course this is a highly optimistic situation where everyo= ne is=20 >>>>> completely focused on migrations - in reality it will take far longer= . >>>>> >>>>> Regardless, I'd think that in order to reasonably uphold Bitcoin's=20 >>>>> conservatism it would be preferable to allow a 4 year migration windo= w. In=20 >>>>> the meantime, mining pools could coordinate emergency soft forking lo= gic=20 >>>>> such that if quantum attackers materialized, they could accelerate th= e=20 >>>>> countdown to the quantum vulnerable funds burn. >>>>> >>>>> Random Tangential Benefits >>>>> On the plus side, burning all quantum vulnerable bitcoin would allow= =20 >>>>> us to prune all of those UTXOs out of the UTXO set, which would also = clean=20 >>>>> up a lot of dust. Dust UTXOs are a bit of an annoyance and there has = even=20 >>>>> been a recent proposal for how to incentivize cleaning them up. >>>>> >>>>> We should also expect that incentivizing migration of the entire UTXO= =20 >>>>> set will create substantial demand for block space that will sustain = a fee=20 >>>>> market for a fairly lengthy amount of time. >>>>> >>>>> In Summary >>>>> While the moral quandary of violating any of Bitcoin's inviolable=20 >>>>> properties can make this a very complex issue to discuss, the game th= eory=20 >>>>> and incentives between burning vulnerable coins versus allowing them = to be=20 >>>>> claimed by entities with quantum supremacy appears to be a much simpl= er=20 >>>>> issue. >>>>> >>>>> I, for one, am not interested in rewarding quantum capable entities b= y=20 >>>>> inflating the circulating money supply just because some people lost = their=20 >>>>> keys long ago and some laggards are not upgrading their bitcoin walle= t's=20 >>>>> security. >>>>> >>>>> We can hope that this scenario never comes to pass, but hope is not a= =20 >>>>> strategy. >>>>> >>>>> I welcome your feedback upon any of the above points, and contributio= n=20 >>>>> of any arguments I failed to consider. >>>>> >>>>> --=20 >>>>> You received this message because you are subscribed to the Google=20 >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReM= q8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com=20 >>>>> >>>>> . >>>>> >>>> --=20 >>>> You received this message because you are subscribed to the Google=20 >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit=20 >>>> https://groups.google.com/d/msgid/bitcoindev/CAGXD5f1eTwqMAkxzdJOup3sy= R%2B5UjrkAaHroBJT0HQw5FA2_YQ%40mail.gmail.com=20 >>>> >>>> . >>>> >>> --=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/= 3fec8fc3-efa1-49c5-8bab-592e0138d31dn%40googlegroups.com. ------=_Part_693751_1904856168.1776521865074 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

Against freezing.

A vulnerable user post-CRQC is someone who made two active choices: reus= ing addresses, and not migrating once a standard is available. That's the u= ser breaking the social contract, not the protocol. P2PKH, P2WPKH, P2SH, P2= WSH outputs which have never spent are not at risk =E2=80=94 pubkey is hash= ed, not exposed. P2PK, reused addresses, and P2TR key path are. Bitcoin isn= 't globally broken =E2=80=94 specific address types are, and users holding = them after a migration path exists are accepting the risk.

A script-type freeze applies uniformly to weak output types, not to spec= ific transactions =E2=80=94 categorically different from reversing exchange= hacks. But once the protocol starts deciding which coins are safe enough t= o spend, that logic is hard to contain.

Either way, the freeze debate is a signal, not the goal. It tells us we = need a standard urgently. That's where the energy should go =E2=80=94 Matt'= s thread is asking the right question What's our goal?.

Regards,

Thom= as


Le jeudi 9 avril 2026 =C3=A0 10:36:50 UTC+2, Jameson Lopp a =C3=A9crit= =C2=A0:
Scratch that; nodes should already be storing the block for whi= ch a UTXO was confirmed in order to calculate relative timelock validity. S= o it should be implementable.

Still, there are several vague stateme= nts that could use more explanation.

"predictable cliffs invite= adversarial behavior." - such as?

"This avoids retroactiv= ely invalidating old transactions while still phasing out insecure construc= tions." - how so? If you chose a relative max age that's less than= the total age of Bitcoin itself, it will by default invalidate extremely o= ld UTXOs.

"If the protocol begins to distinguish between =E2=80= =9Clegitimate=E2=80=9D and =E2=80=9Cquantum=E2=80=91recovered=E2=80=9D spen= ds" - not sure what this means. It's not possible to know if a tra= nsaction was made by a quantum attacker.

On Thu, Apr 9, 2026 at 9:04=E2=80= =AFAM Jameson Lopp <jameso...= @gmail.com> wrote:
While an implied age timelock is interesting in= theory, I don't think it's practical in reality.

The reason= that current styles of timelocks work well is because they are explicit: t= he actual block height / timestamp of the lock is contained somewhere insid= e of the transaction itself.

In order to implement an "implied&= quot; scheme as you propose, it would require all nodes to start indexing U= TXOs by block height in order to avoid a massive performance drop when eval= uating whether or not the UTXO is spendable.

On Thu, Apr 9, 2026 at 3:01=E2= =80=AFAM Bitcoin <lovelo...@g= mail.com> wrote:
The protocol should not assume that future partic= ipants will be able to coordinate around a single deadline without distorti= on. A fixed height at which old outputs become invalid would create a predi= ctable cliff, and predictable cliffs invite adversarial behavior. Markets t= end to rush toward the edge.

B= itcoin works best when incentives are continuous rather than abrupt.
<= div dir=3D"auto">
A staggered expiration of vuln= erable script types is more consistent with the system=E2=80=99s long=E2=80= =91term stability. If a class of outputs is known to be weak against new co= mputation, then the network can define a rule that such outputs must be spe= nt within a certain number of blocks after creation. This avoids retroactiv= ely invalidating old transactions while still phasing out insecure construc= tions.

The network alrea= dy treats some script forms as discouraged. Extending this to prohibit crea= tion of new vulnerable forms is a natural evolution. Nodes can continue to = validate the old chain history while refusing to relay or mine new transact= ions that expose public keys directly.

The idea of forcing quantum=E2=80=91recovered coins into lon= g timelocks is interesting, but it introduces a new class of special=E2=80= =91case behavior. Bitcoin=E2=80=99s rules should be simple, general, and pr= edictable. If the protocol begins to distinguish between =E2=80=9Clegitimat= e=E2=80=9D and =E2=80=9Cquantum=E2=80=91recovered=E2=80=9D spends, it impli= es an authority deciding which coins are morally valid. That is a precedent= the system should avoid.

The safest rule is the one that does not require judging intent.

A relative or absolute timelock = applied uniformly to all vulnerable outputs, triggered only by their age, i= s neutral. It does not ask who is spending the coins or why. It only enforc= es that insecure forms must be migrated in time.
The network cannot prevent advances in mathematics= or computation. It can only ensure that the incentives remain aligned so t= hat users upgrade their security before adversaries can exploit weaknesses.= The protocol should encourage timely movement without confiscation.
<= div dir=3D"auto">
The principle remains:

Your keys, your coins =E2=80=94= but only as long as the key is strong.

If a key type becomes weak, the system must give ample time= to move funds to stronger constructions, and then retire the weak form gra= dually so the chain does not become a liability.
=E2=80=94 S.

On Mon, Apr 7, 2025, 6:34=E2=80= =AFAM Nadav Ivgi <na...@shese= k.info> wrote:
One possible alternative to fr= eezing/burning the coins entirely is letting quantum attackers keep some sm= all percent as a reward, but force them to stage the rest to future miners = as an additional security budget subsidy.

This can be implemented as a soft fork, by requiring transactions=20 spending QC-vulnerable coins to allocate some funds to an OP_CLTV[0]-only e= ncumbered output timelocked far into the future. Miners would then monitor = these outputs and claim them as they become available.

For example, allow a 1% reward to be spent freely to any a= ddress but require 99% to be sent to an OP_CLTV output timelocked to a dete= rministically random height between 10-100 years from now.

Th= e 1% reward could also be required to be sent to a script that enforces a t= imelock (in addition to other conditions), to avoid flooding the markets wi= th the rewarded coins all at once. Probably a shorter timelock duration tho= ugh, say picked randomly between 10-30 months.

To = further smooth out variance in the release schedule, coins could be split i= nto up-to-N-BTC outputs, each staggered with a different deterministic time= lock. So for example, a single tx spending 10,000 BTC won't release 9,9= 00 BTC to the miners in a single far-future block (which may cause chain in= stability if the miners get into a reorg war over it), but rather as 9,900 = separate outputs of 1 BTC each released=C2=A0gradually time.[1]
<= br>
I'm still not sure what I think about this. This is not n= ecessarily an endorsement, just a thought. :)

- sh= esek

[0] OP_CSV only supports relative timelocks o= f up to 65535 blocks (~15 months), which is too short for that purpose. OP_= CLTV supports longer (absolute) timelocks.

[1] Thi= s can be made more efficient with CTV, by having a single UTXO carrying the= full amount that slowly unrolls rather than 9,900 separate UTXO entries.


On Sun, Mar 16, 2025 at 5:22=E2=80=AFPM Jameson Lopp <jameso...@gmail.com= > wrote:
The quantum computing debate is heating up. There are many con= troversial aspects to this debate, including whether or not quantum compute= rs will ever actually become a practical threat.

I won't tread = into the unanswerable question of how worried we should be about quantum co= mputers. I think it's far from a crisis, but given the difficulty in ch= anging Bitcoin it's worth starting to seriously discuss. Today I wish t= o focus on a philosophical quandary related to one of the decisions that wo= uld need to be made if and when we implement a quantum safe signature schem= e.

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

1. Quantum computing never = materializes, never 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 t= his scenario it would likely make the points below moot because Bitcoin wou= ld be fundamentally broken and it would take far too long to upgrade the pr= otocol, wallet software, and migrate user funds in order to restore confide= nce in the network.
3. Quantum computing advances slowly enough that we = come to consensus about how to upgrade Bitcoin and post quantum security ha= s been minimally adopted by the time an attacker appears.
4. Quantum com= puting advances slowly enough that we come to consensus about how to upgrad= e Bitcoin and post 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 Fre= eze?
I've started seeing more people weighing in on what is l= ikely the most contentious aspect of how a quantum resistance upgrade shoul= d be handled in terms of migrating user funds. Should quantum vulnerable fu= nds be left open to be swept 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 have an inflationary impact on bitcoin'= s price, to use a turn of phrase, the inflation is transitory. Those with l= ow time preference should support returning lost coins to circulation."= ;=C2=A0
- Hun= ter Beast

On the other hand:

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

I don't think "c= onfiscation" is the most precise term to use, as the funds are not bei= ng seized and reassigned. Rather, what we're really discussing would be= better described as "burning" - placing the funds out of reac= h of everyone.

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

Fundamen= tal 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-the-key-pro= perties-of-bitcoin/

The particular properties in play with regar= d to this issue seem to be:

Censorship Resistance - No one sh= ould have the power to prevent others from using their bitcoin or interacti= ng with the network.

Forward Compatibility - changing the rul= es such that certain valid transactions become invalid could undermine conf= idence in the protocol.

Conservatism - Users should not be ex= pected to be highly responsive to system issues.

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

Not your keys, not your coins.

I posit that the = corollary to this principle is:

Your keys, only your coins.

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

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

Who is at Risk?<= br>There has long been a narrative that Satoshi's coins and othe= rs from the Satoshi era of P2PK locking scripts that exposed the public key= directly on the blockchain will be those that get scooped up by a quantum = "miner." But unfortunately it's not that simple. If I had a p= owerful quantum computer, which coins would I target? I'd go to the Bit= coin 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://bitinfochart= s.com/top-100-richest-bitcoin-addresses.html

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

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

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

By making q= uantum vulnerable funds unspendable we potentially harm some Bitcoin users = who were not paying attention and neglected to migrate their funds to a qua= ntum safe locking script. This violates the "conservativism" prin= ciple stated earlier. On the flip side, we prevent those funds plus far mor= e lost funds from falling into the hands of the few privileged folks who ga= in early access to quantum computers.

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

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

Allowing a quantum computer to access lost funds doesn't= make those users any worse off than they were before, however it would<= /i> have a negative impact upon everyone who is currently holding bitcoin.<= br>
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 th= eir investment. We also know from experience that when someone suddenly fin= ds themselves in possession of 9+ figures worth of highly liquid assets, th= ey tend to diversify into other things by selling.

Allowing quantum = recovery of bitcoin is tantamount to wealth redistribution. What we&= #39;d be allowing is for bitcoin to be redistributed from those who are ign= orant of quantum computers to those who have won the technological race to = acquire quantum computers. It's hard to see a bright side to that scena= rio.

Is Quantum Recovery Good for Anyone?
Does quantum recovery HELP anyone? I've yet to come across an argu= ment 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 network by allowing funds to be claimed by those who did not earn t= hem.

But wait, you may be thinking, wouldn't quantum "miner= s" have earned their coins by all the work and resources invested in b= uilding a quantum computer? I suppose, in the same sense that a burglar ear= ns their spoils by the resources they invest into surveilling targets and l= earning the skills needed to break into buildings. What I say "earned&= quot; I mean through productive mutual trade.

For example:

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

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

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

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

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

Historical Precedent
Previ= ous protocol vulnerabilities weren=E2=80=99t celebrated as "fair game&= quot; but rather were treated as failures to be remediated. Treating quantu= m theft differently risks rewriting Bitcoin=E2=80=99s history as a free-for= -all 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 cryptocur= rency - if you keep your keys in your possession, only you should be able t= o access your money. Bitcoin is built on the idea that private keys secure = an individual=E2=80=99s assets, and unauthorized access (even via advanced = tech) is theft, not a legitimate transfer.

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

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

Unfair Advantage
Quant= um attackers, likely equipped with rare and expensive technology, would hav= e an unjust edge over regular users who lack access to such tools. This cre= ates an inequitable system where only the technologically elite can exploit= others, contradicting Bitcoin=E2=80=99s ethos of decentralized power.
<= br>Bitcoin is designed to create an asymmetric advantage for DEFENDING one&= #39;s wealth. It's supposed to be impractically expensive for attackers= to crack the entropy and cryptography protecting one's coins. But now = we find ourselves discussing a situation where this asymmetric advantage is= compromised in favor of a specific class of attackers.

Economic Disruption
Large-scale theft from vulnerable addr= esses could crash Bitcoin=E2=80=99s price as quantum recovered funds are du= mped on exchanges. This would harm all holders, not just those directly tar= geted, leading to broader financial chaos in the markets.

Moral Responsibility
Permitting theft via quantum computin= g sets a precedent that technological superiority justifies unethical behav= ior. This is essentially taking a "code is law" stance in which w= e refuse to admit that both code and laws can be modified to adapt to previ= ously unforeseen situations.

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

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

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

Incentives Drive Security
I can tell you from a decad= e of working in Bitcoin security - the average user is lazy and is a procra= stinator. If Bitcoiners are given a "drop dead date" after which = they know vulnerable funds will be burned, this pressure accelerates the ad= option of post-quantum cryptography and strengthens Bitcoin long-term. Allo= wing vulnerable users to delay upgrading indefinitely will result in more l= aggards, leaving the network more exposed when quantum tech becomes availab= le.

Steel Manning
Clearly this is a compl= ex and controversial topic, thus it's worth thinking through the opposi= ng arguments.

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 som= eone's access to their coins that we allow them to be stolen!

Bu= t I think the flip side to the property rights narrative is that burning vu= lnerable coins prevents said property from falling into undeserving hands. = If the entire Bitcoin ecosystem just stands around and allows quantum adver= saries 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.

As such, I think the "protecti= ng property rights" argument is a wash.

Quantu= m Computers Won't Attack Bitcoin
There is a great deal of ske= pticism that sufficiently powerful quantum computers will ever exist, so we= shouldn't bother preparing for a non-existent threat. Others have argu= ed that even if 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 instead attack other infrastructure.

It's quite di= fficult to quantify exactly how valuable attacking other infrastructure wou= ld be. It also really depends upon when an entity gains quantum supremacy a= nd thus if by that time most of the world's systems have already been u= pgraded. While I think you could argue that certain entities gaining quantu= m capability might not attack 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
Some have argued that even if a quantum attacker ta= rgeted bitcoin, they'd only go after old, likely lost P2PK outputs so a= s to not arouse suspicion and cause a market panic.

I'm not so s= ure about that; why go after 50 BTC at a time when you could take 250,000 B= TC 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 amount of= time before someone else discovers the exploit and either benefits from it= or patches it. Take, for example, the recent ByBit attack - the highest va= lue crypto hack of all time. Lazarus Group had compromised the Safe wallet = front end JavaScript app and they could have simply had it reassign ownersh= ip of everyone's Safe wallets as they were interacting with their walle= t. But instead they chose to only specifically target ByBit's wallet wi= th $1.5 billion in it because they wanted to maximize their extractable val= ue. If Lazarus had started stealing from every wallet, they would have been= discovered quickly and the Safe web app would likely have been patched wel= l before any billion dollar wallets executed the malicious code.

I t= hink the "only stealing small amounts" argument is strongest for = Situation #2 described earlier, where a quantum attacker arrives before qua= ntum safe cryptography has been deployed across the Bitcoin ecosystem. Beca= use if it became clear that Bitcoin's cryptography was broken AND there= was nowhere safe for vulnerable users to migrate, the only logical option = would be 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 migration path available.

The 21 Million Coi= n Supply Should be in Circulation
Some folks are arguing that it&= #39;s important for the "circulating / spendable" supply to be as= close to 21M as possible and that having a significant portion of the supp= ly out of circulation is somehow undesirable.

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

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

Self-Sovereignty and Pe= rsonal Responsibility
Bitcoin=E2=80=99s design empowers individua= ls to control their own wealth, free from centralized intervention. This fr= eedom comes with the burden of securing one's private keys. If quantum = computing can break obsolete cryptography, the fault lies with users who di= dn't move their funds to quantum safe locking scripts. Expecting the ne= twork to shield users from their own negligence undermines the principle th= at you, and not a third party, are accountable for your assets.

I th= ink 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, n= eed to consider the incentives and game theory in play with regard to quant= um safe Bitcoiners vs quantum vulnerable Bitcoiners. More on that later.
Code is Law
Bitcoin operates on transparent= , immutable rules embedded in its protocol. If a quantum attacker uses supe= rior technology to derive private keys from public keys, they=E2=80=99re no= t "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 = foreseen far in advance.

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

Ma= rket Signals Drive Security
If quantum attackers start stealing f= unds, it sends a clear signal to the market: upgrade your security or lose = everything. This pressure accelerates the adoption of post-quantum cryptogr= aphy and strengthens Bitcoin long-term. Coddling vulnerable users delays th= is necessary evolution, potentially leaving the network more exposed when q= uantum tech becomes widely accessible. Theft is a brutal but effective teac= her.

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

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

Fairness i= n Competition
Quantum attackers aren't cheating; they're = using publicly available physics and math. Anyone with the resources and fo= resight 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 never promised equality of outcome - only equality of oppo= rtunity within its rules.

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

Economic Resilience
Bitcoin has weathered thefts be= fore (MTGOX, Bitfinex, FTX, etc) and emerged stronger. The market can absor= b quantum losses, with unaffected users continuing to hold and new entrants= buying in at lower prices. Fear of economic collapse overestimates the imp= act - the network=E2=80=99s antifragility thrives on such challenges.
This is a big grey area because we don't know when a quantum computer= will come online and we don't know how quickly said computers would be= able to steal bitcoin. If, for example, the first generation of sufficient= ly powerful quantum computers were stealing less volume than the current bl= ock reward then of course it will have minimal economic impact. But if they= 're taking thousands of BTC per day and bringing them back into circula= tion, there will likely be a noticeable market impact as it absorbs the new= supply.

This is where the circumstances will really matter. If a qu= antum attacker appears AFTER the Bitcoin protocol has been upgraded to supp= ort quantum resistant cryptography then we should expect the most valuable = active wallets will have upgraded and the juiciest target would be the 31,0= 00 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dor= mant since 2010. In general I'd expect that the amount of BTC re-enteri= ng the circulating supply would look somewhat similar to the mining emissio= n curve: volume would start off very high as the most valuable addresses ar= e drained and then it would fall off as quantum computers went down the lis= t targeting addresses with less and less BTC.

Why is economic impact= a factor worth considering? Miners and businesses in general. More coins b= eing liquidated will push down the price, which will negatively impact mine= r revenue. Similarly, I can attest from working in the industry for a decad= e, that lower prices result in less demand from businesses across the entir= e industry. As such, burning quantum vulnerable bitcoin is good for the ent= ire industry.

Practicality & Neutrality of Non-= Intervention
There=E2=80=99s no reliable way to distinguish =E2= =80=9Ctheft=E2=80=9D from legitimate "white hat" key recovery. If= someone loses their private key and a quantum computer recovers it, is tha= t stealing or reclaiming? Policing quantum actions requires invasive assump= tions about intent, which Bitcoin=E2=80=99s trustless design can=E2=80=99t = accommodate. Letting the chips fall where they may avoids this mess.
Philosophical Purity
Bitcoin rejects bailouts. = It=E2=80=99s a cold, hard system where outcomes reflect preparation and ski= ll, not sentimentality. If quantum computing upends the game, that=E2=80=99= s the point - Bitcoin isn=E2=80=99t meant to be safe or fair in a nanny-sta= te sense; it=E2=80=99s meant to be free. Users who lose funds to quantum at= tacks are casualties of liberty and their own ignorance, not victims of inj= ustice.

Bitcoin's DAO Moment
This sit= uation has some similarities to The DAO hack of an Ethereum 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 because it's a situat= ion 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.

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

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

Incen= tives Matter
We can wax philosophical until the cows come home, b= ut what are the actual incentives for existing Bitcoin holders regarding th= is decision?

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

I= f true, the corollary is:

"Quantum recovered coins only make everyone else's coins w= orth less. Think of it as a theft from everyone." - Jameson Lopp
Thus, assuming we get to a point where quantum resistant signatu= res are supported within the Bitcoin protocol, what's the incentive to = let vulnerable coins remain spendable?

* It's not good for the a= ctual owners of those coins. It disincentivizes 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 assuredly reduce the purchasing pow= er of all bitcoin holders.

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

Remember that blocking spending of certain class= es of locking scripts is a tightening of the rules - a soft fork. As such, = it can be meaningfully enacted and enforced by a mere majority of hashpower= . If miners generally agree that it's in their best interest to burn vu= lnerable coins, are other users going to care enough to put in the effort t= o run new node software that resists the soft fork? Seems unlikely to me.
How to Execute Burning
In order to be as o= bjective as possible, the goal would be to announce to the world that after= a specific block height / timestamp, Bitcoin nodes will no longer accept t= ransactions (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 funds that are susceptible= to long-range attacks such as those in P2PK scripts or those that exposed = their public keys due to previously re-using addresses, but I expect the ad= ditional 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 upgrade. We can only hope= that hardware wallet manufacturers are able to implement post quantum cryp= tography on their existing hardware with only a firmware update.

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

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

Random Tangentia= l Benefits
On the plus side, burning all quantum vulnerable bitco= in would allow us to prune all of those UTXOs out of the UTXO set, which wo= uld also clean up a lot of dust. Dust UTXOs are a bit of an annoyance and t= here has even been a recent proposal for how to incentivize cleaning them u= p.

We should also expect that incentivizing migration of the entire = UTXO set will create substantial demand for block space that will 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 discuss, the= game theory and incentives between burning vulnerable coins versus allowin= g them to be claimed by entities with quantum supremacy appears to be a muc= h simpler issue.

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

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

I welcome your feedback = 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+..= .@googlegroups.com.
To view this discussion visit https://groups.google= .com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0G= YN97P6hQ%40mail.gmail.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 bitcoindev+..= .@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/CAGXD5f1eTwqMAkxzdJOup3syR%2B5UjrkAaHroBJT0HQw5FA2_YQ%40mail.gmail.co= m.

--
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/bitcoind= ev/3fec8fc3-efa1-49c5-8bab-592e0138d31dn%40googlegroups.com.
------=_Part_693751_1904856168.1776521865074-- ------=_Part_693750_1173719507.1776521865074--