From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 01:37:00 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wAksi-0004UC-Fx for bitcoindev@gnusha.org; Thu, 09 Apr 2026 01:37:00 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-415e1ea16b4sf1669929fac.1 for ; Thu, 09 Apr 2026 01:36:56 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1775723811; cv=pass; d=google.com; s=arc-20240605; b=MX4LMUoTe7/VjvrxxhEhkzF5vn8xAy7zJN4UY/I7Ofh7+IvsEBOklqiJMxTBbsDhMI 45uyhCwfJcm5F+JZAt2SFjkR7p6jGv+6m/fn4xagVT2UNO1GGDnddZy8HwvHKeYYk8Vl DXnHDerly+6OiEvibBWpMGVkNs1g92wUiNtdQoxOy/+u65Z3to0m/VdcPxCYgg0Or9M6 IhsVxfaynGImJ/Z5mfGVlj4ndQU3Ao4D6yrX3nPFX4DVYXqMoii+86AlyoL6gZjkPwv2 EGOsTmifyeU52wsP+Jg69tHqxJVJP69WDfBsEaAJBmTqFTai9YbF1ylOnZlnCVgpJOy2 Nknw== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=wrIEq48/P/DqK5m6ZAgPIiz50Nhuz/o+0iT0Yyt9aZE=; fh=MqR28e4j2udewTLuB2tVtffz+lr9SGlpoAzqhKaqhio=; b=ePELmIIBYd7ZSh/Y8IKe6MSM6OYMcIOssSNfx12om5F/VPAD9IidTZQb0G+Tgzw1Kv RBv4SOcjVs+bry6eVCxA4k8FE6S0w3Ua+D4rR2TzEHxhjW21WPaBfcXIJI/CiD/rUa6p dQ2F/w+fG/eZ+yN0FxJc/q5KvlBD7BLSKOhGSp+2LAG+PSQRGjmyy9RWdRAsZJKcW7Vw vTjYLFDwyLuv722F1rBGM8MnVM/bkSHWNdC+NG8UFL05qKeMk7toT7JHv9DNWV6xGTg8 4Bk3VRRA0z3NCmMKavfMVCBb/LiX25/66Xrh95iutgG9QcmiXdNYzG0IGDJ9EGKj+SJs 1CJw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=M0Q7i2YF; arc=pass (i=1); spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) smtp.mailfrom=jameson.lopp@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=20251104; t=1775723811; x=1776328611; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=wrIEq48/P/DqK5m6ZAgPIiz50Nhuz/o+0iT0Yyt9aZE=; b=lNGh31LXWWYmK0t8fEZHaDrIgnmVbIMw7F6tAmKwzbNj8Sb+Xec41S531W2mzTBygM s+eUf5v8l1LpwUUSiN38lFbTiQTfcOY6cnAVvXxDW+0yXQaA9ybZyOvGBnkKYHJ6gtqo fYCmMVu+vEZfpqPsRndLmko4r7RVJgE7eI+tD7FHv2n8lfxj73ZQY5b2NEtHHkxVfuXk +XMzSRg6xY2/OdwYEXLGsUkVlV+73hz00UA74Paw3HtO2Kmsoufv8RupbyoI3obAhChj gAjCHpV4FGgsoQZKfWirhV34eb8Ol1YkRJOBTFx5EzayEl66Y43uBt46tTWJllZvRwiD go9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775723811; x=1776328611; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wrIEq48/P/DqK5m6ZAgPIiz50Nhuz/o+0iT0Yyt9aZE=; b=JZTHKJHtndeE0XhJpKWIw6IyIFtwybCviMwAiBjiDRlMlep/Nd08dEhebgUICfkFFy 6XUF2MsEOGaZrI/42Hj1e4zylgQMiJu7ifAB/GeAXOAlkDDCo/X65PuzPoT426H4tVCV ZgNmrGl1c+817rL6Mo4O5GGJ9nStJ+hy48yAMiEgcve3ov+8HAiZW/TLgMvKKxQDwijC nJbeaJho9vgQGWG+u6AXSIwAcsXWC3yA7QWVTOX89g6cNOksBFMo94nfRuUKvJYQycod 5yP5F6LXh7yR8IL9aELp9MBK6spGxfC6ythjw+p/rLY6XfhMjpwQw8d4i40pquGVrUDe OR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775723811; x=1776328611; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=wrIEq48/P/DqK5m6ZAgPIiz50Nhuz/o+0iT0Yyt9aZE=; b=DZT2dJG/YNShsElOHbJhsFNzq2StWUD2H5REFtJ3itganGFZ8vSTkMENZqO0H1FnBB S1DCblP1wgwoGRGQ2ybeA7z5zy9SdnHqJEO/rTSntetsz1jRxXs7qwE7laRDbQKpe3ct +VlNzwsWC/cVzPccMYMrmWcCBK8LBerq7vt2CTH6KyJgEZPphyd8FLBnVsjTK/ZhO/BE S0gSFxAgeSxzVdgiDt/32KoP3sYZIc0TNrBIpQi1xzJ8IEZuexHgQqKBhjAf6eHTAGid FfB1B8tnfSzsg21YhFh5DrwmTJyieA4pwgMA8lffv67+5X3MoEHBpw1vwDNwdMJxVxEz jDAw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCU2ZGLHRaclSY05U71m0gbDfFPnFrcI7igdQNV0qW4kFbhogVhUVISX2l6yWcLTs7HVCYN/WA+RDeDz@gnusha.org X-Gm-Message-State: AOJu0YzwwIZNB0QExjTzLKWbHqbOFCu9caNkQT+ImmDWpkuO3XvFuLNE H7mOFq9k3Pbn0HLitNsGZcmmrSKRhpVI/lKyPSsfGoEqa9wKAwiymlA5 X-Received: by 2002:a05:6870:e97:b0:41b:ff2c:de23 with SMTP id 586e51a60fabf-4230fe72c8cmr12636259fac.10.1775723810654; Thu, 09 Apr 2026 01:36:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLmn2bCBA9jdcq5ncBKRfqoG+G/azZNa+6QyAdGiXZrpA==" Received: by 2002:a05:6870:70a7:b0:41c:65ea:68a1 with SMTP id 586e51a60fabf-422ee040a5dls3927848fac.0.-pod-prod-03-us; Thu, 09 Apr 2026 01:36:45 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUOfZ5F6PwWT+0eawAa1chSz/vz4FhoeyD5XxfXSxjzaF+VT1TFuVgjXh0pARnURSnj5MQ2mtKAua2b@googlegroups.com X-Received: by 2002:a05:6808:67cb:b0:45e:6697:f983 with SMTP id 5614622812f47-46ef57f0296mr12494680b6e.5.1775723805346; Thu, 09 Apr 2026 01:36:45 -0700 (PDT) Received: by 2002:a05:600c:6b0e:b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-488cf0d7085ms5e9; Thu, 9 Apr 2026 00:38:53 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXOAsUk2Fy5bLg9rDsd6qn2k7yWLa8E+qEDRzjVxOLXoFZkOy+WZRLN5SEUSqZVILyuP7R1n6FXBPPD@googlegroups.com X-Received: by 2002:a05:600c:3acb:b0:485:46fd:7887 with SMTP id 5b1f17b1804b1-4889972b76amr335503545e9.13.1775720332000; Thu, 09 Apr 2026 00:38:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775720331; cv=pass; d=google.com; s=arc-20240605; b=GFzd6j0XyT8rhZCdM//yNIpYDAVpFBUS/Oujv3//celSI8qSwe7oRq7aMAxH39VkPT OtMvjl7DAvFWyDnRCbROXYh8FbTOB+tg1LBaBViRPdm+oCqmPpIy4lLRjcx96VHqwAkq LudG0rKMF4uxbZKCA8sBBLarefD+uVBz+Rh1wcF3BMoY4RRyKpaviBdtECFl7T7s0mF2 /HUu0It/XB17L9C2Hfc7pTp88n7ET8d1LdIhTuFo+ofMTrziEOFqcaJZbOIT9pwHTMc0 Eyp2LGM09Cv/uJS3tWrh1kMgeHujQDIaIA4G7FZjnGLlf7oHo1YxX4cYKvWe8prUsSFo uwUA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=QjebwnzHFulYP8PaJPJrmI9aedGSMn9qg3Y6ZvODtNc=; fh=CuxzJ1JryV4tfaL3goRhQNVo0NhV+QkjIZLArE1/r5c=; b=laLK0EH6aKMQKFCmaBsWd253v7juGcm+lPTJXWNyW+HUXfFCGj4wzrn3dgle8JacrQ +sK9Flcp+CZ30V2OA45WcZ9G37F+ecVqrv6yNOwWcJCjEqRnVSyOt2PA1NrOdd9cPiET dDKBL4J9QE0IeAGwz6+qw6znuoH/2VSuDfM3CoDwqWfabCfsO4mGgPz87dWfMmYs+8d2 CqOH7DWAINwQ5NzJwgjert9fnXQAiwrAUcT8J77gz+NcRgB/VajJjyspwjeWSJqqywhK 8nAvs+YWVBPxnidbcr2E3AeEm+aCwwK2dD/UImUYsykjDA5Tf5VkIyasGgTMzL3DNbFs JHIg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=M0Q7i2YF; arc=pass (i=1); spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com. [2a00:1450:4864:20::12b]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-488cd187402si168675e9.3.2026.04.09.00.38.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2026 00:38:51 -0700 (PDT) Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) client-ip=2a00:1450:4864:20::12b; Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5a3af1b7549so737954e87.1 for ; Thu, 09 Apr 2026 00:38:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775720331; cv=none; d=google.com; s=arc-20240605; b=AuLVvWonNhzsL3NAy7dwn7S6/SSilJGUhBmmzOItapdOCIu4vDxuI4kacH9k/BBh2a Eu8pMa7PjShkVsvqJDJiKfWe/wYL1QWvwKEDe2w2PCNJEvPgVflGpsQExeR70t0TvOxw YaPssROSZri4GjAc0MGtSA67uTluJh3Q2gvGGyEIfmsd2vgnyMcCwRRRAD138NRKcY6a pM1csDXcF0i2Tklzz6uZqTa9XrXoi9LIRc5QoGHJC1YJgru6qFaM0pHf7pj63wnmSam+ uPrH5CgS6LQA6i2uKGEDi5YoNRJdxJHT+Wg7KuBEnXJn03HW6P/TYFKCCRBD0IIOAZlr KNiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=QjebwnzHFulYP8PaJPJrmI9aedGSMn9qg3Y6ZvODtNc=; fh=CuxzJ1JryV4tfaL3goRhQNVo0NhV+QkjIZLArE1/r5c=; b=eu2Sb9xlcpIVbDkL/jE1bWyLYxuQrr3tMkr2+3jQ8bnrISOxfVyP+OLVhQgWQmXxsI T3K99rt7/R7VYCJDyPAWOIOTbUEqkMLrUHBCiqX03n9eMOPR7GN4eGsE+OmNDSS47YNX 1gQTzhcXzJz/pniz1N8U5SKpfl4gO37dyfzaE/Lxwy2GnsPwvzhdKIFt2M+BtrssLzRN PV6+CxYNUnPdXAThoiXyLcqsgfe7jln1WjgLzC8RQaCZb2j9EOXjnocyGdMjGhUkucv+ 9R3IGQWy7j6OFL6L+LDizv+mcK4h51HT6MXNS5supqu6yOFrFlHcwT6rq1voVCXnCVkG 4C9A==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCV1SY/q9FlNhQJ4GeFRzFrkzZblkEAxuhUuZClef2+DAomtZp+djYyDylRWaDV1A+1yh4eIZXzIHK1l@googlegroups.com X-Gm-Gg: AeBDietb8jU+BxTHMiXVXJqcsLFl1zAycOU1XVgmmlTnFkpW41cpCkO8zZuOFNhLh8y JuYYviAaw4oXe05AfGbnNxf3iGNGzyF+G/xDOi8J7c/nHEdq2UlVG8ZJRLyclztvac7XiBI7MP+ RKz+DpX1ulrhrQqSoeOdehmqqJaU+iD5EMUTULbyilRPneSfEExp+KkaNcm+COjjasG296vieNj y4xLQQmhYa6gsK5zCKB+nMkYuLrqZC843rs7ikd4xP+IBU8ytEoX7pWyzraAMPaj1QJ9F03Tm/m 1BtpOTbgHdXByIiU0I/o2C7O71/1ZlQ1SnzEn0XwuDmWt+yJ9ELhvDyUt+UlJt2H9hFJfGahcqY z/cGS1nO2a5MRyEbdh20j2wKX X-Received: by 2002:a05:6512:3049:b0:5a2:793d:ce6 with SMTP id 2adb3069b0e04-5a3375852b9mr7376369e87.32.1775720330453; Thu, 09 Apr 2026 00:38:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jameson Lopp Date: Thu, 9 Apr 2026 09:38:38 +0200 X-Gm-Features: AQROBzD1ojf47VpSERbA5MlamGjzJq35bpfBfCpdlNeLBuNxj4HxkeHg8yjqLzg Message-ID: Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin To: Bitcoin Cc: Nadav Ivgi , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000846a24064f021bcc" X-Original-Sender: jameson.lopp@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=M0Q7i2YF; arc=pass (i=1); spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) smtp.mailfrom=jameson.lopp@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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 0.0 (/) --000000000000846a24064f021bcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Scratch that; nodes should already be storing the block for which a UTXO was confirmed in order to calculate relative timelock validity. So it should be implementable. Still, there are several vague statements that could use more explanation. "predictable cliffs invite adversarial behavior." - such as? "This avoids retroactively invalidating old transactions while still phasing out insecure constructions." - how so? If you chose a relative max age that's less than the total age of Bitcoin itself, it will by default invalidate extremely old UTXOs. "If the protocol begins to distinguish between =E2=80=9Clegitimate=E2=80=9D= and =E2=80=9Cquantum=E2=80=91recovered=E2=80=9D spends" - not sure what this me= ans. It's not possible to know if a transaction was made by a quantum attacker. On Thu, Apr 9, 2026 at 9:04=E2=80=AFAM Jameson Lopp wrote: > While an implied age timelock is interesting in theory, I don't think it'= s > practical in reality. > > The reason that current styles of timelocks work well is because they are > explicit: the actual block height / timestamp of the lock is contained > somewhere inside of the transaction itself. > > In order to implement an "implied" scheme as you propose, it would requir= e > all nodes to start indexing UTXOs by block height in order to avoid a > massive performance drop when evaluating whether or not the UTXO is > spendable. > > On Thu, Apr 9, 2026 at 3:01=E2=80=AFAM Bitcoin w= rote: > >> The protocol should not assume that future participants will be able to >> coordinate around a single deadline without distortion. A fixed height a= t >> which old outputs become invalid would create a predictable cliff, and >> predictable cliffs invite adversarial behavior. Markets tend to rush tow= ard >> the edge. >> >> Bitcoin works best when incentives are continuous rather than abrupt. >> >> A staggered expiration of vulnerable script types is more consistent wit= h >> the system=E2=80=99s long=E2=80=91term stability. If a class of outputs = is known to be weak >> against new computation, then the network can define a rule that such >> outputs must be spent within a certain number of blocks after creation. >> This avoids retroactively invalidating old transactions while still phas= ing >> out insecure constructions. >> >> The network already treats some script forms as discouraged. Extending >> this to prohibit creation of new vulnerable forms is a natural evolution= . >> Nodes can continue to validate the old chain history while refusing to >> relay or mine new transactions that expose public keys directly. >> >> The idea of forcing quantum=E2=80=91recovered coins into long timelocks = is >> interesting, but it introduces a new class of special=E2=80=91case behav= ior. >> Bitcoin=E2=80=99s rules should be simple, general, and predictable. If t= he protocol >> begins to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2=80=9C= quantum=E2=80=91recovered=E2=80=9D spends, >> it implies an authority deciding which coins are morally valid. That is = a >> precedent the system should avoid. >> >> The safest rule is the one that does not require judging intent. >> >> A relative or absolute timelock applied uniformly to all vulnerable >> outputs, triggered only by their age, is neutral. It does not ask who is >> spending the coins or why. It only enforces that insecure forms must be >> migrated in time. >> >> The network cannot prevent advances in mathematics or computation. It ca= n >> only ensure that the incentives remain aligned so that users upgrade the= ir >> security before adversaries can exploit weaknesses. The protocol should >> encourage timely movement without confiscation. >> >> The principle remains: >> >> Your keys, your coins =E2=80=94 but only as long as the key is strong. >> >> If a key type becomes weak, the system must give ample time to move fund= s >> to stronger constructions, and then retire the weak form gradually so th= e >> chain does not become a liability. >> >> =E2=80=94 S. >> >> On Mon, Apr 7, 2025, 6:34=E2=80=AFAM Nadav Ivgi wrot= e: >> >>> One possible alternative to freezing/burning the coins entirely is >>> letting quantum attackers keep some small percent as a reward, but forc= e >>> them to stage the rest to future miners as an additional security budge= t >>> subsidy. >>> >>> This can be implemented as a soft fork, by requiring transactions >>> spending QC-vulnerable coins to allocate some funds to an OP_CLTV[0]-on= ly >>> encumbered output timelocked far into the future. Miners would then mon= itor >>> these outputs and claim them as they become available. >>> >>> For example, allow a 1% reward to be spent freely to any address but >>> require 99% to be sent to an OP_CLTV output timelocked to a >>> deterministically random height between 10-100 years from now. >>> >>> The 1% reward could also be required to be sent to a script that >>> enforces a timelock (in addition to other conditions), to avoid floodin= g >>> the markets with the rewarded coins all at once. Probably a shorter >>> timelock duration though, say picked randomly between 10-30 months. >>> >>> To further smooth out variance in the release schedule, coins could be >>> split into up-to-N-BTC outputs, each staggered with a different >>> deterministic timelock. So for example, a single tx spending 10,000 BTC >>> won't release 9,900 BTC to the miners in a single far-future block (whi= ch >>> may cause chain instability if the miners get into a reorg war over it)= , >>> but rather as 9,900 separate outputs of 1 BTC each released gradually >>> time.[1] >>> >>> I'm still not sure what I think about this. This is not necessarily an >>> endorsement, just a thought. :) >>> >>> - shesek >>> >>> [0] OP_CSV only supports relative timelocks of up to 65535 blocks (~15 >>> months), which is too short for that purpose. OP_CLTV supports longer >>> (absolute) timelocks. >>> >>> [1] This can be made more efficient with CTV, by having a single UTXO >>> carrying the full amount that slowly unrolls rather than 9,900 separate >>> UTXO entries. >>> >>> >>> On Sun, Mar 16, 2025 at 5:22=E2=80=AFPM Jameson Lopp >>> wrote: >>> >>>> The quantum computing debate is heating up. There are many >>>> controversial aspects to this debate, including whether or not quantum >>>> computers will ever 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 >>>> difficulty in changing Bitcoin it's worth starting to seriously discus= s. >>>> Today I wish to focus on a philosophical quandary related to one of th= e >>>> decisions that would need to be made if and when we implement a quantu= m >>>> safe signature scheme. >>>> >>>> Several Scenarios >>>> Because this essay will reference game theory a fair amount, and there >>>> are many variables at play that could change the nature of the game, I >>>> think it's important to clarify the 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 scen= ario >>>> it would likely make the points below moot because Bitcoin would be >>>> fundamentally broken and it would take far too long to upgrade the >>>> protocol, wallet software, and migrate user funds in order to restore >>>> confidence in the network. >>>> 3. Quantum computing advances slowly enough that we come to consensus >>>> about how to upgrade Bitcoin and post quantum security has been minima= lly >>>> adopted by the time an attacker appears. >>>> 4. Quantum computing advances slowly enough that we come to consensus >>>> about 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 >>>> contentious aspect of how a quantum resistance upgrade should be handl= ed in >>>> terms of migrating user funds. Should quantum vulnerable funds be left= open >>>> to be swept by anyone with a sufficiently powerful quantum computer OR >>>> should they be permanently locked? >>>> >>>> "I don't see why old coins should be confiscated. The better option is >>>>> to let those with quantum computers free up old coins. While this mig= ht >>>>> have an inflationary impact on bitcoin's price, to use a turn of phra= se, >>>>> the inflation is transitory. Those with low time preference should su= pport >>>>> returning 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 th= reat, >>>>> the Bitcoin ecosystem has no other option than softforking out the ab= ility >>>>> to spend from signature schemes (including ECDSA and BIP340) that are >>>>> vulnerable to QCs. The alternative is that millions of BTC become >>>>> vulnerable to theft; I cannot see how the currency can maintain any v= alue >>>>> 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 >>>> funds 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. >>>> However, if quantum computing becomes a threat to Bitcoin's elliptic c= urve >>>> cryptography, *an inviolable property of Bitcoin will be violated one >>>> way or another*. >>>> >>>> Fundamental Properties at Risk >>>> 5 years ago I attempted to comprehensively categorize all of Bitcoin's >>>> fundamental properties that give it value. >>>> https://nakamoto.com/what-are-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 from using their bitcoin or interacting with the network. >>>> >>>> *Forward Compatibility* - changing the rules such that certain valid >>>> transactions become invalid could undermine confidence in the protocol= . >>>> >>>> *Conservatism* - Users should not be expected to be highly responsive >>>> to system issues. >>>> >>>> As a result of the above principles, we have developed a strong meme >>>> (kudos to Andreas Antonopoulos) that goes as follows: >>>> >>>> Not your keys, not your coins. >>>> >>>> >>>> I posit that the corollary to this principle is: >>>> >>>> Your keys, only your coins. >>>> >>>> >>>> A quantum capable entity breaks the corollary of this foundational >>>> principle. We secure our bitcoin with the mathematical probabilities >>>> related to extremely large random numbers. Your funds are only secure >>>> because truly random large numbers should not be guessable or discover= able >>>> by anyone else in the world. >>>> >>>> This is the principle behind the motto *vires in numeris* - strength >>>> in numbers. In a world with quantum enabled adversaries, this principl= e is >>>> null and void for many types of cryptography, including the elliptic c= urve >>>> digital 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 quan= tum >>>> "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 ri= ch >>>> list and find the wallets that have exposed their public keys due to >>>> re-using addresses that have previously been spent from. You can easil= y >>>> find them at >>>> https://bitinfocharts.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. S= o a >>>> quantum attacker would need to reverse engineer 2 keys for Kraken or 3= for >>>> Bitfinex / Tether in order to spend funds. But many are single signatu= re. >>>> >>>> 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 so= me of >>>> the first to upgrade given their incentives. >>>> >>>> The Ethical Dilemma: Quantifying Harm >>>> Which decision results in the most harm? >>>> >>>> By making quantum vulnerable funds unspendable we potentially harm som= e >>>> Bitcoin users who were not paying attention and neglected to migrate t= heir >>>> funds to a quantum safe locking script. This violates the "conservativ= ism" >>>> principle stated earlier. On the flip side, we prevent those funds plu= s far >>>> more lost funds from falling into the hands of the few privileged folk= s who >>>> gain early access to quantum computers. >>>> >>>> By leaving quantum vulnerable funds available to spend, the same set o= f >>>> users who would otherwise have funds frozen are likely to see them sto= len. >>>> And many early adopters who lost their keys will eventually see their >>>> unreachable 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 >>>> spent a decade trying to retrieve it from the landfill where he knows = it's >>>> buried, but can't get permission to excavate. I suspect that, given th= e >>>> choice, he'd prefer those funds be permanently frozen rather than fall= into >>>> someone else's possession - I know I would. >>>> >>>> Allowing a quantum computer to access lost funds doesn't make those >>>> users any worse off than they were before, however it *would* have a >>>> negative impact upon everyone who is currently holding bitcoin. >>>> >>>> It's prudent to expect significant economic disruption if large amount= s >>>> of coins fall into new hands. Since a quantum computer is going to hav= e a >>>> massive up front cost, expect those behind it to desire to recoup thei= r >>>> investment. We also know from experience that when someone suddenly fi= nds >>>> themselves in possession of 9+ figures worth of highly liquid assets, = they >>>> tend to diversify into other things by selling. >>>> >>>> Allowing quantum recovery of bitcoin is *tantamount to wealth >>>> redistribution*. What we'd be allowing is for bitcoin to be >>>> redistributed from those who are ignorant of quantum computers to thos= e who >>>> have won the technological race to acquire quantum computers. It's har= d to >>>> see a bright side to that scenario. >>>> >>>> Is Quantum Recovery Good for Anyone? >>>> >>>> Does quantum recovery HELP anyone? I've yet to come across an argument >>>> that it's a net positive in any way. It certainly doesn't add any secu= rity >>>> 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 >>>> their coins by all the work and resources invested in building a quant= um >>>> computer? I suppose, in the same sense that a burglar earns their spoi= ls by >>>> the resources they invest into surveilling targets and learning the sk= ills >>>> needed to break into buildings. What I say "earned" I mean through >>>> productive mutual trade. >>>> >>>> For example: >>>> >>>> * Investors earn BTC by trading for other currencies. >>>> * Merchants earn BTC by trading for goods and services. >>>> * Miners earn BTC by trading 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 larges= t >>>> tech companies. >>>> >>>> One could certainly hope that an organization with quantum supremacy i= s >>>> benevolent and acts in a "white hat" manner to return lost coins to th= eir >>>> owners, but that's incredibly optimistic and foolish to rely upon. Suc= h a >>>> situation creates an insurmountable ethical dilemma of only recovering= lost >>>> bitcoin rather than currently owned bitcoin. There's no way to precise= ly >>>> differentiate between the two; anyone can claim to have lost their bit= coin >>>> but if they have lost their keys then proving they ever had the keys >>>> becomes rather difficult. I imagine that any such white hat recovery >>>> efforts would have to rely upon attestations from trusted third partie= s >>>> like exchanges. >>>> >>>> Even if the first actor with quantum supremacy is benevolent, we must >>>> assume the technology could fall into adversarial hands and thus think >>>> adversarially about the potential worst case outcomes. Imagine, for >>>> example, that North Korea continues scooping up billions of dollars fr= om >>>> hacking crypto exchanges and decides to invest some of those proceeds = into >>>> building a quantum computer for the biggest payday ever... >>>> >>>> Downsides to Allowing Quantum Recovery >>>> Let's think through an exhaustive list of pros and cons for allowing o= r >>>> preventing the seizure of funds by a quantum adversary. >>>> >>>> Historical Precedent >>>> Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair = game" but >>>> rather were treated as failures to be remediated. Treating quantum the= ft >>>> differently risks rewriting Bitcoin=E2=80=99s history as a free-for-al= l rather than >>>> a system that seeks to protect its users. >>>> >>>> Violation of Property Rights >>>> Allowing a quantum adversary to take control of funds undermines the >>>> fundamental principle of cryptocurrency - if you keep your keys in you= r >>>> possession, only you should be able to access your money. Bitcoin is b= uilt >>>> on the idea that private keys secure an individual=E2=80=99s assets, a= nd >>>> unauthorized access (even via advanced tech) is theft, not a legitimat= e >>>> transfer. >>>> >>>> Erosion of Trust in Bitcoin >>>> If quantum attackers can exploit vulnerable addresses, confidence in >>>> Bitcoin as a secure store of value would collapse. Users and investors= rely >>>> on cryptographic integrity, and widespread theft could drive adoption = away >>>> from Bitcoin, destabilizing its ecosystem. >>>> >>>> This is essentially the counterpoint to claiming the burning of >>>> vulnerable funds is a violation of property rights. While some will >>>> certainly see it as such, others will find the apathy toward stopping >>>> quantum theft to be similarly concerning. >>>> >>>> Unfair Advantage >>>> Quantum attackers, likely equipped with rare and expensive technology, >>>> would have an unjust edge over regular users who lack access to such t= ools. >>>> This creates an inequitable system where only the technologically elit= e can >>>> exploit others, contradicting Bitcoin=E2=80=99s ethos of decentralized= power. >>>> >>>> Bitcoin is designed to create an asymmetric advantage for DEFENDING >>>> one's wealth. It's supposed to be impractically expensive for attacker= s to >>>> crack the entropy and cryptography protecting one's coins. But now we = find >>>> ourselves discussing a situation where this asymmetric advantage is >>>> compromised in favor of a specific class of attackers. >>>> >>>> Economic Disruption >>>> Large-scale theft from vulnerable addresses could crash Bitcoin=E2=80= =99s price >>>> as quantum recovered funds are dumped on exchanges. This would harm al= l >>>> holders, not just those directly targeted, leading to broader financia= l >>>> chaos in the markets. >>>> >>>> Moral Responsibility >>>> Permitting theft via quantum computing sets a precedent that >>>> technological superiority justifies unethical behavior. This is essent= ially >>>> taking a "code is law" stance in which we refuse to admit that both co= de >>>> and laws can be modified to adapt to previously unforeseen situations. >>>> >>>> Burning of coins can certainly be considered a form of theft, thus I >>>> think it's worth differentiating the two different thefts being discus= sed: >>>> >>>> 1. self-enriching & likely malicious >>>> 2. harm prevention & not necessarily malicious >>>> >>>> Both options lack the consent of the party whose coins are being burnt >>>> or transferred, thus I think the simple argument that theft is immoral >>>> becomes a wash and it's important to drill down into the details of ea= ch. >>>> >>>> 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 an= d >>>> strengthens Bitcoin long-term. Allowing vulnerable users to delay upgr= ading >>>> indefinitely will result in more laggards, leaving the network more ex= posed >>>> when quantum tech becomes available. >>>> >>>> Steel Manning >>>> Clearly this is a complex and controversial topic, thus it's worth >>>> thinking through the opposing arguments. >>>> >>>> Protecting Property Rights >>>> Allowing quantum computers to take vulnerable bitcoin could potentiall= y >>>> be spun as a hard money narrative - we care so greatly about not viola= ting >>>> someone'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 >>>> burning vulnerable coins prevents said property from falling into >>>> undeserving hands. If the entire Bitcoin ecosystem just stands around = and >>>> allows quantum adversaries to claim funds that rightfully belong to ot= her >>>> users, is that really a "win" in the "protecting property rights" cate= gory? >>>> It feels more like apathy to me. >>>> >>>> As such, I think the "protecting property rights" argument is a wash. >>>> >>>> Quantum Computers Won't Attack Bitcoin >>>> There is a great deal of skepticism that sufficiently powerful quantum >>>> computers will ever exist, so we shouldn't bother preparing for a >>>> non-existent threat. Others have argued that even if such a computer w= as >>>> built, a quantum attacker would not go after bitcoin because they woul= dn't >>>> want to reveal their hand by doing so, and would instead attack other >>>> infrastructure. >>>> >>>> It's quite difficult to quantify exactly how valuable attacking other >>>> infrastructure would be. It also really depends upon when an entity ga= ins >>>> quantum supremacy and thus if by that time most of the world's systems= have >>>> already been upgraded. While I think you could argue that certain enti= ties >>>> gaining quantum capability might not attack Bitcoin, it would only del= ay >>>> the inevitable - eventually somebody will achieve the capability who >>>> decides to use it for such an attack. >>>> >>>> Quantum Attackers Would Only Steal Small Amounts >>>> Some have argued that even if a quantum attacker 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 class= ic >>>> "zero day exploit" game theory in which an attacker knows they have a >>>> limited amount of time before someone else discovers the exploit and e= ither >>>> benefits from it or patches it. Take, for example, the recent ByBit at= tack >>>> - the highest value crypto hack of all time. Lazarus Group had comprom= ised >>>> the Safe wallet front end JavaScript app and they could have simply ha= d it >>>> reassign ownership of everyone's Safe wallets as they were interacting= with >>>> their wallet. 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 discovered quickly and the Safe web app would likely h= ave >>>> been patched well before any billion dollar wallets executed the malic= ious >>>> code. >>>> >>>> I think the "only stealing small amounts" argument is strongest for >>>> Situation #2 described earlier, where a quantum attacker arrives befor= e >>>> quantum safe cryptography has been deployed across the Bitcoin ecosyst= em. >>>> Because if it became clear that Bitcoin's cryptography was broken AND = there >>>> was nowhere safe for vulnerable users to migrate, the only logical opt= ion >>>> would be for everyone to liquidate their bitcoin as quickly as possibl= e. As >>>> such, I don't think it applies as strongly for situations in which we = have >>>> a migration path available. >>>> >>>> The 21 Million Coin Supply Should be in Circulation >>>> Some folks are arguing that it's important for the "circulating / >>>> spendable" supply to be as close to 21M as possible and that having a >>>> significant portion of the supply out of circulation is somehow undesi= rable. >>>> >>>> While the "21M BTC" attribute is a strong memetic narrative, I don't >>>> think anyone has ever expected that it would all be in circulation. It= has >>>> always been understood that many coins will be lost, and that's actual= ly >>>> part of the game theory of owning bitcoin! >>>> >>>> And remember, the 21M number in and of itself is not a particularly >>>> important detail - it's not even mentioned in the whitepaper. What's >>>> important is that the supply is well known and not subject to change. >>>> >>>> Self-Sovereignty and Personal Responsibility >>>> Bitcoin=E2=80=99s design empowers individuals to control their own wea= lth, free >>>> from centralized intervention. This freedom comes with the burden of >>>> securing one's private keys. If quantum computing can break obsolete >>>> cryptography, the fault lies with users who didn't move their funds to >>>> quantum safe locking scripts. Expecting the network to shield users fr= om >>>> their own negligence undermines the principle that you, and not a thir= d >>>> party, are accountable for your assets. >>>> >>>> I think this is generally a fair point that "the community" doesn't ow= e >>>> you anything in terms of helping you. I think that we do, however, nee= d to >>>> consider 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 pri= vate >>>> keys from public keys, they=E2=80=99re not "hacking" the system - they= 're simply >>>> following what's mathematically permissible within the current code. >>>> Altering the protocol to stop this introduces subjective human >>>> intervention, which clashes with the objective, deterministic nature o= f >>>> 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. Leaning on this point seems more like a pro-ossification stance = that >>>> it's better to do nothing and allow harm to occur rather than take act= ion >>>> to stop an attack that was foreseen far in advance. >>>> >>>> Technological Evolution as a Feature, Not a Bug >>>> It's well known that cryptography tends to weaken over time and >>>> eventually break. Quantum computing is just the next step in this >>>> progression. Users who fail to adapt (e.g., by adopting quantum-resist= ant >>>> wallets when available) are akin to those who ignored technological >>>> advancements like multisig or hardware wallets. Allowing quantum theft >>>> incentivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic,= punishing >>>> complacency while rewarding 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 >>>> accelerates the adoption of post-quantum cryptography and strengthens >>>> Bitcoin long-term. Coddling vulnerable users delays this necessary >>>> evolution, potentially leaving the network more exposed when quantum t= ech >>>> becomes widely accessible. Theft is a brutal but effective teacher. >>>> >>>> Centralized Blacklisting Power >>>> Burning vulnerable funds requires centralized decision-making - a soft >>>> fork to invalidate certain transactions. This sets a dangerous precede= nt >>>> for future interventions, eroding Bitcoin=E2=80=99s decentralization. = If quantum >>>> theft is blocked, what=E2=80=99s next - reversing exchange hacks? The = system must >>>> remain neutral, even if it means some lose out. >>>> >>>> I think this could be a potential slippery slope if the proposal was t= o >>>> only burn specific addresses. Rather, I'd expect a neutral proposal to= burn >>>> all funds in locking script types that are known to be quantum vulnera= ble. >>>> Thus, we could eliminate any subjectivity from the code. >>>> >>>> Fairness in Competition >>>> Quantum attackers aren't cheating; they're using publicly available >>>> physics and math. Anyone with the resources and foresight can build or >>>> access quantum tech, just as anyone could mine Bitcoin in 2009 with a = CPU. >>>> Early adopters took risks and reaped rewards; quantum innovators are d= oing >>>> the same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin has= never promised >>>> equality of outcome - only equality of opportunity within its rules. >>>> >>>> I find this argument to be a mischaracterization because we're not >>>> talking about CPUs. This is more akin to talking about ASICs, except e= ach >>>> ASIC costs millions if not billions of dollars. This is out of reach f= rom >>>> all but the wealthiest organizations. >>>> >>>> Economic Resilience >>>> Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and >>>> emerged stronger. The market can absorb quantum losses, with unaffecte= d >>>> users continuing to hold and new entrants buying in at lower prices. F= ear >>>> of economic 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 >>>> will come online and we don't know how quickly said computers would be= able >>>> to steal bitcoin. If, for example, the first generation of sufficientl= y >>>> powerful quantum computers were stealing less volume than the current = block >>>> reward then of course it will have minimal economic impact. But if the= y're >>>> taking thousands of BTC per day and bringing them back into circulatio= n, >>>> 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 suppo= rt >>>> quantum resistant 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 2010. 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 would 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 addresses with less and less BT= C. >>>> >>>> Why is economic impact a factor worth considering? Miners and >>>> businesses in general. More coins being liquidated will push down the >>>> price, which will negatively impact miner revenue. Similarly, I can at= test >>>> from working in the industry for a decade, that lower prices result in= less >>>> demand from businesses across the entire industry. As such, burning qu= antum >>>> vulnerable bitcoin is good for the entire industry. >>>> >>>> Practicality & Neutrality of Non-Intervention >>>> There=E2=80=99s no reliable way to distinguish =E2=80=9Ctheft=E2=80=9D= from legitimate "white >>>> hat" key recovery. If someone loses their private key and a quantum >>>> computer recovers it, is that stealing or reclaiming? Policing quantum >>>> actions requires invasive assumptions about intent, which Bitcoin=E2= =80=99s >>>> trustless design can=E2=80=99t accommodate. Letting the chips fall whe= re they may >>>> avoids this mess. >>>> >>>> Philosophical Purity >>>> Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system where outco= mes >>>> reflect preparation and skill, not sentimentality. If quantum computin= g >>>> upends the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t mean= t 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 ignorance, 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 beca= use >>>> it's a situation where a threat is known but there's some period of ti= me >>>> before the attacker can actually execute the theft. As such, there's t= ime >>>> to mitigate the attack by changing the protocol. >>>> >>>> It also created a schism in the community around the true meaning of >>>> "code is law," resulting in Ethereum Classic, which decided to allow t= he >>>> attacker to retain control of the stolen funds. >>>> >>>> A soft fork to burn vulnerable bitcoin could certainly result in a har= d >>>> fork if there are enough miners who reject the soft fork and continue >>>> including transactions. >>>> >>>> Incentives Matter >>>> We can wax philosophical until the cows come home, but what are the >>>> actual incentives for existing Bitcoin holders regarding this decision= ? >>>> >>>> "Lost coins only make everyone else's coins worth slightly more. Think >>>>> of it as a donation to everyone." - Satoshi Nakamoto >>>> >>>> >>>> If true, the corollary is: >>>> >>>> "Quantum recovered coins only make everyone else's coins worth less. >>>>> Think of it as a theft from everyone." - Jameson Lopp >>>> >>>> >>>> Thus, assuming we get to a point where quantum resistant signatures ar= e >>>> supported within the Bitcoin protocol, what's the incentive to let >>>> vulnerable 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 >>>> balloon will assuredly reduce the purchasing power of all bitcoin hold= ers. >>>> >>>> Forking Game Theory >>>> From a game theory point of view, I see this as incentivizing users to >>>> upgrade their wallets. If you disagree with the burning of vulnerable >>>> coins, all you have to do is move your funds to a quantum safe signatu= re >>>> scheme. Point 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 significant resources fighting a fork when you can just move yo= ur >>>> coins to a new 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 meaning= fully >>>> enacted and enforced by a mere majority of hashpower. If miners genera= lly >>>> agree that it's in their best interest to burn vulnerable coins, are o= ther >>>> users going to care enough to put in the effort to run new node softwa= re >>>> 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 n= odes >>>> will no longer accept transactions (or blocks containing such transact= ions) >>>> that spend funds from any scripts other than the newly instituted quan= tum >>>> safe schemes. >>>> >>>> It could take a staggered approach to first freeze funds that are >>>> susceptible to long-range attacks such as those in P2PK scripts or tho= se >>>> that exposed their public keys due to previously re-using addresses, b= ut I >>>> expect the additional complexity would drive further controversy. >>>> >>>> How long should the grace period be in order to give the ecosystem tim= e >>>> to upgrade? I'd say a minimum of 1 year for software wallets to upgrad= e. We >>>> can only hope that hardware wallet manufacturers are able to implement= post >>>> quantum cryptography on their existing hardware with only a firmware u= pdate. >>>> >>>> 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 exclude dust UTXOs you could probably get 95% of BTC value migrate= d in >>>> 1 month. Of course this is a highly optimistic situation where everyon= e is >>>> completely focused on migrations - in reality it will take far longer. >>>> >>>> Regardless, I'd think that in order to reasonably uphold Bitcoin's >>>> conservatism it would be preferable to allow a 4 year migration window= . In >>>> the meantime, mining pools could coordinate emergency soft forking log= ic >>>> such that 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 u= s >>>> to prune all of those UTXOs out of the UTXO set, which would also clea= n 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 >>>> market for a fairly lengthy amount of time. >>>> >>>> In Summary >>>> While the moral quandary of violating any of Bitcoin's inviolable >>>> properties can make this a very complex issue to discuss, the game the= ory >>>> and incentives between burning vulnerable coins versus allowing them t= o be >>>> claimed by entities with quantum supremacy appears to be a much simple= r >>>> issue. >>>> >>>> I, for one, am not interested in rewarding quantum capable entities by >>>> inflating the circulating money supply just because some people lost t= heir >>>> keys long ago and some laggards are not upgrading their bitcoin wallet= 's >>>> security. >>>> >>>> We can hope that this scenario never comes to pass, but hope is not a >>>> strategy. >>>> >>>> I welcome your feedback upon any of the above points, and contribution >>>> of any arguments I failed to consider. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "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/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq= 8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com >>>> >>>> . >>>> >>> -- >>> 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/bitcoindev/CAGXD5f1eTwqMAkxzdJOup3syR= %2B5UjrkAaHroBJT0HQw5FA2_YQ%40mail.gmail.com >>> >>> . >>> >> --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CADL_X_cucGigAjw2ramxAyHf45SBcStGVvixJ7O%3D3kSfk1xEVA%40mail.gmail.com. --000000000000846a24064f021bcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scratch that; nodes should already be storing the block fo= r which a UTXO was confirmed in order to calculate relative timelock validi= ty. So it should be implementable.

Still, there are several vague st= atements that could use more explanation.

"predictable cliffs i= nvite adversarial behavior." - such as?

"This avoids retro= actively invalidating old transactions while still phasing out insecure con= structions." - how so? If you chose a relative max age that's less= than the total age of Bitcoin itself, it will by default invalidate extrem= ely old UTXOs.

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

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

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

In order t= o implement an "implied" scheme as you propose, it would require = all nodes to start indexing UTXOs by block height in order to avoid a massi= ve performance drop when evaluating whether or not the UTXO is spendable.
On= Thu, Apr 9, 2026 at 3:01=E2=80=AFAM Bitcoin <loveloyal420@gmail.com> wrote:
=
T= he protocol should not assume that future participants will be able to coor= dinate around a single deadline without distortion. A fixed height at which= old outputs become invalid would create a predictable cliff, and predictab= le cliffs invite adversarial behavior. Markets tend to rush toward the edge= .

Bitcoin works best when ince= ntives are continuous rather than abrupt.

=
A staggered expiration of vulnerable script types is more= consistent with the system=E2=80=99s long=E2=80=91term stability. If a cla= ss of outputs is known to be weak against new computation, then the network= can define a rule that such outputs must be spent within a certain number = of blocks after creation. This avoids retroactively invalidating old transa= ctions while still phasing out insecure constructions.

The network already treats some script forms= as discouraged. Extending this to prohibit creation of new vulnerable form= s is a natural evolution. Nodes can continue to validate the old chain hist= ory while refusing to relay or mine new transactions that expose public key= s directly.

The idea of = forcing quantum=E2=80=91recovered coins into long timelocks is interesting,= but it introduces a new class of special=E2=80=91case behavior. Bitcoin=E2= =80=99s rules should be simple, general, and predictable. If the protocol b= egins to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2=80=9Cquan= tum=E2=80=91recovered=E2=80=9D spends, it implies an authority deciding whi= ch coins are morally valid. That is a precedent the system should avoid.

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

A relative or absolute timelock applied uniformly to all vul= nerable outputs, triggered only by their age, is neutral. It does not ask w= ho is spending the coins or why. It only enforces that insecure forms must = be migrated in time.

The= network cannot prevent advances in mathematics or computation. It can only= ensure that the incentives remain aligned so that users upgrade their secu= rity before adversaries can exploit weaknesses. The protocol should encoura= ge timely movement without confiscation.

<= div dir=3D"auto">The principle remains:

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

If a key typ= e becomes weak, the system must give ample time to move funds to stronger c= onstructions, and then retire the weak form gradually so the chain does not= become a liability.

=E2= =80=94 S.

On Mon, Apr 7, 2025, 6:34=E2=80=AFAM Nadav Ivgi <nadav@shesek.info> w= rote:
One possible alternative to freezing/burning= the coins entirely is letting quantum attackers keep some small percent as= a reward, but force them to stage the rest to future miners as an addition= al security budget subsidy.

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

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

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

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

- sh= esek

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

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


On Sun, Mar 16, 2025 at 5:22=E2=80=AFPM Jameson Lopp <jameson.lopp@gmail.com> wrote:
The quantum computing debate is he= ating up. There are many controversial aspects to this debate, including wh= ether or not quantum computers will ever actually become a practical threat= .

I won't tread into the unanswerable question of how worried w= e should be about quantum computers. I think it's far from a crisis, bu= t given the difficulty in changing Bitcoin it's worth starting to serio= usly 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 signature scheme.

Several ScenariosBecause this essay will reference game theory a fair amount, and th= ere are 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 threa= t materializes suddenly and Bitcoin does not have quantum safe signatures a= s part of the protocol. In this scenario it would likely make the points be= low moot because Bitcoin would be fundamentally broken and it would take fa= r too long to upgrade the protocol, wallet software, and migrate user funds= in order to restore confidence in the network.
3. Quantum computing adv= ances slowly enough that we come to consensus about how to upgrade Bitcoin = and post quantum security has been minimally adopted by the time an attacke= r appears.
4. Quantum computing advances slowly enough that we come to c= onsensus about how to upgrade Bitcoin and post quantum security has been hi= ghly adopted by the time an attacker appears.

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

To Freeze or not to Freeze?
I've started seeing more p= eople weighing in on what is likely the most contentious aspect of how a qu= antum resistance upgrade should be handled in terms of migrating user funds= . Should quantum vulnerable funds be left open to be swept by anyone with a= sufficiently powerful quantum computer OR should they be permanently locke= d?

"I don'= ;t see why old coins should be confiscated. The better option is to let tho= se with quantum computers free up old coins. While this might have an infla= tionary impact on bitcoin's price, to use a turn of phrase, the inflati= on is transitory. Those with low time preference should support returning l= ost coins to circulation."=C2=A0
- Hunter Beast

On the o= ther 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 thre= at, the Bitcoin ecosystem has no other option than softforking out the abil= ity to spend from signature schemes (including ECDSA and BIP340) that are v= ulnerable to QCs. The alternative is that millions of BTC become vulnerable= to theft; I cannot see how the currency can maintain any value at all in s= uch 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 funds are not being seized and reassigned. Rather, what we'= ;re really discussing would be better described as "burning" - pl= acing the funds out of reach of everyone.

Not freezing user f= unds is one of Bitcoin's inviolable properties. However, if quantum com= puting becomes a threat to Bitcoin's elliptic curve cryptography, an= inviolable property of Bitcoin will be violated one way or another.
Fundamental Properties at Risk
5 years ago = I attempted to comprehensively categorize all of Bitcoin's fundamental = properties that give it value. https://n= akamoto.com/what-are-the-key-properties-of-bitcoin/

The particul= ar properties in play with regard to this issue seem to be:

Censo= rship Resistance - No one should have the power to prevent others from = using their bitcoin or interacting with the network.

Forward Comp= atibility - changing the rules such that certain valid transactions bec= ome invalid could undermine confidence in the protocol.

Conservat= ism - Users should not be expected to be highly responsive to system is= sues.

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

Not your keys, not your coins.
I posit that the corollary to this principle is:

Your keys, only your coins.
A quantum capable entity breaks the corollary of this founda= tional principle. We secure our bitcoin with the mathematical probabilities= related to extremely large random numbers. Your funds are only secure beca= use truly random large numbers should not be guessable or discoverable by a= nyone else in the world.

This is the principle behind the motto v= ires in numeris - strength in numbers. In a world with quantum enabled = adversaries, this principle is null and void for many types of cryptography= , including the elliptic curve digital signatures used in Bitcoin.

<= font size=3D"6">Who is at Risk?
There has long been a narrative t= hat Satoshi's coins and others from the Satoshi era of P2PK locking scr= ipts that exposed the public key directly on the blockchain will be those t= hat 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 wallets that ha= ve exposed their public keys due to re-using addresses that have previously= been spent from. You can easily find them at https://bitinfocharts.com/top-100-richest-bitcoin-addresses.htm= l

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

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

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

By making quantum vulnerable funds unspendable we pote= ntially harm some Bitcoin users who were not paying attention and neglected= to migrate their funds to a quantum safe locking script. This violates the= "conservativism" principle stated earlier. On the flip side, we = prevent those funds plus 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 spent a decade try= ing to retrieve it from the landfill where he knows it's buried, but ca= n't get permission to excavate. I suspect that, given the choice, he= 9;d prefer those funds be permanently frozen rather than fall into someone = else's possession - I know I would.

Allowing a quantum computer = to access lost funds doesn't make those users any worse off than they w= ere before, however it would have a negative impact upon everyone wh= o is currently holding bitcoin.

It's prudent to expect significa= nt economic disruption if large amounts of coins fall into new hands. Since= a quantum computer is going to have a massive up front cost, expect those = behind it to desire to recoup their investment. We also know from experienc= e that when someone suddenly finds themselves in possession of 9+ figures w= orth of highly liquid assets, they tend to diversify into other things by s= elling.

Allowing quantum recovery of bitcoin is tantamount to wea= lth redistribution. What we'd be allowing is for bitcoin to be redi= stributed from those who are ignorant of quantum computers to those who hav= e won the technological race to acquire quantum computers. It's hard to= see a bright side to that scenario.

Is Quantum Rec= overy Good for Anyone?

Does quantum recovery HELP anyone? I&#= 39;ve yet to come across an argument that it's a net positive in any wa= y. It certainly doesn't add any security to the network. If anything, i= t greatly decreases the security of the network by allowing funds to be cla= imed by those who did not earn them.

But wait, you may be thinking, = wouldn't quantum "miners" have earned their coins by all the = work and resources invested in building a quantum computer? I suppose, in t= he same sense that a burglar earns their spoils by the resources they inves= t into surveilling targets and learning the skills needed to break into bui= ldings. What I say "earned" I mean through productive mutual trad= e.

For example:

* Investors earn BTC by trading for other cur= rencies.
* Merchants earn BTC by trading for goods and services.
* Mi= ners earn BTC by trading thermodynamic security.
* Quantum miners don= 9;t trade anything, they are vampires feeding upon the system.

There= 's no reason to believe that allowing quantum adversaries to recover vu= lnerable bitcoin will be of benefit to anyone other than the select few org= anizations that win the technological arms race to build the first such com= puters. Probably nation states and/or the top few largest tech companies.
One could certainly hope that an organization with quantum supremacy = is benevolent and acts in a "white hat" manner to return lost coi= ns to their owners, but that's incredibly optimistic and foolish to rel= y upon. Such a situation creates an insurmountable ethical dilemma of only = recovering lost bitcoin rather than currently owned bitcoin. There's no= way to precisely differentiate between the two; anyone can claim to have l= ost their bitcoin but if they have lost their keys then proving they ever h= ad the keys becomes rather difficult. I imagine that any such white hat rec= overy efforts would have to rely upon attestations from trusted third parti= es like exchanges.

Even if the first actor with quantum supremacy is= benevolent, we must assume the technology could fall into adversarial hand= s and thus think adversarially about the potential worst case outcomes. Ima= gine, for example, that North Korea continues scooping up billions of dolla= rs from hacking crypto exchanges and decides to invest some of those procee= ds into building a quantum computer for the biggest payday ever...

<= font size=3D"6">Downsides to Allowing Quantum Recovery
Let's = think through an exhaustive list of pros and cons for allowing or preventin= g the seizure of funds by a quantum adversary.

Hist= orical Precedent
Previous protocol vulnerabilities weren=E2=80=99= t celebrated as "fair game" but rather were treated as failures t= o be remediated. Treating quantum theft differently risks rewriting Bitcoin= =E2=80=99s history as a free-for-all rather than a system that seeks to pro= tect its users.

Violation of Property Rights=
Allowing a quantum adversary to take control of funds undermines the fu= ndamental principle of cryptocurrency - if you keep your keys in your posse= ssion, only you should be able to access your money. Bitcoin is built on th= e idea that private keys secure an individual=E2=80=99s assets, and unautho= rized access (even via advanced tech) is theft, not a legitimate transfer.<= br>
Erosion of Trust in Bitcoin
If quantum at= tackers can exploit vulnerable addresses, confidence in Bitcoin as a secure= store of value would collapse. Users and investors rely on cryptographic i= ntegrity, and widespread theft could drive adoption away from Bitcoin, dest= abilizing its ecosystem.

This is essentially the counterpoint to cla= iming the burning of vulnerable funds is a violation of property rights. Wh= ile some will certainly see it as such, others will find the apathy toward = stopping quantum theft to be similarly concerning.

= Unfair Advantage
Quantum attackers, likely equipped with rare and= expensive technology, would have an unjust edge over regular users who lac= k access to such tools. This creates an inequitable system where only the t= echnologically elite can exploit others, contradicting Bitcoin=E2=80=99s et= hos of decentralized power.

Bitcoin is designed to create an asymmet= ric advantage for DEFENDING one's wealth. It's supposed to be impra= ctically expensive for attackers to crack the entropy and cryptography prot= ecting one's coins. But now we find ourselves discussing a situation wh= ere this asymmetric advantage is compromised in favor of a specific class o= f attackers.

Economic Disruption
Large-sc= ale theft from vulnerable addresses could crash Bitcoin=E2=80=99s price as = quantum recovered funds are dumped on exchanges. This would harm all holder= s, not just those directly targeted, leading to broader financial chaos in = the markets.

Moral Responsibility
Permitt= ing theft via quantum computing sets a precedent that technological superio= rity justifies unethical behavior. This is essentially taking a "code = is law" stance in which we refuse to admit that both code and laws can= be modified to adapt to previously unforeseen situations.

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

1. s= elf-enriching & likely malicious
2. harm prevention & not necess= arily malicious

Both options lack the consent of the party whose coi= ns are being burnt or transferred, thus I think the simple argument that th= eft is immoral becomes a wash and it's important to drill down into the= details of each.

Incentives Drive Security<= br>I can tell you from a decade of working in Bitcoin security - the averag= e user is lazy and is a procrastinator. If Bitcoiners are given a "dro= p dead date" after which they know vulnerable funds will be burned, th= is pressure accelerates the adoption of post-quantum cryptography and stren= gthens Bitcoin long-term. Allowing vulnerable users to delay upgrading inde= finitely will result in more laggards, leaving the network more exposed whe= n quantum tech becomes available.

Steel Manning
= Clearly this is a complex and controversial topic, thus it's wor= th thinking through the opposing arguments.

Protect= ing Property Rights
Allowing quantum computers to take vulnerable= bitcoin could potentially be spun as a hard money narrative - we care so g= reatly about not violating someone's access to their coins that we allo= w them to be stolen!

But I think the flip side to the property right= s narrative is that burning vulnerable coins prevents said property from fa= lling into undeserving hands. If the entire Bitcoin ecosystem just stands a= round and allows quantum adversaries to claim funds that rightfully belong = to other users, is that really a "win" in the "protecting pr= operty rights" category? It feels more like apathy to me.

As su= ch, I think the "protecting property rights" argument is a wash.<= br>
Quantum Computers Won't Attack BitcoinThere is a great deal of skepticism that sufficiently powerful quantum co= mputers will ever exist, so we shouldn't bother preparing for a non-exi= stent threat. Others have argued that even if such a computer was built, a = quantum attacker would not go after bitcoin because they wouldn't want = to reveal their hand by doing so, and would instead attack other infrastruc= ture.

It's quite difficult to quantify exactly how valuable atta= cking other infrastructure would be. It also really depends upon when an en= tity gains quantum supremacy and thus if by that time most of the world'= ;s systems have already been upgraded. While I think you could argue that c= ertain entities gaining quantum capability might not attack Bitcoin, it wou= ld only delay the inevitable - eventually somebody will achieve the capabil= ity who decides to use it for such an attack.

Quant= um 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 day exploit" game theory in which an attacker knows= they have a limited amount of time before someone else discovers the explo= it and either benefits from it or patches it. Take, for example, the recent= ByBit attack - the highest value crypto hack of all time. Lazarus Group ha= d compromised the Safe wallet front end JavaScript app and they could have = simply had it reassign ownership of everyone's Safe wallets as they wer= e interacting with their wallet. But instead they chose to only specificall= y target ByBit's wallet with $1.5 billion in it because they wanted to = maximize their extractable value. If Lazarus had started stealing from ever= y wallet, they would have been discovered quickly and the Safe web app woul= d likely have been patched well before any billion dollar wallets executed = the malicious code.

I think the "only stealing small amounts&qu= ot; argument is strongest for Situation #2 described earlier, where a quant= um attacker arrives before quantum safe cryptography has been deployed acro= ss the Bitcoin ecosystem. Because if it became clear that Bitcoin's cry= ptography was broken AND there was nowhere safe for vulnerable users to mig= rate, the only logical option would be for everyone to liquidate their bitc= oin as quickly as possible. As such, I don't think it applies as strong= ly for situations in which we have a migration path available.

The 21 Million Coin Supply Should be in Circulation
S= ome folks are arguing that it's important for the "circulating / s= pendable" supply to be as close to 21M as possible and that having a s= ignificant portion of the supply out of circulation is somehow undesirable.=

While the "21M BTC" attribute is a strong memetic narrati= ve, I don't think anyone has ever expected that it would all be in circ= ulation. It has always been understood that many coins will be lost, and th= at's actually part of the game theory of owning bitcoin!

And rem= ember, the 21M number in and of itself is not a particularly important deta= il - it's not even mentioned in the whitepaper. What's important is= that the supply is well known and not subject to change.

Self-Sovereignty and Personal Responsibility
Bitcoin=E2=80= =99s design empowers individuals to control their own wealth, free from cen= tralized intervention. This freedom comes with the burden of securing one&#= 39;s private keys. If quantum computing can break obsolete cryptography, th= e fault lies with users who didn't move their funds to quantum safe loc= king scripts. Expecting the network to shield users from their own negligen= ce undermines the principle that you, and not a third party, are accountabl= e for your assets.

I think this is generally a fair point that "= ;the community" doesn't owe you anything in terms of helping you. = I think that we do, however, need to consider the incentives and game theor= y in play with regard to quantum safe Bitcoiners vs quantum vulnerable Bitc= oiners. More on that later.

Code is Law
B= itcoin operates on transparent, immutable rules embedded in its protocol. I= f a quantum attacker uses superior technology to derive private keys from p= ublic keys, they=E2=80=99re not "hacking" the system - they'r= e simply following what's mathematically permissible within the current= code. Altering the protocol to stop this introduces subjective human inter= vention, which clashes with the objective, deterministic nature of blockcha= in.

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. Leaning on this point seems more like a pro-ossification stance that = it's better to do nothing and allow harm to occur rather than take acti= on to stop an attack that was foreseen far in advance.

Technological Evolution as a Feature, Not a Bug
It's well= known that cryptography tends to weaken over time and eventually break. Qu= antum computing is just the next step in this progression. Users who fail t= o adapt (e.g., by adopting quantum-resistant wallets when available) are ak= in to those who ignored technological advancements like multisig or hardwar= e wallets. Allowing quantum theft incentivizes innovation and keeps Bitcoin= =E2=80=99s ecosystem dynamic, punishing complacency while rewarding vigilan= ce.

Market Signals Drive Security
If quan= tum attackers start stealing funds, it sends a clear signal to the market: = upgrade your security or lose everything. This pressure accelerates the ado= ption of post-quantum cryptography and strengthens Bitcoin long-term. Coddl= ing vulnerable users delays this necessary evolution, potentially leaving t= he network more exposed when quantum tech becomes widely accessible. Theft = is a brutal but effective teacher.

Centralized Blac= klisting Power
Burning vulnerable funds requires centralized deci= sion-making - a soft fork to invalidate certain transactions. This sets a d= angerous precedent for future interventions, eroding Bitcoin=E2=80=99s dece= ntralization. If quantum theft is blocked, what=E2=80=99s next - reversing = exchange hacks? The system must remain neutral, even if it means some lose = out.

I think this could be a potential slippery slope if the proposa= l was to only burn specific addresses. Rather, I'd expect a neutral pro= posal to burn all funds in locking script types that are known to be quantu= m vulnerable. Thus, we could eliminate any subjectivity from the code.
<= br>Fairness in Competition
Quantum attackers are= n't cheating; they're using publicly available physics and math. An= yone with the resources and foresight can build or access quantum tech, jus= t as anyone could mine Bitcoin in 2009 with a CPU. Early adopters took risk= s and reaped rewards; quantum innovators are doing the same. Calling it =E2= =80=9Cunfair=E2=80=9D ignores that Bitcoin has never promised equality of o= utcome - only equality of opportunity within its rules.

I find this = argument to be a mischaracterization because we're not talking about CP= Us. This is more akin to talking about ASICs, except each ASIC costs millio= ns if not billions of dollars. This is out of reach from all but the wealth= iest organizations.

Economic Resilience
B= itcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and emerged = stronger. The market can absorb quantum losses, with unaffected users conti= nuing to hold and new entrants buying in at lower prices. Fear of economic = collapse overestimates the impact - the network=E2=80=99s antifragility thr= ives on such challenges.

This is a big grey area because we don'= t know when a quantum computer will come online and we don't know how q= uickly said computers would be able to steal bitcoin. If, for example, the = first generation of sufficiently powerful quantum computers were stealing l= ess volume than the current block reward then of course it will have minima= l economic impact. But if they're taking thousands of BTC per day and b= ringing them back into circulation, there will likely be a noticeable marke= t impact as it absorbs the new supply.

This is where the circumstanc= es will really matter. If a quantum attacker appears AFTER the Bitcoin prot= ocol has been upgraded to support quantum resistant cryptography then we sh= ould expect the most valuable active wallets will have upgraded and the jui= ciest target would be the 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNp= N8kFyiAN1dr which has been dormant since 2010. In general I'd expect th= at the amount of BTC re-entering the circulating supply would look somewhat= similar to the mining emission curve: volume would start off very high as = the most valuable addresses are drained and then it would fall off as quant= um computers went down the list targeting addresses with less and less BTC.=

Why is economic impact a factor worth considering? Miners and busin= esses in general. More coins being liquidated will push down the price, whi= ch will negatively impact miner revenue. Similarly, I can attest from worki= ng in the industry for a decade, that lower prices result in less demand fr= om businesses across the entire industry. As such, burning quantum vulnerab= le bitcoin is good for the entire industry.

Practic= ality & Neutrality of Non-Intervention
There=E2=80=99s no rel= iable way to distinguish =E2=80=9Ctheft=E2=80=9D from legitimate "whit= e hat" key recovery. If someone loses their private key and a quantum = computer recovers it, is that stealing or reclaiming? Policing quantum acti= ons requires invasive assumptions about intent, which Bitcoin=E2=80=99s tru= stless design can=E2=80=99t accommodate. Letting the chips fall where they = may avoids this mess.

Philosophical PurityBitcoin 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 D= AO 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 a= ttacker and return funds to their original owners. The game theory is simil= ar because it's a situation where a threat is known but there's som= e period of time before the attacker can actually execute the theft. As suc= h, there's time to mitigate the attack by changing the protocol.
It also created a schism in the community around the true meaning of "= ;code is law," resulting in Ethereum Classic, which decided to allow t= he attacker to retain control of the stolen funds.

A soft fork to bu= rn vulnerable bitcoin could certainly result in a hard fork if there are en= ough miners who reject the soft fork and continue including transactions.
Incentives Matter
We can wax philosophical= until the cows come home, but what are the actual incentives for existing = Bitcoin holders regarding this decision?

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

If true, the corollary is:

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

Thus, assuming we get to a point whe= re quantum resistant signatures are supported within the Bitcoin protocol, = what's the incentive to let vulnerable 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 g= ood for the more attentive / responsible owners of coins who have quantum s= ecured their stash. Allowing the circulating supply to balloon will assured= ly reduce the purchasing power of all bitcoin holders.

Forking Game Theory
From a game theory point of view, I see t= his as incentivizing users to upgrade their wallets. If you disagree with t= he burning of vulnerable coins, all you have to do is move your funds to a = quantum safe signature scheme. Point being, I don't see there being an = economic majority (or even more than a tiny minority) of users who would fi= ght such a soft fork. Why expend significant resources fighting a fork when= you can just move your coins to a new address?

Remember that blocki= ng spending of certain classes of locking scripts is a tightening of the ru= les - a soft fork. As such, it can be meaningfully enacted and enforced by = a mere majority of hashpower. If miners generally agree that it's in th= eir best interest to burn vulnerable coins, are other users going to care e= nough to put in the effort to run new node software that resists the soft f= ork? Seems unlikely to me.

How to Execute Burning
In order to be as objective as possible, the goal would be to anno= unce to the world that after a specific block height / timestamp, Bitcoin n= odes will no longer accept transactions (or blocks containing such transact= ions) that spend funds from any scripts other than the newly instituted qua= ntum safe schemes.

It could take a staggered approach to first freez= e funds that are susceptible to long-range attacks such as those in P2PK sc= ripts or those that exposed their public keys due to previously re-using ad= dresses, but I expect the additional complexity would drive further controv= ersy.

How long should the grace period be in order to give the ecosy= stem time to upgrade? I'd say a minimum of 1 year for software wallets = to upgrade. We can only hope that hardware wallet manufacturers are able to= implement post quantum cryptography on their existing hardware with only a= firmware update.

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

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

Random Tangential Benefits
On the plus side, burning = all quantum vulnerable bitcoin would allow us to prune all of those UTXOs o= ut 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 incentiviz= ing migration of the entire UTXO set will create substantial demand for blo= ck space that will sustain a fee market for a fairly lengthy amount of time= .

In Summary
While the moral quandary of = violating any of Bitcoin's inviolable properties can make this a very c= omplex issue to discuss, the game theory and incentives between burning vul= nerable coins versus allowing them to be claimed by entities with quantum s= upremacy appears to be a much simpler issue.

I, for one, am not inte= rested in rewarding quantum capable entities by inflating the circulating m= oney supply just because some people lost their keys long ago and some lagg= ards are not upgrading their bitcoin wallet's security.

We can h= ope that this scenario never comes to pass, but hope is not a strategy.
=
I welcome your feedback upon any of the above points, and contribution = of any arguments I failed to consider.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3= DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGXD5f1eTwqMAkxz= dJOup3syR%2B5UjrkAaHroBJT0HQw5FA2_YQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CADL_X_cucGigAjw2ramxAyHf45SBcStGVvixJ7O%3D3kSfk1xEVA%40ma= il.gmail.com.
--000000000000846a24064f021bcc--