Delivery-date: Fri, 25 Jul 2025 09:59:50 -0700 Received: from mail-qk1-f188.google.com ([209.85.222.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ufLlr-0007f4-9F for bitcoindev@gnusha.org; Fri, 25 Jul 2025 09:59:50 -0700 Received: by mail-qk1-f188.google.com with SMTP id af79cd13be357-7e03ac1bf79sf184823585a.3 for ; Fri, 25 Jul 2025 09:59:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1753462781; cv=pass; d=google.com; s=arc-20240605; b=JH01dHg+7NprB4rtI92VHZYsM3F5917X1Sj5mBZztr8Fu1xzlApP95Bu9Ulf7tfmU2 T21JfMpLUZBVCSgin16HUbni5sRc1NkWFwf0mJ6pN3+A5Si5AAPMh4+bJW9qFrFXzZno HoBpn7vddVova26OVNLzDalHVa2pJ1NAbkw9ZEg6L2VM/00oQvkTdeoiiobrdrvw57XN xMNGeUQX4su5I4JIgLI62l1F0kbGDFQ0jHi8D5x50Jm2Bzm0IXgOFjqK7ZNvX7EezJU3 XDnvWGRnKWKyn2EGPTCGWLQd2bSTuJDoB4ffDkbjGOU1ueGXQSDUIfJ+4FjLtQVIMl+F cWew== 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=JG7Hhwkn2/cRclm3TS+0TeE4BUj+2S7t7sS4Mdsx4M0=; fh=OlLv6RGYoydLq4CD8AvU6bggEsmZkIhyp8hNwuY7wdM=; b=GRqjtheAQ2ePdiCP1KxjBqukwBtYsoD/+pUw+NRVGzM0Juqp7NXmUc7P7uLSgf/mes n+3MpBOZL/dqkv7HYAy3CToOjLPpEt7DbF5y9O5U+uXeUEIYI7t3fnfujbu5ZVYOXcWQ sP6Vp8sRC5KNq7KANzz4MMUlJ352AzLMJrCpn4rimIrYacDJMYXLj6+NbiEJW7xM/iG6 av3teoAhqUJlVf1sRE3DxAG0bDA3ZXPW1uPgglPGVaJ97HJqLQnlkSp5HXrvttjBl9p1 OASG0LFUvHiU9PiWpYh89XS7FwdVAejw5BTtIdzem+iOHl9PcLJfSS/NzGV0WBbMjhAJ l0yg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="K/cvdiVW"; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=antoine.riard@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=1753462781; x=1754067581; 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=JG7Hhwkn2/cRclm3TS+0TeE4BUj+2S7t7sS4Mdsx4M0=; b=U0NuQGLqazXBqIHunP4RampTHHfv0N2/dFS9vbJcuwJqwFL3dacQYBif9eLJQDaTyG ghfP6h6Wb4cbuK5LlnuKv0tT/bkileTu7dZCIrPt0HW0QiCwJr1hVj+LYEekQpTTbifw cUzxxyrLnLCyOcUawFvleaR5bWB1fW66HX/ncCDl0bQa2PNvkySQiZM+Lmlmdm/JcV4Y 8+MG7uA/0OS9UQPvGR3dIS7jmQL2fFGMqVWab1Kfn28EPkSs9nb+Wqk0sT+eL/RJ6o7T 6y1SI+FScobgmAUpgMcnaBk04eZ6HH6nVSjgiYMctRsztMJfUFVQWA1CnNbpzbSxZE3E pFtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753462781; x=1754067581; 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=JG7Hhwkn2/cRclm3TS+0TeE4BUj+2S7t7sS4Mdsx4M0=; b=TSCYBo74MpZ77W42ugnj/1OTrXRsEmgKNE8pHmw1zXZZ8J1F4z8l8Q0ri/EjnBGLsL nGwacOfXA7tXfp/njB4lOzcuUNvDi7TvRxc0HsOQeXmgPleLmvpcaZcdutE1rcOIvJ/g zGWvPsuwA66iAi7ircyrP7edVF3ORQglohCdXgVNkzWz3QqyeIBevEnx9EApFyXh9L81 JOxLdEg7x497LE4+ZhZ5AdrQ+METzcesx6AJiva5Rsi1C8BWXLxjX2xUfCw46y8RTd9A SIHYxOEbfL+6NuACKsBHogsgGInBMxcQLJoBJg5n8/LtOq6/1lCnqCN+vkxGjNAoElL3 kc/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753462781; x=1754067581; 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=JG7Hhwkn2/cRclm3TS+0TeE4BUj+2S7t7sS4Mdsx4M0=; b=txW2Mf4oO+Us9ozLbRTTXB5wA66wLSqUAYLN3UmbXPDYS/t5DK8RmHDQVisJWzOtp8 DB+DfTxFs8DUxZ8utAxeCXbahTVORe/QTv7RwXN0ZkEA+ffEpk98dpaQn+wqENzzHlRv x+03YotsCYgPlFqotxUiO6PtWtn5Np5BmQbFRA4DL9s/Xc+pvUbl1gx6p6oA2F1A+0DH mbk1II78BdUDimPRsw9R5hsSOyaqyYzgbLxJ0OlIYvUuS2z0WxkWHkwPoGlKY/FL8b5k R8tiko++wHA7TYvotzws+PWGDiiw23tWPOvoFj5EQ2i+2D0hwwb3fbmDeIzhhXXKOIPS pm+w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUAhS+UgGQCWrUSXbPsMXxfp1Ocvk48v/IUCDeVyHLoFs5Bx5xC68vSFI/hQusBTvC4mer6YODUpH4N@gnusha.org X-Gm-Message-State: AOJu0YxR1sgBdLzjb5VkAULDYWq4peuXQQIGBwc6TVq37CLUcFbDOlqY eCVJuGG+TE8t1jCt7Fbo2a7Qf5YhNiftXkFy+Ie16x6XP3frOxPvncvD X-Google-Smtp-Source: AGHT+IFyKT3bUmPfXlJdNsLjOg3VOIj5L2ZABqN1Geyk5/qInt9vfE8hOByCX+XZsQTu0mBQtCbk1Q== X-Received: by 2002:a05:620a:370d:b0:7e0:9977:a803 with SMTP id af79cd13be357-7e63c1bafffmr338522085a.54.1753462780069; Fri, 25 Jul 2025 09:59:40 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZftkRKwQ0quaCURUu7lT4VGdjdjAPtfEz6/4UxODFhAsA== Received: by 2002:a05:622a:552:b0:4ab:8d30:5860 with SMTP id d75a77b69052e-4ae7bd33e2bls39016401cf.1.-pod-prod-08-us; Fri, 25 Jul 2025 09:59:36 -0700 (PDT) X-Received: by 2002:a05:620a:19a7:b0:7e6:301e:d03e with SMTP id af79cd13be357-7e63bf5b49amr273897785a.12.1753462776509; Fri, 25 Jul 2025 09:59:36 -0700 (PDT) Received: by 2002:a05:620a:a009:b0:7c5:50d5:7703 with SMTP id af79cd13be357-7e34d62451bms85a; Fri, 18 Jul 2025 12:13:42 -0700 (PDT) X-Received: by 2002:a05:620a:4492:b0:7e3:412f:14f5 with SMTP id af79cd13be357-7e3436167fcmr1552149585a.43.1752866020843; Fri, 18 Jul 2025 12:13:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752866020; cv=none; d=google.com; s=arc-20240605; b=YiTeyNj5nT+cOXvCByUIpKTqLKi/dDzEb/CZUboGNddrpuj54rJ+CsXjOVt8U2Oy/v l71hn8SVkHv3LLq7q4XDCIzfYeyr8//0mWoksnPAm5r1hEtO/i7iJzEagktHt0WXvQJe 4WmaKHE6TkN3+p9Zcmz0D+2KyBwEtU6uaX2BXCgGAlGtrUssGqSzm8aCFOEr6KbGq/Pc EdlDmHJC326ycbDIcY44FSbsgCPLaC8b5OL1p0e6vsPVPjFGZ2pxo23bjJ5HwN243HX5 s0JXh8EDMbKeo+lEcDKpdhE8eey8VLrMADHmkIE+KwhJBj8XgzLHhiJnfXYimwuO5dYx kq2Q== 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=5w52R4pq2ECjsn6XVCa3/7kSgWNIFpGjyO7zlUpZhcA=; fh=dEDbYMbbYyDNRr1LOwMlw2+lJDEDNk0XskwzeS3uI5o=; b=MlwgDH99iWd8Si8SQd9EbNH+/gj8Ah97wd/ePZivUmMfjunbZCqSXdR2W1nx6Be0mP uwxrDAyKPqkWN/ObXl8zew0grBRnlVPFg9meNH9xvIKJ99qwTBf6TK2dLE0X5iDdjkIx Tx1GQggD4q+227fSSf23Bg2fOAupZNnO/LI5n+0jSREo9m/DPcoo/EDNaihWFM+OFFwg b+Y0Os1TFwwpcTVSZ2uwzCF/fv501ML0ihNVWyauksSrp6A/oTMS9gLNT2wmEKYm9bdM 2vytCRGJivd0ElT6w9iZTqxElal9STJcgxZXMfZQ1zz7MtlH2LyhTOVO2n0SdxJbcpqL 3VzA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="K/cvdiVW"; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com. [2607:f8b0:4864:20::102f]) by gmr-mx.google.com with ESMTPS id af79cd13be357-7e356c1cfa9si11949185a.3.2025.07.18.12.13.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Jul 2025 12:13:40 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) client-ip=2607:f8b0:4864:20::102f; Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-315c1b0623cso2384594a91.1 for ; Fri, 18 Jul 2025 12:13:40 -0700 (PDT) X-Gm-Gg: ASbGncsiLNSdlzT5e23m/3cpNCflMKsRHOjzqwEX4hVJEfc48DTD8/Pz93YRoYYWIEr Mdj8Q9dLEpvBOfP05G0Bi4jwWLOj+SCsg4XQzZVhO2qlg4uDyNSF7ENpeBnFTCN2dbkWz16OThj c9XVPdiNLIIISbyVyy6WEH38kGAVsNbFMaU7qNVUP+O3fnRp/g5YXZJEe+fniV76zT6asBMY9oq 9AogrXG X-Received: by 2002:a17:90b:4985:b0:311:c1ec:7d12 with SMTP id 98e67ed59e1d1-31c9f43718cmr16814274a91.23.1752866019263; Fri, 18 Jul 2025 12:13:39 -0700 (PDT) MIME-Version: 1.0 References: <37ed2e5d-34cd-4391-84b8-5bcc6d42c617n@googlegroups.com> <4d9ce13e-466d-478b-ab4d-00404c80d620n@googlegroups.com> In-Reply-To: From: Antoine Riard Date: Fri, 18 Jul 2025 20:13:26 +0100 X-Gm-Features: Ac12FXy3c5WArHzvL6438O6uDZ9XSXKMHhSDrWeEYsDVm97bNzuVYa7sHJ7yk-Y Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: Jameson Lopp Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006ac9fe063a38eccf" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="K/cvdiVW"; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=antoine.riard@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.5 (/) --0000000000006ac9fe063a38eccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Beware the blurry line between stoicism and apathy. > > How well will it play out if we can say "well, we could have stopped a massive threat but chose not to, because we were confident the system would survive." > > The alternative path is "we saw a threat coming and the community collaborated to neutralize it before massive harm occurred." > > Both scenarios show resilience. Which evokes greater confidence? Beware "ce qu'on ne voit pas" and the perverse incentives introduced by a Q-Day. Expect massively PQ "claimed-to-be" secure wallet rushed under a false sense of emergency, very insecure against classic attacks. If I was running a big custodian, def old schoold insurance on quantum risk is a thing. They already do for pure custody risks. Otherwise, it's a typical "trolly problem" applied to bitcoin protocol dev. Indeed multiple viewpoints can be valid. > I can't speak for Jameson, but let me put forward my own concern. If miners can buy much less electricity for 1-BTC this is a major problem for Bitcoin. If the price of electricity denominated in Bitcoin goes way up, miners will have to mine at a massive loss. Many will stop mining, then the block rate will go down and Bitcoin will appear to be less valuable (high fees, slow confirmation, panic), which makes mining even more of a loss, and so on. This also invites miners who have nothing left to lose to engage in mining attacks. It's a real problem, but not specific to quantum. The same risk could happen when the inflation schedule is dried up after few halvings, or other exogeneous reason. About the price crash and hypothetical impact on miners, a lot of open dimensions: - unclear if the quantum adversary is economically rational and HODL its stack - unclear if the quantum adversary would be able to liquidate its BTC stack bc on-ramp flagging them as stolen BTCs - fragmentation of the on-ramp BTC markets over the world and if price down would reflect uniformly - unclear if selling strategy of quantum adversary can be anticipated by miners - poor elasticity of demand for miners electricity providers (e.g hydro or flare) - unclear if the price crash can be quickly corrected by strong hands anticipating the "once-in-a-lifetime" cheap sell - what else ? I do agree it's a serious concern to have. On the other hand, we don't have a real quantitative model to reason on miners reaction. In my view, this conv would be far more constructive, fact-based if someone can come up with a model on miners impact with what if ~20% of coins are quantum nuked. Best, Antoine OTS hash: 74b5c0cdee22c391c2c50b052b652368ce1d01edc660077847b8ed662f0d172c Le lun. 14 juil. 2025 =C3=A0 19:52, Jameson Lopp a =C3=A9crit : > > > On Mon, Jul 14, 2025 at 10:09=E2=80=AFAM Antoine Riard > wrote: > >> Hi Jameson, >> >> Thanks for your thoughts on this complex subject. >> >> First and foremost, I think your following statement: "Never before has >> Bitcoin faced >> an existential threat to its cryptographic primitives" is very myopic, >> given that >> cryptanalysts and number theorists are making progress every year in >> their works, and >> each bitcoin cryptographic primitive has been and is constantly analyzed >> to uncover >> potential weaknesses. >> >> So in my view the quantum threat is a bit less specific that the image >> you're painting >> of it. Even if go all to upgrade to lattices-based schemes, we have no >> certainty that >> novels flaws won't be found, one can just go to see the modifications of >> the NIST-approved >> schemes in between their rounds of selection that we'll never reach >> something like >> "self-sovereign peace of mind"...Unless we start to forbid people of >> practicing the >> art of mathematics, practice which has been ongoing since Euclide and >> Pythagore... >> >> I do concede that quantum is a bit different, as after all new physics >> paradigm >> do not happen often (Heisenberg published in the 20s iirc), though that'= s >> in my >> view the flaw of your reasoning as you're assuming some "post-quantum" >> upgraded >> state where bitcoin, as a community and a network, would be definitely >> safe from >> advances in applied science. At minima, in my understanding, you're >> arguing this >> time is different to justify extra-ordinary technical measures never see= n >> before, >> namely the freezing of "vulnerable" coins. >> >> > Correct, this time is different in that we're not talking about vague > unknown weaknesses. Rather, we're talking about a known algorithm that > makes breaking cryptographic primitives orders of magnitude cheaper. > > The unknown becomes the rate at which advancements in quantum computing > will be achieved, which is concerning given the funding going into pushin= g > said advancements forward. > > >> I'm worried this is opening a Pandora box, where we would introduce a >> precedent >> that it is legitimate as a community to technicaly confiscate some coins >> of users, >> without their _consents_, for extra-ordinary reasons. That's opening a >> worms of >> shenanigans in the future...There is no guarantee that this precedent >> won't >> be leveraged in the future by any group of entities to justify future >> upgrades >> eroding one of the "fundamental property" you're yourself deeming as >> valuable. >> >> > This is a fair fear, though the counterpoint is that it is legitimate for > the community to protect itself against security threats. It just so > happens that both viewpoints can be valid. > > This is especially worrying as if I'm understanding you correctly you're >> justifying >> this position as that somehow we should protect the price of the currenc= y >> as an end >> in itself (i.e "Beyond its impact on price, ..."). It's unclear the pric= e >> of bitcoin >> versus what fiat or hard asset (e.g oil) you have in mind. And in anyway= , >> as far >> as I know, none of the bitcoin devs is seating on the board of the FED, >> the ECB >> or the BoJ... >> >> To put it simply, even if a quantum attacker can tomorrow starts to stea= l >> vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop. In my >> humble >> opinion, let's not introduce the idea that, we, as a community of >> stakeholders >> and developers we have a positive "fiduciary" duty to act to maintain th= e >> price >> of bitcoin in some "monetary snake" with another class of assets... >> >> > Protocol developers have no fiduciary duty to bitcoin holders. I wouldn't > argue they have any duty whatsoever to users. > > Bitcoin is not (yet) a unit of account. The ecosystem does not run on 1 > BTC =3D 1 BTC. The purchasing power of satoshis is very much relevant to = the > health and sustainability of the ecosystem at its current level. > > I would not claim that "devs must do something" - rather, I believe that > the incentives of other groups I outlined will roughly align them with my > thinking. > > That's also the problem with game theory, all the matrices of analysis ar= e >> based on some scale of utilitarism. See Von Neuman's Theory of Games, th= e >> section on "The Notion of Utility". My subjective appreciation of the >> value >> of my coins might not be your subjective appreication of the value of yo= ur >> coins. >> >> Now I do understand the perspective of the institutional holders, the >> exchanges, >> the custodians or any other industry providers, who might be in the full >> uncertainty >> about their business responsibilities in case of a quantum threat >> affecting their >> custodied coins. But, first legally speaking there is something call >> "force majeure" >> and in view of the quantum threat, which is a risk discussed far beyond >> the bitcoin >> industry, they should be able to shield themselves behind that. Secondly= , >> if there >> is any futute upgrade "opt-in" only path a la BIP360, you can move your >> funds or >> the ones under custody under a PQC scheme like Dilthium or Falcon and b= e >> good >> without caring about what the others users are doing. Thirdly, if you're >> an actor >> in the industry like Coinbase and you're deeply concerned about how >> extended maelstrom >> on the price might affect the viability of your operations, it is unclea= r >> to me why >> you don't call MunichRe or any other company like that tomorrow to craft >> and be >> covered by specific insurance on quantum threats... >> >> Agreed that companies may be legally protected from lawsuits. Not sure > about the insurance angle, though I'd see that as a one time payout > that could very well come at the expense of said business ceasing > operations. I suspect few businesses would be happy with that. > > Unfortunately I don't think opt-in security suffices in this situation. > Human nature is to procrastinate and if the incentives are insufficient t= o > motivate mass migration to quantum secure schemes, Q-Day will be > quite unpleasant. > > >> To be frank, all those considerations on how "I cannot see how the >> currency can >> maintain any value at all in such a setting", is a strong red flag of lo= w >> time >> preferences. It's not like we're used to strong volatility in bitcoin >> with the >> almost 2 decades of operations of the network. In my view, it's more a >> hint of >> very high-exposition by some to a single class of asset, i.e bitcoin, >> rather than wise >> diversification... And a push to sacrify a "fundamental property" i.e >> "conservatism" >> in view of short-term concerns (i.e the stability of the currency price >> along >> a period of few years). >> >> > Bitcoin has many inviolable properties and some of them are actually in > conflict with each other. Conservatism and property rights are clearly on > the table in this matter. > > But shouldn't one of Bitcoin's fundamental properties be the fact that it > can be upgraded? That it can respond to new challenges and threats? > > Beyond just the quantum computing issue, I expect the above to create > continued conflict between ossifiers and developers over the long term. > > Do not get me wrong, I'm certainly not of the school "let's reward quantu= m >> attackers". Leveraging techical superiority and employing CRQRC to steal >> vulnerable coins would be clearly a theft. But ethically, the best we ca= n >> do is >> to have an opt-in upgrade path and be pro-active, by education and >> outreach, >> to have the maximum of coin owners upgrading to non-vulnerable addresses >> types. >> Then show the level of "fortitude" or "endurance" as a community in face >> of price >> fluctuations for a while, while seeing regularly old P2PK coins hacked. >> Marcus >> Aurelius can be bought for few bucks in most of decent libraries... >> >> > Beware the blurry line between stoicism and apathy. > > How well will it play out if we can say "well, we could have stopped a > massive threat but chose not to, because we were confident the system wou= ld > survive." > > The alternative path is "we saw a threat coming and the community > collaborated to neutralize it before massive harm occurred." > > Both scenarios show resilience. Which evokes greater confidence? > > I'm definitely on the "no old coins confiscation" position you're >> underlighting: >> >> "I don't see why old coins should be confiscated. The better option is t= o >> let >> those with quantum computers free up old coins. While this might have an >> inflationary impact on bitcoin's price, to use a turn of phrase, the >> inflation >> is transitory. Those with low time preference should support returning >> lost >> coins to circulation". >> >> Notwhitstanding that I disagree with your position, one can only >> appreciate >> the breadth and depth with which you're gathering and articulating all t= he >> elements on this complex problem. >> >> Best, >> Antoine >> OTS hash: c064b43047bf3036faf098b5ac8e74930df63d25629f590a41952229794028= 26 >> Le lundi 14 juillet 2025 =C3=A0 00:53:34 UTC+1, Tadge Dryja a =C3=A9crit= : >> >>> Hi >>> >>> While I generally agree that "freeze" beats "steal", and that a lot of >>> lead time is good, I don't think this plan is viable. >>> To me the biggest problem is that it ties activation of a PQ output typ= e >>> to *de*activation of EC output types. That would mean that someone who >>> wants to keep using all the great stuff in libsecp256k1 should try to >>> prevent BIP360 from being activated. >>> >>> Sure, there can be risks from CRQCs. But this proposal would go the >>> other direction, disabling important functionality and even destroying >>> coins preemptively, in anticipation of something that may never happen. >>> >>> Also, how do you define "quantum-vulnerable UTXO"? Would any P2PKH, or >>> P2WPKH output count? Or only P2PKH / P2WPKH outputs where the public k= ey >>> is already known? I can understand disabling spends from known-pubkey >>> outputs, but for addresses where the public key has never been revealed= , >>> commit/reveal schemes (like the one I posted about & am working on a >>> follow-up post for) should safely let people spend from those outputs >>> indefinitely. >>> >>> With no evidence of a QRQC, I can see how there would be people who'd >>> say "We might never really know if a CRQC exists, so we need to disable= EC >>> spends out of caution" and others who'd say "Don't disable EC spends, s= ince >>> that's destroying coins", and that could be a persistent disagreement. = But >>> I hope if we did in fact have a proof that a CRQC has broken secp256k1, >>> there would be significant agreement on freezing known-pubkey EC output= s. >>> >>> -Tadge >>> On Saturday, July 12, 2025 at 8:46:09=E2=80=AFPM UTC-4 Jameson Lopp wro= te: >>> >>>> Building upon my earlier essay against allowing quantum recovery of >>>> bitcoin >>>> >>>> I wish to formalize a proposal after several months of discussions. >>>> >>>> This proposal does not delve into the multitude of issues regarding >>>> post quantum cryptography and trade-offs of different schemes, but rat= her >>>> is meant to specifically address the issues of incentivizing adoption = and >>>> migration of funds *after* consensus is established that it is prudent >>>> to do so. >>>> >>>> As such, this proposal requires P2QRH as described in BIP-360 or >>>> potential future proposals. >>>> Abstract >>>> >>>> This proposal follows the implementation of post-quantum (PQ) output >>>> type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Sch= norr >>>> signatures. It turns quantum security into a private incentive: fail >>>> to upgrade and you will certainly lose access to your funds, creating = a >>>> certainty where none previously existed. >>>> >>>> - >>>> >>>> Phase A: Disallows sending of any funds to quantum-vulnerable >>>> addresses, hastening the adoption of P2QRH address types. >>>> - >>>> >>>> Phase B: Renders ECDSA/Schnorr spends invalid, preventing all >>>> spending of funds in quantum-vulnerable UTXOs. This is triggered by= a >>>> well-publicized flag-day roughly five years after activation. >>>> - >>>> >>>> Phase C (optional): Pending further research and demand, a separate >>>> BIP proposing a fork to allow recovery of legacy UTXOs through ZK p= roof of >>>> possession of BIP-39 seed phrase. >>>> >>>> Motivation >>>> >>>> We seek to secure the value of the UTXO set and minimize incentives >>>> for quantum attacks. This proposal is radically different from any in >>>> Bitcoin=E2=80=99s history just as the threat posed by quantum computin= g is >>>> radically different from any other threat in Bitcoin=E2=80=99s history= . Never >>>> before has Bitcoin faced an existential threat to its cryptographic >>>> primitives. A successful quantum attack on Bitcoin would result in >>>> significant economic disruption and damage across the entire ecosystem= . >>>> Beyond its impact on price, the ability of miners to provide network >>>> security may be significantly impacted. >>>> >>>> - >>>> >>>> Accelerating quantum progress. >>>> - >>>> >>>> NIST ratified three production-grade PQ signature schemes in >>>> 2024; academic road-maps now estimate a cryptographically-releva= nt quantum >>>> computer as early as 2027-2030. [McKinsey >>>> >>>> ] >>>> - >>>> >>>> Quantum algorithms are rapidly improving >>>> - >>>> >>>> The safety envelope is shrinking by dramatic increases in >>>> algorithms even if the pace of hardware improvements is slower. = Algorithms >>>> are improving up to 20X >>>> , >>>> lowering the theoretical hardware requirements for breaking clas= sical >>>> encryption. >>>> - >>>> >>>> Bitcoin=E2=80=99s exposed public keys. >>>> - >>>> >>>> Roughly 25% of all bitcoin have revealed a public key on-chain; >>>> those UTXOs could be stolen with sufficient quantum power. >>>> - >>>> >>>> We may not know the attack is underway. >>>> - >>>> >>>> Quantum attackers could compute the private key for known public >>>> keys then transfer all funds weeks or months later, in a covert = bleed to >>>> not alert chain watchers. Q-Day may be only known much later if = the attack >>>> withholds broadcasting transactions in order to postpone reveali= ng their >>>> capabilities. >>>> - >>>> >>>> Private keys become public. >>>> - >>>> >>>> Assuming that quantum computers are able to maintain their >>>> current trajectories and overcome existing engineering obstacles= , there is >>>> a near certain chance that all P2PK (and other outputs with expo= sed >>>> pubkeys) private keys will be found and used to steal the funds. >>>> - >>>> >>>> Impossible to know motivations. >>>> - >>>> >>>> Prior to a quantum attack, it is impossible to know the >>>> motivations of the attacker. An economically motivated attacker= will try >>>> to remain undetected for as long as possible, while a malicious = attacker >>>> will attempt to destroy as much value as possible. >>>> - >>>> >>>> Upgrade inertia. >>>> - >>>> >>>> Coordinating wallets, exchanges, miners and custodians >>>> historically takes years. >>>> - >>>> >>>> The longer we postpone migration, the harder it becomes to >>>> coordinate wallets, exchanges, miners, and custodians. A clear, = time-boxed >>>> pathway is the only credible defense. >>>> - >>>> >>>> Coordinating distributed groups is more prone to delay, even if >>>> everyone has similar motivations. Historically, Bitcoin has been= slow to >>>> adopt code changes, often taking multiple years to be approved. >>>> >>>> Benefits at a Glance >>>> >>>> - >>>> >>>> Resilience: Bitcoin protocol remains secure for the foreseeable >>>> future without waiting for a last-minute emergency. >>>> - >>>> >>>> Certainty: Bitcoin users and stakeholders gain certainty that a >>>> plan is both in place and being implemented to effectively deal wit= h the >>>> threat of quantum theft of bitcoin. >>>> - >>>> >>>> Clarity: A single, publicized timeline aligns the entire ecosystem >>>> (wallets, exchanges, hardware vendors). >>>> - >>>> >>>> Supply Discipline: Abandoned keys that never migrate become >>>> unspendable, reducing supply, as Satoshi described >>>> . >>>> >>>> Specification >>>> >>>> Phase >>>> >>>> What Happens >>>> >>>> Who Must Act >>>> >>>> Time Horizon >>>> >>>> Phase A - Disallow spends to legacy script types >>>> >>>> Permitted sends are from legacy scripts to P2QRH scripts >>>> >>>> Everyone holding or accepting BTC. >>>> >>>> 3 years after BIP-360 implementation >>>> >>>> Phase B =E2=80=93 Disallow spends from quantum vulnerable outputs >>>> >>>> At a preset block-height, nodes reject transactions that rely on >>>> ECDSA/Schnorr keys. >>>> >>>> Everyone holding or accepting BTC. >>>> >>>> 2 years after Phase A activation. >>>> >>>> Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs via= ZK Proof >>>> >>>> Users with frozen quantum vulnerable funds and a HD wallet seed phrase >>>> can construct a quantum safe ZK proof to recover funds. >>>> >>>> Users who failed to migrate funds before Phase B. >>>> >>>> TBD pending research, demand, and consensus. >>>> Rationale >>>> >>>> - >>>> >>>> Even if Bitcoin is not a primary initial target of a >>>> cryptographically relevant quantum computer, widespread knowledge t= hat such >>>> a computer exists and is capable of breaking Bitcoin=E2=80=99s cryp= tography will >>>> damage faith in the network . >>>> - >>>> >>>> An attack on Bitcoin may not be economically motivated - an >>>> attacker may be politically or maliciously motivated and may attemp= t to >>>> destroy value and trust in Bitcoin rather than extract value. Ther= e is no >>>> way to know in advance how, when, or why an attack may occur. A de= fensive >>>> position must be taken well in advance of any attack. >>>> - >>>> >>>> Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tant= alizing >>>> target: any UTXO that has ever exposed its public key on-chain (rou= ghly 25 >>>> % of all bitcoin) could be stolen by a cryptographically relevant q= uantum >>>> computer. >>>> - >>>> >>>> Existing Proposals are Insufficient. >>>> 1. >>>> >>>> Any proposal that allows for the quantum theft of =E2=80=9Clost= =E2=80=9D bitcoin >>>> is creating a redistribution dilemma. There are 3 types of propo= sals: >>>> 1. >>>> >>>> Allow anyone to steal vulnerable coins, benefitting those who >>>> reach quantum capability earliest. >>>> 2. >>>> >>>> Allow throttled theft of coins, which leads to RBF battles >>>> and ultimately miners subsidizing their revenue from lost coi= ns. >>>> 3. >>>> >>>> Allow no one to steal vulnerable coins. >>>> - >>>> >>>> Minimizes attack surface >>>> 1. >>>> >>>> By disallowing new spends to quantum vulnerable script types, we >>>> minimize the attack surface with each new UTXO. >>>> 2. >>>> >>>> Upgrades to Bitcoin have historically taken many years; this >>>> will hasten and speed up the adoption of new quantum resistant s= cript >>>> types. >>>> 3. >>>> >>>> With a clear deadline, industry stakeholders will more readily >>>> upgrade existing infrastructure to ensure continuity of services= . >>>> - >>>> >>>> Minimizes loss of access to funds >>>> 1. >>>> >>>> If there is sufficient demand and research proves possible, >>>> submitting a ZK proof of knowledge of a BIP-39 seed phrase corre= sponding to >>>> a public key hash or script hash would provide a trustless means= for legacy >>>> outputs to be spent in a quantum resistant manner, even after th= e sunset. >>>> >>>> >>>> Stakeholder >>>> >>>> Incentive to Upgrade >>>> >>>> Miners >>>> >>>> =E2=80=A2 Larger size PQ signatures along with incentive for users to = migrate >>>> will create more demand for block space and thus higher fees collected= by >>>> miners. >>>> >>>> =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks. >>>> >>>> =E2=80=A2 A quantum attack on Bitcoin will significantly devalue both = their >>>> hardware and Bitcoin as a whole. >>>> >>>> Institutional Holders >>>> >>>> =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack o= n Bitcoin >>>> would violate the fiduciary duty to shareholders. >>>> >>>> =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitig= ate emerging >>>> threats will prove Bitcoin to be an investment grade asset. >>>> >>>> Exchanges & Custodians >>>> >>>> =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overni= ght. >>>> >>>> =E2=80=A2 Early migration is cheap relative to potential losses, poten= tial >>>> lawsuits over improper custody and reputational damage. >>>> >>>> Everyday Users >>>> >>>> =E2=80=A2 Self-sovereign peace of mind. >>>> >>>> =E2=80=A2 Sunset date creates a clear deadline and incentive to improv= e their >>>> security rather than an open-ended =E2=80=9Csome day=E2=80=9D that inv= ites procrastination. >>>> >>>> Attackers >>>> >>>> =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins = cannot be >>>> spent after Q-day. >>>> >>>> Key Insight: As mentioned earlier, the proposal turns quantum security >>>> into a private incentive to upgrade. >>>> >>>> This is not an offensive attack, rather, it is defensive: our thesis i= s >>>> that the Bitcoin ecosystem wishes to defend itself and its interests >>>> against those who would prefer to do nothing and allow a malicious act= or to >>>> destroy both value and trust. >>>> >>>> >>>> "Lost coins only make everyone else's coins worth slightly more. Think >>>>> of it as a donation to everyone." - Satoshi Nakamoto >>>> >>>> >>>> If true, the corollary is: >>>> >>>> >>>> "Quantum recovered coins only make everyone else's coins worth less. >>>>> Think of it as a theft from everyone." >>>> >>>> >>>> The timelines that we are proposing are meant to find the best balance >>>> between giving ample ability for account owners to migrate while >>>> maintaining the integrity of the overall ecosystem to avoid catastroph= ic >>>> attacks. >>>> >>>> Backward Compatibility >>>> >>>> As a series of soft forks, older nodes will continue to operate withou= t >>>> modification. Non-upgraded nodes, however, will consider all post-quan= tum >>>> witness programs as anyone-can-spend scripts. They are strongly encour= aged >>>> to upgrade in order to fully validate the new programs. >>>> >>>> Non-upgraded wallets can receive and send bitcoin from non-upgraded an= d >>>> upgraded wallets until Phase A. After Phase A, they can no longer rece= ive >>>> from any other wallets and can only send to upgraded wallets. After P= hase >>>> B, both senders and receivers will require upgraded wallets. Phase C w= ould >>>> likely require a loosening of consensus rules (a hard fork) to allow >>>> vulnerable funds recovery via ZK proofs. >>>> >>> -- >> 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+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/4d9ce13e-466d-478b-ab4d-004= 04c80d620n%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/= CALZpt%2BEi2r_sXP5cw%2BL2wP9zQ0_8L-JSfG16zRSayuP9cTdt2Q%40mail.gmail.com. --0000000000006ac9fe063a38eccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Beware the blurry line between stoicism and apathy.>
> How well will it play out if we can say "well, we coul= d have stopped a massive threat but chose not to, because we were confident= the system would survive."
>
> The alternative path is &= quot;we saw a threat coming and the community collaborated to neutralize it= before massive harm occurred."
>
> Both scenarios show r= esilience. Which evokes greater confidence?

Beware "ce qu'o= n ne voit pas" and the perverse incentives introduced by a Q-Day.
<= br>Expect massively PQ "claimed-to-be" secure wallet rushed under= a false sense of emergency, very insecure against classic attacks.

= If I was running a big custodian, def old schoold insurance on quantum risk= is a thing. They already do for pure custody risks.

Otherwise, it&#= 39;s a typical "trolly problem" applied to bitcoin protocol dev. = Indeed multiple viewpoints can be valid.

> I can't speak for = Jameson, but let me put forward my own concern. If miners can buy much less= electricity for 1-BTC this is a major problem for Bitcoin. If the price of= electricity denominated in Bitcoin goes way up, miners will have to mine a= t a massive loss. Many will stop mining, then the block rate will go down a= nd Bitcoin will appear to be less valuable (high fees, slow confirmation, p= anic), which makes mining even more of a loss, and so on. This also invites= miners who have nothing left to lose to engage in mining attacks.

I= t's a real problem, but not specific to quantum. The same risk could ha= ppen when the inflation schedule is dried up after few halvings, or other e= xogeneous reason.

About the price crash and hypothetical impact on m= iners, a lot of open dimensions:
- unclear if the quantum adversary is e= conomically rational and HODL its stack
- unclear if the quantum adversa= ry would be able to liquidate its BTC stack bc on-ramp flagging them as sto= len BTCs
- fragmentation of the on-ramp BTC markets over the world and i= f price down would reflect uniformly
- unclear if selling strategy of qu= antum adversary can be anticipated by miners
- poor elasticity of demand= for miners electricity providers (e.g hydro or=C2=A0flare)
- unclear if= the price crash can be quickly corrected by strong hands anticipating the = "once-in-a-lifetime" cheap sell
- what else ?

I do agre= e it's a serious concern to have. On the other hand, we don't have = a real quantitative model to reason on miners reaction.

In my view, = this conv would be far more constructive, fact-based if someone can come up= with a model on miners impact with what if ~20% of coins are quantum nuked= .

Best,
Antoine
OTS hash: 74b5c0cdee22c391c2c50b052b652368ce1d= 01edc660077847b8ed662f0d172c

Le=C2=A0lun. 14 juil. 202= 5 =C3=A0=C2=A019:52, Jameson Lopp <jameson.lopp@gmail.com> a =C3=A9crit=C2=A0:
<= br>

On Mon, Jul 14, 2025 at 10:09=E2=80=AFAM Antoine Riard <antoine.riard@gmail.com= > wrote:
Hi J= ameson,

Thanks for your thoughts on this complex subject.

Fir= st and foremost, I think your following statement: "Never before has B= itcoin faced
an existential threat to its cryptographic primitives"= is very myopic, given that
cryptanalysts and number theorists are makin= g progress every year in their works, and
each bitcoin cryptographic pri= mitive has been and is constantly analyzed to uncover
potential weakness= es.

So in my view the quantum threat is a bit less specific that the= image you're painting
of it. Even if go all to upgrade to lattices-= based schemes, we have no certainty that
novels flaws won't be found= , one can just go to see the modifications of the NIST-approved
schemes = in between their rounds of selection that we'll never reach something l= ike
"self-sovereign peace of mind"...Unless we start to forbid= people of practicing the
art of mathematics, practice which has been on= going since Euclide and Pythagore...

I do concede that quantum is a = bit different, as after all new physics paradigm
do not happen often (He= isenberg published in the 20s iirc), though that's in my
view the fl= aw of your reasoning as you're assuming some "post-quantum" u= pgraded
state where bitcoin, as a community and a network, would be defi= nitely safe from
advances in applied science. At minima, in my understan= ding, you're arguing this
time is different to justify extra-ordinar= y technical measures never seen before,
namely the freezing of "vul= nerable" coins.


Correct, this = time is different in that we're not talking about vague unknown weaknes= ses. Rather, we're talking about a known algorithm that makes breaking = cryptographic primitives orders of magnitude cheaper.

<= div>The unknown becomes the rate at which advancements in quantum computing= will be achieved, which is concerning given the funding going into pushing= said advancements forward.
=C2=A0
I'm worried this is opening a Pandora box, whe= re we would introduce a precedent
that it is legitimate as a community t= o technicaly confiscate some coins of users,
without their _consents_, = for extra-ordinary reasons. That's opening a worms of
shenanigans in= the future...There is no guarantee that this precedent won't
be lev= eraged in the future by any group of entities to justify future upgradeseroding one of the "fundamental property" you're yourself de= eming as valuable.


This is a fair f= ear, though the counterpoint is that it is legitimate for the community to = protect itself against security threats. It just so happens that both viewp= oints can be valid.

This is especially worrying as if I'm understanding you = correctly you're justifying
this position as that somehow we should = protect the price of the currency as an end
in itself (i.e "Beyond = its impact on price, ..."). It's unclear the price of bitcoin
v= ersus what fiat or hard asset (e.g oil) you have in mind. And in anyway, as= far
as I know, none of the bitcoin devs is seating on the board of the = FED, the ECB
or the BoJ...

To put it simply, even if a quantum at= tacker can tomorrow starts to steal
vulnerable coins, 1 BTC will be alwa= ys equal to 1 BTC. Full stop. In my humble
opinion, let's not introd= uce the idea that, we, as a community of stakeholders
and developers we = have a positive "fiduciary" duty to act to maintain the price
= of bitcoin in some "monetary snake" with another class of assets.= ..


Protocol developers have no fidu= ciary duty to bitcoin holders. I wouldn't argue they have any duty what= soever=C2=A0to users.

Bitcoin is not (yet) a unit = of account. The ecosystem does not run on 1 BTC =3D 1 BTC. The purchasing p= ower of satoshis is very much relevant to the health and sustainability of = the ecosystem at its current level.

I would not cl= aim that "devs must do something" - rather, I believe that the in= centives of other groups I outlined will roughly align them with my thinkin= g.

Th= at's also the problem with game theory, all the matrices of analysis ar= e
based on some scale of utilitarism. See Von Neuman's Theory of Gam= es, the
section on "The Notion of Utility". My subjective appr= eciation of the value
of my coins might not be your subjective appreicat= ion of the value of your
coins.

Now I do understand the perspecti= ve of the institutional holders, the exchanges,
the custodians or any ot= her industry providers, who might be in the full uncertainty
about their= business responsibilities in case of a quantum threat affecting their
c= ustodied coins. But, first legally speaking there is something call "f= orce majeure"
and in view of the quantum threat, which is a risk di= scussed far beyond the bitcoin
industry, they should be able to shield t= hemselves behind that. Secondly, if there
is any futute upgrade "op= t-in" only path a la BIP360, you can move your funds or
the ones un= der custody =C2=A0under a PQC scheme like Dilthium or Falcon and be goodwithout caring about what the others users are doing. Thirdly, if you'= re an actor
in the industry like Coinbase and you're deeply concerne= d about how extended maelstrom
on the price might affect the viability o= f your operations, it is unclear to me why
you don't call MunichRe o= r any other company like that tomorrow to craft and be
covered by specif= ic insurance on quantum threats...

Agreed that com= panies may be legally protected from lawsuits. Not sure about the insurance= angle, though I'd see that as a one time payout that=C2=A0could very= =C2=A0well come at the expense of said business ceasing operations. I suspe= ct few businesses would be happy with that.

Unfort= unately I don't think opt-in security suffices in this situation. Human= nature is to procrastinate and if the incentives are insufficient to motiv= ate mass migration to quantum secure schemes, Q-Day will be quite=C2=A0unpl= easant.
=C2=A0
To be frank, all those considerations on how "I cannot see how th= e currency can
maintain any value at all in such a setting", is a s= trong red flag of low time
preferences. It's not like we're used= to strong volatility in bitcoin with the
almost 2 decades of operations= of the network. In my view, it's more a hint of
very high-expositio= n by some to a single class of asset, i.e bitcoin, rather than wise
dive= rsification... And a push to sacrify a "fundamental property" i.e= "conservatism"
in view of short-term concerns (i.e the stabil= ity of the currency price along
a period of few years).


Bitcoin has many inviolable properties and some of = them are actually in conflict with each other. Conservatism and property ri= ghts are clearly on the table in this matter.

But = shouldn't one of Bitcoin's fundamental properties be the fact that = it can be upgraded? That it can respond to new challenges and threats?

Beyond just the quantum computing issue, I expect the = above to create continued conflict between ossifiers and developers over th= e long term.

Do not get me wrong, I'm certainly not of the school "let&= #39;s reward quantum
attackers". Leveraging techical superiority an= d employing CRQRC to steal
vulnerable coins would be clearly a theft. Bu= t ethically, the best we can do is
to have an opt-in upgrade path and be= pro-active, by education and outreach,
to have the maximum of coin owne= rs upgrading to non-vulnerable addresses types.
Then show the level of &= quot;fortitude" or "endurance" as a community in face of pri= ce
fluctuations for a while, while seeing regularly old P2PK coins hacke= d. Marcus
Aurelius can be bought for few bucks in most of decent librari= es...


Beware the blurry line betwee= n stoicism and apathy.

How well will it play out i= f we can say "well, we could have stopped a massive threat but chose n= ot to, because we were confident the system would survive."
=
The alternative path is "we saw a threat coming and the= community collaborated to neutralize it before massive harm occurred."= ;

Both scenarios show resilience. Which evokes gre= ater confidence?

I'm definitely on the "no old coins confiscation"= position you're underlighting:

"I don't see why old co= ins should be confiscated. The better option is to let
those with quantu= m computers free up old coins. While this might have an
inflationary imp= act on bitcoin's price, to use a turn of phrase, the inflation
is tr= ansitory. Those with low time preference should support returning lost
c= oins to circulation".

Notwhitstanding that I disagree with your= position, one can only appreciate
the breadth and depth with which you&= #39;re gathering and articulating all the
elements on this complex probl= em.

Best,
Antoine
OTS hash: c064b43047bf3036faf098b5ac8e74930d= f63d25629f590a4195222979402826
Le lundi 14 juillet 2025 =C3=A0 00:53:34 UTC+1, Ta= dge Dryja a =C3=A9crit=C2=A0:
Hi =C2=A0

While I generally agree that "freeze&q= uot; beats "steal", and that a lot of lead time is good, I don= 9;t think this plan is viable.
To me the biggest problem is that it ties= activation of a PQ output type to *de*activation of EC output types.=C2=A0= That would mean that someone who wants to keep using all the great stuff i= n libsecp256k1 should try to prevent BIP360 from being activated.

Su= re, there can be risks from CRQCs.=C2=A0 But this proposal would go the oth= er direction, disabling important functionality and even destroying coins p= reemptively, in anticipation of something that may never happen.

Als= o, how do you define "quantum-vulnerable UTXO"?=C2=A0 Would any P= 2PKH, or P2WPKH output count?=C2=A0 Or only P2PKH / P2WPKH outputs where th= e public key is already known?=C2=A0 I can understand disabling spends from= known-pubkey outputs, but for addresses where the public key has never bee= n revealed, commit/reveal schemes (like the one I posted about & am wor= king on a follow-up post for) should safely let people spend from those out= puts indefinitely.

With no evidence of a QRQC, I can see how there w= ould be people who'd say "We might never really know if a CRQC exi= sts, so we need to disable EC spends out of caution" and others who= 9;d say "Don't disable EC spends, since that's destroying coin= s", and that could be a persistent disagreement.=C2=A0 But I hope if w= e did in fact have a proof that a CRQC has broken secp256k1, there would be= significant agreement on freezing known-pubkey EC outputs.

-Tadge
On Saturday, July 12, 2025 at 8:46:09=E2=80=AFPM UTC-4 Jameson L= opp wrote:

<= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style= :normal;font-variant:normal;text-decoration:none;vertical-align:baseline;wh= ite-space:pre-wrap">Building upon my earlier essay against allowing quantum recovery of bitcoin I wish to formalize a proposal after several months of discussions.=

This proposal does not delve into the multitude of issues regar= ding post quantum cryptography and trade-offs of different schemes, but rat= her is meant to specifically address the issues of incentivizing adoption a= nd migration of funds after co= nsensus is established that it is prudent to do so.

As such, this proposal requires P2Q= RH as described in BIP-360 or potential future proposals.

Abstract

This proposal follows the implemen= tation of post-quantum (PQ) output type (P2QRH) and introduces a pre-announ= ced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security in= to a private incentive: fail to upgrade and you will certainly lose access to your funds, crea= ting a certainty where none previously existed.=C2=A0

  • Phase A: Disallows sending of = any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH = address types.

  • Phase B: Renders ECDSA/Schnorr spends = invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This= is triggered by a well-publicized flag-day roughly five years after activa= tion.

  • Pha= se C (optional): Pending further research an= d demand, a separate BIP proposing a fork to allow recovery of legacy UTXOs= through ZK proof of possession of BIP-39 seed phrase.=C2=A0=C2=A0

Motivation

We seek to secure the value of the UTXO set and minimize incentives f= or quantum attacks. This proposal is radically different from any in Bitcoi= n=E2=80=99s history just as the threat posed by quantum computing is radica= lly different from any other threat in Bitcoin=E2=80=99s history.=C2=A0 Nev= er before has Bitcoin faced an existential threat to its cryptographic prim= itives. A successful quantum attack on Bitcoin would result in significant = economic disruption and damage across the entire ecosystem. Beyond its impa= ct on price, the ability of miners to provide network security may be signi= ficantly impacted.=C2=A0=C2=A0

  • Accelerati= ng quantum progress.=C2=A0

  • NIST ratified three production-grade PQ signature schemes in 2024; a= cademic road-maps now estimate a cryptographically-relevant quantum compute= r as early as 2027-2030. [McKinsey]

Quantum= algorithms are rapidly improving

  • The safety envelope is shrinking by dramatic increases in algorithms even= if the pace of hardware improvements is slower. Algorithms are improving up to 20X, lowering th= e theoretical hardware requirements for breaking classical encryption.

  • Bitcoin= =E2=80=99s exposed public keys.=C2=A0=

    • Roughly 25% of all bitcoin have revealed a public key on-= chain; those UTXOs could be stolen with sufficient quantum power.=C2=A0=C2= =A0

  • We may not know the attack is underway.=C2=A0

    =

    • Quantum attackers could compute the priv= ate key for known public keys then transfer all funds weeks or months later= , in a covert bleed to not alert chain watchers. Q-Day may be only known mu= ch later if the attack withholds broadcasting transactions in order to post= pone revealing their capabilities.

  • Private keys become public.=C2=A0

    =

    • Assuming that quantum compu= ters are able to maintain their current trajectories and overcome existing = engineering obstacles, there is a near certain chance that all P2PK (and ot= her outputs with exposed pubkeys) private keys will be found and used to st= eal the funds.

  • Impossible to know motivations.=C2=A0

    • Prior to a quantum attack, it is impossible= to know the motivations of the attacker.=C2=A0 An economically motivated a= ttacker will try to remain undetected for as long as possible, while a mali= cious attacker will attempt to destroy as much value as possible.=C2=A0=C2= =A0

  • = Upgrade inertia.=C2=A0

    • Coordinating wallets, exchanges, miners and custodians historically take= s years.

    • The longer we postpone migration, the harder it becomes to coordinate = wallets, exchanges, miners, and custodians. A clear, time-boxed pathway is = the only credible defense.

    • = Coordinating distributed groups is more prone to de= lay, even if everyone has similar motivations. Historically, Bitcoin has be= en slow to adopt code changes, often taking multiple years to be approved.<= /span>

    Benefits at a Gla= nce

    • Resilience: Bitcoin protocol remains secure for the foreseeab= le future without waiting for a last-minute emergency.

    • Certainty: Bitcoin users and stakeholders gain certain= ty that a plan is both in place and being implemented to effectively deal w= ith the threat of quantum theft of bitcoin.=C2=A0=C2=A0

    • Clarity: A single, publicized timeline aligns the ent= ire ecosystem (wallets, exchanges, hardware vendors).

    • Supply Discipline: Abandoned keys that never migrate b= ecome unspendable, reducing supply, as Sa= toshi described.=C2=A0=C2=A0

    Specification

    = <= td style=3D"border-width:1pt;border-style:solid;border-color:rgb(0,0,0);ver= tical-align:top;padding:5pt;overflow:hidden">

    Ph= ase B =E2=80=93 Disallow spends from quantum vulnerable = outputs

    Phase

    What Happens

    Who Must Act<= /span>

    Time Horizon

    Phase A - Disallow spends to legacy scr= ipt types

    		<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;f= ont-variant-east-asian:normal;font-variant-alternates:normal;vertical-align= :baseline">Permitted sends are from legacy scripts to P2QRH scripts<= /p>

    Everyone holding or accepting BTC.

    3 years = after BIP-360 implementation

    At a preset block-height, nodes reject transactions that rely on E= CDSA/Schnorr keys.=C2=A0

    Everyone hol= ding or accepting BTC.

    2 years after Phase A activation.

    <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-= numeric:normal;font-variant-east-asian:normal;font-variant-alternates:norma= l;vertical-align:baseline">Phase C =E2=80=93 Re-enable s= pends from quantum vulnerable outputs via ZK Proof

    Users with frozen quant= um vulnerable funds and a HD wallet seed phrase can construct a quantum saf= e ZK proof to recover funds.

    Users who failed to migrate funds before Phas= e B.

    TBD pending research, demand, and consensus.

    Rationale

    • <= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">Even if Bitcoin is not a primary initial target of a= cryptographically relevant quantum computer, widespread knowledge that suc= h a computer exists and is capable of breaking Bitcoin=E2=80=99s cryptograp= hy will damage faith in the network .=C2=A0

    • An attack on Bitcoin may not be econo= mically motivated - an attacker may be politically or maliciously motivated= and may attempt to destroy value and trust in Bitcoin rather than extract = value.=C2=A0 There is no way to know in advance how, when, or why an attack= may occur.=C2=A0 A defensive position must be taken well in advance of any= attack.=C2=A0=C2=A0

    • Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be= a tantalizing target: any UTXO that has ever exposed its public key on-cha= in (roughly 25 % of all bitcoin) could be stolen by a cryptographically rel= evant quantum computer.

    • Existing Pro= posals are Insufficient.=C2=A0=C2=A0

      1. Any proposal that allows for the quantum theft of =E2=80=9Clos= t=E2=80=9D bitcoin is creating a redistribution dilemma. There are 3 types = of proposals:

        1. Allow anyone = to steal vulnerable coins, benefitting those who reach quantum capability e= arliest.

        2. Allow throttled theft of coins, which leads to RBF battles and ul= timately miners subsidizing their revenue from lost coins.

          3. <= li dir=3D"ltr" style=3D"list-style-type:lower-roman;font-size:11pt;font-fam= ily:"Courier New",monospace;color:rgb(0,0,0);background-color:tra= nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-va= riant-alternates:normal;vertical-align:baseline;white-space:pre-wrap">

          Allow no one to= steal vulnerable coins.

    • Minimizes attack surface

      1. By disallowing new spends to q= uantum vulnerable script types, we minimize the attack surface with each ne= w UTXO.=C2=A0=C2=A0

      2. Upgrades to Bitcoin have historically taken many years= ; this will hasten and speed up the adoption of new quantum resistant scrip= t types.=C2=A0

      3. With a clear deadline, industry stakeholders will more read= ily upgrade existing infrastructure to ensure continuity of services.=C2=A0= =C2=A0

    • Minimizes loss of access to funds=C2=A0

      1. If there is sufficient demand and resea= rch proves possible, submitting a ZK proof of knowledge of a BIP-39 seed ph= rase corresponding to a public key hash or script hash would provide a tru= stless means for legacy outputs to be spent in a quantum resistant manner, = even after the sunset.=C2=A0=C2=A0


    <= /colgroup><= td style=3D"border-width:1pt;border-style:solid;border-color:rgb(0,0,0);ver= tical-align:top;padding:5pt;overflow:hidden">

    In= centive to Upgrade

    Stakeholder

    Min= ers

    =E2=80=A2 Post-Phase B, non-upgraded mine= rs produce invalid blocks.

    =E2=80=A2 A quantum attack= on Bitcoin will significantly devalue both their hardware and Bitcoin as a= whole.=C2=A0

    Institutional= Holders

    =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack= on Bitcoin would violate the fiduciary duty to shareholders.=C2=A0=C2=A0

    =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to e= ffectively mitigate emerging threats will prove Bitcoin to be an investment= grade asset.

    Exchanges &am= p; Custodians

    		=

    = =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them= overnight.

    =E2=80=A2 Early migration is cheap relati= ve to potential losses, potential lawsuits over improper custody and reputa= tional damage.

    Everyday Use= rs

    =E2=80=A2 Self-sovereign peace of mind.

    =E2=80=A2 Su= nset date creates a clear deadline and incentive to improve their security = rather than an open-ended =E2=80=9Csome day=E2=80=9D that invites procrasti= nation.

    Attackers

    =E2=80= =A2 Economic incentive diminishes as sunset nears, stolen coins cannot be s= pent after Q-day.

    Key Insight: As mentio= ned earlier, the proposal turns quantum security into a private incentive to upgrade.=C2=A0= =C2=A0

    This is not an offensive attack, rather, it is= defensive: our thesis is that the Bitcoin ecosystem wishes to defend itsel= f and its interests against those who would prefer to do nothing and allow = a malicious actor to destroy both value and trust.=C2=A0=C2=A0


    =

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

    If true= , the corollary is:


    The timelines that we are proposing are meant to find the best bal= ance between giving ample ability for account owners to migrate while maint= aining the integrity of the overall ecosystem to avoid catastrophic attacks= .=C2=A0=C2=A0


    Backward Compatibility

    As a series of soft forks, older nodes will continue to operat= e without modification. Non-upgraded nodes, however, will consider all post= -quantum witness programs as anyone-can-spend scripts. They are strongly en= couraged to upgrade in order to fully validate the new programs.

    =

    Non-upgraded wallets can receive and send bitcoin from non-= upgraded and upgraded wallets until Phase A. After Phase A, they can no lon= ger receive from any other wallets and can only send to upgraded wallets.= =C2=A0 After Phase B, both senders and receivers will require upgraded wall= ets.=C2=A0Phase C would likely require a loosening of consensus rules (a ha= rd fork) to allow vulnerable funds recovery via ZK proofs.

    --
    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/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegrou= ps.com.

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