From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Aug 2026 07:56:30 -0700 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wtntz-0008EW-Ty for bitcoindev@gnusha.org; Tue, 11 Aug 2026 07:56:30 -0700 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-6ae4917006esf2283804eaf.2 for ; Tue, 11 Aug 2026 07:56:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1786460182; cv=pass; d=google.com; s=arc-20260327; b=fO4rhCX2eqRLVsfqo63l4WiAHv7JzK1aoc82gQd2hnt5gjKiEWtyebJuRxiiind6zX gBklz/5JtGa6PRXGqfiTZKgcBUAqzT3DQ+kqopATSg2ybcqE0pwXht2OSAyRMVouG4NQ +H+be+OS5heViGHWSRbWNgvKBhWc94xzahQW/OMTUDDf3ic5D9b8nApm4y1vCJr6gItp /hmTBqr6+mmIrDduCFCdv0RYhUV+QdsOulSsjcY76XBHkkBrvAVM1Xc/Y2CnrpEtX0dm AsHx64gwuIWxnXQjEcNsrJi5OEYxj5Z9iQV2FFgToLEsUQlP8AMplm/XP5f1dcLKAR/P rPoQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=5qbo5beQUxkphC9CFYbigymt0d0amyfz+NSDMmJ84xs=; fh=tovf7B0NsxHSNfae8xQmwwmG2ii0OesFS8mO1MgoJsg=; b=Zunw3klpJztBPN6BUcWCV//sfd10j0sDurM0OcRKPGWBB9yXfHBGJuLLLu0IM+VGuk cNLy7Ya1ZIpW5LZEOqUcFsaaD2ez7fjgBvhRrRLp5Ia8NBP87er3863hQEoNj4pdwWft B6R649C/OsQq+i1rNtxQg744RS81HGNvUUuN7zNuG9ACFZRd/F928+XLf5dueJyL/5Bc i6MDZwzcB1e6bW6xZwb3mHfW1yUfb/y1+IQPW+ZBvdjn7x39m6zUjud/s4HpX+bf9lpq eAQ6t8SLXUE5jqST8xSAy8uMMV3Jcr9NtWKGejmAX7NQtQRTH8/N2sGpdCru3oifzDEp 3ouQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=c2juo2dxknabtp2llvue2ghnje.protonmail header.b="nlM/aLQd"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786460182; x=1787064982; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5qbo5beQUxkphC9CFYbigymt0d0amyfz+NSDMmJ84xs=; b=I375z/pX1FEfzjRr/W7lC332rgecBixYGOOBIdnlSu+vPT8t7ft3Hk46O09H84+lBC GHQozCQeqPJBc69w9UeApu2ftG/JbQOkNrYkPp7xQds6QvlOb5bVOnY/+eJCoBITJ4u2 lMduymHqy7bFaKglZaz2rR9fvsQeOxVDcpO4jl/SCukuwz8XdsBBFIy32VBtt34cJXaP lMytMPq7k5y8g0/g6lSmQMyIfSYLaUEE6i8NV6gWLTRf/glJnEMDdmQoJnDWHdGbK+rL 1UUEOErg56143/o29/nfeICghABKxC1A6thU5f6D3mWn7QEAGjM2mQyYbbiYS03BBXkT sc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786460182; x=1787064982; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=5qbo5beQUxkphC9CFYbigymt0d0amyfz+NSDMmJ84xs=; b=Jb0Lliinmq8IJYgLh7cx5Ej/kzP7Vt0LBkDTd6j6ydUx8ryxL+XJmWpESpjwi+XaX2 g6SkCorkkgaCrymg98+vqjg7XyumdGrlT7NjSwk5K587TdhxXrWN/sB+gIms6Dp8cp+c 54UFoiw7OUOaxrvmMleu3/pzRyTx3rbMCeTkgrDKMqiJPwKkKaPkq27vJg116pmUywG9 bRvswPDs7PrTpDCOD9b557ip59CC3TU+RSMQnuGkbMbpQhCfUkPfXIEMO8C0VDNWyOeQ 0M+sJVwNDna0QPpW55jcRiCXss22EdmObk+sNESeBEz1891yNEofR17vSeLZFm74pcy0 orkw== X-Forwarded-Encrypted: i=2; AHgh+RoFj6YwIocR6GtWUCrePUW4wlTbW6p0hzJEn6XLnbueQxXUWMKIbAzLlTWcf1laJgysyHlyKfGmnhH0@gnusha.org X-Gm-Message-State: AOJu0YzZyR3TA6wJwsDaswFG5YtImxS1x264MPQhDK7Sz3z+UbJ0aTXL FYizceRx0C57ZGOZAmNPJ8uApCZgw3u0aTsi6GJag2KfVT1+Agr2p0IQ X-Received: by 2002:a05:6820:80f:b0:6a3:1dc5:3570 with SMTP id 006d021491bc7-6b0a3237255mr2343601eaf.31.1786460181900; Tue, 11 Aug 2026 07:56:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPRNVmcRNFlyJY5UDA6uicBBgKNpzKAzr+fc0B0q68TWUQ==" Received: by 2002:a05:6820:201a:b0:6ac:a68c:87b9 with SMTP id 006d021491bc7-6b041377ea4ls2436716eaf.0.-pod-prod-03-us; Tue, 11 Aug 2026 07:56:16 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RrbQzZrv5FYeVmRpr5NXr5HuTsO67dSTR5aqKh1vu1v+/4C9GYwvBE0Lo6QrgoJhQv02IJSJiP/5pas@googlegroups.com X-Received: by 2002:a05:6808:1314:b0:497:d1e7:5e90 with SMTP id 5614622812f47-4b1fd967fafmr2938455b6e.18.1786460176828; Tue, 11 Aug 2026 07:56:16 -0700 (PDT) Received: by 2002:a05:600c:570f:b0:495:5022:71be with SMTP id 5b1f17b1804b1-4995b122a12ms5e9; Tue, 11 Aug 2026 07:46:23 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RruEy5J4KWP3HXm0/elmPvxrPRNERrLj0D8KIQS4FSYT3kOmzIlKvQIRO8IJE7LkuLhZlDpelt7imtI@googlegroups.com X-Received: by 2002:a05:600c:4e4a:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-4997843ee51mr66773655e9.7.1786459581239; Tue, 11 Aug 2026 07:46:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786459581; cv=none; d=google.com; s=arc-20260327; b=WMVCMQXshOWik2xex+qjcBU9aQyTii01r9ZZJYS4mm2KFxi+AVWvuIv0dFcVgqBIhL +lNycwBsSqGuqsCJdSGPEQOr7XyTMvuCH23HjytuXx4I8FDd37MiNfhiOIGu5hPn12OZ rsZhz34cqp4uK/dbxXPlCCUkprEsKtdIjxWFZyZHNoNXjuFh1sIdgHPZYNml3Au+rLRf 70F4j1g2nephStcoLAqH4+1U2FgQuyfYKim5W2YbawHHU/8K8bp3vh0Kj2alfP7eOEBK DhJqQeRCImicu6StrxHNYUh2osz90TPOm9HD0M/LJOstckb7CXvrie0uZMVpd6Ve30cI S5QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=tFfd0ryujJWxniSNZHBYWoMKjb/EYbR/loNHyLeq+HI=; fh=damNe00l9VF7aUu2BFJ3Gdo7CcZXLO84FFy5MbKvVas=; b=L0MVEsEpsHRPtGzusm/eeNkkgXYFdDGXJu/KqcQT5HnUHZuYBTRXPchJ0OyY/Bd92N eq2fTpXGt9Ep6N3We3dvOe4EJs+/uP6odTDeUBOJZwljlBLbotqxscnKtRIAeZZP6cMu 72J67l8KZVbSNZCMHNTpP10vwSqaCPX+W/5+wRFTJpW8qMXiUUrEG72Erl+LqADugqwE FQN/emi4cr5lL1+E93gyOG/rZSiVdqSRx1xQxLFVwb7yO6n/x5CqtmdT8os7w5dKk/l5 R1peu4v6kudqlKFjA8+eW3MGZpGUlWMfSLMe5ppRI63mwX/zp55nsO08dA0/C6dvn2E/ ADbQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=c2juo2dxknabtp2llvue2ghnje.protonmail header.b="nlM/aLQd"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch. [185.70.43.25]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4997414f3b6si544235e9.2.2026.08.11.07.46.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 07:46:21 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) client-ip=185.70.43.25; Date: Tue, 11 Aug 2026 14:46:12 +0000 To: Ian Quantum From: "'conduition' via Bitcoin Development Mailing List" Cc: Antoine Riard , Bitcoin Development Mailing List , btc@ariard.me Subject: Re: [bitcoindev] The game-theory problems of PQ sunsetting modes Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: f422b787a6d05f8b5c7e379a9714bb4131b85507 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------5390cf92119e9e206fe279d3d9ecf9fae64f038fcfe3c9377168f79313ed82d0"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=c2juo2dxknabtp2llvue2ghnje.protonmail header.b="nlM/aLQd"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------5390cf92119e9e206fe279d3d9ecf9fae64f038fcfe3c9377168f79313ed82d0 Content-Type: multipart/mixed;boundary=---------------------5dce4db9eb87e705aec7a612ee4238fe -----------------------5dce4db9eb87e705aec7a612ee4238fe Content-Type: multipart/alternative;boundary=---------------------ca1e17267eceb80492f5e7a03f226378 -----------------------ca1e17267eceb80492f5e7a03f226378 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > It will run for 9-12 days according to my calculations. Can you show us these calculations? > The CCP publicly stated that they must destroy Bitcoin in order to surviv= e as a country, on the evening news. Do you have a source on this claim? > Drain the side chain of their coins ... > The next target would likely not be Bitcoin or any side chains of Bitcoin= , but Ethereum. I'm not sure if that'd be a wise idea, since sidechains and altcoins like E= thereum are more likely to hard fork to undo an attack:=C2=A0https://ethres= ear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/1= 8901 Quantum attackers would want plausible deniability, but also finality (no b= acksies). Otherwise the attack is pointless. regards, conduition On Monday, July 27th, 2026 at 9:50 AM, Ian Quantum wrote: > The first cryptographically relevant quantum computers are likely to be s= low, especially if they are neutral atom, trapped ion or some of the NV Dia= mond variants depending on the speed of the computation and stability of th= e qubits. Realizing the quantum attacks are going to be a surprise, my game= theory approach is different. Quantum Physicists will not suddenly decide = to become hackers and start attacking banking networks while living in the = USA, EU or China. Chinese strategy as I see it will be covered separately, = below. > Quantum Physics will not offer new near term gains in mining, as Pierre-L= uc explained. Attacks against Bitcoin are broken into short and long window= s of opportunity. Since the first quantum computer to break Bitcoin will li= kely be a long window, slow attack neutral atom I will give some more gener= al information. It will run for 9-12 days according to my calculations. Wit= h tricks, they currently have a run window that permits an attack. With qub= it reuse the attack is a function of time, not the size of the machine assu= ming it has more than 2000 qubits of operational space. The attacks can be = squeezed in under 900 qubits, but the runtime grows to match. The optimal s= trategy would be full width for a single key break, then switching to runni= ng multiple keys concurrently on one machine as soon as funds are available= for more qubits. Attack round 2 would likely break 4-100 keys at a time, o= perating against a single equation like secp256k1, secp256r1, ed25519, x255= 19, etc. Switching equations is just a change to the python in linux. Addin= g more physical qubits allows attacking more keys in parallel for the same = steps and time (but a little extra bookkeeping). Attacking RSA2048 keys wil= l be 1-3 years after the first secp256k1 break unless it is PSI Quantum in = late 2027 and they hit their milestone target. >=20 > The long window attack will eventually be surpassed by the short window a= ttack, coming from photonics or superconductors. There are some obscure (no= t mainstream) fast operations possible on trapped ion and NV Diamond quantu= m computers. When the short window CRQC comes into play, the runtime will b= e in minutes but still parallel execution for a small qubit cost and no tim= e cost. 10 private keys in 10-70 minutes would be the target. This is sched= uled for 2028 by PSI Quantum, but I hope that they are simply "under retain= er" by the NSA and not able to publicly demonstrate their capabilities. PSI= Q has already demonstrated qubit reuse, they have already mass produced hu= ndreds of thousands of qubits in horizontally scaling systems. If they star= t off cracking a single private key, they can switch to breaking 2, then 4 = just by continuing mass production and installation. >=20 > A strategic CRQC operator would select their first target as one with low= reputation and questionable security. Drain the side chain of their coins = and don't touch Satoshi's Shield or any tripwire transactions. To further i= ncrease deniability, the stalwart quantum physicists may decide to launder = the gains in the same way that people from North Korea or Iran does. A few = hundred million dollars is a likely early target. > The next target would likely not be Bitcoin or any side chains of Bitcoin= , but Ethereum. The public keys are 100% exposed in DeFi. Physicists have u= rged upgrading prior to 2024 and the upgrades will likely arrive too little= , too late. Pocket another $100 billion, ideally with continued plausible d= eniability. >=20 > At this point the quantum attacker could spend 5-15% of the gains and sim= ply purchase the ASIC manufacturer outright. This would allow them to again= operate with plausible deniability. Get hired by the company after the pur= chase. Work on something fun. Now that the quantum achievement has been com= pleted. The purchase of 1-2 ASIC manufacturers would allow them to simply o= wn the hash rate, with any generational improvement. They could choose to s= ell machines after they have been eclipsed by newer hash rates. >=20 >=20 > China has a different goal. The CCP publicly stated that they must destro= y Bitcoin in order to survive as a country, on the evening news. Currently = 1/3 of China's GDP is leaving the country each year and Bitcoin is the most= efficient method to do so. Tron and Tether are face value, but Bitcoin is = easy to send money overseas. Use Yuan to buy mining equipment, sell Bitcoin= for EU or USD. This is done at a profit, while art sales and Tether are do= ne at a significant or small loss respectively. China's Middle Class faces = export controls on sending money overseas, international banking is extreme= ly limited and total control is the CCP bare minimum standard. >=20 >=20 > Against this backdrop, China has thrown millions of dollars at dozens of = companies to create a huge number of quantum computers racing to be the fir= st to break Bitcoin. Bitcoin is the stated goal. Destroying Bitcoin as a st= ore of value is the government strategy. Rapid sales of any known public ke= ys will commence ASAP, and CRCQ will be mass produced. So their likely runt= ime would be targeting Satoshi's Shield, getting 50 BTC per break. If they = can catch exchange funds "proof of reserves" then they will topple most of = the economic value. 6.9 million BTC to target. They might trigger a tripwir= e, the goal is to dump the market and the exchanges. >=20 > I suspect the CCP will target Ethereum in order to cause critical damage = to the US economy, especially as stablecoins and CBDC have jumped in. Bitco= in sales would allow them to pay down a small portion of their debt. Ethere= um sales would allow China to supersede the USA as the dominant economy. As= I have said publicly, the strategy is much different depending on the thre= at actor who gets the first and who gets the fast CRQC. >=20 > The game theory for each threat actor is different: > US Individual: plausible deniability, stealth, money laundering. > US Company: salvage laws, plausible deniability, can not have govt fundin= g and target US companies like Blackrock, (micro)Strategy, Coinbase, etc. > EU Company: ideologically driven, might break a few accounts for retireme= nt but not touch most public keys. > China: must crash all crypto to survive. If they can destroy Bitcoin, min= ing and pay down debt, great. If they can use this to 'break the hegemonic = order' they will definitely do so. >=20 > I would be happy to discuss here or on Signal. >=20 > On Mon, Jul 27, 2026 at 1:53=E2=80=AFAM Antoine Riard wrote: >=20 > > Hello Conduition, > >=20 > > > Solid analysis Antoine. However things play out here, activating a PQ= sunset fork of any kind while in the company of a CRQC is apparently quite= hard to do right without setting the incentives up such that they sabotage= the whole effort. > >=20 > > That's the insight that my post aims to underscore, effectively > > that activating a PQ sunset fork of any kind might be very hard > > in the presence of one or more company with a CQRC, at the very > > least there is a lot of uncertainty due to the incentives. > >=20 > > You're correct that the problem appears as soon as you have a > > company with one CRQC, where it can just go really deep in the > > history of the chain. As soon as you start to have two CRQC, > > there is an advantage to burn more EC coins in fees, to reorg to > > your advantage, so we're back with some notion of chain finality. > >=20 > > See more comments on rough ideas to alleviate the issue. > >=20 > > > Very neat observation. For such a rollback to occur, the miners would= have to cooperatively elect to stop mining the more mature ("authentic") c= hain, where users have already migrated/forked, and instead start mining on= an old block (the "revisionist" chain). Any resources they spend on this m= ining will have no payoff until the cumulative proof-of-work of the revisio= nist chain surpasses that of the authentic chain. Until then, honest valida= tor nodes will simply sit idle. > >=20 > > Roughly in what you're describing yes. If you're a miner, I think > > you can play even more sneaky chain games on what you're mentioning > > about ressources. Let's say you're gaining "coins" on the "authentic" > > chain, and after the 100 blocks maturity rule, you immediately short > > them on the market to reinvest your proceedings in the energy cost of > > the "revisionist" chain (or do a mining halt, as not mining might give > > an advantage to the "revisionist" chain). > >=20 > > You're a miner, if the "authentic" chain wins, that's fine you're > > already re-sell the matured coin. If the "revisionist" chain wins, > > you got new fresh coinbase on the "revisionist" chain i.e a double-spen= d, > > plus any CQRC "bounty" coming from the exploited coins. > >=20 > > I think there is some "mining silent reorg" advantage here. > >=20 > > > Due to the vast incentive towards colluding with the CRQC, maybe this= would be feasible for some large miners? > > > > > > This would essentially be a massive double-spend attack as well, sinc= e miners who successfully roll back the blockchain in this way would be reo= rging their own mining earnings out of existence, some of which they presum= ably sold (on the authentic chain) to pay for electricity. This might make = the exchanges they sold the coins to extremely unhappy: The miners are effe= ctively retconning their own deposits. > >=20 > > See my point above, they're only limited by the 100 block maturity rule= s. > > Yes, miners would start to be unable to settle "fresh" coins, but also = "old" > > coins (both EC and PQ), as they are at risk of being roll back (at leas= t for > > the ones who are weeks recent). > >=20 > > > For this to happen, miners must be able to withstand significant cape= x (on mining a revisionist chain), while being blackballed by exchanges, an= d possibly also devaluing the very coins they were bribed with by the CRQC.= And even then, it's not clear how - assuming they were able to pull the at= tack off and remain solvent - the miners would actually use the ill-gotten = coins, and whether they'd have any value on the other side of a successful = deep reorg attack. > >=20 > > One of the point of the analysis, they might be able to fund their cape= x, with > > the exploited coins, if they can get liquidity for them on the exchange= s. On the > > other hand, as long as they're economically solvent, they can keep the = EC-exploited > > coins, until some far future, when the market price them at an interest= ing price > > enough, and slowly and covertly sell them out of their balance sheet by= then. > >=20 > > > Still, for shallow reorgs (a few blocks) this seems like a worthwhile= concern that seriously hampers any tripwire attempts. The best case is if = we can deploy the EC disabling fork before such tempting incentives enter t= he field of play. > >=20 > > A naive tripwire (there might be more secure design worthy to think mor= e about it), > > of course sounds it will be always at risk of being keep out of the cha= in by miners. > > Even the "we move fast and try to disable EC", assuming it's philosophi= cally acceptable > > by the community, and I'm among the one disagreeing to do so, as I poin= ted out in my > > previous post, the stack of "lost" EC coins might be worth 10 years of = bitcoins, that's > > a lot of reorg budget. > >=20 > > So in the hypothesis, you have a "sunset" activation, then 3 months aft= er a CRQC > > getting out of the box, there is a lot of incentives uncertainty. Even = worst, there > > is even a "Lorentz effect", where the public and well-known "sunset" ac= tivation, > > incentives "advanced adversaries" to reveal the CRQC they were keeping = sleeping > > in the backyard, as they know after the activation the cost structure i= s altered. > >=20 > > I'm thinking there are other solutions that we have not explored yet su= ch as > > PQ-blessed periodic checkpoints. E.g, let's say that every month, by co= nsensus > > rule, there is a checkpoint published that needs to be finalized e.g be= ing > > signed by more than % of PQ-safe pubkeys (e.g %1 of the overall coins). > >=20 > > As those pubkeys are PQ-safe, they cannot be forged by a CRQC, and a mi= ning > > coalition would not be able to go deeper than this checkpoint height, c= apping > > up the maximum of EC-unsafe coins that could be used as reorg budget. O= f course, > > that would ask for a number of stakeholders in the ecosystem to have on= line keys > > for the "checkpoint" finalization, though that % can be kept low [0] [1= ]. > >=20 > > It's just a "rough idea", as somehow it's re-introducing a form of chec= kpoint > > (which is meehhhh...but not worse than the sun setting ideas imho). I t= hink there > > are more imaginative ideas that we can come up on the design table to a= lleviate > > the risk of a CQRC acting in coordination with a mining coalition. > >=20 > > Notwithstanding the ultimate direction taken, the first primitive that > > would need it to give us more design flexibility would be the PQ-safe s= igning > > algorithm, be it Falcon, SkiSign or whatever. > >=20 > > Best, > > Antoine > > OTS hash: bdb435e6c81eb762bb6a12a03e2c23a83396a3481b8894af79732c2e2b569= 682 > >=20 > > [0] This also let the door open for a EC coins owner, of which the pubk= ey > > has not been revealed e.g P2TR to exfiltrate their old coins towards > > safer one. > > [1] The checkpoint would have to be carefully designed to avoid being t= ampered > > by a miner, e.g a PQ-signed checkpoint would gain a proof-of-work bonus= discount ? > > I'm already far in the territory of heretical consensus design ideas... > >=20 > > Le dim. 19 juil. 2026 =C3=A0 23:02, conduition a= =C3=A9crit : > >=20 > > > Solid analysis Antoine. However things play out here, activating a PQ= sunset fork of any kind while in the company of a CRQC is apparently quite= hard to do right without setting the incentives up such that they sabotage= the whole effort. > > >=20 > > >=20 > > > > If a CQRC entity is able to build a coalition with a 51% majority o= f miners, the "upgradedPQ safe" coins might be also at risk [4]. Indeed, su= ch malicious coalition > > > > could just roll-back the chain state back to the migration height o= f > > > > said coin, solve the DL for this coin and unroll back forward the c= hain. > > > >=20 > > > > I do not believe that the old chain history would be safe from deep > > > > reorgs attacks by CQRC capable entities, as soft-fork deployments a= re > > > > "height-based" burnt and not "hash-based" burnt (BIP90). Checkpoint= s > > > > have been removed from the latest bitcoind versions. Maybe user-act= ivated > > > > checkpoints or other similar mechanisms might be a more robust defe= nse > > > > against CQRC entities attacking the chain finality. > > >=20 > > >=20 > > >=20 > > > Very neat observation. For such a rollback to occur, the miners would= have to cooperatively elect to stop mining the more mature ("authentic") c= hain, where users have already migrated/forked, and instead start mining on= an old block (the "revisionist" chain). Any resources they spend on this m= ining will have no payoff until the cumulative proof-of-work of the revisio= nist chain surpasses that of the authentic chain. Until then, honest valida= tor nodes will simply sit idle. > > >=20 > > >=20 > > > Due to the vast incentive towards colluding with the CRQC, maybe this= would be feasible for some large miners? > > >=20 > > > This would essentially be a massive double-spend attack as well, sinc= e miners who successfully roll back the blockchain in this way would be reo= rging their own mining earnings out of existence, some of which they presum= ably sold (on the authentic chain) to pay for electricity. This might make = the exchanges they sold the coins to extremely unhappy: The miners are effe= ctively retconning their own deposits. > > >=20 > > > For this to happen, miners must be able to withstand significant cape= x (on mining a revisionist chain), while being blackballed by exchanges, an= d possibly also devaluing the very coins they were bribed with by the CRQC.= And even then, it's not clear how - assuming they were able to pull the at= tack off and remain solvent - the miners would actually use the ill-gotten = coins, and whether they'd have any value on the other side of a successful = deep reorg attack. > > >=20 > > > Still, for shallow reorgs (a few blocks) this seems like a worthwhile= concern that seriously hampers any tripwire attempts. The best case is if = we can deploy the EC disabling fork before such tempting incentives enter t= he field of play. > > >=20 > > > regards, > > > conduition > > > On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard wrote: > > >=20 > > > > Hi list, > > > >=20 > > > > In this post, I'm extending on the game-theory problems > > > > underscored for my answer to [ ] to other post-quantum > > > > sunsetting scenarios previously mentioned on this list. > > > >=20 > > > > Firstly, let's remember the "tripwire" idea [0]. With the > > > > "tripwire", if I understand it correctly we introduce a > > > > consensus level proof of quantum computers e.g with a NUMS > > > > puzzle. > > > >=20 > > > > This NUMS is committed in a honeypot UTXO let's say with > > > > some non-null bitcoin reward to unlock it. When the NUMS > > > > point is solved by a QC entity, it automatically triggers > > > > a "freeze" of all the "legacy" coins starting at some block > > > > height-defined window in the future. > > > >=20 > > > > While it appears feasible engineering-wise, the problem > > > > is more on the game-theory plane of analysis. As it was > > > > previously noted by another commentator than me [1], why > > > > an economically-rational CRQC entity would go to trigger > > > > such an evident "honeypot" UTXO depriving it from further > > > > (covert) extractions of the legacy coins to a safe wallet > > > > owned by this entity. > > > >=20 > > > > A more sophisticated scenario, that I was laying out more > > > > recently, a 51% majority coalition of miners could coordinate > > > > with a CRQC entity to censor the transaction inclusion of any > > > > PQ proof, even an inclusion attempt of a PQ proof generated by > > > > an honest PQ entity [2]. > > > >=20 > > > > Exposing again the economic analysis, a year of mining income > > > > is evaluated at around $20B. The number of legacy P2Pk coins > > > > is evaluated to be around 1.7 M of coins or as of today $107B. > > > > If we go to account the numbers of "coin loss", the estimated > > > > number can be more around 3-4 M, so let's say $215B worth of > > > > target coins (a coin lost to you is not a coin lost to a CRQC > > > > entity...). > > > >=20 > > > > That's something like ~10 years of potential income, that an > > > > economically rational miner might not refuse if a miner has > > > > a credible odd of capturing a share of this magic income to > > > > the prorata of their hashrate capabilities [3]. > > > >=20 > > > > If we assume a PQ coin extraction game with 2 CQRC entities > > > > availing roughly the same capabilities, they might compete for > > > > the majority hashrate of the miners, those miners solely driven > > > > by economic incentives. The focal point of equilibrium between > > > > the two strategies is likely going to be the marginal energy cost > > > > to run a CQRC, assuming that in a fee race a CQRC entity can > > > > offer to the majority of miners to burn more of a coin value > > > > as reorg fee. > > > >=20 > > > > Secondly, for the second approach of sunsetting, the one very rough= ly > > > > described in BIP361 and based on pure "flag-day" activation, the > > > > security analysis can extend to this approach too. Even assuming > > > > a week-long period for a BIP9-like activation mechanism, a coalitio= n > > > > of miners might stil go to reorg in depth the chain before the > > > > activation of said soft-fork. > > > >=20 > > > > Such an approach is only theoretically increasing the coordination = cost > > > > (and one would observe the asymmetry of information is selecting a = time > > > > horizon period, as a CRQC might appear at any time during this peri= od). > > > >=20 > > > > One can observe that the 2 sunsetting approach, be it "tripwire" or > > > > "flag-day" approaches are introducing a "choke point" to the chain = finality, > > > > as in the lack of it a CQRC entity might covertly exfiltrate "legac= y" coins, > > > > with no knowledge of the miners, or even without coordination with = them. > > > >=20 > > > > After the "choke point", a CQRC entity might alter its strategy of = going > > > > overt and start to offer fee bounties to reorg the chain as it's ad= vantage > > > > to the majority of miners (to not loss an exploitation advantage to= another > > > > CQRC entity). > > > >=20 > > > > Finally, in this analysis we're only underscoring the risk of "lega= cy" > > > > coins, i.e coins that would have not upgraded to a PQ safe format, = after > > > > some time horizon. However, in the Bitcoin blockchain world, time i= s > > > > relative, or rather only thermodynamically convergent. If a CQRC en= tity > > > > is able to build a coalition with a 51% majority of miners, the "up= graded > > > > PQ safe" coins might be also at risk [4]. Indeed, such malicious co= alition > > > > could just roll-back the chain state back to the migration height o= f > > > > said coin, solve the DL for this coin and unroll back forward the c= hain. > > > >=20 > > > > I do not believe that the old chain history would be safe from deep > > > > reorgs attacks by CQRC capable entities, as soft-fork deployments a= re > > > > "height-based" burnt and not "hash-based" burnt (BIP90). Checkpoint= s > > > > have been removed from the latest bitcoind versions. Maybe user-act= ivated > > > > checkpoints or other similar mechanisms might be a more robust defe= nse > > > > against CQRC entities attacking the chain finality. > > > >=20 > > > > Current bitcoin mining process and the chain finality is assumed to= be > > > > reasonably secure under the Gambler's Ruin Problem and some other a= ssumptions > > > > (e.g a reliable network to relay the blocks). It might be considere= d that > > > > the introduction of CQRC computers might not be only a risk for the= "legacy" > > > > coins, though far more concerning for the chain finality itself. > > > >=20 > > > > Independently of being philosophically "pro" or "contra" in freezin= g > > > > legacy coins, I do believe the irruption of one or more CQRC entiti= es > > > > and the potential of disruptions on the Bitcoin network stability i= s > > > > a subject deserving a bit more research and more work from the deve= lopment > > > > community [5]. > > > >=20 > > > > Cheers, > > > > Antoine > > > > OTS hash: 496d9c26c6f3d805dae88f487600f46990572fc84c4ca907fb85b5441= c235cf3 > > > >=20 > > > > [0] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NI= AwAJ > > > > [1] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNg= AwAJ > > > > [2] One might consider the following realistic scenario, it > > > > might that even if a CRQC become relevant, at first it will > > > > be only operated by big companies let's say in the US or China > > > > and they will prefer to keep the existence of such capabilities > > > > hidden for a while for non-economical reasons. > > > > Suddenly, one of the actor starts to use those post-quantum > > > > capabilities and the social equilibrium does not hold anymore > > > > with impactful second-order implications for the Bitcoin ecosystem. > > > > [3] On the low time incentive miner hypothesis, one can empirically > > > > observe (as of June '26) than it has limits given how fast are read= y > > > > mainstream mining companies to reallocate their data centers and > > > > sources of energies to more generic high-performance computations > > > > rather than SHA256 hashing. > > > > [4] For the degree of scientificity of "game-theory" in itself, I c= an > > > > only forward the reader to the "Formulation of the Economic Problem= " > > > > chapter in the "Theory of Games and Economic Behavior" book from Vo= n > > > > Neumann & Morgenstern, 1944 > > > > [5] As quantum raises a number of skeptical eyebrows in the communi= ty, > > > > the first elaboration of quantum physics have been as old as the 30= 's, > > > > and so far no one has got a Nobel Prize, or any other major scienti= fic > > > > prize to prove the physical impossibility of a large-scale quantum = computer > > > >=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, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/CALZpt%2BFOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171%3D25C3ryJPQ%40mail.gmai= l.com. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/CALZpt%2BEjD5h9387diQvwtUY9nV-GFgN-Ukp9tY%3DuqBofb-w7Tg%40mail.gmail.co= m. --=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/= JyKb0LwJfIGSwrbg-Gj5AUDYFHT1vtcYsug27Plxe6h0gk4zAjTK393yF6mf_a2jLSiGuJRrTnN= B7tg3SbCrpIPXSa71pcE9u_RaUuApr4U%3D%40proton.me. -----------------------ca1e17267eceb80492f5e7a03f226378 Content-Type: multipart/related;boundary=---------------------e11cffa3f71d1beb791ae432e2c92865 -----------------------e11cffa3f71d1beb791ae432e2c92865 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It will run for 9-12 days according to my calcu= lations.

Can you show us these calculations?

The CCP publicly stated that they must destroy= Bitcoin in order to survive as a country, on the evening news.
<= /div>

Do you have a source on this claim?

Drain the side chain of thei= r coins ...
The next target would likely not = be Bitcoin or any side chains of Bitcoin, but Ethereum.
<= span>
I'm not sure if that'd be a wise idea, since sidechains an= d altcoins like Ethereum are more likely to hard fork to undo an attack:&nb= sp;https://ethresear.ch/t/how-to-hard-fork-to-save-most-us= ers-funds-in-a-quantum-emergency/18901

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Quantu= m attackers would want plausible deniability, but also finality (no backsie= s). Otherwise the attack is pointless.

regards,=
conduition
On Monday, July 27th, 2026 at 9:50 AM, Ian Quantum <ianquantum20= 27@gmail.com> wrote:
The first cryptographically relevant quantum c= omputers are likely to be slow, especially if they are neutral atom, trappe= d ion or some of the NV Diamond variants depending on the speed of the comp= utation and stability of the qubits. Realizing the quantum attacks are goin= g to be a surprise, my game theory approach is different. Quantum Physicist= s will not suddenly decide to become hackers and start attacking banking ne= tworks while living in the USA, EU or China. Chinese strategy as I see it w= ill be covered separately, below.

Quantum Physics will = not offer new near term gains in mining, as Pierre-Luc explained. Attacks a= gainst Bitcoin are broken into short and long windows of opportunity. Since= the first quantum computer to break Bitcoin will likely be a long window, = slow attack neutral atom I will give some more general information. It will= run for 9-12 days according to my calculations. With tricks, they currentl= y have a run window that permits an attack. With qubit reuse the attack is = a function of time, not the size of the machine assuming it has more than 2= 000 qubits of operational space. The attacks can be squeezed in under 900 q= ubits, but the runtime grows to match. The optimal strategy would be full w= idth for a single key break, then switching to running multiple keys concur= rently on one machine as soon as funds are available for more qubits. Attac= k round 2 would likely break 4-100 keys at a time, operating against a sing= le equation like secp256k1, secp256r1, ed25519, x25519, etc. Switching equa= tions is just a change to the python in linux. Adding more physical qubits = allows attacking more keys in parallel for the same steps and time (but a l= ittle extra bookkeeping). Attacking RSA2048 keys will be 1-3 years after th= e first secp256k1 break unless it is PSI Quantum in late 2027 and they hit = their milestone target.

The long window attack wil= l eventually be surpassed by the short window attack, coming from photonics= or superconductors. There are some obscure (not mainstream) fast operation= s possible on trapped ion and NV Diamond quantum computers. When the short = window CRQC comes into play, the runtime will be in minutes but still paral= lel execution for a small qubit cost and no time cost. 10 private keys in 1= 0-70 minutes would be the target. This is scheduled for 2028 by PSI Quantum= , but I hope that they are simply "under retainer" by the NSA and not able = to publicly demonstrate their capabilities. PSI Q has already demonstrated = qubit reuse, they have already mass produced hundreds of thousands of qubit= s in horizontally scaling systems. If they start off cracking a single priv= ate key, they can switch to breaking 2, then 4 just by continuing mass prod= uction and installation.

A strategic CRQC operator would s= elect their first target as one with low reputation and questionable securi= ty. Drain the side chain of their coins and don't touch Satoshi's Shield or= any tripwire transactions. To further increase deniability, the stalwart q= uantum physicists may decide to launder the gains in the same way that peop= le from North Korea or Iran does. A few hundred million dollars is a likely= early target.
The next target would likely not be Bitcoin or any= side chains of Bitcoin, but Ethereum. The public keys are 100% exposed in = DeFi. Physicists have urged upgrading prior to 2024 and the upgrades will l= ikely arrive too little, too late. Pocket another $100 billion, ideally wit= h continued plausible deniability.

At this point t= he quantum attacker could spend 5-15% of the gains and simply purchase the = ASIC manufacturer outright. This would allow them to again operate with pla= usible deniability. Get hired by the company after the purchase. Work on so= mething fun. Now that the quantum achievement has been completed. The purchase of 1-2 ASIC manufacturers = would allow them to simply own the hash rate, with any generational improve= ment. They could choose to sell machines after they have been eclipsed by n= ewer hash rates.

China has a different goal. The CCP publicly stated that they must = destroy Bitcoin in order to survive as a country, on the evening news. Curr= ently 1/3 of China's GDP is leaving the country each year and Bitcoin is th= e most efficient method to do so. Tron and Tether are face value, but Bitco= in is easy to send money overseas. Use Yuan to buy mining equipment, sell B= itcoin for EU or USD. This is done at a profit, while art sales and Tether = are done at a significant or small loss respectively. China's Middle Class = faces export controls on sending money overseas, international banking is e= xtremely limited and total control is the CCP bare minimum standard.=

Against this backdrop, Chin= a has thrown millions of dollars at dozens of companies to create a huge nu= mber of quantum computers racing to be the first to break Bitcoin. Bitcoin = is the stated goal. Destroying Bitcoin as a store of value is the governmen= t strategy. Rapid sales of any known public keys will commence ASAP, and CR= CQ will be mass produced. So their likely runtime would be targeting Satosh= i's Shield, getting 50 BTC per break. If they can catch exchange funds "pro= of of reserves" then they will topple most of the economic value. 6.9 milli= on BTC to target. They might trigger a tripwire, the goal is to dump the ma= rket and the exchanges.

I suspect the CCP= will target Ethereum in order to cause critical damage to the US economy, = especially as stablecoins and CBDC have jumped in. Bitcoin sales would allo= w them to pay down a small portion of their debt. Ethereum sales would allo= w China to supersede the USA as the dominant economy. As I have said publi= cly, the strategy is much different depending on the threat actor who gets = the first and who gets the fast CRQC.

The game th= eory for each threat actor is different:
US Individual: plausible deniab= ility, stealth, money laundering.
US Company: salvage laws, plausible de= niability, can not have govt funding and target US companies like Blackrock= , (micro)Strategy, Coinbase, etc.
EU Company: ideologically driv= en, might break a few accounts for retirement but not touch most public key= s.
China: must crash all crypto to survive. If they can destroy B= itcoin, mining and pay down debt, great. If they can use this to 'break the= hegemonic order' they will definitely do so.

I wo= uld be happy to discuss here or on Signal.

On M= on, Jul 27, 2026 at 1:53=E2=80=AFAM Antoine Riard <antoine.riard@gm= ail.com> wrote:
Hello Conduition,

> Solid analysis Antoin= e. However things play out here, activating a PQ sunset fork of any kind wh= ile in the company of a CRQC is apparently quite hard to do right without s= etting the incentives up such that they sabotage the whole effort.

= That's the insight that my post aims to underscore, effectively
that act= ivating a PQ sunset fork of any kind might be very hard
in the presence = of one or more company with a CQRC, at the very
least there is a lot of = uncertainty due to the incentives.

You're correct that the problem a= ppears as soon as you have a
company with one CRQC, where it can just go= really deep in the
history of the chain. As soon as you start to have t= wo CRQC,
there is an advantage to burn more EC coins in fees, to reorg t= o
your advantage, so we're back with some notion of chain finality.
<= br>See more comments on rough ideas to alleviate the issue.

> Ve= ry neat observation. For such a rollback to occur, the miners would have to= cooperatively elect to stop mining the more mature ("authentic") chain, wh= ere users have already migrated/forked, and instead start mining on an old = block (the "revisionist" chain). Any resources they spend on this mining wi= ll have no payoff until the cumulative proof-of-work of the revisionist cha= in surpasses that of the authentic chain. Until then, honest validator node= s will simply sit idle.

Roughly in what you're describing yes. If yo= u're a miner, I think
you can play even more sneaky chain games on what = you're mentioning
about ressources. Let's say you're gaining "coins" on = the "authentic"
chain, and after the 100 blocks maturity rule, you immed= iately short
them on the market to reinvest your proceedings in the ener= gy cost of
the "revisionist" chain (or do a mining halt, as not mining m= ight give
an advantage to the "revisionist" chain).

You're a mine= r, if the "authentic" chain wins, that's fine you're
already re-sell the= matured coin. If the "revisionist" chain wins,
you got new fresh coinba= se on the "revisionist" chain i.e a double-spend,
plus any CQRC "bounty"= coming from the exploited coins.

I think there is some "mining sile= nt reorg" advantage here.

> Due to the vast incentive towards col= luding with the CRQC, maybe this would be feasible for some large miners?>
> This would essentially be a massive double-spend attack as = well, since miners who successfully roll back the blockchain in this way wo= uld be reorging their own mining earnings out of existence, some of which t= hey presumably sold (on the authentic chain) to pay for electricity. This m= ight make the exchanges they sold the coins to extremely unhappy: The miner= s are effectively retconning their own deposits.

See my point above,= they're only limited by the 100 block maturity rules.
Yes, miners would= start to be unable to settle "fresh" coins, but also "old"
coins (both= EC and PQ), as they are at risk of being roll back (at least for
the on= es who are weeks recent).

> For this to happen, miners must be ab= le to withstand significant capex (on mining a revisionist chain), while be= ing blackballed by exchanges, and possibly also devaluing the very coins th= ey were bribed with by the CRQC. And even then, it's not clear how - assumi= ng they were able to pull the attack off and remain solvent - the miners wo= uld actually use the ill-gotten coins, and whether they'd have any value on= the other side of a successful deep reorg attack.

One of the point = of the analysis, they might be able to fund their capex, with
the exploi= ted coins, if they can get liquidity for them on the exchanges. On the
o= ther hand, as long as they're economically solvent, they can keep the EC-ex= ploited
coins, until some far future, when the market price them at an i= nteresting price
enough, and slowly and covertly sell them out of their = balance sheet by then.

> Still, for shallow reorgs (a few blocks)= this seems like a worthwhile concern that seriously hampers any tripwire a= ttempts. The best case is if we can deploy the EC disabling fork before suc= h tempting incentives enter the field of play.

A naive tripwire (the= re might be more secure design worthy to think more about it),
of course= sounds it will be always at risk of being keep out of the chain by miners.=
Even the "we move fast and try to disable EC", assuming it's philosophi= cally acceptable
by the community, and I'm among the one disagreeing to = do so, as I pointed out in my
previous post, the stack of "lost" EC coin= s might be worth 10 years of bitcoins, that's
a lot of reorg budget.
=
So in the hypothesis, you have a "sunset" activation, then 3 months aft= er a CRQC
getting out of the box, there is a lot of incentives uncertain= ty. Even worst, there
is even a "Lorentz effect", where the public and w= ell-known "sunset" activation,
incentives "advanced adversaries" to reve= al the CRQC they were keeping sleeping
in the backyard, as they know aft= er the activation the cost structure is altered.

I'm thinking there = are other solutions that we have not explored yet such as
PQ-blessed per= iodic checkpoints. E.g, let's say that every month, by consensus
rule, t= here is a checkpoint published that needs to be finalized e.g being
sign= ed by more than % of PQ-safe pubkeys (e.g %1 of the overall coins).

= As those pubkeys are PQ-safe, they cannot be forged by a CRQC, and a mining=
coalition would not be able to go deeper than this checkpoint height, c= apping
up the maximum of EC-unsafe coins that could be used as reorg bud= get. Of course,
that would ask for a number of stakeholders in the ecosy= stem to have online keys
for the "checkpoint" finalization, though that = % can be kept low [0] [1].

It's just a "rough idea", as somehow it's= re-introducing a form of checkpoint
(which is meehhhh...but not worse t= han the sun setting ideas imho). I think there
are more imaginative idea= s that we can come up on the design table to alleviate
the risk of a CQR= C acting in coordination with a mining coalition.

Notwithstanding th= e ultimate direction taken, the first primitive that
would need it to gi= ve us more design flexibility would be the PQ-safe signing
algorithm, be= it Falcon, SkiSign or whatever.

Best,
Antoine
OTS hash: bdb43= 5e6c81eb762bb6a12a03e2c23a83396a3481b8894af79732c2e2b569682

[0] This= also let the door open for a EC coins owner, of which the pubkey
has no= t been revealed e.g P2TR to exfiltrate their old coins towards
safer one= .
[1] The checkpoint would have to be carefully designed to avoid being = tampered
by a miner, e.g a PQ-signed checkpoint would gain a proof-of-wo= rk bonus discount ?
I'm already far in the territory of heretical consen= sus design ideas...

Le dim. 19 juil. 2026 =C3=A0 23:02, conduition <conduition@proton.me> a =C3=A9crit :
Solid analysis Antoine. However things play out = here, activating a PQ sunset fork of any kind while in the company of a = CRQC is apparently quite hard to do right without setting the incentive= s up such that they sabotage the whole effort.

If a CQRC entity is able to build a coalition w= ith a 51% majority of miners, the "upgraded
PQ safe" coins might = be also at risk [4]. Indeed, such malicious coalition
could just roll-back the chain state back to the migration height of
said coin, solve the DL for this coin and unroll back fo= rward the chain.

I do not believe tha= t the old chain history would be safe from deep
reor= gs attacks by CQRC capable entities, as soft-fork deployments are
"height-based" burnt and not "hash-based" burnt (BIP90). Chec= kpoints
have been removed from the latest bitcoind v= ersions. Maybe user-activated
checkpoints or other s= imilar mechanisms might be a more robust defense
against = CQRC entities attacking the chain finality.

<= /div>
Very = neat observation. For such a rollback to occur, the miners would have to co= operatively elect to stop mining the more mature ("authentic") chain, where= users have already migrated/forked, and instead start mining on an old blo= ck (the "revisionist" chain). Any resources they spend on this mining will = have no payoff until the cumulative proof-of-work of the revisionist chain = surpasses that of the authentic chain. Until then, honest validator nodes w= ill simply sit idle.

Due to the vast incentive towards colluding with= the CRQC, maybe this would be feasible for some large miners?

This would essentially be a m= assive double-spend attack as well, since miners who successfully roll back= the blockchain in this way would be reorging their own mining earnings out= of existence, some of which they presumably sold (on the authentic chain) = to pay for electricity. This might make the exchanges they sold the coins t= o extremely unhappy: The miners are effectively retconning their own deposi= ts.

For this to h= appen, miners must be able to withstand significant capex (on mining a revi= sionist chain), while being blackballed by exchanges, and possibly also dev= aluing the very coins they were bribed with by the CRQC. And even then, it'= s not clear how - assuming they were able to pull the attack off and remain= solvent - the miners would actually use the ill-gotten coins, and w= hether they'd have any value on the other side of a successful deep reorg a= ttack.

=
Still, for= shallow reorgs (a few blocks) this seems like a worthwhile concern that se= riously hampers any tripwire attempts. The best case is if we can deploy th= e EC disabling fork before such tempting incentives enter the field = of play.
regards,=
conduition=
On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard <antoine.riard@gmail.com> wrote:

Hi list,

In this post, I'm extending on the game-theory p= roblems
underscored for my answer to [ ] to other post-quantum
sunset= ting scenarios previously mentioned on this list.

Firstly, let's rem= ember the "tripwire" idea [0]. With the
"tripwire", if I understand it c= orrectly we introduce a
consensus level proof of quantum computers e.g w= ith a NUMS
puzzle.

This NUMS is committed in a honeypot UTXO let'= s say with
some non-null bitcoin reward to unlock it. When the NUMS
p= oint is solved by a QC entity, it automatically triggers
a "freeze" of a= ll the "legacy" coins starting at some block
height-defined window in th= e future.

While it appears feasible engineering-wise, the problemis more on the game-theory plane of analysis. As it was
previously note= d by another commentator than me [1], why
an economically-rational CRQC = entity would go to trigger
such an evident "honeypot" UTXO depriving it = from further
(covert) extractions of the legacy coins to a safe walletowned by this entity.

A more sophisticated scenario, that I was la= ying out more
recently, a 51% majority coalition of miners could coordin= ate
with a CRQC entity to censor the transaction inclusion of any
PQ = proof, even an inclusion attempt of a PQ proof generated by
an honest PQ= entity [2].

Exposing again the economic analysis, a year of mining = income
is evaluated at around $20B. The number of legacy P2Pk coins
i= s evaluated to be around 1.7 M of coins or as of today $107B.
If we go t= o account the numbers of "coin loss", the estimated
number can be more a= round 3-4 M, so let's say $215B worth of
target coins (a coin lost to yo= u is not a coin lost to a CRQC
entity...).

That's something like = ~10 years of potential income, that an
economically rational miner might= not refuse if a miner has
a credible odd of capturing a share of this m= agic income to
the prorata of their hashrate capabilities [3].

If= we assume a PQ coin extraction game with 2 CQRC entities
availing rough= ly the same capabilities, they might compete for
the majority hashrate o= f the miners, those miners solely driven
by economic incentives. The foc= al point of equilibrium between
the two strategies is likely going to be= the marginal energy cost
to run a CQRC, assuming that in a fee race a C= QRC entity can
offer to the majority of miners to burn more of a coin v= alue
as reorg fee.

Secondly, for the second approach of sunsettin= g, the one very roughly
described in BIP361 and based on pure "flag-day"= activation, the
security analysis can extend to this approach too. Even= assuming
a week-long period for a BIP9-like activation mechanism, a coa= lition
of miners might stil go to reorg in depth the chain before theactivation of said soft-fork.

Such an approach is only theoreticall= y increasing the coordination cost
(and one would observe the asymmetry = of information is selecting a time
horizon period, as a CRQC might appea= r at any time during this period).

One can observe that the 2 sunset= ting approach, be it "tripwire" or
"flag-day" approaches are introducing= a "choke point" to the chain finality,
as in the lack of it a CQRC enti= ty might covertly exfiltrate "legacy" coins,
with no knowledge of the mi= ners, or even without coordination with them.

After the "choke point= ", a CQRC entity might alter its strategy of going
overt and start to of= fer fee bounties to reorg the chain as it's advantage
to the majority of= miners (to not loss an exploitation advantage to another
CQRC entity).<= br>
Finally, in this analysis we're only underscoring the risk of "legac= y"
coins, i.e coins that would have not upgraded to a PQ safe format, af= ter
some time horizon. However, in the Bitcoin blockchain world, time is=
relative, or rather only thermodynamically convergent. If a CQRC entit= y
is able to build a coalition with a 51% majority of miners, the "upgra= ded
PQ safe" coins might be also at risk [4]. Indeed, such malicious coa= lition
could just roll-back the chain state back to the migration height= of
said coin, solve the DL for this coin and unroll back forward the ch= ain.

I do not believe that the old chain history would be safe from = deep
reorgs attacks by CQRC capable entities, as soft-fork deployments a= re
"height-based" burnt and not "hash-based" burnt (BIP90). Checkpoints<= br>have been removed from the latest bitcoind versions. Maybe user-activate= d
checkpoints or other similar mechanisms might be a more robust defense=
against CQRC entities attacking the chain finality.

Current bitc= oin mining process and the chain finality is assumed to be
reasonably se= cure under the Gambler's Ruin Problem and some other assumptions
(e.g a = reliable network to relay the blocks). It might be considered that
the i= ntroduction of CQRC computers might not be only a risk for the "legacy"
= coins, though far more concerning for the chain finality itself.

In= dependently of being philosophically "pro" or "contra" in freezing
legac= y coins, I do believe the irruption of one or more CQRC entities
and the= potential of disruptions on the Bitcoin network stability is
a subject = deserving a bit more research and more work from the development
communi= ty [5].

Cheers,
Antoine
OTS hash: 496d9c26c6f3d805dae88f48760= 0f46990572fc84c4ca907fb85b5441c235cf3

[0] https://g= roups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ
[1] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZN= gAwAJ
[2] One might consider the following realistic scenario, itmight that even if a CRQC become relevant, at first it will
be only ope= rated by big companies let's say in the US or China
and they will prefer= to keep the existence of such capabilities
hidden for a while for non-e= conomical reasons.
Suddenly, one of the actor starts to use those post-q= uantum
capabilities and the social equilibrium does not hold anymore
= with impactful second-order implications for the Bitcoin ecosystem.
[3] = On the low time incentive miner hypothesis, one can empirically
observe = (as of June '26) than it has limits given how fast are ready
mainstream = mining companies to reallocate their data centers and
sources of energi= es to more generic high-performance computations
rather than SHA256 hash= ing.
[4] For the degree of scientificity of "game-theory" in itself, I c= an
only forward the reader to the "Formulation of the Economic Problem"<= br>chapter in the "Theory of Games and Economic Behavior" book from Von
= Neumann & Morgenstern, 1944
[5] As quantum raises a number of skepti= cal eyebrows in the community,
the first elaboration of quantum physics = have been as old as the 30's,
and so far no one has got a Nobel Prize, o= r any other major scientific
prize to prove the physical impossibility o= f a large-scale quantum computer

--
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%2= BFOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171%3D25C3ryJPQ%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 e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt= %2BEjD5h9387diQvwtUY9nV-GFgN-Ukp9tY%3DuqBofb-w7Tg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/JyKb0L= wJfIGSwrbg-Gj5AUDYFHT1vtcYsug27Plxe6h0gk4zAjTK393yF6mf_a2jLSiGuJRrTnNB7tg3S= bCrpIPXSa71pcE9u_RaUuApr4U%3D%40proton.me.
-----------------------e11cffa3f71d1beb791ae432e2c92865-- -----------------------ca1e17267eceb80492f5e7a03f226378-- -----------------------5dce4db9eb87e705aec7a612ee4238fe Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------5dce4db9eb87e705aec7a612ee4238fe-- --------5390cf92119e9e206fe279d3d9ecf9fae64f038fcfe3c9377168f79313ed82d0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmp7NaAJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdREZpg1fifTDTHUGu3P2JXt0RFFGnqD4iXXnLY 6Vjt5RYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAC8ogD8DOUD3qxUJnx7vGB6 3XOU7k3j+YijP7nal8VnWqH12M0BAM7mUu8TVJG4RHYD1yqydJmLLO1JL+qT 9Rm+6G1sE3AJ =I0bx -----END PGP SIGNATURE----- --------5390cf92119e9e206fe279d3d9ecf9fae64f038fcfe3c9377168f79313ed82d0--