path: root/e9/8ee347a33d06ff441d87133d00d7ee1b656164

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 <bitcoindev+bncBAABBT6J4C7AMGQE4R7R3LI@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <lf-lists@mattcorallo.com>)
	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 <jameson.lopp@gmail.com>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.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/
> <https://nakamoto.com/what-are-the-key-properties-of-bitcoin/>
> The particular properties in play with regard to this issue seem to be:
>=20
> *Censorship Resistance* - No one should have the power to prevent others =
from using their bitcoin or=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 <https://=20
> 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 <mailto:bitcoindev+unsubscribe@go=
oglegroups.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 <https://=20
> 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.