From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Apr 2026 11:55:41 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wIWXw-0005b1-M6 for bitcoindev@gnusha.org; Thu, 30 Apr 2026 11:55:40 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-42c125431f7sf3118212fac.3 for ; Thu, 30 Apr 2026 11:55:36 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1777575331; cv=pass; d=google.com; s=arc-20240605; b=ZxcEs3AyW1BtwNekRvoyIFL7W9glcITmURX0R/QVumFpAS2vOBCVS8PRoz+aCfibG/ CTNc5om5iCWrLx2P25g7HtuvCMEOrB9+f8/0InxEEJhkpnLymJuGa6QU1RHTtJv/Sagp XKG+ixUNJJHNke0tSFE1eIa8oSlcclfRFtt2BI3heirQNCuj2vlangh/WjQn+HOMuHEo nJGYlgffPs8Z3ZQB+f4RxuvTDZdtAawsO5qOauMecze6z7CM9UQ7KaMbCHCbouJW+nkj uqRUVzK/BZq3whnXscPBLX8LngCX5eMV9DAicqTm7fB3yPiz2Y8qjIhN8mmNLh6+IAC2 Dyig== 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=lB5Br1aXHa2dWJjYcEAPVRLEGGn/m1uPlAIqe3DP48s=; fh=xvDEIl1waVBU9QjixsJY+Wf6ZlXy92FYgFFBy9cy2fQ=; b=BCq63FdTxEdckEZzQNfSyf4z3TQ6NHLikb02MPDlaejAc8yGl325xumrrugZBxuxBO k8O/IvMILbftFUZucdmljKrcTZXE4ZrvzTGO6s3KpK4mP5UZi0TGV9ufRti007DjOOzA 7BY1A0mFhr0VOyCclE1zjbK1EWeQY47u6vtrDt+KoBRPzR/nW48A13fNinLFSwp0/tHf Qkg/tvKOQSAwLGGLfNsMDYri/ZBZrHDfX47385q1NIbISwoz66vgoIi03WKE+FhS0C/P Y0xpWF2LQqpbqJqKRcGzEndt6SUIGQmYgU2u906yjNvsuwj+5xZW5ALr2KvdMWVURY0T TUmA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=D9FshSCz; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=saintwenhao@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=1777575331; x=1778180131; 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=lB5Br1aXHa2dWJjYcEAPVRLEGGn/m1uPlAIqe3DP48s=; b=JT/ACjHihra2JyJ3EmLG6UwnMmol8pJ8o9KFfTJZpFfOGoGud1ZsWQFpD86hA1hWP9 Sno14yGpqY7gizCsX94lbjAZ9TBTArsCCkdHrHO+iUth32xvqYywKYlAr1++ScYyGtOr 4DGxVQ/GhgjNnh1vyhpN+eW9kRwwtME2jwovrmJyZS0qNfNKXpMbxBNSnK0dF3oEWVA6 e0+0GuVFYTJ3fyA+Cf0l7r3RGW1bWbD+d7yXDO3fJug35sKCzdtBTU1O1pZGRgqZvEsc DHyZ6uQl5ZmOlLc7cOkzSCaqIIFs+uNqfE/6Tz3CBGXhKNQljbiCs9V3N9fPvGwZpkeq dL6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777575331; x=1778180131; 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=lB5Br1aXHa2dWJjYcEAPVRLEGGn/m1uPlAIqe3DP48s=; b=ZUGLrJydxyYe8KrR7BJ2T803OhUfFjrquYM2K+E2KFopu0fYAQGUOj5LsY+GBIW2L6 L9stAAhDun56Cy+I5ahUgmLldl+qGbo3m1ZOg2ZhRmk8cRqxXVmqXHQ3ae+VkBICdNKg +vs4qupL1JM6DqSa3pqC7tT8MmW1Yz7MuM9W/ki1xfth4OOPCWI7354IPWsOPvNIwELr Ll+xrKWQ8H69DY0gqx8GNzdAk9MBtaDGrdT0q7CXPLnBlA2OfaN5bZ0UH2GP7WD48gI8 /BW5SZEtREMcraKgDvt04fHsqpfOWV9XO4Y7IglYi5Gr2wM7tt5D4npVkWCizyxcHBV5 Z1Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777575331; x=1778180131; 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=lB5Br1aXHa2dWJjYcEAPVRLEGGn/m1uPlAIqe3DP48s=; b=UnSin9aLkF1mZsgwXTCOI2bBJFcz7M6bmYGMp+a3o+dsfGrXoB/WddZAQE6afk9O2W CpFWtG0+htZyKUIlFgaq3PoMjHbYrS59TQcX8hwbIMUtng7DtNvNyzvSdxanwJFSY8mb iw10BDAXcMLO0Pvjfs9JOh0Pf1/AEczhOrbs1dO85inXfuiiLEkjff0GI6WUjfdCyz3g D581ORxqitH4DWOO4VyOMnwy2BjneMeHShE7KxI9Me92lkNO1gKI0zYC+kGWeZ1qQkyK 2ksLFIdoeFC9/XsWXtZ7MrFZ/z1k4M4vK4TGeGcP0NPe0yuNvUpgIh9icnM2xLSviHDQ NJuA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/V6B5GgseeS/+zpIoakpr3gPqifWmQsbBsl/e4J07k31GLEJ5dog85xVeukWSkFlks230vEwBNCjW/@gnusha.org X-Gm-Message-State: AOJu0Yzo9NcUDXgJV2XRVHfkn/IcS+Bmp7fJWTW6hA6Ggow71OQXqbU3 vxbB+gBYvhXiPrwEA2gTCEA3q5dSQEWie18+tl6PxpG1MTYrGTBnvxw9 X-Received: by 2002:a05:6871:3863:b0:42f:d33a:41e0 with SMTP id 586e51a60fabf-43433bb9f9bmr2555476fac.22.1777575330501; Thu, 30 Apr 2026 11:55:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNr8aH0FlyX5vvfwzkSabfk+h37gfWMYR6IP34r4ZkpYg==" Received: by 2002:a05:6870:6488:b0:41c:64c3:46be with SMTP id 586e51a60fabf-43430002b17ls729684fac.1.-pod-prod-07-us; Thu, 30 Apr 2026 11:55:26 -0700 (PDT) X-Received: by 2002:a05:6808:d53:b0:479:477f:559c with SMTP id 5614622812f47-47c5fb8ac3bmr2237002b6e.14.1777575326430; Thu, 30 Apr 2026 11:55:26 -0700 (PDT) Received: by 2002:a05:600c:2301:b0:488:963a:630a with SMTP id 5b1f17b1804b1-488fbcef612ms5e9; Tue, 28 Apr 2026 23:21:32 -0700 (PDT) X-Received: by 2002:a05:600c:470c:b0:48a:7965:b92a with SMTP id 5b1f17b1804b1-48a7b54bf53mr42702695e9.26.1777443690702; Tue, 28 Apr 2026 23:21:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1777443690; cv=pass; d=google.com; s=arc-20240605; b=Ng3+XzLq84xPmun01XBQ2Ud02jUesrGAhpp6rslnPTJgKAmcN9F4LNLeyjR7wpVDct p01mMwihJu+VbKmkLUoAU/2vQt993ls0JyCyRGPfYaYSV05XIFeVWL3HNI/gtLS6s1fZ 6C4nFn8rjwRFe3K9EVyQQ4rm1pU8b4xMb+QcFm2jO1JxZjVs5rbtshyQrGhldfZVVD5g UBda4Yj/NjdXdgwCmwalI+f+OiQfby3WfWcSGjhyBL+DMIKnoQC2Md8ShYArVuPTcRtm E5/N8dZBkzk+v91i0a59UK5net3tUwsR+ObAyGGTnb6EKcMmpDdnOer768nOwGW3NTae jt4g== 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=rQlvgIjLegHtQQqMutrbE4Wt+ux+/R1XRjsE9cJgbCU=; fh=qsIjjjz9uHFgXy188rF0UCrA62ZKIfn8xtMqJJ6blB8=; b=Zv59kmEWi/Bm2sI7ttZ3yh2qYFAhz+KDHdddfR/QcOe7RhG1fjdHqqKAq9Gx3LQEvF 0Sqhy/jQBcEXEd2CV9TXPS6Kyq+1iOqvTLPImAzB0CoetK2d6hnaLDB+ux2vMZFUHhVY jK1Z5AefWncqMhOJP0tXBpFc5Ed2MHVIFlN5wmFJNwpeodtRLQOi+0TNvJ1QJzrwyZBc K+vsrVqur68E7OL2qcX6G1A5APE7pDTy/YmCNVy4XwpxIIfb1fkXpSAcxPwgwkl7fVIi Ahm8qsmCFwrq98ZAADTwH5UPQrB/o2HWVqmtVdk9Mmut0lN40GMoXbChm73YZBGMguWW UUXg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=D9FshSCz; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com. [2a00:1450:4864:20::233]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-48a7c1d2c96si203075e9.2.2026.04.28.23.21.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2026 23:21:30 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) client-ip=2a00:1450:4864:20::233; Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-38ddeb0f5abso94888041fa.3 for ; Tue, 28 Apr 2026 23:21:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777443690; cv=none; d=google.com; s=arc-20240605; b=PQEZIBBBAMbpg56A4dcJHrJHow8Zj7XzbzGlWjqn2jHk9YfDZaclERFb8S9uNj4vTy 7KBf6Y8R7OwseTpi0w4H9RL3gQ8WVX3Wsb9UqBLJvwQHHxf5rpUR24X4cT9lN5qp8oI2 psX9YtHvTM9iBK/tk+AAL4sxPI0gOebUzrJTaDx03NirBIlPiZkwKX1mwT6dCrITy40d IaGbmKmTCYGEPq+HSOw4pqPoBXqL32LsCZt5fGL/QjlD7vVAt1kJJuAOqi6uJQEetp80 tOjEXnumPgDkybJC+ldlSyK2xpO+EnBOh5WIMXHiqzX32d99zMkujx1bewPcjKYZzgmo +Iqw== 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=rQlvgIjLegHtQQqMutrbE4Wt+ux+/R1XRjsE9cJgbCU=; fh=qsIjjjz9uHFgXy188rF0UCrA62ZKIfn8xtMqJJ6blB8=; b=fFkEdsjmV1hxnOFDmgCER4CXWSApOHTiLrqeZKTm+1waCQmCEadNGVhV0gaOopAILL v4X3Yg7kM8MiXiLbisANBVPUWLEZxDHgowgw4sPqZNRNe9B+3SSzMkI3i5J8stEcq3ug NWZ66sr45N/Vh7drEefnwwuLCuBXlpT9Whsj4ZEa8y6uDnvgo+5Y5YeTueD5Qb/LKI50 Gry/fSY10h8Vpie3gjzO6yqoQJv96RzeGUHTYQvYM6vkBK0Qjuh5tj9qZaYWjydrW0hC rR0AiBUpJ7fSr5T8unw6cip2d9o8wVQA+I27o13sKvd4ZHoDhki8M/5z+BeHhFkzQIw7 71wA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDievRQ6R6hBiWFo1M/zeqQ2nFflpKRjLS2E9Cna/XqNkjJIM9MkH0msEaikvlMtW 0Uc46Y/GtsAdovIQQ9U2GSuXR3oGqA6irakWkq7C5LNygozXu/6T5rNgHvSffeJL3p5j6wM2Ur4 nu0hMMel7GMl3bF3fAxcnJTJVQ/xpIe/Z3DHtZAYeE6h2er1tTASqP4oa62MpgRUKNkPNp2AEKn x6uNUbrlUHNATo/RnHiRS2btq5tvIGJ/NoTrQd5s/tqGm2iRCT7q9GYKQD319LWj2cHs9Xm0BZK W4Y4fH/3oZyvx3NP X-Received: by 2002:a2e:bc85:0:b0:38e:84e3:3476 with SMTP id 38308e7fff4ca-3924bcdeb77mr9312921fa.25.1777443689415; Tue, 28 Apr 2026 23:21:29 -0700 (PDT) MIME-Version: 1.0 References: <3fec8fc3-efa1-49c5-8bab-592e0138d31dn@googlegroups.com> In-Reply-To: <3fec8fc3-efa1-49c5-8bab-592e0138d31dn@googlegroups.com> From: Saint Wenhao Date: Wed, 29 Apr 2026 08:21:17 +0200 X-Gm-Features: AVHnY4Lu1fiuFf3ZyaljfkZoFVnqsOydkrMZuFKUblbfFla8D8SaaYN213jThqk Message-ID: Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin To: Thomas Suau Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b747840650935b87" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=D9FshSCz; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=saintwenhao@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 (/) --000000000000b747840650935b87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > P2SH, P2WSH outputs which have never spent are not at risk P2SH has a risk of collision, when it is used by more than one user. Which is why P2WSH uses SHA-256 alone, without pushing the result of that through RIPEMD-160. It is even described in BIP-141, as a justification for P2WSH: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content= -P2WSH > The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness. And now, in 2026, we have around 2^96 chainwork. Which could make these attacks more practical than theoretical. While quantum computers are still in theory, so if I would have to guess, then I would put more money on a scenario, where RIPEMD-160 collision is found faster than anyone will break secp256k1. There are even some canaries, which could give some incentive to reveal RIPEMD-160 collision, for example 3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay or 39VXyuoc6SXYKp9TcAhoiN1mb4ns6z3Yu6. But yes, for a single user, 160-bit addresses are safe to use, at least for now. However, publishing the first collision may create a lot of FUD, and then, moving these coins to a different address type will be highly recommended, because then you will never know, if new 160-bit addresses can be spent in more ways, which were not yet disclosed on-chain. wt., 28 kwi 2026 o 22:47 Thomas Suau napisa=C5=82(a): > Hi, > > Against freezing. > > A vulnerable user post-CRQC is someone who made two active choices: > reusing addresses, and not migrating once a standard is available. That's > the user breaking the social contract, not the protocol. P2PKH, P2WPKH, > P2SH, P2WSH outputs which have never spent are not at risk =E2=80=94 pubk= ey is > hashed, not exposed. P2PK, reused addresses, and P2TR key path are. Bitco= in > isn't globally broken =E2=80=94 specific address types are, and users hol= ding them > after a migration path exists are accepting the risk. > > A script-type freeze applies uniformly to weak output types, not to > specific transactions =E2=80=94 categorically different from reversing ex= change > hacks. But once the protocol starts deciding which coins are safe enough = to > spend, that logic is hard to contain. > > Either way, the freeze debate is a signal, not the goal. It tells us we > need a standard urgently. That's where the energy should go =E2=80=94 Mat= t's thread > is asking the right question What's our goal? > . > > Regards, > > Thomas > > Le jeudi 9 avril 2026 =C3=A0 10:36:50 UTC+2, Jameson Lopp a =C3=A9crit : > >> Scratch that; nodes should already be storing the block for which a UTXO >> was confirmed in order to calculate relative timelock validity. So it >> should be implementable. >> >> Still, there are several vague statements that could use more explanatio= n. >> >> "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 m= ax >> 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= means. 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 contai= ned >>> somewhere inside of the transaction itself. >>> >>> In order to implement an "implied" scheme as you propose, it would >>> require all nodes to start indexing UTXOs by block height in order to a= void >>> 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 wr= ote: >>> >>>> The protocol should not assume that future participants will be able t= o >>>> coordinate around a single deadline without distortion. A fixed height= at >>>> which old outputs become invalid would create a predictable cliff, and >>>> predictable cliffs invite adversarial behavior. Markets tend to rush t= oward >>>> the edge. >>>> >>>> Bitcoin works best when incentives 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 class of o= utputs 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 ph= asing >>>> out insecure constructions. >>>> >>>> The network already treats some script forms as discouraged. Extending >>>> this to prohibit creation of new vulnerable forms is a natural evoluti= on. >>>> 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 timelock= s is >>>> interesting, but it introduces a new class of special=E2=80=91case beh= avior. >>>> Bitcoin=E2=80=99s rules should be simple, general, and predictable. If= the protocol >>>> begins to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2=80= =9Cquantum=E2=80=91recovered=E2=80=9D spends, >>>> it implies an authority deciding which coins are morally valid. That i= s 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 b= e >>>> migrated in time. >>>> >>>> The network cannot prevent advances in mathematics or computation. It >>>> can only ensure that the incentives remain aligned so that users upgra= de >>>> their 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 >>>> funds to stronger constructions, and then retire the weak form gradual= ly so >>>> the chain does not become a liability. >>>> >>>> =E2=80=94 S. >>>> >>>> On Mon, Apr 7, 2025, 6:34=E2=80=AFAM Nadav Ivgi wr= ote: >>>> >>>>> One possible alternative to freezing/burning the coins entirely is >>>>> letting quantum attackers keep some small percent as a reward, but fo= rce >>>>> them to stage the rest to future miners as an additional security bud= get >>>>> 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]-= only >>>>> encumbered output timelocked far into the future. Miners would then m= onitor >>>>> 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 flood= ing >>>>> 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 b= e >>>>> split into up-to-N-BTC outputs, each staggered with a different >>>>> deterministic timelock. So for example, a single tx spending 10,000 B= TC >>>>> won't release 9,900 BTC to the miners in a single far-future block (w= hich >>>>> may cause chain instability if the miners get into a reorg war over i= t), >>>>> 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 a= n >>>>> endorsement, just a thought. :) >>>>> >>>>> - shesek >>>>> >>>>> [0] OP_CSV only supports relative timelocks of up to 65535 blocks (~1= 5 >>>>> 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 separa= te >>>>> 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 quant= um >>>>>> computers will ever actually become a practical threat. >>>>>> >>>>>> I won't tread into the unanswerable question of how worried we shoul= d >>>>>> be about quantum computers. I think it's far from a crisis, but give= n the >>>>>> difficulty in changing Bitcoin it's worth starting to seriously disc= uss. >>>>>> 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 quan= tum >>>>>> 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 sc= enario >>>>>> 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 restor= e >>>>>> confidence in the network. >>>>>> 3. Quantum computing advances slowly enough that we come to consensu= s >>>>>> about how to upgrade Bitcoin and post quantum security has been mini= mally >>>>>> adopted by the time an attacker appears. >>>>>> 4. Quantum computing advances slowly enough that we come to consensu= s >>>>>> about how to upgrade Bitcoin and post quantum security has been high= ly >>>>>> 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 b= e >>>>>> handled in terms of migrating user funds. Should quantum vulnerable = funds >>>>>> be left open to be swept by anyone with a sufficiently powerful quan= tum >>>>>> 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 thi= s might >>>>>>> have an inflationary impact on bitcoin's price, to use a turn of ph= rase, >>>>>>> the inflation is transitory. Those with low time preference should = support >>>>>>> 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 bi= g >>>>>>> if) the existence of a cryptography-breaking QC becomes a credible = threat, >>>>>>> the Bitcoin ecosystem has no other option than softforking out the = ability >>>>>>> to spend from signature schemes (including ECDSA and BIP340) that a= re >>>>>>> vulnerable 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 such a setting. And this affects everyone; even those whi= ch >>>>>>> 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 fund= s *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= 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://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 protoc= ol. >>>>>> >>>>>> *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 secur= e >>>>>> because truly random large numbers should not be guessable or discov= erable >>>>>> 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 princi= ple is >>>>>> null and void for many types of cryptography, including the elliptic= curve >>>>>> 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 qu= antum >>>>>> "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 have exposed their public keys due to >>>>>> re-using addresses that have previously been spent from. You can eas= ily >>>>>> 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.= So 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 signa= ture. >>>>>> >>>>>> 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 a= dd a >>>>>> quantum safe signature scheme, we should expect those wallets to be = some of >>>>>> the first to upgrade given their incentives. >>>>>> >>>>>> The Ethical Dilemma: Quantifying Harm >>>>>> Which decision results in the most harm? >>>>>> >>>>>> By making quantum vulnerable funds unspendable we potentially harm >>>>>> some Bitcoin users who were not paying attention and neglected to mi= grate >>>>>> their funds to a quantum safe locking script. This violates the >>>>>> "conservativism" principle stated earlier. On the flip side, we prev= ent >>>>>> 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 users who would otherwise have funds frozen are likely to see the= m >>>>>> stolen. 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 U= SD. 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, g= iven >>>>>> the choice, he'd prefer those funds be permanently frozen rather tha= n 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 >>>>>> amounts of coins fall into new hands. Since a quantum computer is go= ing to >>>>>> have a massive up front cost, expect those behind it to desire to re= coup >>>>>> their investment. We also know from experience that when someone sud= denly >>>>>> finds 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 th= ose who >>>>>> have won the technological race to acquire quantum computers. It's h= ard 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 a= dd any >>>>>> security to the network. If anything, it greatly decreases the secur= ity of >>>>>> the network by allowing funds to be claimed by those who did not ear= n 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 qua= ntum >>>>>> computer? I suppose, in the same sense that a burglar earns their sp= oils by >>>>>> the resources they invest into surveilling targets and learning the = skills >>>>>> 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 upo= n >>>>>> the system. >>>>>> >>>>>> There's no reason to believe that allowing quantum adversaries to >>>>>> recover vulnerable bitcoin will be of benefit to anyone other than t= he >>>>>> select few organizations that win the technological arms race to bui= ld the >>>>>> first such computers. Probably nation states and/or the top few larg= est >>>>>> tech companies. >>>>>> >>>>>> One could certainly hope that an organization with quantum supremacy >>>>>> is benevolent and acts in a "white hat" manner to return lost coins = to >>>>>> their owners, but that's incredibly optimistic and foolish to rely u= pon. >>>>>> 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= lost >>>>>> their bitcoin but if they have lost their keys then proving they eve= r had >>>>>> the keys becomes rather difficult. I imagine that any such white hat >>>>>> recovery efforts would have to rely upon attestations from trusted t= hird >>>>>> parties like exchanges. >>>>>> >>>>>> Even if the first actor with quantum supremacy is benevolent, we mus= t >>>>>> assume the technology could fall into adversarial hands and thus thi= nk >>>>>> adversarially about the potential worst case outcomes. Imagine, for >>>>>> example, that North Korea continues scooping up billions of dollars = from >>>>>> hacking crypto exchanges and decides to invest some of those proceed= s 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 >>>>>> or preventing the seizure of funds by a quantum adversary. >>>>>> >>>>>> Historical Precedent >>>>>> Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fai= r game" >>>>>> but rather were treated as failures to be remediated. Treating quant= um >>>>>> theft differently risks rewriting Bitcoin=E2=80=99s history as a fre= e-for-all >>>>>> rather than a system that seeks to protect its users. >>>>>> >>>>>> Violation of Property Rights >>>>>> Allowing a quantum adversary to take control of funds undermines the >>>>>> fundamental principle of cryptocurrency - if you keep your keys in y= our >>>>>> possession, 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 >>>>>> unauthorized access (even via advanced tech) is theft, not a legitim= ate >>>>>> 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 investo= rs rely >>>>>> on cryptographic integrity, and widespread theft could drive adoptio= n 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 stoppin= g >>>>>> 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 ac= cess to >>>>>> such tools. This creates an inequitable system where only the >>>>>> technologically elite 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 attack= ers to >>>>>> crack the entropy and cryptography protecting one's coins. But now w= e 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 >>>>>> all holders, not just those directly targeted, leading to broader fi= nancial >>>>>> chaos in the markets. >>>>>> >>>>>> Moral Responsibility >>>>>> Permitting theft via quantum computing sets a precedent that >>>>>> technological superiority justifies unethical behavior. This is esse= ntially >>>>>> 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 situation= s. >>>>>> >>>>>> Burning of coins can certainly be considered a form of theft, thus I >>>>>> think it's worth differentiating the two different thefts being disc= ussed: >>>>>> >>>>>> 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 det= ails 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 give= n a >>>>>> "drop dead date" after which they know vulnerable funds will be burn= ed, >>>>>> this pressure accelerates the adoption of post-quantum cryptography = and >>>>>> strengthens Bitcoin long-term. Allowing vulnerable users to delay up= grading >>>>>> indefinitely will result in more laggards, leaving the network more = exposed >>>>>> 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 >>>>>> potentially be spun as a hard money narrative - we care so greatly a= bout >>>>>> not violating 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 aroun= d and >>>>>> allows quantum adversaries to claim funds that rightfully belong to = other >>>>>> users, is that really a "win" in the "protecting property rights" ca= tegory? >>>>>> 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= was >>>>>> built, a quantum attacker would not go after bitcoin because they wo= uldn't >>>>>> want to reveal their hand by doing so, and would instead attack othe= r >>>>>> infrastructure. >>>>>> >>>>>> It's quite difficult to quantify exactly how valuable attacking othe= r >>>>>> infrastructure would be. It also really depends upon when an entity = gains >>>>>> quantum supremacy and thus if by that time most of the world's syste= ms have >>>>>> already been upgraded. While I think you could argue that certain en= tities >>>>>> gaining quantum capability might not attack Bitcoin, it would only d= elay >>>>>> 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 arou= se >>>>>> 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 cla= ssic >>>>>> "zero day exploit" game theory in which an attacker knows they have = a >>>>>> limited amount of time before someone else discovers the exploit and= either >>>>>> benefits from it or patches it. Take, for example, the recent ByBit = attack >>>>>> - the highest value crypto hack of all time. Lazarus Group had compr= omised >>>>>> the Safe wallet front end JavaScript app and they could have simply = had it >>>>>> reassign ownership of everyone's Safe wallets as they were interacti= ng with >>>>>> their wallet. But instead they chose to only specifically target ByB= it'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= have >>>>>> been patched well before any billion dollar wallets executed the mal= icious >>>>>> code. >>>>>> >>>>>> I think the "only stealing small amounts" argument is strongest for >>>>>> Situation #2 described earlier, where a quantum attacker arrives bef= ore >>>>>> quantum safe cryptography has been deployed across the Bitcoin ecosy= stem. >>>>>> Because if it became clear that Bitcoin's cryptography was broken AN= D there >>>>>> was nowhere safe for vulnerable users to migrate, the only logical o= ption >>>>>> would be for everyone to liquidate their bitcoin as quickly as possi= ble. As >>>>>> such, I don't think it applies as strongly for situations in which w= e 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 unde= sirable. >>>>>> >>>>>> 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 actu= ally >>>>>> 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 w= ealth, >>>>>> free from centralized intervention. This freedom comes with the burd= en 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 = from >>>>>> their own negligence undermines the principle that you, and not a th= ird >>>>>> party, are accountable 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, howeve= r, need >>>>>> to consider the incentives and game theory in play with regard to qu= antum >>>>>> 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 p= rivate >>>>>> keys from public keys, they=E2=80=99re not "hacking" the system - th= ey'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= 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 reduci= ng >>>>>> harm. Leaning on this point seems more like a pro-ossification stanc= e that >>>>>> it's better to do nothing and allow harm to occur rather than take a= ction >>>>>> 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-resi= stant >>>>>> wallets when available) are akin to those who ignored technological >>>>>> advancements like multisig or hardware wallets. Allowing quantum the= ft >>>>>> incentivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynami= c, punishing >>>>>> complacency while rewarding vigilance. >>>>>> >>>>>> Market Signals Drive Security >>>>>> If quantum attackers start stealing funds, it sends a clear signal t= o >>>>>> the market: upgrade your security or lose everything. This pressure >>>>>> accelerates the adoption of post-quantum cryptography and strengthen= s >>>>>> Bitcoin long-term. Coddling vulnerable users delays this necessary >>>>>> evolution, potentially leaving the network more exposed when quantum= tech >>>>>> 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 >>>>>> precedent for future interventions, eroding Bitcoin=E2=80=99s decent= ralization. If >>>>>> quantum theft is blocked, what=E2=80=99s next - reversing exchange h= acks? 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 >>>>>> to only burn specific addresses. Rather, I'd expect a neutral propos= al 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 >>>>>> 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= doing >>>>>> the same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin h= as 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= each >>>>>> ASIC costs millions if not billions of dollars. This is out of reach= from >>>>>> all but the wealthiest organizations. >>>>>> >>>>>> Economic Resilience >>>>>> Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and >>>>>> emerged stronger. The market can absorb quantum losses, with unaffec= ted >>>>>> users continuing to hold and new entrants buying in at lower prices.= Fear >>>>>> of economic collapse overestimates the impact - the network=E2=80=99= s antifragility >>>>>> thrives on such challenges. >>>>>> >>>>>> This is a big grey area because we don't know when a quantum compute= r >>>>>> 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 sufficien= tly >>>>>> powerful quantum computers were stealing less volume than the curren= t block >>>>>> reward then of course it will have minimal economic impact. But if t= hey're >>>>>> taking thousands of BTC per day and bringing them back into circulat= ion, >>>>>> there will likely be a noticeable market impact as it absorbs the ne= w >>>>>> supply. >>>>>> >>>>>> This is where the circumstances will really matter. If a quantum >>>>>> attacker appears AFTER the Bitcoin protocol has been upgraded to sup= port >>>>>> quantum resistant cryptography then we should expect the most valuab= le >>>>>> active wallets will have upgraded and the juiciest target would be t= he >>>>>> 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which h= as been >>>>>> dormant since 2010. In general I'd expect that the amount of BTC >>>>>> re-entering the circulating supply would look somewhat similar to th= e >>>>>> 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 = BTC. >>>>>> >>>>>> Why is economic impact a factor worth considering? Miners and >>>>>> businesses in general. More coins being liquidated will push down th= e >>>>>> price, which will negatively impact miner revenue. Similarly, I can = attest >>>>>> from working in the industry for a decade, that lower prices result = in less >>>>>> demand from businesses across the entire industry. As such, burning = quantum >>>>>> 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 quant= um >>>>>> actions requires invasive assumptions about intent, which Bitcoin=E2= =80=99s >>>>>> trustless design can=E2=80=99t accommodate. Letting the chips fall w= here they may >>>>>> avoids this mess. >>>>>> >>>>>> Philosophical Purity >>>>>> Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system where out= comes >>>>>> reflect preparation and skill, not sentimentality. If quantum comput= ing >>>>>> upends the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t me= ant to be safe or fair >>>>>> in a nanny-state sense; it=E2=80=99s meant to be free. Users who los= e funds to >>>>>> quantum attacks are casualties of liberty and their own ignorance, n= ot >>>>>> 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 attacke= r and >>>>>> return funds to their original owners. The game theory is similar be= cause >>>>>> it's a situation where a threat is known but there's some period of = time >>>>>> before the attacker can actually execute the theft. As such, there's= time >>>>>> to 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= the >>>>>> attacker to retain control of the stolen funds. >>>>>> >>>>>> A soft fork to burn vulnerable bitcoin could certainly result in a >>>>>> hard fork if there are enough miners who reject the soft fork and co= ntinue >>>>>> 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 decisi= on? >>>>>> >>>>>> "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 >>>>>> are supported within the Bitcoin protocol, what's the incentive to l= et >>>>>> 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 suppl= y to >>>>>> balloon will assuredly reduce the purchasing power of all bitcoin ho= lders. >>>>>> >>>>>> 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 vulner= able >>>>>> coins, all you have to do is move your funds to a quantum safe signa= ture >>>>>> scheme. Point being, I don't see there being an economic majority (o= r 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 = your >>>>>> coins to a new address? >>>>>> >>>>>> Remember that blocking spending of certain classes of locking script= s >>>>>> is a tightening of the rules - a soft fork. As such, it can be meani= ngfully >>>>>> enacted and enforced by a mere majority of hashpower. If miners gene= rally >>>>>> agree that it's in their best interest to burn vulnerable coins, are= other >>>>>> users going to care enough to put in the effort to run new node soft= ware >>>>>> 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 will no longer accept transactions (or blocks containi= ng such >>>>>> transactions) that spend funds from any scripts other than the newly >>>>>> instituted quantum safe schemes. >>>>>> >>>>>> It could take a staggered approach to first freeze funds that are >>>>>> susceptible to long-range attacks such as those in P2PK scripts or t= hose >>>>>> that exposed their public keys due to previously re-using addresses,= but I >>>>>> expect the additional complexity would drive further controversy. >>>>>> >>>>>> How long should the grace period be in order to give the ecosystem >>>>>> time to upgrade? I'd say a minimum of 1 year for software wallets to >>>>>> upgrade. We can only hope that hardware wallet manufacturers are abl= e 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 scenario. Thou= gh if >>>>>> you exclude dust UTXOs you could probably get 95% of BTC value migra= ted in >>>>>> 1 month. Of course this is a highly optimistic situation where every= one is >>>>>> completely focused on migrations - in reality it will take far longe= r. >>>>>> >>>>>> Regardless, I'd think that in order to reasonably uphold Bitcoin's >>>>>> conservatism it would be preferable to allow a 4 year migration wind= ow. In >>>>>> the meantime, mining pools could coordinate emergency soft forking l= ogic >>>>>> such that if quantum attackers materialized, they could accelerate t= he >>>>>> 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 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 UTX= O >>>>>> 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 t= heory >>>>>> and incentives between burning vulnerable coins versus allowing them= to be >>>>>> claimed by entities with quantum supremacy appears to be a much simp= ler >>>>>> issue. >>>>>> >>>>>> I, for one, am not interested in rewarding quantum capable entities >>>>>> by inflating the circulating money supply just because some people l= ost >>>>>> their keys long ago and some laggards are not upgrading their bitcoi= n >>>>>> 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+...@googlegroups.com. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXRe= Mq8nA_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, sen= d >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/CAGXD5f1eTwqMAkxzdJOup3s= yR%2B5UjrkAaHroBJT0HQw5FA2_YQ%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/3fec8fc3-efa1-49c5-8bab-592e= 0138d31dn%40googlegroups.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/= CACgYNOL38xCV8TAMhuHLGhpQO6f4jRc-bxoio-pL%3D6RDRXb11A%40mail.gmail.com. --000000000000b747840650935b87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> P2SH, P2WSH outputs which have never spent are not at= risk

P2SH has a risk of collision, when it is used by more than one= user. Which is why P2WSH uses SHA-256 alone, without pushing the result of= that through RIPEMD-160. It is even described in BIP-141, as a justificati= on for P2WSH: https://github.com/bitcoin/bips/blob/maste= r/bip-0141.mediawiki#user-content-P2WSH

> The scriptPubKey oc= cupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size i= mproves security against possible collision attacks, as 2^80 work is not in= feasible anymore (By the end of 2015, 2^84 hashes have been calculated in B= itcoin mining since the creation of Bitcoin). The spending script is same a= s the one for an equivalent BIP16 P2SH output but is moved to witness.
<= br>And now, in 2026, we have around 2^96 chainwork. Which could make these = attacks more practical than theoretical. While quantum computers are still = in theory, so if I would have to guess, then I would put more money on a sc= enario, where RIPEMD-160 collision is found faster than anyone will break s= ecp256k1. There are even some canaries, which could give some incentive to = reveal RIPEMD-160 collision, for example 3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay= or 39VXyuoc6SXYKp9TcAhoiN1mb4ns6z3Yu6.

But yes, for a single user, = 160-bit addresses are safe to use, at least for now. However, publishing th= e first collision may create a lot of FUD, and then, moving these coins to = a different address type will be highly recommended, because then you will = never know, if new 160-bit addresses can be spent in more ways, which were = not yet disclosed on-chain.

wt., 28 kwi 2026 o 22:47= =C2=A0Thomas Suau <tomeclair@gmai= l.com> napisa=C5=82(a):

Hi,=C2=A0

Against freezing.

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

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

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

Regards,

Thomas


Le jeudi 9 avril 2026 =C3=A0 10:36:50 UTC+2,= Jameson Lopp a =C3=A9crit=C2=A0:
Scratch that; nodes should already be st= oring the block for which a UTXO was confirmed in order to calculate relati= ve timelock validity. So it should be implementable.

Still, there ar= e several vague statements that could use more explanation.

"pr= edictable cliffs invite adversarial behavior." - such as?

"= ;This avoids retroactively invalidating old transactions while still phasin= g out insecure constructions." - how so? If you chose a relative max a= ge that's less than the total age of Bitcoin itself, it will by default= invalidate extremely old UTXOs.

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

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

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

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

On Thu, Apr 9, 2026 at 3:01=E2=80= =AFAM Bitcoin <lovelo...@gmail.com> wrote:
= The protocol should not assume that future participants will be able to coo= rdinate around a single deadline without distortion. A fixed height at whic= h old outputs become invalid would create a predictable cliff, and predicta= ble cliffs invite adversarial behavior. Markets tend to rush toward the edg= e.

Bitcoin works best when inc= entives are continuous rather than abrupt.

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

The network already treats some script form= s as discouraged. Extending this to prohibit creation of new vulnerable for= ms is a natural evolution. Nodes can continue to validate the old chain his= tory while refusing to relay or mine new transactions that expose public ke= ys 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 protoco= l begins to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2=80=9Cq= uantum=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 as= k who is spending the coins or why. It only enforces that insecure forms mu= st be migrated in time.

= The network cannot prevent advances in mathematics or computation. It can o= nly ensure that the incentives remain aligned so that users upgrade their s= ecurity before adversaries can exploit weaknesses. The protocol should enco= urage 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 funds to stronge= r constructions, 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 <na...@shesek.info> wrote:
One= possible alternative to freezing/burning the coins entirely is letting qua= ntum attackers keep some small percent as a reward, but force them to stage= the rest to future miners as an additional security budget subsidy.
<= div>
This can be implemented as a soft fork, by req= uiring transactions=20 spending QC-vulnerable coins to allocate some funds to an OP_CLTV[0]-only e= ncumbered output timelocked far into the future. Miners would then monitor = these outputs and claim them as they become available.

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

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

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

- sh= esek

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

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


On Sun, Mar 16, 2025 at 5:22=E2=80=AFPM Jameson Lopp <jameso...@gmail.com> wrote:
The quantu= m computing debate is heating up. There are many controversial aspects to t= his debate, including whether or not quantum computers will ever actually b= ecome a practical threat.

I won't tread into the unanswerable q= uestion 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 discuss. Today I wish to focus on a philosophi= cal quandary related to one of the decisions that would need to be made if = and when we implement a quantum safe signature scheme.

Several Scenarios
Because this essay will reference game theo= ry a fair amount, and there are many variables at play that could change th= e nature of the game, I think it's important to clarify the possible sc= enarios up front.

1. Quantum computing never materializes, never bec= omes a threat, and thus everything discussed in this essay is moot.
2. A= quantum computing threat materializes suddenly and Bitcoin does not have q= uantum safe signatures as part of the protocol. In this scenario it would l= ikely make the points below moot because Bitcoin would be fundamentally bro= ken 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 minimally adopte= d by the time an attacker appears.
4. Quantum computing advances slowly = enough that we come to consensus about how to upgrade Bitcoin and post quan= tum security has been highly adopted by the time an attacker appears.
For the purposes of this post, I'm envisioning being in situation 3 o= r 4.

To Freeze or not to Freeze?
I've= started seeing more people weighing in on what is likely the most contenti= ous aspect of how a quantum resistance upgrade should be handled in terms o= f migrating user funds. Should quantum vulnerable funds be left open to be = swept by anyone with a sufficiently powerful quantum computer OR should the= y be permanently locked?

"I don't see why old coins should be confiscated. The bette= r option is to let those with quantum computers free up old coins. While th= is might have an inflationary impact on bitcoin's price, to use a turn = of phrase, the inflation is transitory. Those with low time preference shou= ld support returning lost coins to circulation."=C2=A0
- Hunter Beast
<= div>
On the other hand:

"Of course they have to be confiscated. If and w= hen (and that's a big if) the existence of a cryptography-breaking QC b= ecomes a credible threat, the Bitcoin ecosystem has no other option than so= ftforking out the ability 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 value at all in such a setting. And this affects everyone; even those = which diligently moved their coins to PQC-protected schemes."
- Pie= ter Wuille

I don't think "confiscation" is th= e most precise term to use, as the funds are not being seized and reassigne= d. Rather, what we're really discussing would be better described as &q= uot;burning" - placing the funds out of reach of everyone.
<= br>Not freezing user funds is one of Bitcoin's inviolable properties. H= owever, if quantum computing becomes a threat to Bitcoin's elliptic cur= ve cryptography, an inviolable property of Bitcoin will be violated one = way or another.

Fundamental Properties at Risk<= br>5 years ago I attempted to comprehensively categorize all of Bitc= oin's fundamental properties that give it value. https://nakamoto.com/what-are-the-key-properties-of-b= itcoin/

The particular properties in play with regard to this is= sue seem to be:

Censorship Resistance - No one should have th= e 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 th= e protocol.

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

As a result of the above princi= ples, we have developed a strong meme (kudos to Andreas Antonopoulos) that = goes as follows:

N= ot your keys, not your coins.

I posit that the corollary to= this principle is:

Who is at Risk?
Th= ere 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 quan= tum computer, which coins would I target? I'd go to the Bitcoin rich li= st and find the wallets that have exposed their public keys due to re-using= addresses that have previously been spent from. You can easily find them a= t 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 crac= k because they are multisig wallets. So a quantum attacker would need to re= verse engineer 2 keys for Kraken or 3 for Bitfinex / Tether in order to spe= nd funds. But many are single signature.

Point being, it's not o= nly 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, w= e should expect those wallets to be some of the first to upgrade given thei= r incentives.

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

By making quantu= m vulnerable funds unspendable we potentially harm some Bitcoin users who w= ere 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 los= t funds from falling into the hands of the few privileged folks who gain ea= rly access to quantum computers.

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

Imagine, for example, being James Howells, who acc= identally threw away a hard drive with 8,000 BTC on it, currently worth ove= r $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 the choice, he'd prefer those funds be permanently= frozen rather than fall into someone else's possession - I know I woul= d.

Allowing a quantum computer to access lost funds doesn't make= those users any worse off than they were before, however it would h= ave a negative impact upon everyone who is currently holding bitcoin.
It's prudent to expect significant economic disruption if large amoun= ts 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 i= nvestment. We also know from experience that when someone suddenly finds th= emselves in possession of 9+ figures worth of highly liquid assets, they te= nd to diversify into other things by selling.

Allowing quantum recov= ery 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 those who have won the technological race to acqui= re quantum computers. It's hard to see a bright side to that scenario.<= br>
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 s= ecurity to the network. If anything, it greatly decreases the security of t= he network by allowing funds to be claimed by those who did not earn them.<= br>
But wait, you may be thinking, wouldn't quantum "miners&quo= t; have earned their coins by all the work and resources invested in buildi= ng a quantum computer? I suppose, in the same sense that a burglar earns th= eir spoils by the resources they invest into surveilling targets and learni= ng the skills needed to break into buildings. What I say "earned"= I mean through productive mutual trade.

For example:

* Inves= tors earn BTC by trading for other currencies.
* Merchants earn BTC by t= rading for goods and services.
* Miners earn BTC by trading thermodynami= c security.
* Quantum miners don't trade anything, they are vampires= feeding upon the system.

There's no reason to believe that allo= wing quantum adversaries to recover vulnerable bitcoin will be of benefit t= o 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 a= n organization with quantum supremacy is benevolent and acts in a "whi= te hat" manner to return lost coins to their owners, but that's in= credibly optimistic and foolish to rely upon. Such a situation creates an i= nsurmountable ethical dilemma of only recovering lost bitcoin rather than c= urrently owned bitcoin. There's no way to precisely differentiate betwe= en the two; anyone can claim to have lost their bitcoin but if they have lo= st 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 parties like exchanges.

Even if the= first actor with quantum supremacy is benevolent, we must assume the techn= ology could fall into adversarial hands and thus think adversarially about = the potential worst case outcomes. Imagine, for example, that North Korea c= ontinues scooping up billions of dollars from hacking crypto exchanges and = decides to invest some of those proceeds into building a quantum computer f= or the biggest payday ever...

Downsides to Allowing= Quantum Recovery
Let's think through an exhaustive list of p= ros and cons for allowing or preventing the seizure of funds by a quantum a= dversary.

Historical Precedent
Previous p= rotocol 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-all = rather than a system that seeks to protect its users.

Violation of Property Rights
Allowing a quantum adversary to t= ake control of funds undermines the fundamental principle of cryptocurrency= - if you keep your keys in your possession, only you should be able to acc= ess your money. Bitcoin is built on the idea that private keys secure an in= dividual=E2=80=99s assets, and unauthorized access (even via advanced tech)= is theft, not a legitimate transfer.

Erosion of Tr= ust in Bitcoin
If quantum attackers can exploit vulnerable addres= ses, 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 suc= h, others will find the apathy toward stopping quantum theft to be similarl= y concerning.

Unfair Advantage
Quantum at= tackers, likely equipped with rare and expensive technology, would have an = unjust edge over regular users who lack access to such tools. This creates = an inequitable system where only the technologically elite can exploit othe= rs, contradicting Bitcoin=E2=80=99s ethos of decentralized power.

Bi= tcoin is designed to create an asymmetric advantage for DEFENDING one's= wealth. It's supposed to be impractically expensive for attackers to c= rack the entropy and cryptography protecting one's coins. But now we fi= nd ourselves discussing a situation where this asymmetric advantage is comp= romised in favor of a specific class of attackers.

= Economic Disruption
Large-scale theft from vulnerable addresses c= ould 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 technological superiority justifies unethical behavior. Th= is is essentially taking a "code is law" stance in which we refus= e to admit that both code and laws can be modified to adapt to previously u= nforeseen situations.

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

1. self-enriching & likely malicious<= br>2. harm prevention & not necessarily malicious

Both options l= ack the consent of the party whose coins are being burnt or transferred, th= us I think the simple argument that theft is immoral becomes a wash and it&= #39;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 procrastina= tor. If Bitcoiners are given a "drop dead date" after which they = know vulnerable funds will be burned, this pressure accelerates the adoptio= n of post-quantum cryptography and strengthens Bitcoin long-term. Allowing = vulnerable users to delay upgrading indefinitely will result in more laggar= ds, leaving the network more exposed when quantum tech becomes available.
Steel Manning
Clearly this is a complex an= d controversial topic, thus it's worth thinking through the opposing ar= guments.

Protecting Property Rights
Allow= ing quantum computers to take vulnerable bitcoin could potentially be spun = as a hard money narrative - we care so greatly about not violating someone&= #39;s access to their coins that we allow them to be stolen!

But I t= hink the flip side to the property rights narrative is that burning vulnera= ble coins prevents said property from falling into undeserving hands. If th= e entire Bitcoin ecosystem just stands around and allows quantum adversarie= s to claim funds that rightfully belong to other users, is that really a &q= uot;win" in the "protecting property rights" category? It fe= els more like apathy to me.

As such, I think the "protecting pr= operty rights" argument is a wash.

Quantum Com= puters Won't Attack Bitcoin
There is a great deal of skeptici= sm that sufficiently powerful quantum computers will ever exist, so we shou= ldn't bother preparing for a non-existent threat. Others have argued th= at 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, a= nd would instead attack other infrastructure.

It's quite difficu= lt to quantify exactly how valuable attacking other infrastructure would be= . It also really depends upon when an entity gains quantum supremacy and th= us if by that time most of the world's systems have already been upgrad= ed. While I think you could argue that certain entities gaining quantum cap= ability might not attack Bitcoin, it would only delay the inevitable - even= tually 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 targete= d 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 a= bout that; why go after 50 BTC at a time when you could take 250,000 BTC wi= th the same effort as 50 BTC? This is a classic "zero day exploit"= ; game theory in which an attacker knows they have a limited amount of time= before someone else discovers the exploit and either benefits from it or p= atches it. Take, for example, the recent ByBit attack - the highest value c= rypto hack of all time. Lazarus Group had compromised the Safe wallet front= end JavaScript app and they could have simply had it reassign ownership of= everyone's Safe wallets as they were interacting with their wallet. Bu= t instead they chose to only specifically target ByBit's wallet with $1= .5 billion in it because they wanted to maximize their extractable value. I= f Lazarus had started stealing from every wallet, they would have been disc= overed quickly and the Safe web app would likely have been patched well bef= ore 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 = nowhere safe for vulnerable users to migrate, the only logical option would= be for everyone to liquidate their bitcoin as quickly as possible. As such= , I don't think it applies as strongly for situations in which we have = a migration path available.

The 21 Million Coin Sup= ply Should be in Circulation
Some folks are arguing that it's= important for the "circulating / spendable" supply to be as clos= e to 21M as possible and that having a significant portion of the supply ou= t of circulation is somehow undesirable.

While the "21M BTC&quo= t; attribute is a strong memetic narrative, I don't think anyone has ev= er expected that it would all be in circulation. It has always been underst= ood that many coins will be lost, and that's actually part of the game = theory of owning bitcoin!

And remember, the 21M number in and of its= elf 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 Persona= l 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 compu= ting can break obsolete cryptography, the fault lies with users who didn= 9;t move their funds to quantum safe locking scripts. Expecting the network= to shield users from their own negligence undermines the principle that yo= u, and not a third party, are accountable for your assets.

I think t= his 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, need t= o consider the incentives and game theory in play with regard to quantum sa= fe Bitcoiners vs quantum vulnerable Bitcoiners. More on that later.

= Code is Law
Bitcoin operates on transparent, imm= utable rules embedded in its protocol. If a quantum attacker uses superior = technology to derive private keys from public keys, they=E2=80=99re not &qu= ot;hacking" the system - they're simply following what's mathe= matically permissible within the current code. Altering the protocol to sto= p this introduces subjective human intervention, which clashes with the obj= ective, deterministic nature of blockchain.

While I tend to agree th= at code is law, one of the entire points of laws is that they can be amende= d to improve their efficacy in reducing harm. Leaning on this point seems m= ore like a pro-ossification stance that it's better to do nothing and a= llow harm to occur rather than take action to stop an attack that was fores= een far in advance.

Technological Evolution as a Fe= ature, Not a Bug
It's well known that cryptography tends to w= eaken over time and eventually break. Quantum computing is just the next st= ep in this progression. Users who fail to adapt (e.g., by adopting quantum-= resistant wallets when available) are akin to those who ignored technologic= al advancements like multisig or hardware wallets. Allowing quantum theft i= ncentivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic, punis= hing 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 every= thing. This pressure accelerates the adoption of post-quantum cryptography = and strengthens Bitcoin long-term. Coddling vulnerable users delays this ne= cessary evolution, potentially leaving the network more exposed when quantu= m tech becomes widely accessible. Theft is a brutal but effective teacher.<= br>
Centralized Blacklisting Power
Burning vu= lnerable funds requires centralized decision-making - a soft fork to invali= date certain transactions. This sets a dangerous precedent for future inter= ventions, eroding Bitcoin=E2=80=99s decentralization. If quantum theft is b= locked, what=E2=80=99s next - reversing exchange hacks? The system must rem= ain neutral, even if it means some lose out.

I think this could be a= potential slippery slope if the proposal was to only burn specific address= es. 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 elimin= ate any subjectivity from the code.

Fairness in Com= petition
Quantum attackers aren't cheating; they're using= publicly available physics and math. Anyone with the resources and foresig= ht can build or access quantum tech, just as anyone could mine Bitcoin in 2= 009 with a CPU. Early adopters took risks and reaped rewards; quantum innov= ators are doing the same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that = Bitcoin has never promised equality of outcome - only equality of opportuni= ty within its rules.

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

Economic Resilience
Bitcoin has weathered thefts before = (MTGOX, Bitfinex, FTX, etc) and emerged stronger. The market can absorb qua= ntum losses, with unaffected users continuing to hold and new entrants buyi= ng in at lower prices. Fear of economic collapse overestimates the impact -= the network=E2=80=99s antifragility thrives on such challenges.

Thi= s 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 sufficiently po= werful quantum computers were stealing less volume than the current block r= eward then of course it will have minimal economic impact. But if they'= re taking thousands of BTC per day and bringing them back into circulation,= there will likely be a noticeable market impact as it absorbs the new supp= ly.

This is where the circumstances will really matter. If a quantum= attacker appears AFTER the Bitcoin protocol has been upgraded to support q= uantum resistant cryptography then we should expect the most valuable activ= e wallets will have upgraded and the juiciest target would be the 31,000 BT= C in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant = since 2010. In general I'd expect that the amount of BTC re-entering th= e circulating supply would look somewhat similar to the mining emission cur= ve: volume would start off very high as the most valuable addresses are dra= ined and then it would fall off as quantum computers went down the list tar= geting addresses with less and less BTC.

Why is economic impact a fa= ctor worth considering? Miners and businesses in general. More coins being = liquidated will push down the price, which will negatively impact miner rev= enue. Similarly, I can attest from working in the industry for a decade, th= at lower prices result in less demand from businesses across the entire ind= ustry. As such, burning quantum vulnerable bitcoin is good for the entire i= ndustry.

Practicality & Neutrality of Non-Inter= vention
There=E2=80=99s no reliable way to distinguish =E2=80=9Ct= heft=E2=80=9D from legitimate "white hat" key recovery. If someon= e loses their private key and a quantum computer recovers it, is that steal= ing or reclaiming? Policing quantum actions requires invasive assumptions a= bout intent, which Bitcoin=E2=80=99s trustless design can=E2=80=99t accommo= date. Letting the chips fall where they may avoids this mess.

Philosophical Purity
Bitcoin rejects bailouts. It=E2= =80=99s a cold, hard system where outcomes reflect preparation and skill, n= ot sentimentality. If quantum computing upends the game, that=E2=80=99s the= point - Bitcoin isn=E2=80=99t meant to be safe or fair in a nanny-state se= nse; 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 injustic= e.

Bitcoin's DAO Moment
This situatio= n has some similarities to The DAO hack of an Ethereum smart contract in 20= 16, 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 w= here a threat is known but there's some period of time before the attac= ker can actually execute the theft. As such, there's time to mitigate t= he 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 the attacker to retain control of = the stolen funds.

A soft fork to burn vulnerable bitcoin could certa= inly result in a hard fork if there are enough miners who reject the soft f= ork and continue including transactions.

Incentives= Matter
We can wax philosophical until the cows come home, but wh= at are the actual incentives for existing Bitcoin holders regarding this de= cision?

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

If tru= e, 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 a= re supported within the Bitcoin protocol, what's the incentive to let v= ulnerable coins remain spendable?

* It's not good for the actual= owners of those coins. It disincentivizes owners from upgrading until perh= aps it's too late.
* It's not good for the more attentive / resp= onsible owners of coins who have quantum secured their stash. Allowing the = circulating supply to balloon 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 upg= rade their wallets. If you disagree with the burning of vulnerable coins, a= ll you have to do is move your funds to a quantum safe signature scheme. Po= int being, I don't see there being an economic majority (or even more t= han a tiny minority) of users who would fight such a soft fork. Why expend = significant resources fighting a fork when you can just move your 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 ca= n be meaningfully enacted and enforced by a mere majority of hashpower. If = miners generally agree that it's in their best interest to burn vulnera= ble coins, are other users 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 object= ive as possible, the goal would be to announce to the world that after a sp= ecific block height / timestamp, Bitcoin nodes will no longer accept transa= ctions (or blocks containing such transactions) that spend funds from any s= cripts other than the newly instituted quantum safe schemes.

It coul= d take a staggered approach to first freeze funds that are susceptible to l= ong-range attacks such as those in P2PK scripts or those that exposed their= public keys due to previously re-using addresses, but I expect the additio= nal complexity would drive further controversy.

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

Beyond t= hat, it will take at least 6 months worth of block space for all users to m= igrate their funds, even in a best case scenario. Though if you exclude dus= t UTXOs you could probably get 95% of BTC value migrated in 1 month. Of cou= rse this is a highly optimistic situation where everyone is completely focu= sed 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 logic such that if q= uantum attackers materialized, they could accelerate the countdown to the q= uantum vulnerable funds burn.

Random Tangential Ben= efits
On the plus side, burning all quantum vulnerable bitcoin wo= uld allow us to prune all of those UTXOs out of the UTXO set, which would a= lso 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 = market for a fairly lengthy amount of time.

In Summ= ary
While the moral quandary of violating any of Bitcoin's in= violable properties can make this a very complex issue to discuss, the game= theory and incentives between burning vulnerable coins versus allowing the= m to be claimed by entities with quantum supremacy appears to be a much sim= pler issue.

I, for one, am not interested in rewarding quantum capab= le entities by inflating the circulating money supply just because some peo= ple lost their keys long ago and some laggards are not upgrading their bitc= oin wallet's security.

We can hope that this scenario never come= s 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 cons= ider.

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

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.=
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGXD5f1= eTwqMAkxzdJOup3syR%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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/3fec8fc3-efa1-49c5-8bab-592e0138d31dn%40googlegrou= ps.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/CACgYNOL38xCV8TAMhuHLGhpQO6f4jRc-bxoio-pL%3D6RDRXb11A%40ma= il.gmail.com.
--000000000000b747840650935b87--