Delivery-date: Mon, 17 Mar 2025 06:34:18 -0700 Received: from mail-ot1-f56.google.com ([209.85.210.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tuAbg-0003m2-8s for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:34:18 -0700 Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-72894df5158sf5127672a34.1 for ; Mon, 17 Mar 2025 06:34:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1742218450; cv=pass; d=google.com; s=arc-20240605; b=JWMv9VtfyrlWGc0u9pz7O4CXKvhadNSLcU1Ccf10g5f3JGpQTPewOXtMLTZ4X1IV4V I4O5tP2ZDozMaWu+S1SW5PIuxSQiHSXTPGm4d1exfXPbhEpqLHwsLn1d26U6hC624zBX NIyrfnPdRqgiT/HKJ9e5kj9E6kYxQBDvxNVYFRAND6ls1BCm27/T8WGYyKlM9dfMlT3l hAvZQW5F/NCbhgpgiOJh0Lb6DKAhayH5+COvz4M/GtWT5HiaXAg+dyK/gsd/gk7Wjecx cnLj8UYYkxlKfagAz32SAjbDXE5zV/2iRzpL/zl8b91qmb82hjWK4h5UqQi+NuPuthTZ l0Mw== 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:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=3Ezx2/TMgUY7CbYLfU9xn4MO4fi3L6sldsSn2Q2GOYw=; fh=ygHEsWst/EYBmA08R99AqX1pTmhiQ77m9d/IJlpPCAo=; b=O032nx20qyxcZbPuTtBLw+zmJQY2+AYMwsMVxuy+bh1AwzqcMAAvFWrKgEknq3MWdF xtjNXIBTVE+wgfMN03P/IaqWlecFo/NJOBESaIFZM5btsUdPNPX2ttuZwov22XyiatCe 3WlhXPN/GsBVvRWvQRKDgyQkSWGGcC/PZJB12S11rnbrFeMKlr0PLbfND7oc19hMamyB TmtC3gyuNxIgFXB4M6gUw6ZwesP+HuDoLLeLBnlBykIcwapwj0fYpV0FNbK+D7AzgBWL AlwaYMjHEFJPuB1SZJIJ03C3x8O/Ywa/9ORDcscpJbfu1iLBwYYb8r6uM3ntE2A1wva3 LRoA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1742211663 header.b=TzSZs2RS; dkim=pass header.i=@clients.mail.as397444.net header.s=1742211665 header.b=f3F2+f6Y; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1742218450; x=1742823250; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=3Ezx2/TMgUY7CbYLfU9xn4MO4fi3L6sldsSn2Q2GOYw=; b=PDhQk0yCfKoy4T7lQaYGIlkM/o01FYo/8dYiCGR3QXSziNbXHgobF4oPXm6gT65X0U 4cVNGs3orjhnLmV3JG6wbHCbbzy2/l0NZvsezqgTu6pCFEO4szzzCFRd2wLMwST0NrTy c3zBGbXR19S1vQlMfyxk/Ia7pkVa5MexyfH0SLfrkDGVe3SOlxQVVZtf87Wej8nAwEmt wu93yhokA7IOsd6Wbhp3FQ9JCcUuTxm/QdTK63dCh+M9J+ktWWmQeCxtG/dNFHyMLqdu tEO4yb78j/u1HaljWpDspsQQOmPosncseuZ4ULulAs/KkfxVVwD6OauNhSsLOP7BWCW+ lpLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742218450; x=1742823250; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:mime-version:date:message-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=3Ezx2/TMgUY7CbYLfU9xn4MO4fi3L6sldsSn2Q2GOYw=; b=LeJN0YpuS6HHeoe2kzGzmNl0LNgiNCsztdDgPfCH6B0xrFX9H36sxOdAspjrkFsexQ WCLbPRgR470Pm5mCBkxfnt5jypPfnIsCWjD17FbqqnJVPEhEEOEo/tbJuZ+U2l3e9Mxr MYgaNKCvUHS18kCdUZ3wLna+erA+jUmDDGT7Ys61LeWf9ab8QVX2LxvFY+iTrzpFXe/d oSf/xq2jJ9Ddtw2TJY+rb7sSHMIgZ5zUrLPZ+fPpjROd2doo11BO0T30EOw1w+8NqEqg OESkXy5NJI67nb0lI0kKn1IvSrZ7xx5qo8TMc25OwgqiqPNiXRQK5PJZKnl6200DFfnR CGxw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVOjS4mhv8ZoPJhWMyppEKSGh+B211YHR3XLYoeRE9O+aGJesKoBvyx45ewLhxu3qoQCWd+Zlh0bgQO@gnusha.org X-Gm-Message-State: AOJu0YxeaTslP53+xXLkPt2/3G2UpMNULoBWmbvpeil/BEduL83ishHD MmYmcdrtEq064bO90UjMlWCzVCkbifJvDfY85v8mj0PniznfT1RV X-Google-Smtp-Source: AGHT+IEH4l1WpVyHufX/ABIOtfCkb/P/v7Adsb2cBWffZlNUpILkLhESiHUH+AwWycm3Ntn7RmnRLA== X-Received: by 2002:a05:6830:3d01:b0:72a:48b6:720 with SMTP id 46e09a7af769-72bb1974a67mr9469904a34.14.1742218450151; Mon, 17 Mar 2025 06:34:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJ8V+oktr14JkkAYIZ6+IImZGATlayN3OCF0fWpxcGQTQ== Received: by 2002:a05:6820:4881:b0:600:33ae:b1ae with SMTP id 006d021491bc7-601eea41d07ls123313eaf.0.-pod-prod-00-us; Mon, 17 Mar 2025 06:34:07 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUU2UEZjDwgl5a8bs3M60rBaM53FuOnTlCn/ryrTbly4atbKQ0K/I/Ioqv9Ae/yz3eVbGyfquZQnq5g@googlegroups.com X-Received: by 2002:a05:6808:17a0:b0:3f1:ccc5:26b5 with SMTP id 5614622812f47-3fded9c840amr5630270b6e.6.1742218447387; Mon, 17 Mar 2025 06:34:07 -0700 (PDT) Received: by 2002:a05:6808:1a1b:b0:3fa:6f09:b173 with SMTP id 5614622812f47-3fde05287ecmsb6e; Mon, 17 Mar 2025 05:00:07 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUJfD4DxoIsaqdpJKPo0tp1BM/PmTwc4YCeS24laKRfoZfOgRjN9ZTLD2N1ETRc6PV5MzK6mCJpRc11@googlegroups.com X-Received: by 2002:a05:6830:6a12:b0:72b:7d40:5fe2 with SMTP id 46e09a7af769-72bbc882475mr6995294a34.12.1742212806439; Mon, 17 Mar 2025 05:00:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1742212806; cv=none; d=google.com; s=arc-20240605; b=kIxrQ2vSTbVsTEoy/SKUdXABAoBq2kITdxTN19t+ARnR7yjpcEYQWy5dqSLsYl5R2l QpKNSdNvXxIz1dyHjIDYtYwQkeUg3bqohOe9JNHkOda7EYAMlsv8+/lsb/5et9XHga6w 7ALkABrmZBh6223W9rz/RFjECDlC7ao0qreCJfjCDpKTVjBNn5pKgN7CM0VAqpDbmqgK RRkkRJPsBPNy5p5Lzosz6vT3X3J80YEQUEPwTw7R3Y35MHSiSNH+jlqMMqOrK8pmokEd srNw2uvx8YON+OuhjIVag31nzuM8QNAbfdziEtg2yJHxIkXKVmIrf13dTIoeRVXBp3AS dnKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:dkim-signature :dkim-signature; bh=JL7L+KxPPgB/ZAFnbLQh6FHjSi4P7wFDZC5ozKyzf7w=; fh=BY6ewZzmz/1dFxIQGQaZeeRzSBNGp99ncSIpp35SjPQ=; b=Jio/0UiVx9LxcRiS8RAZNj8a673VP/kEC0qkI7ApfyUKXvTvrBFzB16SxYyCjWQTL/ +qzAevRrwEqcFaflNjWbvwLcGJ2y79+k8i0BDoCUffks9MJCiqUZhPV/7WUe8xgmLLIe cwYj947HXzCbE53VHYx/SW3LGPAgA6lklGKA8H8AUf7YpY6UrAs/nbCNxPm0uX1vYhjF uvrH/1FCevHNxtq17PQMdvHVmOC6mFtahaop5g/82a/rC7v0xP3XdkJACC+N5hKU1Ur5 woapMjJf4jJLMTjEhM8r791eU07rtzrTRAlYk/CQVi/G3ogaMB+d4e5m4ZB3f/gJF3e/ rkHA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1742211663 header.b=TzSZs2RS; dkim=pass header.i=@clients.mail.as397444.net header.s=1742211665 header.b=f3F2+f6Y; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-72bb2672813si288820a34.1.2025.03.17.05.00.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Mar 2025 05:00:06 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1tu98U-0049lx-35; Mon, 17 Mar 2025 12:00:04 +0000 Message-ID: <43afd5bb-244e-4698-ba3d-139efa2c2058@mattcorallo.com> Date: Mon, 17 Mar 2025 08:00:01 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin To: Jameson Lopp , Bitcoin Development Mailing List References: Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1742211663 header.b=TzSZs2RS; dkim=pass header.i=@clients.mail.as397444.net header.s=1742211665 header.b=f3F2+f6Y; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.2 (/) Thanks for posting this Jameson, I think this is a strong motivation to do "simple PQC" today - while we don= 't need to decide on the=20 tough question of seizing non-PQC coins today, we want to have the option t= o do so in the future. In order for that option to be practical, wallets need to be embedding PQC = public keys in their=20 outputs probably at least a decade before the seizure occurs, with any addi= tional time giving us an=20 important safety margin. Thus it seems like time we add the simplest form of PQC we can - a trivial = OP_HASHBASEDSIG (probably=20 SPHINCS+) to tapscript to enable wallets to have hidden PQC keys (including= multisig) in their taptrees. Matt On 3/16/25 10:15 AM, Jameson Lopp wrote: > The quantum computing debate is heating up. There are many controversial = aspects to this debate,=20 > including whether or not quantum computers will ever actually become a pr= actical threat. >=20 > I won't tread into the unanswerable question of how worried we should be = about quantum computers. I=20 > think it's far from a crisis, but given the difficulty in changing Bitcoi= n it's worth starting to=20 > seriously discuss. Today I wish to focus on a philosophical quandary rela= ted to one of the decisions=20 > that would need to be made if and when we implement a quantum safe signat= ure scheme. >=20 > Several Scenarios > Because this essay will reference game theory a fair amount, and there ar= e many variables at play=20 > that could change the nature of the game, I think it's important to clari= fy the possible scenarios=20 > up front. >=20 > 1. Quantum computing never materializes, never becomes a threat, and thus= everything discussed in=20 > this essay is moot. > 2. A quantum computing threat materializes suddenly and Bitcoin does not = have quantum safe=20 > signatures as part of the protocol. In this scenario it would likely make= the points below moot=20 > because Bitcoin would be fundamentally broken and it would take far too l= ong to upgrade the=20 > protocol, wallet software, and migrate user funds in order to restore con= fidence in the network. > 3. Quantum computing advances slowly enough that we come to consensus abo= ut how to upgrade Bitcoin=20 > and post quantum security has been minimally adopted by the time an attac= ker appears. > 4. Quantum computing advances slowly enough that we come to consensus abo= ut how to upgrade Bitcoin=20 > and post quantum security has been highly adopted 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 co= ntentious aspect of how a=20 > quantum resistance upgrade should be handled in terms of migrating user f= unds. Should quantum=20 > vulnerable funds be left open to be swept by anyone with a sufficiently p= owerful quantum computer OR=20 > should they be permanently locked? >=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 have an inflationary im= pact on bitcoin's price, to > use a turn of phrase, the inflation is transitory. Those with low tim= e preference should support > returning lost coins to circulation."=20 >=20 > - Hunter Beast >=20 >=20 > On the other hand: >=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 ecosy= stem has no other option > than softforking out the ability to spend from signature schemes (inc= luding ECDSA and BIP340) > that are vulnerable to QCs. The alternative is that millions of BTC b= ecome 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 their coins to PQC-protec= ted schemes." > - Pieter Wuille >=20 >=20 > I don't think "confiscation" is the most precise term to use, as the fund= s are not being seized and=20 > reassigned. Rather, what we're really discussing would be better describe= d as "burning" - placing=20 > the funds *out of reach of everyone*. >=20 > Not freezing user funds is one of Bitcoin's inviolable properties. Howeve= r, if quantum computing=20 > becomes a threat to Bitcoin's elliptic curve cryptography, *an inviolable= property of Bitcoin will=20 > be violated one way or another*. >=20 > Fundamental Properties at Risk > 5 years ago I attempted to comprehensively categorize all of Bitcoin's fu= ndamental properties that=20 > give it value. https://nakamoto.com/what-are-the-key-properties-of-bitcoi= n/ > > 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=20 > interacting with the network. >=20 > *Forward Compatibility* - changing the rules such that certain valid tran= sactions become invalid=20 > 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 (kud= os to Andreas Antonopoulos)=20 > that goes as follows: >=20 > Not your keys, not your coins. >=20 >=20 > I posit that the corollary to this principle is: >=20 > Your keys, only your coins. >=20 >=20 > A quantum capable entity breaks the corollary of this foundational princi= ple. We secure our bitcoin=20 > with the mathematical probabilities related to extremely large random num= bers. Your funds are only=20 > secure because truly random large numbers should not be guessable or disc= overable by anyone else in=20 > the world. >=20 > This is the principle behind the motto /vires in numeris/ - strength in n= umbers. In a world with=20 > quantum enabled adversaries, this principle is null and void for many typ= es of cryptography,=20 > including the elliptic curve digital signatures used in Bitcoin. >=20 > Who is at Risk? > There has long been a narrative that Satoshi's coins and others from the = Satoshi era of P2PK locking=20 > scripts that exposed the public key directly on the blockchain will be th= ose that get scooped up by=20 > a quantum "miner." But unfortunately it's not that simple. If I had a pow= erful quantum computer,=20 > which coins would I target? I'd go to the Bitcoin rich list and find the = wallets that have exposed=20 > their public keys due to re-using addresses that have previously been spe= nt from. You can easily=20 > find them at https://bitinfocharts.com/top-100-richest-bitcoin-addresses.= html bitinfocharts.com/top-100-richest-bitcoin-addresses.html> >=20 > Note that a few of these wallets, like Bitfinex / Kraken / Tether, would = be slightly harder to crack=20 > because they are multisig wallets. So a quantum attacker would need to re= verse engineer 2 keys for=20 > Kraken or 3 for Bitfinex / Tether in order to spend funds. But many are s= ingle signature. >=20 > Point being, it's not only the really old lost BTC that are at risk to a = quantum enabled adversary,=20 > at least at time of writing. If we add a quantum safe signature scheme, w= e should expect those=20 > 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 B= itcoin users who were not=20 > paying attention and neglected to migrate their funds to a quantum safe l= ocking script. This=20 > violates the "conservativism" principle stated earlier. On the flip side,= we prevent those funds=20 > plus far more lost funds from falling into the hands of the few privilege= d folks who gain early=20 > access to quantum computers. >=20 > By leaving quantum vulnerable funds available to spend, the same set of u= sers who would otherwise=20 > have funds frozen are likely to see them stolen. And many early adopters = who lost their keys will=20 > eventually see their unreachable funds scooped up by a quantum enabled ad= versary. >=20 > Imagine, for example, being James Howells, who accidentally threw away a = hard drive with 8,000 BTC=20 > on it, currently worth over $600M USD. He has spent a decade trying to re= trieve it from the landfill=20 > where he knows it's buried, but can't get permission to excavate. I suspe= ct that, given the choice,=20 > he'd prefer those funds be permanently frozen rather than fall into someo= ne else's possession - I=20 > know I would. >=20 > Allowing a quantum computer to access lost funds doesn't make those users= any worse off than they=20 > were before, however it /would/ have a negative impact upon everyone who = is currently holding bitcoin. >=20 > It's prudent to expect significant economic disruption if large amounts o= f coins fall into new=20 > hands. Since a quantum computer is going to have a massive up front cost,= expect those behind it to=20 > desire to recoup their investment. We also know from experience that when= someone suddenly finds=20 > themselves in possession of 9+ figures worth of highly liquid assets, the= y tend to diversify into=20 > other things by selling. >=20 > Allowing quantum recovery of bitcoin is /tantamount to wealth redistribut= ion/. What we'd be allowing=20 > is for bitcoin to be redistributed from those who are ignorant of quantum= computers to those who=20 > have won the technological race to acquire quantum computers. It's hard t= o see a bright side to that=20 > scenario. >=20 > Is Quantum Recovery Good for Anyone? >=20 > Does quantum recovery HELP anyone? I've yet to come across an argument th= at it's a net positive in=20 > any way. It certainly doesn't add any security to the network. If anythin= g, it greatly decreases the=20 > security of the network 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 thei= r coins by all the work and=20 > resources invested in building a quantum computer? I suppose, in the same= sense that a burglar earns=20 > their spoils by the resources they invest into surveilling targets and le= arning the skills needed to=20 > break into buildings. What I say "earned" I mean through productive mutua= l 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 the= system. >=20 > There's no reason to believe that allowing quantum adversaries to recover= vulnerable bitcoin will be=20 > of benefit to anyone other than the select few organizations that win the= technological arms race to=20 > build the first such computers. Probably nation states and/or the top few= largest tech companies. >=20 > One could certainly hope that an organization with quantum supremacy is b= enevolent and acts in a=20 > "white hat" manner to return lost coins to their owners, but that's incre= dibly optimistic and=20 > foolish to rely upon. Such a situation creates an insurmountable ethical = dilemma of only recovering=20 > lost bitcoin rather than currently owned bitcoin. There's no way to preci= sely differentiate between=20 > the two; anyone can claim to have lost their bitcoin but if they have los= t their keys then proving=20 > they ever had the keys becomes rather difficult. I imagine that any such = white hat recovery efforts=20 > would have to rely upon attestations from trusted third parties like exch= anges. >=20 > Even if the first actor with quantum supremacy is benevolent, we must ass= ume the technology could=20 > fall into adversarial hands and thus think adversarially about the potent= ial worst case outcomes.=20 > Imagine, for example, that North Korea continues scooping up billions of = dollars from hacking crypto=20 > exchanges and decides to invest some of those proceeds into building a qu= antum computer for the=20 > biggest payday ever... >=20 > Downsides to Allowing Quantum Recovery > Let's think through an exhaustive list of pros and cons for allowing or p= reventing the seizure of=20 > funds by a quantum adversary. >=20 > Historical Precedent > Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair gam= e" but rather were treated as=20 > failures to be remediated. Treating quantum theft differently risks rewri= ting Bitcoin=E2=80=99s history as a=20 > 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 fund= amental principle of=20 > cryptocurrency - if you keep your keys in your possession, only you shoul= d be able to access your=20 > money. Bitcoin is built on the idea that private keys secure an individua= l=E2=80=99s assets, and=20 > unauthorized access (even via advanced tech) is theft, not a legitimate t= ransfer. >=20 > Erosion of Trust in Bitcoin > If quantum attackers can exploit vulnerable addresses, confidence in Bitc= oin as a secure store of=20 > value would collapse. Users and investors rely on cryptographic integrity= , and widespread theft=20 > could drive adoption away from Bitcoin, destabilizing its ecosystem. >=20 > This is essentially the counterpoint to claiming the burning of vulnerabl= e funds is a violation of=20 > property rights. While some will certainly see it as such, others will fi= nd the apathy toward=20 > stopping quantum theft to be similarly concerning. >=20 > Unfair Advantage > Quantum attackers, likely equipped with rare and expensive technology, wo= uld have an unjust edge=20 > over regular users who lack access to such tools. This creates an inequit= able system where only the=20 > technologically elite can exploit others, contradicting Bitcoin=E2=80=99s= ethos of decentralized power. >=20 > Bitcoin is designed to create an asymmetric advantage for DEFENDING one's= wealth. It's supposed to=20 > be impractically expensive for attackers to crack the entropy and cryptog= raphy protecting one's=20 > coins. But now we find ourselves discussing a situation where this asymme= tric advantage is=20 > compromised 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=20 > are dumped on exchanges. This would harm all holders, not just those dire= ctly targeted, leading to=20 > broader financial chaos in the markets. >=20 > Moral Responsibility > Permitting theft via quantum computing sets a precedent that technologica= l superiority justifies=20 > unethical behavior. This is essentially taking a "code is law" stance in = which we refuse to admit=20 > that both code and laws can be modified to adapt to previously unforeseen= situations. >=20 > Burning of coins can certainly be considered a form of theft, thus I thin= k it's worth=20 > 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=20 > the simple argument that theft is immoral becomes a wash and it's importa= nt to drill down into the=20 > details of each. >=20 > Incentives Drive Security > I can tell you from a decade of working in Bitcoin security - the average= user is lazy and is a=20 > procrastinator. If Bitcoiners are given a "drop dead date" after which th= ey know vulnerable funds=20 > will be burned, this pressure accelerates the adoption of post-quantum cr= yptography and strengthens=20 > Bitcoin long-term. Allowing vulnerable users to delay upgrading indefinit= ely will result in more=20 > laggards, leaving the network more exposed when quantum tech becomes avai= lable. >=20 > Steel Manning > Clearly this is a complex and controversial topic, thus it's worth thinki= ng through the opposing=20 > arguments. >=20 > Protecting Property Rights > Allowing quantum computers to take vulnerable bitcoin could potentially b= e spun as a hard money=20 > narrative - we care so greatly about not violating someone's access to th= eir coins that we allow=20 > them to be stolen! >=20 > But I think the flip side to the property rights narrative is that burnin= g vulnerable coins prevents=20 > said property from falling into undeserving hands. If the entire Bitcoin = ecosystem just stands=20 > around and allows quantum adversaries to claim funds that rightfully belo= ng to other users, is that=20 > really a "win" in the "protecting property rights" category? It feels mor= e 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 co= mputers will ever exist, so=20 > we shouldn't bother preparing for a non-existent threat. Others have argu= ed that even if such a=20 > computer was built, a quantum attacker would not go after bitcoin because= they wouldn't want to=20 > reveal their hand by doing so, and would instead attack other infrastruct= ure. >=20 > It's quite difficult to quantify exactly how valuable attacking other inf= rastructure would be. It=20 > also really depends upon when an entity gains quantum supremacy and thus = if by that time most of the=20 > world's systems have already been upgraded. While I think you could argue= that certain entities=20 > gaining quantum capability might not attack Bitcoin, it would only delay = the inevitable - eventually=20 > somebody will achieve the capability who decides to use it for such an at= tack. >=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=20 > lost P2PK outputs so as to not arouse suspicion and cause a market panic. >=20 > I'm not so sure about that; why go after 50 BTC at a time when you could = take 250,000 BTC with the=20 > same effort as 50 BTC? This is a classic "zero day exploit" game theory i= n which an attacker knows=20 > they have a limited amount of time before someone else discovers the expl= oit and either benefits=20 > from it or patches it. Take, for example, the recent ByBit attack - the h= ighest value crypto hack of=20 > all time. Lazarus Group had compromised the Safe wallet front end JavaScr= ipt app and they could have=20 > simply had it reassign ownership of everyone's Safe wallets as they were = interacting with their=20 > wallet. But instead they chose to only specifically target ByBit's wallet= with $1.5 billion in it=20 > because they wanted to maximize their extractable value. If Lazarus had s= tarted stealing from every=20 > wallet, they would have been discovered quickly and the Safe web app woul= d likely have been patched=20 > well before any billion dollar wallets executed the malicious code. >=20 > I think the "only stealing small amounts" argument is strongest for Situa= tion #2 described earlier,=20 > where a quantum attacker arrives before quantum safe cryptography has bee= n deployed across the=20 > Bitcoin ecosystem. Because if it became clear that Bitcoin's cryptography= was broken AND there was=20 > nowhere safe for vulnerable users to migrate, the only logical option wou= ld be for everyone to=20 > liquidate their bitcoin as quickly as possible. As such, I don't think it= applies as strongly for=20 > situations in which we have a migration path available. >=20 > The 21 Million Coin Supply Should be in Circulation > Some folks are arguing that it's important for the "circulating / spendab= le" supply to be as close=20 > to 21M as possible and that having a significant portion of the supply ou= t of circulation is somehow=20 > undesirable. >=20 > While the "21M BTC" attribute is a strong memetic narrative, I don't thin= k anyone has ever expected=20 > that it would all be in circulation. It has always been understood that m= any coins will be lost, and=20 > 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 impor= tant detail - it's not even=20 > mentioned in the whitepaper. What's important is that the supply is well = known and not subject to=20 > change. >=20 > Self-Sovereignty and Personal Responsibility > Bitcoin=E2=80=99s design empowers individuals to control their own wealth= , free from centralized=20 > intervention. This freedom comes with the burden of securing one's privat= e keys. If quantum=20 > computing can break obsolete cryptography, the fault lies with users who = didn't move their funds to=20 > quantum safe locking scripts. Expecting the network to shield users from = their own negligence=20 > undermines the principle that you, and not a third party, are accountable= for your assets. >=20 > I think this is generally a fair point that "the community" doesn't owe y= ou anything in terms of=20 > helping you. I think that we do, however, need to consider the incentives= and game theory in play=20 > with regard to quantum safe Bitcoiners vs quantum vulnerable Bitcoiners. = More on that later. >=20 > Code is Law > Bitcoin operates on transparent, immutable rules embedded in its protocol= . If a quantum attacker=20 > uses superior technology to derive private keys from public keys, they=E2= =80=99re not "hacking" the system -=20 > they're simply following what's mathematically permissible within the cur= rent code. Altering the=20 > protocol to stop this introduces subjective human intervention, which cla= shes with the objective,=20 > deterministic nature of blockchain. >=20 > While I tend to agree that code is law, one of the entire points of laws = is that they can be amended=20 > to improve their efficacy in reducing harm. Leaning on this point seems m= ore like a pro-ossification=20 > stance that it's better to do nothing and allow harm to occur rather than= take action to stop an=20 > 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 eventuall= y break. Quantum computing=20 > is just the next step in this progression. Users who fail to adapt (e.g.,= by adopting quantum-=20 > resistant wallets when available) are akin to those who ignored technolog= ical advancements like=20 > multisig or hardware wallets. Allowing quantum theft incentivizes innovat= ion and keeps Bitcoin=E2=80=99s=20 > ecosystem dynamic, punishing complacency while rewarding vigilance. >=20 > Market Signals Drive Security > If quantum attackers start stealing funds, it sends a clear signal to the= market: upgrade your=20 > security or lose everything. This pressure accelerates the adoption of po= st-quantum cryptography and=20 > strengthens Bitcoin long-term. Coddling vulnerable users delays this nece= ssary evolution,=20 > potentially leaving the network more exposed when quantum tech becomes wi= dely accessible. Theft is a=20 > brutal but effective teacher. >=20 > Centralized Blacklisting Power > Burning vulnerable funds requires centralized decision-making - a soft fo= rk to invalidate certain=20 > transactions. This sets a dangerous precedent for future interventions, e= roding Bitcoin=E2=80=99s=20 > decentralization. If quantum theft is blocked, what=E2=80=99s next - reve= rsing exchange hacks? The system=20 > 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 o= nly burn specific=20 > addresses. Rather, I'd expect a neutral proposal to burn all funds in loc= king script types that are=20 > 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 physi= cs and math. Anyone with=20 > the resources and foresight can build or access quantum tech, just as any= one could mine Bitcoin in=20 > 2009 with a CPU. Early adopters took risks and reaped rewards; quantum in= novators are doing the=20 > same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin has never = promised equality of outcome - only=20 > equality of opportunity within its rules. >=20 > I find this argument to be a mischaracterization because we're not talkin= g about CPUs. This is more=20 > akin to talking about ASICs, except each ASIC costs millions if not billi= ons of dollars. This is out=20 > of reach from all but the wealthiest organizations. >=20 > Economic Resilience > Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and emerg= ed stronger. The market can=20 > absorb quantum losses, with unaffected users continuing to hold and new e= ntrants buying in at lower=20 > prices. Fear of economic collapse overestimates the impact - the network= =E2=80=99s antifragility thrives on=20 > such challenges. >=20 > This is a big grey area because we don't know when a quantum computer wil= l come online and we don't=20 > know how quickly said computers would be able to steal bitcoin. If, for e= xample, the first=20 > generation of sufficiently powerful quantum computers were stealing less = volume than the current=20 > block reward then of course it will have minimal economic impact. But if = they're taking thousands of=20 > BTC per day and bringing them back into circulation, there will likely be= a noticeable market impact=20 > as it absorbs the new supply. >=20 > This is where the circumstances will really matter. If a quantum attacker= appears AFTER the Bitcoin=20 > protocol has been upgraded to support quantum resistant cryptography then= we should expect the most=20 > valuable active wallets will have upgraded and the juiciest target would = be the 31,000 BTC in the=20 > address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant since 2= 010. In general I'd expect=20 > that the amount of BTC re-entering the circulating supply would look some= what similar to the mining=20 > emission curve: volume would start off very high as the most valuable add= resses are drained and then=20 > it would fall off as quantum computers went down the list targeting addre= sses with less and less BTC. >=20 > Why is economic impact a factor worth considering? Miners and businesses = in general. More coins=20 > being liquidated will push down the price, which will negatively impact m= iner revenue. Similarly, I=20 > can attest from working in the industry for a decade, that lower prices r= esult in less demand from=20 > businesses across the entire industry. As such, burning quantum vulnerabl= e bitcoin is good for the=20 > entire industry. >=20 > Practicality & Neutrality of Non-Intervention > There=E2=80=99s no reliable way to distinguish =E2=80=9Ctheft=E2=80=9D fr= om legitimate "white hat" key recovery. If someone=20 > loses their private key and a quantum computer recovers it, is that steal= ing or reclaiming? Policing=20 > quantum actions requires invasive assumptions about intent, which Bitcoin= =E2=80=99s trustless design can=E2=80=99t=20 > 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 outcomes= reflect preparation and skill, not=20 > sentimentality. If quantum computing upends the game, that=E2=80=99s the = point - Bitcoin isn=E2=80=99t meant to be=20 > safe or fair in a nanny-state sense; it=E2=80=99s meant to be free. Users= who lose funds to quantum attacks=20 > are casualties of liberty and their own ignorance, not victims of injusti= ce. >=20 > Bitcoin's DAO Moment > This situation has some similarities to The DAO hack of an Ethereum smart= contract in 2016, which=20 > resulted in a fork to stop the attacker and return funds to their origina= l owners. The game theory=20 > is similar because it's a situation where a threat is known but there's s= ome period of time before=20 > the attacker can actually execute the theft. As such, there's time to mit= igate the attack by=20 > changing the protocol. >=20 > It also created a schism in the community around the true meaning of "cod= e is law," resulting in=20 > Ethereum Classic, which decided to allow the attacker to retain control o= f the stolen funds. >=20 > A soft fork to burn vulnerable bitcoin could certainly result in a hard f= ork if there are enough=20 > miners who reject the soft fork and continue including transactions. >=20 > Incentives Matter > We can wax philosophical until the cows come home, but what are the actua= l incentives for existing=20 > Bitcoin holders regarding this decision? >=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 > "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 s= upported within the Bitcoin=20 > protocol, what's the incentive to let vulnerable coins remain spendable? >=20 > * It's not good for the actual owners of those coins. It disincentivizes = owners from upgrading until=20 > perhaps it's too late. > * It's not good for the more attentive / responsible owners of coins who = have quantum secured their=20 > stash. Allowing the circulating supply to balloon will assuredly reduce t= he purchasing power of all=20 > bitcoin holders. >=20 > Forking Game Theory > From a game theory point of view, I see this as incentivizing users to u= pgrade their wallets. If=20 > you disagree with the burning of vulnerable coins, all you have to do is = move your funds to a=20 > quantum safe signature scheme. Point being, I don't see there being an ec= onomic majority (or even=20 > more than a tiny minority) of users who would fight such a soft fork. Why= expend significant=20 > resources fighting a fork when you can just move your coins to a new addr= ess? >=20 > Remember that blocking spending of certain classes of locking scripts is = a tightening of the rules -=20 > a soft fork. As such, it can be meaningfully enacted and enforced by a me= re majority of hashpower.=20 > If miners generally agree that it's in their best interest to burn vulner= able coins, are other users=20 > going to care enough to put in the effort to run new node software that r= esists the soft fork? Seems=20 > 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=20 > specific block height / timestamp, Bitcoin nodes will no longer accept tr= ansactions (or blocks=20 > containing such transactions) that spend funds from any scripts other tha= n the newly instituted=20 > quantum safe schemes. >=20 > It could take a staggered approach to first freeze funds that are suscept= ible to long-range attacks=20 > such as those in P2PK scripts or those that exposed their public keys due= to previously re-using=20 > addresses, but I expect the additional complexity would drive further con= troversy. >=20 > How long should the grace period be in order to give the ecosystem time t= o upgrade? I'd say a=20 > minimum of 1 year for software wallets to upgrade. We can only hope that = hardware wallet=20 > manufacturers are able to implement post quantum cryptography on their ex= isting hardware with only a=20 > firmware update. >=20 > Beyond that, it will take at least 6 months worth of block space for all = users to migrate their=20 > funds, even in a best case scenario. Though if you exclude dust UTXOs you= could probably get 95% of=20 > BTC value migrated in 1 month. Of course this is a highly optimistic situ= ation where everyone is=20 > completely focused on migrations - in reality it will take far longer. >=20 > Regardless, I'd think that in order to reasonably uphold Bitcoin's conser= vatism it would be=20 > preferable to allow a 4 year migration window. In the meantime, mining po= ols could coordinate=20 > emergency soft forking logic such that if quantum attackers materialized,= they could accelerate the=20 > countdown to the quantum vulnerable funds burn. >=20 > Random Tangential Benefits > On the plus side, burning all quantum vulnerable bitcoin would allow us t= o prune all of those UTXOs=20 > out of the UTXO set, which would also clean up a lot of dust. Dust UTXOs = are a bit of an annoyance=20 > and there has even been a recent proposal for how to incentivize cleaning= them up. >=20 > We should also expect that incentivizing migration of the entire UTXO set= will create substantial=20 > demand for block space that will sustain a fee market for a fairly length= y amount of time. >=20 > In Summary > While the moral quandary of violating any of Bitcoin's inviolable propert= ies can make this a very=20 > complex issue to discuss, the game theory and incentives between burning = vulnerable coins versus=20 > allowing them to be claimed 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 in= flating the circulating=20 > money supply just because some people lost their keys long ago and some l= aggards are not upgrading=20 > their bitcoin wallet's security. >=20 > We can hope that this scenario never comes to pass, but hope is not a str= ategy. >=20 > I welcome your feedback upon any of the above points, and contribution of= any arguments I failed to=20 > consider. >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "Bitcoin Development=20 > Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to=20 > bitcoindev+unsubscribe@googlegroups.com . > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/=20 > CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.= com groups.google.com/d/msgid/bitcoindev/=20 > CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.= com?=20 > utm_medium=3Demail&utm_source=3Dfooter>. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 43afd5bb-244e-4698-ba3d-139efa2c2058%40mattcorallo.com.