path: root/9d/bf81542c35650fe7cd1dbd28fb26121664eea4

Delivery-date: Mon, 17 Mar 2025 06:37:20 -0700
Received: from mail-oo1-f60.google.com ([209.85.161.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCYMD7OS6ECBBBWL4C7AMGQEHL7TZOA@googlegroups.com>)
	id 1tuAec-0003sl-Hk
	for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:37:20 -0700
Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-60047981020sf3559033eaf.1
        for <bitcoindev@gnusha.org>; Mon, 17 Mar 2025 06:37:18 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1742218633; cv=pass;
        d=google.com; s=arc-20240605;
        b=C/nvV8nCyedHgJPETSFd1qLowDz2KgCbg1MUTvWg/XRuCxRnAjogk2DtPzC0RagQsN
         dOBS4/Lw53ihB9zex7H7Yccx8TCtZgCURt755dvT2eISCnpiw5dw7cfG3TWq+0kbuFDS
         8UTlpDfcEqmGEUGM0AbEZbxzxEdPhmjXrABPW0yqlXDkGhzD6FqqD1Ifa2hJg0HcLdct
         1kDbnRMvPaLOw1b1+Mu7AUgICZ/57+o2iFYP3WEMm5rw/GjjIJD7swNuxzRvOvFZhavw
         q6PSdrbCYL7Yd4Zw1sad/LuAeqVOE5xZwrQrOajFS1ouI1N5CKHcaxKLDDPm2ZK4QuZY
         95Nw==
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:cc:to
         :subject:message-id:date:from:in-reply-to:references:mime-version
         :sender:dkim-signature:dkim-signature;
        bh=VZdrJMbjjiD5P+Js8h7VAaYnrJY6Ntqu2XYFQVVlpsc=;
        fh=wPkiREm+hLTe6V20Gbc++xc7ry5qsUb3f6BlsbFAhmU=;
        b=gJBDTjR23P5di/uD6xkqQUsTtDCZmokVKagiIoaZV8Z82chHb4+5R04FlRRREuML7w
         EITYBW+SCiJfIOFXPOSOjDRXDwKHMHBxrZXqmcdYbcRJYZIMhjLEZvMT/pd0BS3IP03B
         eOtcfuxFdXO6l0izA++hmLaHZ1X3dLazSUbm2cXAiglaPWyRZX5Cv7/dja1lSGWW8Umo
         ZX3ojMevn91MyFj2LFAjMnYwUzBcaJJqIIeg2Dj+yIauH+OG2ps158kCzCOejd1BXxg1
         9HBgLpRNViFx9a/3MK16P2tu7EufpwJLSWdQD94w8jTncwDcQ/WzxKfTsqnO9yW5SPyp
         Cu4A==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=LFqKnD4H;
       spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::12f as permitted sender) smtp.mailfrom=bnagaev@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1742218633; x=1742823433; 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:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=VZdrJMbjjiD5P+Js8h7VAaYnrJY6Ntqu2XYFQVVlpsc=;
        b=g4kAQE22e95cgSgOF9Zjjp/jXX/w893rk9EeLWJPwnPvy+o+kZHNR44YLjIsxFB7qb
         qNGBIsSgEY7jim95kjgr+0QTfWyfgMYEQlcBvKaQNUL4u7ZVm26cHDs/5PuDzt2YzWle
         X8gRgJb8PQ5+AOs3SQV6mJIPvJm4I3cHJUtqzj9MoYo0TKuMWRg6uQaPOU4s1wYrcGiz
         BiGeIcC6Lena1yAPeHFeTSFyJtnl9HX1U8voDVqp5evJnra+TgQR92Lh0d5r5d4eRyhV
         3sOfdesa4fuO51JS29BZNe4Zmv6Frk/BhmGXHtlyQT07mzxc8bSUaS4V8eP4F4xeNXeE
         TY3w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1742218633; x=1742823433; 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:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:from:to:cc
         :subject:date:message-id:reply-to;
        bh=VZdrJMbjjiD5P+Js8h7VAaYnrJY6Ntqu2XYFQVVlpsc=;
        b=NMuhvtmfN3XBr8rRWaTmidh915L6nwQTvyjsPUwsfodzcHu7VjHwQaGFbqVM1K1z0z
         6/KkpVGFMCjNBkkDeUUFCsmOisy2zjS2+Os4A700aeQ2LOK5vOX/M4SmsaVdAdtEeJBN
         26za4FRwuDMtn5rUEsKMOjYKFz1psi7LwwOhQO2Xqs92iabJ5CkY2JT/y1dYHrUELAYH
         FVPTceuORNwOn1DkJVoOKs+Pgvcl9Kk/SKXIDVujee1xaWk2R42f2R6pJYSc+yHEAJex
         BZ9S6h0nXJX9SA5qvIJjGbfaflh05BFMdrMCN7WBAvYzMiW6xfeQzrVL0P5p3zT2x4G9
         TTKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742218633; x=1742823433;
        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:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VZdrJMbjjiD5P+Js8h7VAaYnrJY6Ntqu2XYFQVVlpsc=;
        b=ANGMd3Oe6NEVxnF4iDLBSDXgL1FD8ySxkU9Pa5HsX/Ir0z2NqZrH1bqHKHMw2PhxRI
         p2RxaNa3KMeo8BfzEwcUcGNQQx4NRh2BsR7kDtC+YH8H0k6J8HTob0mXQ9luyFJk3z0v
         IEmsIGPE3PbQKxrIjNx+Gr8yU+0lp/E54Qv4IE9bVqvajwHloAW9t6hCnpYrYubuYJp/
         cntwzlw8Ls6hV1OMdAQKwcqNan0SA5Gnln3ELy4/M3T16OTLKqWljkTo37ozifQGnZnC
         dmOJiTn4pF5QiJ+98nFr5mcrEfOCgQGlVPCHPsRLibyMq9HMQA0xNWU4ECXlyz4H+03o
         6F+Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW/PHV4ctV0hIQcFCn+kjRDjnZD3O+9+A7XdepO+buwnK0ME3qxZOvS3kEo6QeJcql5kB77EOix2CvM@gnusha.org
X-Gm-Message-State: AOJu0YwbE9S9FeQ4oQCElkScR+4hnFFVSBk/U6tGHouWx9XTamuRCQJC
	+l7PfPPRvlt5upY27OeKKvvIxxShcq9wavIzsnQZetL86yeJI8e7
X-Google-Smtp-Source: AGHT+IHOmk8ntTfmtr7Iyq/NnI4KGbR1ncBwiP+KS9O1+Xh6kHgunCAGAF3zF/3eSbghJaHahEJfPQ==
X-Received: by 2002:a05:6820:201a:b0:600:50bd:6eda with SMTP id 006d021491bc7-601e45d7c6fmr6469116eaf.6.1742218632760;
        Mon, 17 Mar 2025 06:37:12 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKQ6/gpQd61+Lj/Qrp5lsniiQykREu6JqimvD2hGrTiOA==
Received: by 2002:a4a:db6f:0:b0:601:7ee2:67b2 with SMTP id 006d021491bc7-601d89ac51bls46584eaf.2.-pod-prod-08-us;
 Mon, 17 Mar 2025 06:37:10 -0700 (PDT)
X-Received: by 2002:a05:6808:1409:b0:3f6:a535:80a7 with SMTP id 5614622812f47-3fdeefedd31mr8090729b6e.19.1742218630007;
        Mon, 17 Mar 2025 06:37:10 -0700 (PDT)
Received: by 2002:a05:6808:8f0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-3fddc3d65c1msb6e;
        Sun, 16 Mar 2025 12:45:28 -0700 (PDT)
X-Received: by 2002:a17:902:ecc5:b0:223:f7ec:f834 with SMTP id d9443c01a7336-225e0a840camr120234845ad.31.1742154327139;
        Sun, 16 Mar 2025 12:45:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1742154327; cv=none;
        d=google.com; s=arc-20240605;
        b=FJhrii9QzetDNAFL3N5jEOwEsR3mLU1W66bl5YgXsj482dRAxWZfvMBH8jFpR/yws2
         AxpQfb3LH5vdafFDogBEZxf97/4mMPo+pFPLEcw1HGLTor4CB7/byoQRgUFupXUh3/n9
         7BRwINXmN6ueGQVwP2fIy29rHV8ZL7iex5xPcWwsrQa8eZY0pFuG4mnvQEAt/psfh+oz
         Wxn+mqjzVwPxqxBAQ3npAGUGOYVopLbeWdiM0UCItnPgQzck2wvIq7LZnIz0meqHR2Sw
         noONURVS+TeTRLRR45s/hKwp/RDncLugXmSYhGGwZuCs56w9Ah7E3M5bBXNbmPAx/le7
         LGgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=3G2YG+2wncyOf/C08J0ygOenF+Ou+PXOvzs6d7Bp9xk=;
        fh=dEDbYMbbYyDNRr1LOwMlw2+lJDEDNk0XskwzeS3uI5o=;
        b=Fa0X39AYIvNL5HxJMtmZ7dRqwIHAKpJhvT7VpN0+CfNLCdTgCpF3C1cxGulfPgbNPg
         vd42i8JU931f37d2cAa+HJ+zifVoghAAdOgvu42TYvHqQhU7smZiJAEiCvJH/uROKFhz
         axfE8Jj3aeZWowhRp2KtjlHrtA1C7STAy0oMutEpTEZpwlGfKyIeLuxeSU14TvXZtb2G
         /qkfmLT6Wzo9Ah3C3yqNEx79nTSt2XF7/0hKWPMhsaMEev//EUgmxC0OEZR0jxnZI+p1
         ra7eEQsdOzdjEwqD+VFjmEkSbPZhfrjJlGnDd8+dq/itDj96DneXI6ihMhiy1Ouy5+bG
         CSCw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=LFqKnD4H;
       spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::12f as permitted sender) smtp.mailfrom=bnagaev@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com. [2607:f8b0:4864:20::12f])
        by gmr-mx.google.com with ESMTPS id d9443c01a7336-225c6b3b426si3267665ad.1.2025.03.16.12.45.27
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 16 Mar 2025 12:45:27 -0700 (PDT)
Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::12f as permitted sender) client-ip=2607:f8b0:4864:20::12f;
Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-3d46aaf36a2so31562335ab.3
        for <bitcoindev@googlegroups.com>; Sun, 16 Mar 2025 12:45:27 -0700 (PDT)
X-Gm-Gg: ASbGncuYKE/+G5jKZgw+/vEy7GYbehKNVrVxGWxERw87rBP74ezRNgzMM4okCtJojxC
	vf4dh2WaqZ6DFeteL/ecsp23rzNgxiNovng9mtt/QccRciTSljJxMTQSKC3apAyjoew6KS/M/Gw
	BrjU1Ug3Ops5tles6FNmEZ3vlHgA==
X-Received: by 2002:a05:6e02:3498:b0:3d4:700f:67e7 with SMTP id
 e9e14a558f8ab-3d483a6ed9emr120841455ab.17.1742154325807; Sun, 16 Mar 2025
 12:45:25 -0700 (PDT)
MIME-Version: 1.0
References: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com>
In-Reply-To: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com>
From: Nagaev Boris <bnagaev@gmail.com>
Date: Sun, 16 Mar 2025 16:44:48 -0300
X-Gm-Features: AQ5f1JrQDEwgfh3ds9lUjYpxm7_cfDcI6D4jULiHhRK9V5DndvdrNE8dTWO_j1M
Message-ID: <CAFC_Vt54W1RR6GJSSg1tVsLi1=YHCQYiTNLxMj+vypMtTHcUBQ@mail.gmail.com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
To: Jameson Lopp <jameson.lopp@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: bnagaev@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=LFqKnD4H;       spf=pass
 (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::12f as
 permitted sender) smtp.mailfrom=bnagaev@gmail.com;       dmarc=pass (p=NONE
 sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.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.0 (/)

Hi!

What is your perspective on time-locked coins that become spendable
only after a set deadline? Unlike regular holders who can migrate
their funds in advance, owners of time-locked coins, such as those set
to unlock through an inheritance or a smart contract, have no way to
react before the deadline. Imagine you received an inheritance set to
unlock in 2030, only to find that the deadline for migration is set
for 2029. Would such cases be considered an acceptable loss, or is
there a way to account for them without violating Bitcoin=E2=80=99s
principles?

Boris

On Sun, Mar 16, 2025 at 12:22=E2=80=AFPM Jameson Lopp <jameson.lopp@gmail.c=
om> wrote:
>
> The quantum computing debate is heating up. There are many controversial =
aspects to this debate, including whether or not quantum computers will eve=
r actually become a practical threat.
>
> I won't tread into the unanswerable question of how worried we should be =
about quantum computers. I think it's far from a crisis, but given the diff=
iculty in changing Bitcoin it's worth starting to seriously discuss. Today =
I wish to focus on a philosophical quandary related to one of the decisions=
 that would need to be made if and when we implement a quantum safe signatu=
re scheme.
>
> Several Scenarios
> Because this essay will reference game theory a fair amount, and there ar=
e many variables at play 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 this scenario it w=
ould likely make the points below moot because Bitcoin would be fundamental=
ly broken and it would take far too long to upgrade the protocol, wallet so=
ftware, and migrate user funds in order to restore confidence in the networ=
k.
> 3. Quantum computing advances slowly enough that we come to consensus abo=
ut how to upgrade Bitcoin and post quantum security has been minimally adop=
ted by the time an attacker appears.
> 4. Quantum computing advances slowly enough that we come to consensus abo=
ut how to upgrade 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 Freeze?
> I've started seeing more people weighing in on what is likely the most co=
ntentious aspect of how a quantum resistance upgrade should be handled in t=
erms of migrating user funds. Should quantum vulnerable funds be left open =
to be swept by anyone with a sufficiently powerful quantum computer OR shou=
ld they be permanently locked?
>
>> "I don't see why old coins should be confiscated. The better option is t=
o 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 in=
flation is transitory. Those with low time preference should support return=
ing lost coins to circulation."
>>
>> - Hunter Beast
>
>
> On the other hand:
>
>> "Of course they have to be confiscated. If and when (and that's a big if=
) the existence of a cryptography-breaking QC becomes a credible threat, th=
e Bitcoin ecosystem has no other option than softforking out the ability to=
 spend from signature schemes (including ECDSA and BIP340) that are vulnera=
ble to QCs. The alternative is that millions of BTC become vulnerable to th=
eft; 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-protected schemes."
>> - Pieter Wuille
>
>
> I don't think "confiscation" is the most precise term to use, as the fund=
s are not being seized and reassigned. Rather, what we're really discussing=
 would be better described as "burning" - placing the funds out of reach of=
 everyone.
>
> Not freezing user funds is one of Bitcoin's inviolable properties. Howeve=
r, if quantum computing becomes a threat to Bitcoin's elliptic curve crypto=
graphy, an inviolable property of Bitcoin will be violated one way or anoth=
er.
>
> Fundamental Properties at Risk
> 5 years ago I attempted to comprehensively categorize all of Bitcoin's fu=
ndamental properties that give it value. https://nakamoto.com/what-are-the-=
key-properties-of-bitcoin/
>
> The particular properties in play with regard to this issue seem to be:
>
> Censorship Resistance - No one should have the power to prevent others fr=
om using their bitcoin or interacting with the network.
>
> Forward Compatibility - changing the rules such that certain valid transa=
ctions become invalid could undermine confidence in the protocol.
>
> Conservatism - Users should not be expected to be highly responsive to sy=
stem issues.
>
> As a result of the above principles, we have developed a strong meme (kud=
os 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 princi=
ple. We secure our bitcoin with the mathematical probabilities related to e=
xtremely large random numbers. Your funds are only secure because truly ran=
dom large numbers should not be guessable or discoverable by anyone else in=
 the world.
>
> This is the principle behind the motto vires in numeris - strength in num=
bers. In a world with quantum enabled adversaries, this principle is null a=
nd void for many types of cryptography, including the elliptic curve digita=
l signatures used in Bitcoin.
>
> Who is at Risk?
> There has long been a narrative that Satoshi's coins and others 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 powerful quantum computer, =
which coins would I target? I'd go to the Bitcoin rich list and find the wa=
llets that have exposed their public keys due to re-using addresses that ha=
ve previously been spent from. You can easily find them at https://bitinfoc=
harts.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 Bitfine=
x / Tether in order to 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 adversary, at least at time of writing. If we add a quantum=
 safe signature scheme, we should expect those wallets to be some of the fi=
rst 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 some B=
itcoin users who were not paying attention and neglected to migrate their f=
unds to a quantum safe locking script. This violates the "conservativism" p=
rinciple stated earlier. On the flip side, we prevent those funds plus far =
more lost funds from falling into the hands of the few privileged folks who=
 gain early access to quantum computers.
>
> By leaving quantum vulnerable funds available to spend, the same set of u=
sers who would otherwise have funds frozen are likely to see them stolen. A=
nd many early adopters who lost their keys will eventually see their unreac=
hable funds scooped up by a quantum enabled adversary.
>
> Imagine, for example, being James Howells, who accidentally threw away a =
hard drive with 8,000 BTC on it, currently worth over $600M USD. He has spe=
nt a decade trying to retrieve it from the landfill where he knows it's bur=
ied, but can't get permission to excavate. I suspect that, given the choice=
, he'd prefer those funds be permanently frozen rather than fall into someo=
ne 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 have a negative impa=
ct upon everyone who is currently holding bitcoin.
>
> It's prudent to expect significant economic disruption if large amounts o=
f coins fall into new hands. Since a quantum computer is going to have a ma=
ssive up front cost, expect those behind it to desire to recoup their inves=
tment. We also know from experience that when someone suddenly finds themse=
lves in possession of 9+ figures worth of highly liquid assets, they tend t=
o diversify into other things by selling.
>
> Allowing quantum recovery of bitcoin is tantamount to wealth redistributi=
on. What we'd be allowing is for bitcoin to be redistributed from those who=
 are ignorant 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 s=
cenario.
>
> Is Quantum Recovery Good for Anyone?
>
> Does quantum recovery HELP anyone? I've yet to come across an argument th=
at 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 them.
>
> But wait, you may be thinking, wouldn't quantum "miners" have earned thei=
r coins by all the work and resources invested in building a quantum comput=
er? I suppose, in the same sense that a burglar earns their spoils by the r=
esources they invest into surveilling targets and learning the skills neede=
d to break into buildings. What I say "earned" I mean through productive mu=
tual 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 the=
 system.
>
> There's no reason to believe that allowing quantum adversaries to recover=
 vulnerable bitcoin will be of benefit to anyone other than the select few =
organizations that win the technological arms race to build the first such =
computers. Probably nation states and/or the top few largest tech companies=
.
>
> One could certainly hope that an organization with quantum supremacy is b=
enevolent and acts in a "white hat" manner to return lost coins to their ow=
ners, but that's incredibly optimistic and foolish to rely upon. Such a sit=
uation creates an insurmountable ethical dilemma of only recovering lost bi=
tcoin rather than currently owned bitcoin. There's no way to precisely diff=
erentiate between the two; anyone can claim to have lost their bitcoin but =
if they have lost their keys then proving they ever had the keys becomes ra=
ther difficult. I imagine that any such white hat recovery efforts would ha=
ve to rely upon attestations from trusted third parties like exchanges.
>
> Even if the first actor with quantum supremacy is benevolent, we must ass=
ume the technology could fall into adversarial hands and thus think adversa=
rially about the potential worst case outcomes. Imagine, for example, that =
North Korea continues scooping up billions of dollars from hacking crypto e=
xchanges and decides to invest some of those proceeds into building a quant=
um computer for the biggest payday ever...
>
> Downsides to Allowing Quantum Recovery
> Let's think through an exhaustive list of pros and cons for allowing or p=
reventing the seizure of funds by a quantum adversary.
>
> Historical Precedent
> Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair gam=
e" but rather were treated as failures to be remediated. Treating quantum t=
heft differently risks rewriting Bitcoin=E2=80=99s history as a free-for-al=
l rather than a system that seeks to protect its users.
>
> Violation of Property Rights
> Allowing a quantum adversary to take control of funds undermines the fund=
amental principle of cryptocurrency - if you keep your keys in your possess=
ion, only you should be able to access your money. Bitcoin is built on the =
idea that private keys secure an individual=E2=80=99s assets, and unauthori=
zed access (even via advanced tech) is theft, not a legitimate transfer.
>
> Erosion of Trust in Bitcoin
> If quantum attackers can exploit vulnerable addresses, confidence in Bitc=
oin as a secure store of value would collapse. Users and investors rely on =
cryptographic integrity, and widespread theft could drive adoption away fro=
m Bitcoin, destabilizing its ecosystem.
>
> This is essentially the counterpoint to claiming the burning of vulnerabl=
e funds is a violation of property rights. While some will certainly see it=
 as such, others will find the apathy toward stopping quantum theft to be s=
imilarly concerning.
>
> Unfair Advantage
> Quantum attackers, likely equipped with rare and expensive technology, wo=
uld have an unjust edge over regular users who lack access to such tools. T=
his creates an inequitable system where only the technologically elite can =
exploit others, contradicting Bitcoin=E2=80=99s ethos of decentralized powe=
r.
>
> Bitcoin is designed to create an asymmetric advantage for DEFENDING one's=
 wealth. It's supposed to be impractically expensive for attackers to crack=
 the entropy and cryptography protecting one's coins. But now we find ourse=
lves discussing a situation where this asymmetric advantage is compromised =
in favor of a specific class of attackers.
>
> Economic Disruption
> Large-scale theft from vulnerable addresses could crash Bitcoin=E2=80=99s=
 price as quantum recovered funds are dumped on exchanges. This would harm =
all holders, not just those directly targeted, leading to broader financial=
 chaos in the markets.
>
> Moral Responsibility
> Permitting theft via quantum computing sets a precedent that technologica=
l superiority justifies unethical behavior. This is essentially taking a "c=
ode is law" stance in which we refuse to admit that both code and laws can =
be modified to adapt to previously unforeseen situations.
>
> Burning of coins can certainly be considered a form of theft, thus I thin=
k it's worth differentiating the two different thefts being discussed:
>
> 1. self-enriching & likely malicious
> 2. harm prevention & not necessarily malicious
>
> Both options lack the consent of the party whose coins are being burnt or=
 transferred, thus I think the simple argument that theft is immoral become=
s a wash and it's important to drill down into the details of each.
>
> Incentives Drive Security
> I can tell you from a decade of working in Bitcoin security - the average=
 user is lazy and is a procrastinator. If Bitcoiners are given a "drop dead=
 date" after which they know vulnerable funds will be burned, this pressure=
 accelerates the adoption of post-quantum cryptography and strengthens Bitc=
oin long-term. Allowing vulnerable users to delay upgrading indefinitely wi=
ll result in more laggards, leaving the network more exposed when quantum t=
ech becomes available.
>
> Steel Manning
> Clearly this is a complex and controversial topic, thus it's worth thinki=
ng through the opposing arguments.
>
> Protecting Property Rights
> Allowing quantum computers to take vulnerable bitcoin could potentially b=
e spun as a hard money narrative - we care so greatly about not violating s=
omeone's access to their coins that we allow them to be stolen!
>
> But I think the flip side to the property rights narrative is that burnin=
g vulnerable coins prevents said property from falling into undeserving han=
ds. If the entire Bitcoin ecosystem just stands around and allows quantum a=
dversaries to claim funds that rightfully belong to other users, is that re=
ally a "win" in the "protecting property rights" category? It feels more li=
ke 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 quantum co=
mputers will ever exist, so we shouldn't bother preparing for a non-existen=
t threat. Others have argued that even if such a computer was built, a quan=
tum attacker would not go after bitcoin because they wouldn't want to revea=
l their hand by doing so, and would instead attack other infrastructure.
>
> It's quite difficult to quantify exactly how valuable attacking other inf=
rastructure would be. It also really depends upon when an entity gains quan=
tum supremacy and thus if by that time most of the world's systems have alr=
eady been upgraded. While I think you could argue that certain entities gai=
ning quantum capability might not attack Bitcoin, it would only delay the i=
nevitable - 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 targeted bitcoin, they'd=
 only go after old, likely lost P2PK outputs so as to not arouse suspicion =
and cause a market panic.
>
> I'm not so sure about that; why go after 50 BTC at a time when you could =
take 250,000 BTC with the same effort as 50 BTC? This is a classic "zero da=
y exploit" game theory in which an attacker knows they have a limited amoun=
t of time before someone else discovers the exploit and either benefits fro=
m it or patches it. Take, for example, the recent ByBit attack - the highes=
t value crypto hack of all time. Lazarus Group had compromised the Safe wal=
let front end JavaScript app and they could have simply had it reassign own=
ership of everyone's Safe wallets as they were interacting with their walle=
t. But instead they chose to only specifically target ByBit's wallet with $=
1.5 billion in it because they wanted to maximize their extractable value. =
If Lazarus had started stealing from every wallet, they would have been dis=
covered quickly and the Safe web app would likely have been patched well be=
fore any billion dollar wallets executed the malicious code.
>
> I think the "only stealing small amounts" argument is strongest for Situa=
tion #2 described earlier, where a quantum attacker arrives before quantum =
safe cryptography has been deployed across the Bitcoin ecosystem. Because i=
f it became clear that Bitcoin's cryptography was broken AND there was nowh=
ere 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 migrat=
ion path available.
>
> 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 to 21M as possible and that having a significant =
portion of the supply out of circulation is somehow undesirable.
>
> While the "21M BTC" attribute is a strong memetic narrative, I don't thin=
k anyone has ever expected that it would all be in circulation. It has alwa=
ys been understood that many coins will be lost, and that's actually part o=
f the game theory of owning bitcoin!
>
> And remember, the 21M number in and of itself is not a particularly impor=
tant detail - it's not even mentioned in the whitepaper. What's important i=
s 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 wealth=
, free from centralized intervention. This freedom comes with the burden of=
 securing one's private keys. If quantum computing can break obsolete crypt=
ography, the fault lies with users who didn't move their funds to quantum s=
afe locking scripts. Expecting the network to shield users from their own n=
egligence undermines the principle that you, and not a third party, are acc=
ountable for your assets.
>
> I think this is generally a fair point that "the community" doesn't owe y=
ou anything in terms of helping you. I think that we do, however, need to c=
onsider the incentives and game theory in play with regard to quantum 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 superior technology to derive private keys fro=
m public keys, they=E2=80=99re not "hacking" the system - they're simply fo=
llowing what's mathematically permissible within the current code. Altering=
 the protocol to stop this introduces subjective human intervention, which =
clashes with the objective, deterministic nature of blockchain.
>
> While I tend to agree that code is law, one of the entire points of laws =
is that they can be amended to improve their efficacy in reducing harm. Lea=
ning on this point seems more like a pro-ossification stance that it's bett=
er 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 eventuall=
y break. Quantum computing is just the next step in this progression. Users=
 who fail to adapt (e.g., by adopting quantum-resistant wallets when availa=
ble) are akin to those who ignored technological advancements like multisig=
 or hardware wallets. Allowing quantum theft incentivizes innovation and ke=
eps Bitcoin=E2=80=99s ecosystem dynamic, punishing complacency while reward=
ing vigilance.
>
> Market Signals Drive Security
> If quantum attackers start stealing funds, it sends a clear signal to the=
 market: upgrade your security or lose everything. This pressure accelerate=
s the adoption of post-quantum cryptography and strengthens Bitcoin long-te=
rm. Coddling vulnerable users delays this necessary evolution, potentially =
leaving the network more exposed when quantum tech becomes widely accessibl=
e. Theft is a brutal but effective teacher.
>
> Centralized Blacklisting Power
> Burning vulnerable funds requires centralized decision-making - a soft fo=
rk to invalidate certain transactions. This sets a dangerous precedent for =
future interventions, eroding Bitcoin=E2=80=99s decentralization. If quantu=
m theft is blocked, what=E2=80=99s next - reversing exchange hacks? The sys=
tem must remain neutral, even if it means some lose out.
>
> I think this could be a potential slippery slope if the proposal was to o=
nly burn specific addresses. Rather, I'd expect a neutral proposal to burn =
all funds in locking script types that are known to be quantum vulnerable. =
Thus, we could eliminate any subjectivity from the code.
>
> Fairness in Competition
> Quantum attackers aren't cheating; they're using publicly available physi=
cs and math. Anyone with the resources and foresight can build or access qu=
antum tech, just as anyone could mine Bitcoin in 2009 with a CPU. Early ado=
pters took risks and reaped rewards; quantum innovators are doing the same.=
 Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin has never promise=
d equality of outcome - only equality of opportunity within its rules.
>
> I find this argument to be a mischaracterization because we're not talkin=
g about CPUs. This is more akin to talking about ASICs, except each ASIC co=
sts millions if not billions of dollars. This is out of reach from all but =
the wealthiest organizations.
>
> Economic Resilience
> Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and emerg=
ed stronger. The market can absorb quantum losses, with unaffected users co=
ntinuing to hold and new entrants buying in at lower prices. Fear of econom=
ic collapse overestimates the impact - 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 wil=
l come online and we don't know how quickly said computers would be able to=
 steal bitcoin. If, for example, the first generation of sufficiently power=
ful quantum computers were stealing less volume than the current block rewa=
rd then of course it will have minimal economic impact. But if they're taki=
ng thousands of BTC per day and bringing them back into circulation, there =
will likely be a noticeable market impact as it absorbs the new supply.
>
> This is where the circumstances will really matter. If a quantum attacker=
 appears AFTER the Bitcoin protocol has been upgraded to support quantum re=
sistant cryptography then we should expect the most valuable active wallets=
 will have upgraded and the juiciest target would be the 31,000 BTC in the =
address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant since 201=
0. In general I'd expect that the amount of BTC re-entering the circulating=
 supply would look somewhat similar to the mining emission curve: volume wo=
uld start off very high as the most valuable addresses are drained and then=
 it would fall off as quantum computers went down the list targeting addres=
ses with less and less BTC.
>
> Why is economic impact a factor worth considering? Miners and businesses =
in general. More coins being liquidated will push down the price, which wil=
l negatively impact miner revenue. Similarly, I can attest from working in =
the industry for a decade, that lower prices result in less demand from bus=
inesses across the entire industry. As such, burning quantum vulnerable bit=
coin 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 fr=
om legitimate "white hat" key recovery. If someone loses their private key =
and a quantum computer recovers it, is that stealing or reclaiming? Policin=
g quantum actions requires invasive assumptions about intent, which Bitcoin=
=E2=80=99s trustless design can=E2=80=99t accommodate. Letting the chips fa=
ll where they may avoids this mess.
>
> Philosophical Purity
> Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system where outcomes=
 reflect preparation and skill, not sentimentality. If quantum computing up=
ends the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t meant to be=
 safe or fair in a nanny-state sense; it=E2=80=99s meant to be free. Users =
who lose funds to quantum attacks are casualties of liberty and their own i=
gnorance, not victims of injustice.
>
> Bitcoin's DAO Moment
> This situation 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 =
situation where a threat is known but there's some period of time before th=
e attacker can actually execute the theft. As such, there's time to mitigat=
e the attack by changing the protocol.
>
> It also created a schism in the community around the true meaning of "cod=
e is law," resulting in Ethereum Classic, which decided to allow the attack=
er to retain control of the stolen funds.
>
> A soft fork to burn vulnerable bitcoin could certainly result in a hard f=
ork if there are enough miners who reject the soft fork and continue includ=
ing transactions.
>
> Incentives Matter
> We can wax philosophical until the cows come home, but what are the actua=
l incentives for existing Bitcoin holders regarding this decision?
>
>> "Lost coins only make everyone else's coins worth slightly more. Think o=
f it as a donation to everyone." - Satoshi Nakamoto
>
>
> If true, the corollary is:
>
>> "Quantum recovered coins only make everyone else's coins worth less. Thi=
nk of it as a theft from everyone." - Jameson Lopp
>
>
> Thus, assuming we get to a point where quantum resistant signatures are s=
upported within the Bitcoin protocol, what's the incentive to let vulnerabl=
e coins remain spendable?
>
> * It's not good for the actual 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 balloo=
n will assuredly reduce the purchasing power of all bitcoin holders.
>
> Forking Game Theory
> From a game theory point of view, I see this as incentivizing users to up=
grade their wallets. If you disagree with the burning of vulnerable coins, =
all you have to do is move your funds to a quantum safe signature scheme. P=
oint being, I don't see there being an economic majority (or even more than=
 a tiny minority) of users who would fight such a soft fork. Why expend sig=
nificant resources fighting a fork when you can just move your coins to a n=
ew address?
>
> Remember that blocking spending of certain classes of locking scripts is =
a tightening of the rules - a soft fork. As such, it can be meaningfully en=
acted and enforced by a mere majority of hashpower. If miners generally agr=
ee that it's in their best interest to burn vulnerable coins, are other use=
rs going to care enough to put in the effort to run new node software that =
resists the soft fork? Seems unlikely to me.
>
> How to Execute Burning
> In order to be as objective as possible, the goal would be to announce to=
 the world that after a specific block height / timestamp, Bitcoin nodes wi=
ll no longer accept transactions (or blocks containing such transactions) t=
hat spend funds from any scripts other than the newly instituted quantum sa=
fe schemes.
>
> It could take a staggered approach to first freeze funds that are suscept=
ible to long-range attacks such as those in P2PK scripts or those that expo=
sed their public keys due to previously re-using addresses, but I expect th=
e additional complexity would drive further controversy.
>
> How long should the grace period be in order to give the ecosystem time t=
o 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 cryptography on their existing hardware with only a firmware updat=
e.
>
> Beyond that, it will take at least 6 months worth of block space for all =
users to migrate their funds, even in a best case scenario. Though if you e=
xclude dust UTXOs you could probably get 95% of BTC value migrated in 1 mon=
th. Of course this is a highly optimistic situation where everyone is compl=
etely focused on migrations - in reality it will take far longer.
>
> Regardless, I'd think that in order to reasonably uphold Bitcoin's conser=
vatism it would be preferable to allow a 4 year migration window. In the me=
antime, mining pools could coordinate emergency soft forking logic such tha=
t if quantum attackers materialized, they could accelerate the countdown to=
 the quantum vulnerable funds burn.
>
> Random Tangential Benefits
> On the plus side, burning all quantum vulnerable bitcoin would allow us t=
o prune all of those UTXOs out of the UTXO set, which would also clean up a=
 lot of dust. Dust UTXOs are a bit of an annoyance and there has even been =
a recent proposal for how to incentivize cleaning them up.
>
> We should also expect that incentivizing migration of the entire UTXO set=
 will create substantial demand for block space that will sustain a fee mar=
ket for a fairly lengthy amount of time.
>
> In Summary
> While the moral quandary of violating any of Bitcoin's inviolable propert=
ies can make this a very complex issue to discuss, the game theory and ince=
ntives between burning vulnerable coins versus allowing them to be claimed =
by entities with quantum supremacy appears to be a much simpler issue.
>
> I, for one, am not interested in rewarding quantum capable entities by in=
flating the circulating money supply just because some people lost their ke=
ys long ago and some laggards are not upgrading their bitcoin wallet's secu=
rity.
>
> We can hope that this scenario never comes to pass, but hope is not a str=
ategy.
>
> 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=
 "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/CADL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.=
com.



--=20
Best regards,
Boris Nagaev

--=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/=
CAFC_Vt54W1RR6GJSSg1tVsLi1%3DYHCQYiTNLxMj%2BvypMtTHcUBQ%40mail.gmail.com.