From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 08 Jun 2025 07:09:09 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uOGhr-0006g4-Vt for bitcoindev@gnusha.org; Sun, 08 Jun 2025 07:09:08 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-60f3ce73ae2sf2797434eaf.2 for ; Sun, 08 Jun 2025 07:09:04 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749391738; cv=pass; d=google.com; s=arc-20240605; b=da0e+ujG9JV4T7wKwLsVbObqFfMMGMYHhWUa5VDvrKh2KoWM8DuwzZrIlXz+pkYSUA UtVd0d3GX1Ve8MzJNpGqQLaz9Kg+U3jkpbB94FqjN/nNZac31+qlGKtbeLvZ+KCgRklw vbTFzM6GY4yLNQZcUUw4G1nsJ2ygtBtnnjVcOQDCZoryn1ZrsjSOXvpVNXD+ogiR9moA PS9xHF9JxOBtuCq02jbClvHgzDaQsowYJUgNUbigu08w/sZR6iLj+pQHhg71v76hcdBi Xhi3ua86N3j6Z8KiuBtOyemkTtQc9ndVhGiN5kedqAbMnDL+UtHwh5C3/UxgUadIREtZ A1Kw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=SPeH9VVNJ+zI1BuWsh2nB0tARe9R0z3TJMzSykt207k=; fh=S4u7Ot8qqFZNyoBtzDAmosNWb3b7lLKmBnY/L/77cto=; b=G3s7fJQlGrIkmpdvc2qP9w08fS5w85hLsHomRZO64l6XytMfXJHmX3HZfu4M0qVWo3 5KMrRZOpHGUSAhKrfYlVjWzicKVv58kgOJqbCIvOZEiOTyjFQThdMSTyuylgNKaXfLxT 7FSFO7WeJ4GoVrtrF57LSwC6hzFp9bv421gfFO722Hwsmkb6jjXaJC8TW9MWUZ0mM1d1 zDna8ZDqplB3ocpcHlTU0cOtnk1s99A6rzN6cNZRExNgFZCBbetJwba3Eeuxu1Gej7cJ cnCZPTKacYQ+tJJdFq5A+5OnDvSS/LSAnweesECd5cbhdZkkWRIZ/A4+dkcqmiqZGvik MVAA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=iBwnEgXG; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749391738; x=1749996538; 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=SPeH9VVNJ+zI1BuWsh2nB0tARe9R0z3TJMzSykt207k=; b=EfLhmTjuWxvQOteaJTUiQYc2HNsv/06dOONIKbRy0npMVfzMcHBt/QRZPkKmjveUSy 9IxJoPdXlpfCv8cLxEVUO9hOKHOhWZ+Mol9PKh7XQP5VsD00yVnhYwHa3Qi4snJcDv5N xCFIPzOceLqs+scT8s+sXMZG7Oc+kY7HrLybeoG1iqMuNDy3hiffGDRQ+t5tYDI7DZcE V6MCx8MOzaRPvfwkVpRmzCXNjJjnyZ4jgqzVMSj/Di6P3ABO2Cy2o6U0vS/7mROjA1iL iiqCzWrOtncjNaTu52lLdgQWLTRlPktf7qDAbKHwCa0lPbJE3oXu2ykZsv5MU+WlqKG0 XVfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749391738; x=1749996538; 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=SPeH9VVNJ+zI1BuWsh2nB0tARe9R0z3TJMzSykt207k=; b=i/KO5xi7WhMnqydmrUYcoGYkzt8t8Y+qT/V6dU3dHJQamnsXT2nndhybj4wUpy96Vb gnUZsfcmtY53aYqffzCsIGCILgAN2ojHd0Qa8w00w4EccJKhYO01BUtC3hWc8udNYvVM 7oI4nSbU7gxqA5SYL9oX6BjTGpIZ3pERO93rNnjlCNvfepu7Ho2dqliJoJMTN1kJwVYs 67f+BBTtM8Q6Z9+2/ZVEG42Cnod/BqcHBUqP8YEm2HwNIAcLhzjEoLbFJWKmIcyPjwcc KRyLB4tT3VRnihybEHUwLLhPcmu5JHDnlYTxRRMi2KahGdzH4EYwt76gt/B81ToBlfe2 f4zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749391738; x=1749996538; 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-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=SPeH9VVNJ+zI1BuWsh2nB0tARe9R0z3TJMzSykt207k=; b=C0/aCzgc/lHptWtJYx3WzTqBIWHvS8jxe+8/kBst4EPXzt1o8FpTJ915nqdUpVe6la RDB25uzJKzbw/XmkAmQFCm/U12SysKXStJ40O1vKLDSfIUsZfcVc7CTygpbAf0XxzctH vzGKQMkdlhTRmsJq0YOCB0TE4IxD/E+JIFzZ2C8y0GUn/DXZ/+yH6wTKQq63RwDuf3A9 YkhKKdT8DzOC+BheBxKq4eIih7UtiM0daq8lBwvWpWVznoPi2VpOvuDaPwANCv+7fvLz uMGNbUtuNzT2V2WV29ZDhncLOg7t1f24rCmfMDux1dyKLvtffA7/I0JbiTGrdk/o7y2G c99w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWqhExztV7/k/8n2UY2lW3yH8fpBlee/AjljCdBoiwm39XvPzy9qUDZlacInoqqS9O892KZDGmaKl2o@gnusha.org X-Gm-Message-State: AOJu0YxtcAs/CYUFy0YI4F0SmuFm9494SWRjVRGHOvJd42kPuiDnC6Ju qOaDfR4gHHNHORm6/a8kBwno6weCSfWV8kFYtroY7IQ822iNUunWwfJC X-Google-Smtp-Source: AGHT+IEYw+7rdy8qi3XHaJT5scov6+e/u6Q8PiGa5wj+rFY5OjcuuNjmNJbm9pxCEbynoud+TrJM1w== X-Received: by 2002:a05:6820:198c:b0:610:cf37:fa99 with SMTP id 006d021491bc7-610cf37fc7bmr581179eaf.4.1749391737951; Sun, 08 Jun 2025 07:08:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf6JSrscvIAGuCYPfxEiN2MzP9OBSfVpHftyGH9/jEscA== Received: by 2002:a05:6820:3005:b0:60f:f8f:7a6c with SMTP id 006d021491bc7-610cc29407cls75286eaf.1.-pod-prod-09-us; Sun, 08 Jun 2025 07:08:54 -0700 (PDT) X-Received: by 2002:a05:6808:3c8:b0:408:e5f8:9e2b with SMTP id 5614622812f47-409051b14e7mr5225820b6e.10.1749391734739; Sun, 08 Jun 2025 07:08:54 -0700 (PDT) Received: by 2002:ab3:111d:0:b0:2b1:97ca:fe9d with SMTP id a1c4a302cd1d6-2b4e0ec237emsc7a; Sun, 8 Jun 2025 07:04:26 -0700 (PDT) X-Received: by 2002:a05:6512:4020:b0:553:5135:6a13 with SMTP id 2adb3069b0e04-55366bf7c45mr2178068e87.27.1749391463285; Sun, 08 Jun 2025 07:04:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749391463; cv=none; d=google.com; s=arc-20240605; b=i9gkqCcpjzE08My/5ucOA1aecLhDZRue8nUNGSWbOtjeA1UYB9JF4/v/X4VhMD/O1C ZuqAUmEgrfrQ4WF+0/ZJ9MlLoqvtZl9AE96Qajp6INNvJKhClmAXsB4IuNsBNxAhQdUE 5mpi5RSQcrTOj/Y5fwVqHZjLlNXlxMl2eiIepX74B7eHeWI5FKPP++9C2mIPMuZ3wHNR y7/uwPgS11CTMzm5DX3SAduiseLtAR0yvc9jEImMjPTKNQ5GAlk2fIOD9vdRfvcHb69M H31p/h7NW8KnnzGtzD4GyUfBwAcD/eYXU5h0aksEhYJ9NAZEztARhZ/hzsR7GxtgkTk4 SrMw== 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=fTaYvpGad/GiEajslywfnn6Gt0kUX60DNPNhonLbi38=; fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=; b=UoBWfq/pIpXvdLJM9ZSTS0FPFqO5rt/SSy8NnMZbs2W5zsReuLP365yLMm3KK1ALMz JhXqj0G0myJMF/WCguoOHyHnm/aovgtHOA9dOC80zjufhZjs7JwLCJ/7EowRZFp6sCOw 9GvbOP/0fV8UYv/iS13LUhUEoOi8lC9n1UKhvJo0IJBqSa31JpnSXMERZowNSmWzkQma 9wmXrNKqzpW73nSNyhLvX1T6kkyMvHSxvPba1Q27wm+w9De6bvaBB/x9XgRkXamwDu4z XtNNNlxFJmYAsj37BRAdFS4h3zIbbg7lCDumjUp6CAdOxaTnadgWrV6zA6MPEhkX1/Wt Hazw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=iBwnEgXG; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com. [2a00:1450:4864:20::233]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5536772bccdsi217611e87.6.2025.06.08.07.04.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Jun 2025 07:04:23 -0700 (PDT) Received-SPF: pass (google.com: domain of jameson.lopp@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-310447fe59aso34627361fa.0 for ; Sun, 08 Jun 2025 07:04:23 -0700 (PDT) X-Gm-Gg: ASbGncsa+6IGElR5DHBxNr5wj4JMV89aWWlPxjNpZ36HThpgHhOFCBoWAZBQHM10N8m 3IS3pBIMnMfh0l9+nBo7mBi+lVk6TaIsvlhKl271slRnxbxiRnM36C+iVCIpVuQ/smIbpxqvga2 F+p6P7VUezRd1KozN1PgjU4+bXJEKZLzqjhJ+jYoJQvqA= X-Received: by 2002:a05:651c:b0c:b0:32a:d211:2d95 with SMTP id 38308e7fff4ca-32adfd33dcbmr31165361fa.34.1749391462159; Sun, 08 Jun 2025 07:04:22 -0700 (PDT) MIME-Version: 1.0 References: <893891ea-34ec-4d60-9941-9f636be0d747n@googlegroups.com> In-Reply-To: <893891ea-34ec-4d60-9941-9f636be0d747n@googlegroups.com> From: Jameson Lopp Date: Sun, 8 Jun 2025 10:04:09 -0400 X-Gm-Features: AX0GCFskl73kmD2hzSESY1CGBnkwXFhSVGfyG8_UBtx1QXgd86FvtZrbelZi1PA Message-ID: Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin To: "waxwing/ AdamISZ" Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000acdc1706370ff0cd" X-Original-Sender: jameson.lopp@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=iBwnEgXG; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 0.0 (/) --000000000000acdc1706370ff0cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > if developers make a conscious decision to make a code change that confiscates funds, even with a reasonable heads-up, I feel like some lawyers might be tempted to make an argument that those developers should be held responsible for any losses. Anyone can sue anyone for anything, so the mere potential for a lawsuit isn't something that I believe should be taken into consideration with regard to protocol changes. But such an argument would be fundamentally flawed, because developers don't actually enforce changes to the protocol. Enforcement must be performed by miners and node operators. I suspect lawyers would have a tough time finding and suing all of them. Suing someone for running software you dislike also sounds like a pretty weak position; at least in America I'd expect to be protected by freedom of speech. Remember that anyone who might desire to do so is still free to write and run software that rejects those changes. Bitcoin is "trustless" if you validate the state of the network with your own independently controlled full node. But, on the flip side, you must "trust" the rest of the network not to coordinate changes to the network that are to your personal detriment. If a supermajority of sovereign actors decide they need to protect themselves from negative consequences of quantum capable adversaries, I wouldn't expect the threat of lawsuits to stop them. On Sat, Jun 7, 2025 at 9:55=E2=80=AFAM waxwing/ AdamISZ wrote: > > I'm not a lawyer, but if developers make a conscious decision to make a > code change that confiscates funds, even with a reasonable heads-up, I fe= el > like some lawyers might be tempted to make an argument that those > developers should be held responsible for any losses. As everyone knows, > Bitcoin has been under legal attacks before, and I'm not sure that anyone > would (or should) be willing to sign off on a change that might potential= ly > open them up to several billion dollars worth of personal responsibility = - > especially if the "bonded courier" actually shows up and reveals a privat= e > key that would have unlocked funds under the pre-QC scheme. > > Coincidentally, Peter Todd has just made the same point in another > (apparently unrelated) thread, here: > https://groups.google.com/g/bitcoindev/c/bmV1QwYEN4k/m/kkHQZd_BAwAJ > > For me it's very clear, that it's not an accident that such "unexpected" > side effects exist. It's a feature that I'd whimsically call "ethical > impedance-mismatch" (the term impedance mismatch has been used in > computing/programming, which itself borrowed it from the real meaning, in > physics). People have a moral/ethical desire to make bitcoin function as > well as possible, and see a failure mode in those using it for other > purposes, but that line of thought clashes with the essential, basic > principle of censorship-resistance. > > So we see technical borked-ness like failure to get accurate fee rates an= d > the like, from doing something (attempting to filter at p2p level) that i= t > is intrinsically counter to the foundational ethical, functional purpose = of > the system: censorship-resistance. And then we see "cascading failures" o= f > the type discussed here: if the devs are working to break bitcoin's ethic= al > promise of censorship-resistance, then thugs^H^H politicians and lawyers, > will seek to take control of that "break" for their own purposes. > > That's why I'm not against "quantum recovery" as per the title of this > thread. Recovery, independent of outside control, *is* bitcoin's function= . > If half a million btc get spent by someone who has "recovered" in an > unexpected way, tough titties. If the entire system collapses because we > can't get our act together before 2085 (OK I know some think it's 2035, I > don't, but whatever), then it is what it is. That is a huge unknown. But > Bitcoin will 100% fail if confiscation of *any* type becomes a thing. > > Cheers, > AdamISZ/waxwing > On Wednesday, June 4, 2025 at 4:56:53=E2=80=AFAM UTC-3 ArmchairCryptologi= st wrote: > >> Hi, >> >> With the longer grace period and selective deactivation, this seems more >> sensible, but there is one elephant in the room that I haven't seen >> mentioned here - namely, the legal aspect. (If it was, sorry I missed it= .) >> >> I'm not a lawyer, but if developers make a conscious decision to make a >> code change that confiscates funds, even with a reasonable heads-up, I f= eel >> like some lawyers might be tempted to make an argument that those >> developers should be held responsible for any losses. As everyone knows, >> Bitcoin has been under legal attacks before, and I'm not sure that anyon= e >> would (or should) be willing to sign off on a change that might potentia= lly >> open them up to several billion dollars worth of personal responsibility= - >> especially if the "bonded courier" actually shows up and reveals a priva= te >> key that would have unlocked funds under the pre-QC scheme. >> >> The only safe-ish way I can see to do this is to have it only affect >> funds that are very likely to be lost in the first place. So at the very >> least, it could not affect UTXOs that could potentially be encumbered wi= th >> a timelock (i.e. P2SH/P2WSH), and it could only affect UTXOs that have n= ot >> moved for a very long time (say 15-20 years). >> >> If quantum computers capable of practical attacks against Bitcoin are >> ever known to actually exist, *sending*=E2=80=8B to non-PQC addresses sh= ould of >> course be disabled immediately. But I feel that the nature of a >> permissionless system implies a large degree of self-responsibility, so = if >> someone chooses to keep using non-PQC addresses even after PQC addresses >> have become available and practical quantum attacks are suspected to be = an >> imminent danger, it's not necessarily up to the developers to tell them >> they can't, only that they really shouldn't. >> >> -- >> Regards, >> ArmchairCryptologist >> >> Sent with Proton Mail secure email. >> >> On Monday, May 26th, 2025 at 2:48 AM, Agustin Cruz >> wrote: >> >> Hi everyone, >> >> QRAMP proposal aims to manage the quantum transition responsibly without >> disrupting Bitcoin=E2=80=99s core principles. >> >> QRAMP has three phases: >> >> 1. Allow wallets to optionally include PQC keys in Taproot outputs. This >> enables early adoption without forcing anyone. >> >> 2. Announce a soft fork to disable vulnerable scripts, with a long >> (~4-year) grace period. This gives ample time to migrate and avoids sudd= en >> shocks. >> >> 3. Gradually deactivate vulnerable outputs based on age or inactivity. >> This avoids a harsh cutoff and gives time for adaptation. >> >> We can also allow exceptions via proof-of-possession, and delay >> restrictions on timelocked outputs to avoid harming future spenders. >> >> QRAMP is not about confiscation or control. It=E2=80=99s about aligning >> incentives, maintaining security, and offering a clear, non-coercive >> upgrade path. >> >> Best, >> Agustin Cruz >> >> >> >> El dom, 25 de may de 2025, 7:03=E2=80=AFp.m., Dustin Ray >> escribi=C3=B3: >> >>> The difference between the ETH/ETC split though was that no one had >>> anything confiscated except the DAO hacker, everyone retained an identi= cal >>> number of tokens on each chain. The proposal for BTC is very different = in >>> that some holders will lose access to their coins during the PQ migrati= on >>> under the confiscation approach. Just wanted to point that out. >>> >>> On Sun, May 25, 2025 at 3:06=E2=80=AFPM 'conduition' via Bitcoin Develo= pment >>> Mailing List wrote: >>> >>>> Hey Saulo, >>>> >>>> You're right about the possibility of an ugly split. Laggards who don'= t >>>> move coins to PQ address schemes will be incentivized to follow any ch= ain >>>> where they keep their coins. But those who do migrate will be incentiv= ized >>>> to follow the chain where unmigrated pre-quantum coins are frozen. >>>> >>>> While you're comparing this event to the ETH/ETC split, we should >>>> remember that ETH remained the dominant chain despite their heavy-hand= ed >>>> rollback. Just goes to show, confusion and face-loss is a lesser evil = than >>>> allowing an adversary to pwn the network. >>>> >>>> This is the free-market way to solve problems without imposing rules o= n >>>> everyone. >>>> >>>> >>>> It'd still be a free market even if quantum-vulnerable coins are >>>> frozen. The only way to test the relative value of quantum-safe vs >>>> quantum-vulnerable coins is to split the chain and see how the market >>>> reacts. >>>> >>>> IMO, the "free market way" is to give people options and let their >>>> money flow to where it works best. That means people should be able to >>>> choose whether they want their money to be part of a system that allow= s >>>> quantum attack, or part of one which does not. I know which I would ch= oose, >>>> but neither you nor I can make that choice for everyone. >>>> >>>> regards, >>>> conduition >>>> On Monday, March 24th, 2025 at 7:19 AM, Agustin Cruz < >>>> agusti...@gmail.com> wrote: >>>> >>>> I=E2=80=99m against letting quantum computers scoop up funds from addr= esses >>>> that don=E2=80=99t upgrade to quantum-resistant. >>>> Saulo=E2=80=99s idea of a free-market approach, leaving old coins up f= or grabs >>>> if people don=E2=80=99t move them, sounds fair at first. Let luck deci= de, right? >>>> But I worry it=E2=80=99d turn into a mess. If quantum machines start c= racking keys >>>> and snagging coins, it=E2=80=99s not just lost Satoshi-era stuff at ri= sk. Plenty of >>>> active wallets, like those on the rich list Jameson mentioned, could g= et >>>> hit too. Imagine millions of BTC flooding the market. Prices tank, tru= st in >>>> Bitcoin takes a dive, and we all feel the pain. Freezing those vulnera= ble >>>> funds keeps that chaos in check. >>>> Plus, =E2=80=9Cyour keys, your coins=E2=80=9D is Bitcoin=E2=80=99s hea= rt. If quantum tech can >>>> steal from you just because you didn=E2=80=99t upgrade fast enough, th= at promise >>>> feels shaky. Freezing funds after a heads-up period (say, four years) >>>> protects that idea better than letting tech giants or rogue states pla= y >>>> vampire with our network. It also nudges people to get their act toget= her >>>> and move to safer addresses, which strengthens Bitcoin long-term. >>>> Saulo=E2=80=99s right that freezing coins could confuse folks or spark= a split >>>> like Ethereum Classic. But I=E2=80=99d argue quantum theft would look = worse. >>>> Bitcoin would seem broken, not just strict. A clear plan and enough ti= me to >>>> migrate could smooth things over. History=E2=80=99s on our side too. B= itcoin=E2=80=99s >>>> fixed bugs before, like SegWit. This feels like that, not a bailout. >>>> So yeah, I=E2=80=99d rather see vulnerable coins locked than handed to= whoever >>>> builds the first quantum rig. It=E2=80=99s less about coddling people = and more >>>> about keeping Bitcoin solid for everyone. What do you all think? >>>> Cheers, >>>> Agust=C3=ADn >>>> >>>> >>>> On Sun, Mar 23, 2025 at 10:29=E2=80=AFPM AstroTown wrote: >>>> >>>>> I believe that having some entity announce the decision to freeze old >>>>> UTXOs would be more damaging to Bitcoin=E2=80=99s image (and its valu= e) than having >>>>> them gathered by QC. This would create another version of Bitcoin, si= milar >>>>> to Ethereum Classic, causing confusion in the market. >>>>> >>>>> It would be better to simply implement the possibility of moving fund= s >>>>> to a PQC address without a deadline, allowing those who fail to do so= to >>>>> rely on luck to avoid having their coins stolen. Most coins would be >>>>> migrated to PQC anyway, and in most cases, only the lost ones would r= emain >>>>> vulnerable. This is the free-market way to solve problems without imp= osing >>>>> rules on everyone. >>>>> >>>>> Saulo Fonseca >>>>> >>>>> >>>>> On 16. Mar 2025, at 15:15, Jameson Lopp wrote: >>>>> >>>>> The quantum computing debate is heating up. There are many >>>>> controversial aspects to this debate, including whether or not quantu= m >>>>> computers will ever actually become a practical threat. >>>>> >>>>> I won't tread into the unanswerable question of how worried we should >>>>> be about quantum computers. I think it's far from a crisis, but given= the >>>>> difficulty in changing Bitcoin it's worth starting to seriously discu= ss. >>>>> Today I wish to focus on a philosophical quandary related to one of t= he >>>>> decisions that would need to be made if and when we implement a quant= um >>>>> safe signature scheme. >>>>> >>>>> Several Scenarios >>>>> Because this essay will reference game theory a fair amount, and ther= e >>>>> 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 sce= nario >>>>> it would likely make the points below moot because Bitcoin would be >>>>> fundamentally broken and it would take far too long to upgrade the >>>>> protocol, wallet software, and migrate user funds in order to restore >>>>> confidence in the network. >>>>> 3. Quantum computing advances slowly enough that we come to consensus >>>>> about how to upgrade Bitcoin and post quantum security has been minim= ally >>>>> adopted by the time an attacker appears. >>>>> 4. Quantum computing advances slowly enough that we come to consensus >>>>> about how to upgrade Bitcoin and post quantum security has been highl= y >>>>> 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 mos= t >>>>> contentious aspect of how a quantum resistance upgrade should be hand= led in >>>>> terms of migrating user funds. Should quantum vulnerable funds be lef= t open >>>>> to be swept by anyone with a sufficiently powerful quantum computer O= R >>>>> should they be permanently locked? >>>>> >>>>> "I don't see why old coins should be confiscated. The better option i= s >>>>>> to let those with quantum computers free up old coins. While this mi= ght >>>>>> have an inflationary impact on bitcoin's price, to use a turn of phr= ase, >>>>>> the inflation is transitory. Those with low time preference should s= upport >>>>>> returning lost coins to circulation." >>>>> >>>>> - Hunter Beast >>>>> >>>>> >>>>> On the other hand: >>>>> >>>>> "Of course they have to be confiscated. If and when (and that's a big >>>>>> if) the existence of a cryptography-breaking QC becomes a credible t= hreat, >>>>>> the Bitcoin ecosystem has no other option than softforking out the a= bility >>>>>> to spend from signature schemes (including ECDSA and BIP340) that ar= e >>>>>> 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 whic= h >>>>>> diligently moved their coins to PQC-protected schemes." >>>>>> - Pieter Wuille >>>>> >>>>> >>>>> I don't think "confiscation" is the most precise term to use, as the >>>>> funds are not being seized and reassigned. Rather, what we're really >>>>> discussing would be better described as "burning" - placing the funds= *out >>>>> of reach of everyone*. >>>>> >>>>> Not freezing user funds is one of Bitcoin's inviolable properties. >>>>> However, if quantum computing becomes a threat to Bitcoin's elliptic = 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 b= e: >>>>> >>>>> *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 protoco= l. >>>>> >>>>> *Conservatism* - Users should not be expected to be highly responsive >>>>> to system issues. >>>>> >>>>> As a result of the above principles, we have developed a strong meme >>>>> (kudos to Andreas Antonopoulos) that goes as follows: >>>>> >>>>> Not your keys, not your coins. >>>>> >>>>> >>>>> I posit that the corollary to this principle is: >>>>> >>>>> Your keys, only your coins. >>>>> >>>>> >>>>> A quantum capable entity breaks the corollary of this foundational >>>>> principle. We secure our bitcoin with the mathematical probabilities >>>>> related to extremely large random numbers. Your funds are only secure >>>>> because truly random large numbers should not be guessable or discove= rable >>>>> 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 princip= le 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 qua= ntum >>>>> "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 r= ich >>>>> list and find the wallets that have exposed their public keys due to >>>>> re-using addresses that have previously been spent from. You can easi= ly >>>>> 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 signat= ure. >>>>> >>>>> Point being, it's not only the really old lost BTC that are at risk t= o >>>>> a quantum enabled adversary, at least at time of writing. If we add a >>>>> quantum safe signature scheme, we should expect those wallets to be s= ome 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 mig= rate >>>>> their funds to a quantum safe locking script. This violates the >>>>> "conservativism" principle stated earlier. On the flip side, we preve= nt >>>>> those funds plus far more lost funds from falling into the hands of t= he 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 them >>>>> stolen. And many early adopters who lost their keys will eventually s= ee >>>>> their unreachable funds scooped up by a quantum enabled adversary. >>>>> >>>>> Imagine, for example, being James Howells, who accidentally threw awa= y >>>>> a hard drive with 8,000 BTC on it, currently worth over $600M USD. He= has >>>>> spent a decade trying to retrieve it from the landfill where he knows= it's >>>>> buried, but can't get permission to excavate. I suspect that, given t= he >>>>> choice, he'd prefer those funds be permanently frozen rather than fal= l 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 goi= ng to >>>>> have a massive up front cost, expect those behind it to desire to rec= oup >>>>> their investment. We also know from experience that when someone sudd= enly >>>>> finds themselves in possession of 9+ figures worth of highly liquid a= ssets, >>>>> 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 tho= se who >>>>> have won the technological race to acquire quantum computers. It's ha= rd 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 argumen= t >>>>> that it's a net positive in any way. It certainly doesn't add any sec= urity >>>>> to the network. If anything, it greatly decreases the security of the >>>>> network by allowing funds to be claimed by those who did not earn the= m. >>>>> >>>>> But wait, you may be thinking, wouldn't quantum "miners" have earned >>>>> their coins by all the work and resources invested in building a quan= tum >>>>> computer? I suppose, in the same sense that a burglar earns their spo= ils by >>>>> the resources they invest into surveilling targets and learning the s= kills >>>>> needed to break into buildings. What I say "earned" I mean through >>>>> productive mutual trade. >>>>> >>>>> For example: >>>>> >>>>> * Investors earn BTC by trading for other currencies. >>>>> * Merchants earn BTC by trading for goods and services. >>>>> * Miners earn BTC by trading thermodynamic security. >>>>> * Quantum miners don't trade anything, they are vampires feeding upon >>>>> the system. >>>>> >>>>> There's no reason to believe that allowing quantum adversaries to >>>>> recover vulnerable bitcoin will be of benefit to anyone other than th= e >>>>> select few organizations that win the technological arms race to buil= d the >>>>> first such computers. Probably nation states and/or the top few large= st >>>>> 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 t= o >>>>> their owners, but that's incredibly optimistic and foolish to rely up= on. >>>>> 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 ever= had >>>>> the keys becomes rather difficult. I imagine that any such white hat >>>>> recovery efforts would have to rely upon attestations from trusted th= ird >>>>> parties like exchanges. >>>>> >>>>> Even if the first actor with quantum supremacy is benevolent, we must >>>>> assume the technology could fall into adversarial hands and thus thin= k >>>>> adversarially about the potential worst case outcomes. Imagine, for >>>>> example, that North Korea continues scooping up billions of dollars f= rom >>>>> hacking crypto exchanges and decides to invest some of those proceeds= into >>>>> building a quantum computer for the biggest payday ever... >>>>> >>>>> Downsides to Allowing Quantum Recovery >>>>> Let's think through an exhaustive list of pros and cons for allowing >>>>> or preventing the seizure of funds by a quantum adversary. >>>>> >>>>> Historical Precedent >>>>> Previous protocol vulnerabilities weren=E2=80=99t celebrated as "fair= game" >>>>> but rather were treated as failures to be remediated. Treating quantu= m >>>>> theft 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 take control of funds undermines the >>>>> fundamental principle of cryptocurrency - if you keep your keys in yo= ur >>>>> 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 legitima= te >>>>> 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 investor= s rely >>>>> on cryptographic integrity, and widespread theft could drive adoption= away >>>>> from Bitcoin, destabilizing its ecosystem. >>>>> >>>>> This is essentially the counterpoint to claiming the burning of >>>>> vulnerable funds is a violation of property rights. While some will >>>>> certainly see it as such, others will find the apathy toward stopping >>>>> quantum theft to be similarly concerning. >>>>> >>>>> Unfair Advantage >>>>> Quantum attackers, likely equipped with rare and expensive technology= , >>>>> would have an unjust edge over regular users who lack access to such = tools. >>>>> This creates an inequitable system where only the technologically eli= te can >>>>> exploit others, contradicting Bitcoin=E2=80=99s ethos of decentralize= d power. >>>>> >>>>> Bitcoin is designed to create an asymmetric advantage for DEFENDING >>>>> one's wealth. It's supposed to be impractically expensive for attacke= rs to >>>>> crack the entropy and cryptography protecting one's coins. But now we= find >>>>> ourselves discussing a situation where this asymmetric advantage is >>>>> compromised in favor of a specific class of attackers. >>>>> >>>>> Economic Disruption >>>>> Large-scale theft from vulnerable addresses could crash Bitcoin=E2=80= =99s >>>>> price as quantum recovered funds are dumped on exchanges. This would = harm >>>>> all holders, not just those directly targeted, leading to broader fin= ancial >>>>> chaos in the markets. >>>>> >>>>> Moral Responsibility >>>>> Permitting theft via quantum computing sets a precedent that >>>>> technological superiority justifies unethical behavior. This is essen= tially >>>>> taking a "code is law" stance in which we refuse to admit that both c= ode >>>>> and laws can be modified to adapt to previously unforeseen situations= . >>>>> >>>>> Burning of coins can certainly be considered a form of theft, thus I >>>>> think it's worth differentiating the two different thefts being discu= ssed: >>>>> >>>>> 1. self-enriching & likely malicious >>>>> 2. harm prevention & not necessarily malicious >>>>> >>>>> Both options lack the consent of the party whose coins are being burn= t >>>>> or transferred, thus I think the simple argument that theft is immora= l >>>>> becomes a wash and it's important to drill down into the details of e= ach. >>>>> >>>>> Incentives Drive Security >>>>> I can tell you from a decade of working in Bitcoin security - the >>>>> average user is lazy and is a procrastinator. If Bitcoiners are given= a >>>>> "drop dead date" after which they know vulnerable funds will be burne= d, >>>>> this pressure accelerates the adoption of post-quantum cryptography a= nd >>>>> strengthens Bitcoin long-term. Allowing vulnerable users to delay upg= rading >>>>> indefinitely will result in more laggards, leaving the network more e= xposed >>>>> 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 ab= out >>>>> not violating someone's access to their coins that we allow them to b= e >>>>> stolen! >>>>> >>>>> But I think the flip side to the property rights narrative is that >>>>> burning vulnerable coins prevents said property from falling into >>>>> undeserving hands. If the entire Bitcoin ecosystem just stands around= and >>>>> allows quantum adversaries to claim funds that rightfully belong to o= ther >>>>> users, is that really a "win" in the "protecting property rights" cat= egory? >>>>> 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 quantu= m >>>>> 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 wou= ldn't >>>>> want to reveal their hand by doing so, and would instead attack other >>>>> infrastructure. >>>>> >>>>> It's quite difficult to quantify exactly how valuable attacking other >>>>> infrastructure would be. It also really depends upon when an entity g= ains >>>>> quantum supremacy and thus if by that time most of the world's system= s have >>>>> already been upgraded. While I think you could argue that certain ent= ities >>>>> gaining quantum capability might not attack Bitcoin, it would only de= lay >>>>> 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 arous= e >>>>> 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 clas= sic >>>>> "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 a= ttack >>>>> - the highest value crypto hack of all time. Lazarus Group had compro= mised >>>>> the Safe wallet front end JavaScript app and they could have simply h= ad it >>>>> reassign ownership of everyone's Safe wallets as they were interactin= g with >>>>> their wallet. But instead they chose to only specifically target ByBi= t'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 mali= cious >>>>> code. >>>>> >>>>> I think the "only stealing small amounts" argument is strongest for >>>>> Situation #2 described earlier, where a quantum attacker arrives befo= re >>>>> quantum safe cryptography has been deployed across the Bitcoin ecosys= tem. >>>>> Because if it became clear that Bitcoin's cryptography was broken AND= there >>>>> was nowhere safe for vulnerable users to migrate, the only logical op= tion >>>>> would be for everyone to liquidate their bitcoin as quickly as possib= le. As >>>>> such, I don't think it applies as strongly for situations in which we= have >>>>> a migration path available. >>>>> >>>>> The 21 Million Coin Supply Should be in Circulation >>>>> Some folks are arguing that it's important for the "circulating / >>>>> spendable" supply to be as close to 21M as possible and that having a >>>>> significant portion of the supply out of circulation is somehow undes= irable. >>>>> >>>>> 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. I= t has >>>>> always been understood that many coins will be lost, and that's actua= lly >>>>> 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 we= alth, >>>>> free from centralized intervention. This freedom comes with the burde= n of >>>>> securing one's private keys. If quantum computing can break obsolete >>>>> cryptography, the fault lies with users who didn't move their funds t= o >>>>> quantum safe locking scripts. Expecting the network to shield users f= rom >>>>> their own negligence undermines the principle that you, and not a thi= rd >>>>> 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, however= , need >>>>> to consider the incentives and game theory in play with regard to qua= ntum >>>>> 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 pr= ivate >>>>> keys from public keys, they=E2=80=99re not "hacking" the system - the= y'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 reducin= g >>>>> harm. Leaning on this point seems more like a pro-ossification stance= that >>>>> it's better to do nothing and allow harm to occur rather than take ac= tion >>>>> 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-resis= tant >>>>> wallets when available) are akin to those who ignored technological >>>>> advancements like multisig or hardware wallets. Allowing quantum thef= t >>>>> incentivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic= , punishing >>>>> complacency while rewarding vigilance. >>>>> >>>>> Market Signals Drive Security >>>>> If quantum attackers start stealing funds, it sends a clear signal to >>>>> the market: upgrade your security or lose everything. This pressure >>>>> accelerates the adoption of post-quantum cryptography and strengthens >>>>> Bitcoin long-term. Coddling vulnerable users delays this necessary >>>>> evolution, potentially leaving the network more exposed when quantum = tech >>>>> becomes widely accessible. Theft is a brutal but effective teacher. >>>>> >>>>> Centralized Blacklisting Power >>>>> Burning vulnerable funds requires centralized decision-making - a sof= t >>>>> fork to invalidate certain transactions. This sets a dangerous preced= ent >>>>> for future interventions, eroding Bitcoin=E2=80=99s decentralization.= If quantum >>>>> theft is blocked, what=E2=80=99s next - reversing exchange hacks? The= system must >>>>> remain neutral, even if it means some lose out. >>>>> >>>>> I think this could be a potential slippery slope if the proposal was >>>>> to only burn specific addresses. Rather, I'd expect a neutral proposa= l 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 o= r >>>>> 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 ha= s 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 unaffect= ed >>>>> users continuing to hold and new entrants buying in at lower prices. = Fear >>>>> of economic collapse overestimates the impact - the network=E2=80=99s= antifragility >>>>> thrives on such challenges. >>>>> >>>>> This is a big grey area because we don't know when a quantum computer >>>>> will come online and we don't know how quickly said computers would b= e able >>>>> to steal bitcoin. If, for example, the first generation of sufficient= ly >>>>> powerful quantum computers were stealing less volume than the current= block >>>>> reward then of course it will have minimal economic impact. But if th= ey're >>>>> taking thousands of BTC per day and bringing them back into circulati= on, >>>>> there will likely be a noticeable market impact as it absorbs the new >>>>> supply. >>>>> >>>>> This is where the circumstances will really matter. If a quantum >>>>> attacker appears AFTER the Bitcoin protocol has been upgraded to supp= ort >>>>> quantum resistant cryptography then we should expect the most valuabl= e >>>>> active wallets will have upgraded and the juiciest target would be th= e >>>>> 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which ha= s been >>>>> dormant since 2010. In general I'd expect that the amount of BTC >>>>> re-entering the circulating supply would look somewhat similar to the >>>>> mining emission curve: volume would start off very high as the most >>>>> valuable addresses are drained and then it would fall off as quantum >>>>> computers went down the list targeting addresses with less and less B= TC. >>>>> >>>>> Why is economic impact a factor worth considering? Miners and >>>>> businesses in general. More coins being liquidated will push down the >>>>> price, which will negatively impact miner revenue. Similarly, I can a= ttest >>>>> from working in the industry for a decade, that lower prices result i= n less >>>>> demand from businesses across the entire industry. As such, burning q= uantum >>>>> 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 quantu= m >>>>> actions requires invasive assumptions about intent, which Bitcoin=E2= =80=99s >>>>> trustless design can=E2=80=99t accommodate. Letting the chips fall wh= ere they may >>>>> avoids this mess. >>>>> >>>>> Philosophical Purity >>>>> Bitcoin rejects bailouts. It=E2=80=99s a cold, hard system where outc= omes >>>>> reflect preparation and skill, not sentimentality. If quantum computi= ng >>>>> upends the game, that=E2=80=99s the point - Bitcoin isn=E2=80=99t mea= nt to be safe or fair >>>>> in a nanny-state sense; it=E2=80=99s meant to be free. Users who lose= funds to >>>>> quantum attacks are casualties of liberty and their own ignorance, no= t >>>>> victims of injustice. >>>>> >>>>> Bitcoin's DAO Moment >>>>> This situation has some similarities to The DAO hack of an Ethereum >>>>> smart contract in 2016, which resulted in a fork to stop the attacker= and >>>>> return funds to their original owners. The game theory is similar bec= ause >>>>> it's a situation where a threat is known but there's some period of t= ime >>>>> 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 con= tinue >>>>> 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 decisio= n? >>>>> >>>>> "Lost coins only make everyone else's coins worth slightly more. Thin= k >>>>>> 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 le= t >>>>> vulnerable coins remain spendable? >>>>> >>>>> * It's not good for the actual owners of those coins. It >>>>> disincentivizes owners from upgrading until perhaps it's too late. >>>>> * It's not good for the more attentive / responsible owners of coins >>>>> who have quantum secured their stash. Allowing the circulating supply= to >>>>> balloon will assuredly reduce the purchasing power of all bitcoin hol= ders. >>>>> >>>>> Forking Game Theory >>>>> From a game theory point of view, I see this as incentivizing users t= o >>>>> upgrade their wallets. If you disagree with the burning of vulnerable >>>>> coins, all you have to do is move your funds to a quantum safe signat= ure >>>>> scheme. Point being, I don't see there being an economic majority (or= even >>>>> more than a tiny minority) of users who would fight such a soft fork.= Why >>>>> expend significant resources fighting a fork when you can just move y= our >>>>> coins to a new address? >>>>> >>>>> Remember that blocking spending of certain classes of locking scripts >>>>> is a tightening of the rules - a soft fork. As such, it can be meanin= gfully >>>>> enacted and enforced by a mere majority of hashpower. If miners gener= ally >>>>> 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 softw= are >>>>> 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 announc= e >>>>> to the world that after a specific block height / timestamp, Bitcoin = nodes >>>>> will no longer accept transactions (or blocks containing such transac= tions) >>>>> that spend funds from any scripts other than the newly instituted qua= ntum >>>>> 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 th= ose >>>>> 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 able= to >>>>> implement post quantum cryptography on their existing hardware with o= nly 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. Thoug= h if >>>>> you exclude dust UTXOs you could probably get 95% of BTC value migrat= ed in >>>>> 1 month. Of course this is a highly optimistic situation where everyo= ne is >>>>> completely focused on migrations - in reality it will take far longer= . >>>>> >>>>> Regardless, I'd think that in order to reasonably uphold Bitcoin's >>>>> conservatism it would be preferable to allow a 4 year migration windo= w. In >>>>> the meantime, mining pools could coordinate emergency soft forking lo= gic >>>>> such that if quantum attackers materialized, they could accelerate th= e >>>>> 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 UTXO >>>>> set will create substantial demand for block space that will sustain = a fee >>>>> market for a fairly lengthy amount of time. >>>>> >>>>> In Summary >>>>> While the moral quandary of violating any of Bitcoin's inviolable >>>>> properties can make this a very complex issue to discuss, the game th= eory >>>>> and incentives between burning vulnerable coins versus allowing them = to be >>>>> claimed by entities with quantum supremacy appears to be a much simpl= er >>>>> issue. >>>>> >>>>> I, for one, am not interested in rewarding quantum capable entities b= y >>>>> inflating the circulating money supply just because some people lost = their >>>>> keys long ago and some laggards are not upgrading their bitcoin walle= t'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 contributio= n >>>>> 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, sen= d >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReM= q8nA_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/E8269A1A-1899-46D2-A7CD-= 4D9D2B732364%40astrotown.de >>>>> . >>>> >>>> >>>>> -- >>>> 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/CAJDmzYxw%2BmXQKjS%2Bh%2B= r6mCoe1rwWUpa_yZDwmwx6U_eO5JhZLg%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+...@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/zyx7G6H1TyB2sWVEKAfIYmCCv= fXniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuHMjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAX= LmiCJOY%3D%40proton.me >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+...@googlegroups.com. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAJDmzYycnXODG_e9ATqTkooUu3= C-RS703P1-RQLW5CdcCehsqg%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/893891ea-34ec-4d60-9941-9f63= 6be0d747n%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/= CADL_X_dz6Zuoh6T%3Dp%2B531kQkgVUbr5iKHeLNe01s5%3DQDp6iw9g%40mail.gmail.com. --000000000000acdc1706370ff0cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0if developers make a conscious decision to make a code change t= hat confiscates funds, even with a reasonable heads-up, I feel like some la= wyers might be tempted to make an argument that those developers should be = held responsible for any losses.

Anyone can sue anyone for anything, so = the mere potential for a lawsuit isn't something that I believe should = be taken into consideration with regard to protocol changes.

<= /div>
But s= uch an argument would be fundamentally flawed, because developers don't= actually enforce changes to the protocol. Enforcement must be performed by= miners and node operators. I suspect lawyers would have a tough time findi= ng and suing all of them. Suing someone for running software you dislike al= so sounds like a pretty weak position; at least in America I'd expect t= o be protected by freedom of speech. Remember that anyone who might desire = to do so is still free to write and run software that rejects those changes= .

Bitcoin is "trustless" if you validate the state of th= e network with your own independently controlled full node. But, on the fli= p side, you must "trust" the rest of the network not to coordinat= e changes to the network that are to your personal detriment. If a supermaj= ority of sovereign actors decide they need to protect themselves from negat= ive consequences of quantum capable adversaries, I wouldn't expect the = threat of lawsuits to stop them.

On Sat, = Jun 7, 2025 at 9:55=E2=80=AFAM waxwing/ AdamISZ <ekaggata@gmail.com> wrote:
> I'm not a lawyer, but if dev= elopers make a conscious decision to make a=20 code change that confiscates funds, even with a reasonable heads-up, I=20 feel like some lawyers might be tempted to make an argument that those=20 developers should be held responsible for any losses. As everyone knows, Bitcoin has been under legal attacks before, and I'm not sure that=20 anyone would (or should) be willing to sign off on a change that might=20 potentially open them up to several billion dollars worth of personal=20 responsibility - especially if the "bonded courier" actually show= s up=20 and reveals a private key that would have unlocked funds under the=20 pre-QC scheme.

Coincidentally, Peter Todd has just= made the same point in another (apparently unrelated) thread, here: https://groups.google.com/g/bitcoindev/c/bmV1QwYEN4k/m/kkH= QZd_BAwAJ

For me it's very clear, that it&= #39;s not an accident that such "unexpected" side effects exist. = It's a feature that I'd whimsically call "ethical impedance-mi= smatch" (the term impedance mismatch has been used in computing/progra= mming, which itself borrowed it from the real meaning, in physics). People = have a moral/ethical desire to make bitcoin function as well as possible, a= nd see a failure mode in those using it for other purposes, but that line o= f thought clashes with the essential, basic principle of censorship-resista= nce.

So we see technical borked-ness like failure = to get accurate fee rates and the like, from doing something (attempting to= filter at p2p level) that it is intrinsically counter to the foundational = ethical, functional purpose of the system: censorship-resistance. And then = we see "cascading failures" of the type discussed here: if the de= vs are working to break bitcoin's ethical promise of censorship-resista= nce, then thugs^H^H politicians and lawyers, will seek to take control of t= hat "break" for their own purposes.

That= 's why I'm not against "quantum recovery" as per the titl= e of this thread. Recovery, independent of outside control, *is* bitcoin= 9;s function. If half a million btc get spent by someone who has "reco= vered" in an unexpected way, tough titties. If the entire system colla= pses because we can't get our act together before 2085 (OK I know some = think it's 2035, I don't, but whatever), then it is what it is. Tha= t is a huge unknown. But Bitcoin will 100% fail if confiscation of *any* ty= pe becomes a thing.

Cheers,
AdamISZ/waxwing
On Wednesday, June 4, = 2025 at 4:56:53=E2=80=AFAM UTC-3 ArmchairCryptologist wrote:
Hi,

With the longer grace period and selective deactivation, th= is seems more sensible, but there is one elephant in the room that I haven&= #39;t seen mentioned here - namely, the legal aspect. (If it was, sorry I m= issed it.)
=
I'= m not a lawyer, but if developers make a conscious decision to make a code = change that confiscates funds, even with a reasonable heads-up, I feel like= some lawyers might be tempted to make an argument that those developers sh= ould be held responsible for any losses. As everyone knows, Bitcoin has bee= n under legal attacks before, and I'm not sure that anyone would (or sh= ould) be willing to sign off on a change that might potentially open them u= p to several billion dollars worth of personal responsibility - especially = if the "bonded courier" actually shows up and reveals a private k= ey that would have unlocked funds under the pre-QC scheme.

The only safe-ish way I can see = to do this is to have it only affect funds that are very likely to be lost = in the first place. So at the very least, it could not affect UTXOs that coul= d potentially be encumbered with a timelock (i.e. P2SH/P2WSH), and it could= only affect UTXOs that have not moved for a very long time (say 15-20 year= s).

If quantum c= omputers capable of practical attacks against Bitcoin are ever known to act= ually exist, sending=E2=80=8B to non-PQC addresses should of course = be disabled immediately. But I feel that the nature of a permissionless sys= tem implies a large degree of self-responsibility, so if someone chooses to= keep using non-PQC addresses even after PQC addresses have become availabl= e and practical quantum attacks are suspected to be an imminent danger, it&= #39;s not necessarily up to the developers to tell them they can't, onl= y that they really shouldn't.

--
Regards,
ArmchairCryptologist

=20
=20
Sent with Proton Mail secure email.

<= /div>
On Monday, May 26th, 2025 at 2:48 AM, Agustin Cruz <agusti...@gmail.com> wrote:
Hi everyone,

QRAMP proposal aims to manage the quantum transition responsib= ly without disrupting Bitcoin=E2=80=99s core principles.

QRAMP has three phases:

1. Allow wallets to optionally include PQC= keys in Taproot outputs. This enables early adoption without forcing anyon= e.

2. Announce a soft fo= rk to disable vulnerable scripts, with a long (~4-year) grace period. This = gives ample time to migrate and avoids sudden shocks.

3. Gradually deactivate vulnerable outputs ba= sed on age or inactivity. This avoids a harsh cutoff and gives time for ada= ptation.

We can also allow exceptions via proof-of-possession, and delay r= estrictions on timelocked outputs to avoid harming future spenders.

QRAMP is not about confiscation= or control. It=E2=80=99s about aligning incentives, maintaining security, = and offering a clear, non-coercive upgrade path.
Best,
Agustin Cruz



El dom, 25 de may de= 2025, 7:03=E2=80=AFp.m., Dustin Ray <dustinvo...@gmail.com> escribi=C3=B3:
The difference between= the ETH/ETC split though was that no one had anything confiscated except t= he DAO hacker, everyone retained an identical number of tokens on each chai= n. The proposal for BTC is very different in that some holders will lose ac= cess to their coins during the PQ migration under the confiscation approach= . Just wanted to point that out.

<= div class=3D"gmail_attr" dir=3D"ltr">On Sun, May 25, 2025 at 3:06=E2=80=AFP= M 'conduition' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hey Saulo,

You're right about the possibility of a= n ugly split. Laggards who don't move coins to PQ address schemes will = be incentivized to follow any chain where they keep their coins. But those = who do migrate will be incentivized to follow the chain where unmigrated pr= e-quantum coins are frozen.

While you're comparing this event to the ETH/ETC split, we = should remember that ETH remained the dominant chain despite their heavy-ha= nded rollback. Just goes to show, confusion and face-loss is a lesser evil = than allowing an adversary to pwn the network.

This is the free-market way to solve problems without imposi= ng rules on everyone.

It'd still be a free market even if quantum-vulne= rable coins are frozen. The only way to test the relative value of quantum-= safe vs quantum-vulnerable coins is to split the chain and see how the mark= et reacts.

IMO, = the "free market way" is to give people options and let their mon= ey flow to where it works best. That means people should be able to choose = whether they want their money to be part of a system that allows quantum at= tack, or part of one which does not. I know which I would choose, but neith= er you nor I can make that choice for everyone.

regards,
conduition
On Monday, March 24th, 2025 at 7:19 AM, Agustin Cruz <agusti...@gmail.com> wrote:
I=E2=80=99m against letting q= uantum computers scoop up funds from addresses that don=E2=80=99t upgrade t= o quantum-resistant.
Saulo=E2=80=99s idea of a free-market approach, le= aving old coins up for grabs if people don=E2=80=99t move them, sounds fair= at first. Let luck decide, right? But I worry it=E2=80=99d turn into a mes= s. If quantum machines start cracking keys and snagging coins, it=E2=80=99s= not just lost Satoshi-era stuff at risk. Plenty of active wallets, like th= ose on the rich list Jameson mentioned, could get hit too. Imagine millions= of BTC flooding the market. Prices tank, trust in Bitcoin takes a dive, an= d we all feel the pain. Freezing those vulnerable funds keeps that chaos in= check.
Plus, =E2=80=9Cyour keys, your coins=E2=80=9D is Bitcoin=E2=80= =99s heart. If quantum tech can steal from you just because you didn=E2=80= =99t upgrade fast enough, that promise feels shaky. Freezing funds after a = heads-up period (say, four years) protects that idea better than letting te= ch giants or rogue states play vampire with our network. It also nudges peo= ple to get their act together and move to safer addresses, which strengthen= s Bitcoin long-term.
Saulo=E2=80=99s right that freezing coins could con= fuse folks or spark a split like Ethereum Classic. But I=E2=80=99d argue qu= antum theft would look worse. Bitcoin would seem broken, not just strict. A= clear plan and enough time to migrate could smooth things over. History=E2= =80=99s on our side too. Bitcoin=E2=80=99s fixed bugs before, like SegWit. = This feels like that, not a bailout.
So yeah, I=E2=80=99d rather see vul= nerable coins locked than handed to whoever builds the first quantum rig. I= t=E2=80=99s less about coddling people and more about keeping Bitcoin solid= for everyone. What do you all think?
Cheers,
Agust=C3=ADn


On = Sun, Mar 23, 2025 at 10:29=E2=80=AFPM AstroTown <sa...@astrotown.de> wrote:
I believe that having some entity announce the = decision to freeze old UTXOs would be more damaging to Bitcoin=E2=80=99s im= age (and its value) than having them gathered by QC. This would create anot= her version of Bitcoin, similar to Ethereum Classic, causing confusion in t= he market.

It would be better to simply implement the= possibility of moving funds to a PQC address without a deadline, allowing = those who fail to do so to rely on luck to avoid having their coins stolen.= Most coins would be migrated to PQC anyway, and in most cases, only the lo= st ones would remain vulnerable. This is the free-market way to solve probl= ems without imposing rules on everyone.

Saulo Fonseca


On 16. Mar 2025, at 15:15, Jameson Lopp <jameso...@gmail.com<= /span>> wrote:

The quantum computing deba= te is heating up. There are many controversial aspects to this debate, incl= uding whether or not quantum computers will ever actually become a practica= l threat.

I won't tread into the unanswerable question of how w= orried we should be about quantum computers. I think it's far from a cr= isis, but given the difficulty in changing Bitcoin it's worth starting = to seriously discuss. Today I wish to focus on a philosophical quandary rel= ated to one of the decisions that would need to be made if and when we impl= ement a quantum safe signature scheme.

Several Scenarios
Because this essay will referenc= e game theory a fair amount, and there are many variables at play that coul= d 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 mo= ot.
2. A quantum computing threat materializes suddenly and Bitcoin does= not have quantum safe signatures as part of the protocol. In this scenario= it would likely make the points below moot because Bitcoin would be fundam= entally broken and it would take far too long to upgrade the protocol, wall= et software, and migrate user funds in order to restore confidence in the n= etwork.
3. Quantum computing advances slowly enough that we come to cons= ensus about how to upgrade Bitcoin and post quantum security has been minim= ally adopted by the time an attacker appears.
4. Quantum computing advan= ces slowly enough that we come to consensus about how to upgrade Bitcoin an= d post quantum security has been highly adopted by the time an attacker app= ears.

For the purposes of this post, I'm envisioning being in si= tuation 3 or 4.

To Freez= e or not to Freeze?
I've started seeing more people weighing = in on what is likely the most contentious aspect of how a quantum resistanc= e upgrade should be handled in terms of migrating user funds. Should quantu= m vulnerable funds be left open to be swept by anyone with a sufficiently p= owerful quantum computer OR should they be permanently locked?

"I don't see why old coin= s should be confiscated. The better option is to let those with quantum com= puters free up old coins. While this might have an inflationary impact on b= itcoin's price, to use a turn of phrase, the inflation is transitory. T= hose with low time preference should support returning lost coins to circul= ation."
- H= unter Beast

On the other hand:

"Of course they have to be = confiscated. If and when (and that's a big if) the existence of a crypt= ography-breaking QC becomes a credible threat, the Bitcoin ecosystem has no= other option than softforking out the ability to spend from signature sche= mes (including ECDSA and BIP340) that are vulnerable to QCs. The alternativ= e 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 sc= hemes."
- Pieter Wuille

I don't think "con= fiscation" is the most precise term to use, as the funds are not being= seized and reassigned. Rather, what we're really discussing would be b= etter described as "burning" - placing the funds out of reach = of everyone.

Not freezing user funds is one of Bitcoin's inv= iolable properties. However, if quantum computing becomes a threat to Bitco= in's elliptic curve cryptography, an inviolable property of Bitcoin = will be violated one way or another.

Fundamental Properties at Risk
5 years ago I att= empted to comprehensively categorize all of Bitcoin's fundamental prope= rties 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 tra= nsactions become invalid could undermine confidence in the protocol.
Conservatism - Users should not be expected to be highly responsive= to system issues.

As a result of the above principles, we have deve= loped 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 coi= ns.

A quantum capable entity breaks the corollary of this f= oundational principle. We secure our bitcoin with the mathematical probabil= ities related to extremely large random numbers. Your funds are only secure= because truly random large numbers should not be guessable or discoverable= by anyone else in the world.

This is the principle behind the motto= vires in numeris - strength in numbers. In a world with quantum ena= bled adversaries, this principle is null and void for many types of cryptog= raphy, including the elliptic curve digital signatures used in Bitcoin.
=
Who is at Risk?
T= here 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 o= n 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 qua= ntum computer, which coins would I target? I'd go to the Bitcoin rich l= ist and find the wallets that have exposed their public keys due to re-usin= g addresses that have previously been spent from. You can easily find them = at https://bitinfo= charts.com/top-100-richest-bitcoin-addresses.html

Note that a fe= w of these wallets, like Bitfinex / Kraken / Tether, would be slightly hard= er 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 or= der to spend funds. But many are single signature.

Point being, it&#= 39;s not only the really old lost BTC that are at risk to a quantum enabled= adversary, at least at time of writing. If we add a quantum safe signature= scheme, we should expect those wallets to be some of the first to upgrade = given their incentives.

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

By making quantum vulnerable funds unspendable we pote= ntially harm some Bitcoin users who were not paying attention and neglected= to migrate their funds to a quantum safe locking script. This violates the= "conservativism" principle stated earlier. On the flip side, we = prevent those funds plus far more lost funds from falling into the hands of= the few privileged folks who gain early access to quantum computers.
By leaving quantum vulnerable funds available to spend, the same set of u= sers who would otherwise have funds frozen are likely to see them stolen. A= nd many early adopters who lost their keys will eventually see their unreac= hable funds scooped up by a quantum enabled adversary.

Imagine, for = example, being James Howells, who accidentally threw away a hard drive with= 8,000 BTC on it, currently worth over $600M USD. He has spent a decade try= ing to retrieve it from the landfill where he knows it's buried, but ca= n't get permission to excavate. I suspect that, given the choice, he= 9;d prefer those funds be permanently frozen rather than fall into someone = else's possession - I know I would.

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

It's prudent to expect significan= t economic disruption if large amounts of coins fall into new hands. Since = a quantum computer is going to have a massive up front cost, expect those b= ehind it to desire to recoup their investment. We also know from experience= that when someone suddenly finds themselves in possession of 9+ figures wo= rth of highly liquid assets, they tend to diversify into other things by se= lling.

Allowing quantum recovery of bitcoin is tantamount to weal= th redistribution. What we'd be allowing is for bitcoin to be redis= tributed from those who are ignorant of quantum computers to those who have= won the technological race to acquire quantum computers. It's hard to = see a bright side to that scenario.

Is Quantum Recovery Good for Anyone?

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

But w= ait, you may be thinking, wouldn't quantum "miners" have earn= ed their coins by all the work and resources invested in building a quantum= computer? I suppose, in the same sense that a burglar earns their spoils b= y the resources they invest into surveilling targets and learning the skill= s needed to break into buildings. What I say "earned" I mean thro= ugh productive mutual trade.

For example:

* Investors earn BT= C by trading for other currencies.
* Merchants earn BTC by trading for g= oods and services.
* Miners earn BTC by trading thermodynamic security.<= br>* 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 oth= er than the select few organizations that win the technological arms race t= o build the first such computers. Probably nation states and/or the top few= largest tech companies.

One could certainly hope that an organizati= on with quantum supremacy is benevolent and acts in a "white hat"= manner to return lost coins to their owners, but that's incredibly opt= imistic and foolish to rely upon. Such a situation creates an insurmountabl= e ethical dilemma of only recovering lost bitcoin rather than currently own= ed 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 key= s then proving they ever had the keys becomes rather difficult. I imagine t= hat any such white hat recovery efforts would have to rely upon attestation= s from trusted third parties like exchanges.

Even if the first actor= with quantum supremacy is benevolent, we must assume the technology could = fall into adversarial hands and thus think adversarially about the potentia= l worst case outcomes. Imagine, for example, that North Korea continues sco= oping up billions of dollars from hacking crypto exchanges and decides to i= nvest some of those proceeds into building a quantum computer for the bigge= st payday ever...

Downsi= des to Allowing Quantum Recovery
Let's think through an exhau= stive 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 "fair game" but rather were treated as fail= ures to be remediated. Treating quantum theft differently risks rewriting B= itcoin=E2=80=99s history as a free-for-all rather than a system that seeks = to protect its users.

Vi= olation of Property Rights
Allowing a quantum adversary to take c= ontrol of funds undermines the fundamental principle of cryptocurrency - if= you keep your keys in your possession, only you should be able to access y= our money. Bitcoin is built on the idea that private keys secure an individ= ual=E2=80=99s assets, and unauthorized access (even via advanced tech) is t= heft, not a legitimate transfer.

Erosion of Trust in Bitcoin
If quantum attackers can exp= loit vulnerable addresses, confidence in Bitcoin as a secure store of value= would collapse. Users and investors rely on cryptographic integrity, and w= idespread theft could drive adoption away from Bitcoin, destabilizing its e= cosystem.

This is essentially the counterpoint to claiming the burni= ng of vulnerable funds is a violation of property rights. While some will c= ertainly see it as such, others will find the apathy toward stopping quantu= m theft to be similarly concerning.

Unfair Advantage
Quantum attackers, likely equipped w= ith rare and expensive technology, would have an unjust edge over regular u= sers who lack access to such tools. This creates an inequitable system wher= e only the technologically elite can exploit others, contradicting Bitcoin= =E2=80=99s ethos of decentralized power.

Bitcoin is designed to crea= te an asymmetric advantage for DEFENDING one's wealth. It's suppose= d to be impractically expensive for attackers to crack the entropy and cryp= tography protecting one's coins. But now we find ourselves discussing a= situation where this asymmetric advantage is compromised in favor of a spe= cific class of attackers.

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

Moral Responsibility
Permitting thef= t via quantum computing sets a precedent that technological superiority jus= tifies unethical behavior. This is essentially taking a "code is law&q= uot; stance in which we refuse to admit that both code and laws can be modi= fied to adapt to previously unforeseen situations.

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

1. self-enri= ching & likely malicious
2. harm prevention & not necessarily ma= licious

Both options lack the consent of the party whose coins are b= eing burnt or transferred, thus I think the simple argument that theft is i= mmoral becomes a wash and it's important to drill down into the details= of each.

Incentives Dri= ve Security
I can tell you from a decade of working in Bitcoin se= curity - the average user is lazy and is a procrastinator. If Bitcoiners ar= e given a "drop dead date" after which they know vulnerable funds= will be burned, this pressure accelerates the adoption of post-quantum cry= ptography and strengthens Bitcoin long-term. Allowing vulnerable users to d= elay upgrading indefinitely will result in more laggards, leaving the netwo= rk more exposed when quantum tech becomes available.

Steel Manning
Clearly this is a comp= lex and controversial topic, thus it's worth thinking through the oppos= ing arguments.

Protectin= g Property Rights
Allowing quantum computers to take vulnerable b= itcoin could potentially be spun as a hard money narrative - we care so gre= atly about 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 fall= ing into undeserving hands. If the entire Bitcoin ecosystem just stands aro= und and allows quantum adversaries to claim funds that rightfully belong to= other users, is that really a "win" in the "protecting prop= erty rights" category? 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 suffici= ently powerful quantum computers will ever exist, so we shouldn't bothe= r 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 becaus= e they wouldn't want to reveal their hand by doing so, and would instea= d attack other infrastructure.

It's quite difficult to quantify = exactly how valuable attacking other infrastructure would be. It also reall= y depends upon when an entity gains quantum supremacy and thus if by that t= ime most of the world's systems have already been upgraded. While I thi= nk you could argue that certain entities gaining quantum capability might n= ot attack Bitcoin, it would only delay the inevitable - eventually somebody= will achieve the capability who decides to use it for such an attack.
<= br>Quantum Attackers Would Only= Steal Small Amounts
Some have argued that even if a quantum atta= cker targeted bitcoin, they'd only go after old, likely lost P2PK outpu= ts so as to not arouse suspicion and cause a market panic.

I'm n= ot so sure about that; why go after 50 BTC at a time when you could take 25= 0,000 BTC with the same effort as 50 BTC? This is a classic "zero day = exploit" game theory in which an attacker knows they have a limited am= ount of time before someone else discovers the exploit and either benefits = from it or patches it. Take, for example, the recent ByBit attack - the hig= hest value crypto 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 thei= r wallet. But instead they chose to only specifically target ByBit's wa= llet with $1.5 billion in it because they wanted to maximize their extracta= ble value. If Lazarus had started stealing from every wallet, they would ha= ve been discovered quickly and the Safe web app would likely have been patc= hed well before any billion dollar wallets executed the malicious code.
=
I think the "only stealing small amounts" argument is stronge= st for Situation #2 described earlier, where a quantum attacker arrives bef= ore quantum safe cryptography has been deployed across the Bitcoin ecosyste= m. 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 = option 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 wh= ich we have a migration path available.

The 21 Million Coin Supply Should be in Circulation<= br>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 undesira= ble.

While the "21M BTC" attribute is a strong memetic nar= rative, 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, an= d that's actually 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 importan= t is that the supply is well known and not subject to change.

Self-Sovereignty and Personal Respons= ibility
Bitcoin=E2=80=99s design empowers individuals to control = their own wealth, free from centralized intervention. This freedom comes wi= th the burden of securing one's private keys. If quantum computing can = break obsolete cryptography, the fault lies with users who didn't move = their funds to quantum safe locking scripts. Expecting the network to shiel= d users from their own negligence undermines the principle that you, and no= t a third party, are accountable for your assets.

I think this is ge= nerally a fair point that "the community" doesn't owe you any= thing in terms of helping you. I think that we do, however, need to conside= r the incentives and game theory in play with regard to quantum safe Bitcoi= ners vs quantum vulnerable Bitcoiners. More on that later.

Code is Law
Bitcoin operates o= n transparent, immutable rules embedded in its protocol. If a quantum attac= ker uses superior technology to derive private keys from public keys, they= =E2=80=99re not "hacking" the system - they're simply followi= ng what's mathematically permissible within the current code. Altering = the protocol to stop this introduces subjective human intervention, which c= lashes with the objective, deterministic nature of blockchain.

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

Technological Evolution as a Feature, Not a Bug
It= 's well known that cryptography tends to weaken over time and eventuall= y break. Quantum computing is just the next step in this progression. Users= who fail to adapt (e.g., by adopting quantum-resistant wallets when availa= ble) are akin to those who ignored technological advancements like multisig= or hardware wallets. Allowing quantum theft incentivizes innovation and ke= eps Bitcoin=E2=80=99s ecosystem dynamic, punishing complacency while reward= ing vigilance.

Market Si= gnals Drive Security
If quantum attackers start stealing funds, i= t sends a clear signal to the market: upgrade your security or lose everyth= ing. This pressure accelerates the adoption of post-quantum cryptography an= d strengthens Bitcoin long-term. Coddling vulnerable users delays this nece= ssary evolution, potentially leaving the network more exposed when quantum = tech becomes widely accessible. Theft is a brutal but effective teacher.
Centralized Blacklisting P= ower
Burning vulnerable funds requires centralized decision-makin= g - a soft fork to invalidate certain transactions. This sets a dangerous p= recedent for future interventions, eroding Bitcoin=E2=80=99s decentralizati= on. 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 o= nly burn specific addresses. Rather, I'd expect a neutral proposal to b= urn all funds in locking script types that are known to be quantum vulnerab= le. Thus, we could eliminate any subjectivity from the code.

Fairness in Competition
Quan= tum attackers aren't cheating; they're using publicly available phy= sics 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 a= dopters took risks and reaped rewards; quantum innovators are doing the sam= e. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin has never promi= sed 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 a= ll but the wealthiest organizations.

Economic Resilience
Bitcoin has weathered thefts bef= ore (MTGOX, Bitfinex, FTX, etc) and emerged stronger. The market can absorb= quantum losses, with unaffected users continuing to hold and new entrants = buying in at lower prices. Fear of economic collapse overestimates the impa= ct - the network=E2=80=99s antifragility thrives on such challenges.
This is a big grey area because we don't know when a quantum computer = will come online and we don't know how quickly said computers would be = able to steal bitcoin. If, for example, the first generation of sufficientl= y powerful quantum computers were stealing less volume than the current blo= ck reward then of course it will have minimal economic impact. But if they&= #39;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 new = supply.

This is where the circumstances will really matter. If a qua= ntum attacker appears AFTER the Bitcoin protocol has been upgraded to suppo= rt quantum resistant cryptography then we should expect the most valuable a= ctive wallets will have upgraded and the juiciest target would be the 31,00= 0 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dorm= ant since 2010. In general I'd expect that the amount of BTC re-enterin= g the circulating supply would look somewhat similar to the mining emission= curve: volume would start off very high as the most valuable addresses are= drained and then it would fall off as quantum computers went down the list= targeting addresses with less and less BTC.

Why is economic impact = a factor worth considering? Miners and businesses in general. More coins be= ing liquidated will push down the 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 enti= re industry.

Practicalit= y & Neutrality of Non-Intervention
There=E2=80=99s no reliabl= e way to distinguish =E2=80=9Ctheft=E2=80=9D from legitimate "white ha= t" key recovery. If someone loses their private key and a quantum comp= uter recovers it, is that stealing or reclaiming? Policing quantum actions = requires invasive assumptions about intent, which Bitcoin=E2=80=99s trustle= ss design can=E2=80=99t accommodate. Letting the chips fall where they may = avoids this mess.

Philos= ophical Purity
Bitcoin rejects bailouts. It=E2=80=99s a cold, har= d system where outcomes reflect preparation and skill, not sentimentality. = If quantum computing upends the game, that=E2=80=99s the point - Bitcoin is= n=E2=80=99t meant to be safe or fair in a nanny-state sense; it=E2=80=99s m= eant to be free. Users who lose funds to quantum attacks are casualties of = liberty and their own ignorance, not victims of injustice.

Bitcoin's DAO Moment
This = situation has some similarities to The DAO hack of an Ethereum smart contra= ct in 2016, which resulted in a fork to stop the attacker and return funds = to their original owners. The game theory is similar because it's a sit= uation where a threat is known but there's some period of time before t= he attacker can actually execute the theft. As such, there's time to mi= tigate the attack by changing the protocol.

It also created a schism= in the community around the true meaning of "code is law," resul= ting in Ethereum Classic, which decided to allow the attacker to retain con= trol of the stolen funds.

A soft fork to burn vulnerable bitcoin cou= ld certainly result in a hard fork if there are enough miners who reject th= e soft fork and continue including transactions.

Incentives Matter
We can wax philosophic= al until the cows come home, but what are the actual incentives for existin= g Bitcoin holders regarding this decision?

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

If true, the corollary is:

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

Thus, assuming we get to a point where qua= ntum resistant signatures are supported within the Bitcoin protocol, what&#= 39;s the incentive to let vulnerable coins remain spendable?

* It= 9;s not good for the actual owners of those coins. It disincentivizes owner= s from upgrading until perhaps it's too late.
* It's not good fo= r the more attentive / responsible owners of coins who have quantum secured= their stash. Allowing the circulating supply to balloon will assuredly red= uce the purchasing power of all bitcoin holders.

Forking Game Theory
From a game theory p= oint of view, I see this as incentivizing users to upgrade their wallets. I= f you disagree with the burning of vulnerable coins, all you have to do is = move your funds to a quantum safe signature scheme. Point being, I don'= t see there being an economic majority (or even more than a tiny minority) = of users who would 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 can be meaningfully ena= cted and enforced by a mere majority of hashpower. If miners generally agre= e 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 software th= at 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 afte= r a specific block height / timestamp, Bitcoin nodes will no longer accept = transactions (or blocks containing such transactions) that spend funds from= any scripts other than the newly instituted quantum safe schemes.

I= t could take a staggered approach to first freeze funds that are susceptibl= e to long-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 a= dditional complexity would drive further controversy.

How long shoul= d 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 hop= e that hardware wallet manufacturers are able to implement post quantum cry= ptography on their existing hardware with only a firmware update.

Be= yond that, it will take at least 6 months worth of block space for all user= s to migrate their funds, even in a best case scenario. Though if you exclu= de dust UTXOs you could probably get 95% of BTC value migrated in 1 month. = Of course this is a highly optimistic situation where everyone is completel= y focused on migrations - in reality it will take far longer.

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

Random Tangential Benefits
On the plus side, burning = all quantum vulnerable bitcoin would allow us to prune all of those UTXOs o= ut of the UTXO set, which would also clean up a lot of dust. Dust UTXOs are= a bit of an annoyance and there has even been a recent proposal for how to= incentivize cleaning them up.

We should also expect that incentiviz= ing migration of the entire UTXO set will create substantial demand for blo= ck space that will sustain a fee market for a fairly lengthy amount of time= .

In Summary
W= hile the moral quandary of violating any of Bitcoin's inviolable proper= ties can make this a very complex issue to discuss, the game theory and inc= entives between burning vulnerable coins versus allowing them to be claimed= by entities with quantum supremacy appears to be a much simpler issue.
=
I, for one, am not interested in rewarding quantum capable entities by = inflating the circulating money supply just because some people lost their = keys long ago and some laggards are not upgrading their bitcoin wallet'= s security.

We can hope that this scenario never comes to pass, but = hope is not a strategy.

I welcome your feedback upon any of the abov= e points, and contribution of any arguments I failed to consider.

--
You received this message because you are subscribe= d to the Google Groups "Bitcoin Development Mailing List" group.<= br>To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7C= itXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/E8269A1A-1899-46D2-A7CD-4D9D2B732364%40astrotown.de.

--
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/CAJDmzYxw%2BmXQKjS%2Bh%2Br6mCoe1rwWUp= a_yZDwmwx6U_eO5JhZLg%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+...@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/msgid/= bitcoindev/zyx7G6H1TyB2sWVEKAfIYmCCvfXniazvrhGlaZuGLeFtjL3Ky7B-9nBptC0GCxuH= Mjjw8RasO7c3ZX46_6Nerv0SgCP0vOi5_nAXLmiCJOY%3D%40proton.me.

--
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.

--
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/893891ea-34ec-4d60-9941-9f636be0d747n%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.co= m/d/msgid/bitcoindev/CADL_X_dz6Zuoh6T%3Dp%2B531kQkgVUbr5iKHeLNe01s5%3DQDp6i= w9g%40mail.gmail.com.
--000000000000acdc1706370ff0cd--