From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 19 Jul 2026 15:18:39 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wlZqI-0003VU-4L for bitcoindev@gnusha.org; Sun, 19 Jul 2026 15:18:39 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-6a17bd28f4bsf9340424eaf.1 for ; Sun, 19 Jul 2026 15:18:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1784499512; cv=pass; d=google.com; s=arc-20260327; b=LaVC5r8fmHJhhatSfXKC+OF8rm0VNfhGGi7pbz5YsLKSuZqMmFGLTeeiMBhSaOQm2u 2Nq0MWPPWKaRNT4qg34ao7fl/i1Iev0jEHO8nCCIonRKOk3OS38u+WQGzXakurlb/c7j VOJG1+ke7/LMNe5jc3AtZ4KNJKH98Hj0dar3qzPm79w/GDhxBHEERBC6zlpavlWigPTE vUJFevsBK6hjD8S17cvoNO3RxiRDg19J7JCNM+tibhWpqGB6MbqkPTiPSqVXC+MPDv0S vDT+Gayr4KiClEg51DRbnz4o03eRgGLGYJbxCaJ12hz200XJ+Wu9IKB3ImuRmOBxnxoo yk/w== 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=2/ZYipXadkyZYBKXMLSdUUesX9aiNkcU0QLEG8rKIV0=; fh=M56mDVsWsxZ1ZPHGVeMgSkGLtR3nmVZuLAVBFjdJ1f4=; b=i0Cz5IGT8zuKKi6BCO8u+DqwzwnIBwbWGahBO0D6IZknjGw+assrAZlHxz4tVReVdQ 9EM1lWQkHMDSLxm2Wm2UJkE5afM7lyKh4lSRABBT2J2QQS2rV7V0+p5T8x/r9ILn4yjo HA+mkatDs+rHq9Ot2Bjdimhgl4pOl108Hpe/ieFL5yO7n6dub/UUgC0hgdCjyDy0AzT7 +69n8NIgLbjYD1UuyrGb5v9GE9avf7F77tSGmcbd4QpyyAgu/fN4hQONJuQ6LGjZyn31 z4IZx2KUgfdbiXR6bV7mmjmQ3jbPEt76fk92ySubq8CHpYsG4+A/LjOMXI/aTL9+sdoq G7fg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=iYk0ysDz; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.28 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=1784499512; x=1785104312; 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=2/ZYipXadkyZYBKXMLSdUUesX9aiNkcU0QLEG8rKIV0=; b=X9/1luKPXB673C3KAmIf/2vPPXs95PuEgk+kxrhWM1XM3p6c53K9Gbq4aDEzfqcJZ6 9lunQEq7Gzx7fUUpnJyzjm2Uz0aQVymx8haCvLPuvNb6XzjOgJKT20WMMs0XgzXE4E9O MCcvkZ6lvXzM2SIp/f8KoT9CIYErCNIyU8ABvAypEnBQuVusW/f/fn4NCBhSebDNhAhm Q8mXZbxNnFuzdg9/tQ1iv1frnRKVK5uDiho84GbL215/cY28qaRzJYYZL0cV7EGK1bue p+HMXYK/dTuUFYxLETbB9ofZkn2K0jyAzP+cWWu8OrxM2unvs2gxrWMCIE2WF0LVzY0d e2kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784499512; x=1785104312; 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=2/ZYipXadkyZYBKXMLSdUUesX9aiNkcU0QLEG8rKIV0=; b=BZG37oc+T1mLDy6SLRTnynSSiORjT7ZnTfNFJ31cAuzHaxkOXuygJUum5GuSSlgVUu MxBf1JSlyGU/Xjg8nddrjBbycaUbfO4W+w9opde6lY0yKH8ymWzRo7pMRapgAsY3TAM8 byJvPpK2cLqDkAep3iVATbTcu9zGTDYWsDGqWAZjs5ZBva6oJgK+mHp0yEyaZXQLUC1a 4VduoMvbF5n/29KaoKuSAjpNc2xUth40IhLzRDKaPPQQ3i1A+uCad9HM87l6UELreoyn S3nZ4DhRVxVG76wBFiaelW38ldIzWU1PL9hHoTHVX7Q3PTkwI2UHiw5DvbXjW3BXbENW Mt8g== X-Forwarded-Encrypted: i=2; AHgh+RpFvl3V/0mqP8PIxiqjlKQ2mnoOC+GkUMnG8qW0sGhkqImgPz+Uau7ho/VcrJ7XqnB1nMIXMOhK7EUO@gnusha.org X-Gm-Message-State: AOJu0Yw0aasev1LTRBy5+eNmVv/B2mqvv7AjQ6LFxQeomKB0Vr7Ub7vt ajmquZU2ORaaZ81marBokqdzgPg45s/0sRBC8Q8ZgQ83tji3fuOrIaQP X-Received: by 2002:a05:6820:80cc:b0:6a3:9756:b604 with SMTP id 006d021491bc7-6a53669198amr6076890eaf.11.1784499511759; Sun, 19 Jul 2026 15:18:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPTb6fFvcE9VtdnDgWXmkdbwlAIi/AS3tHNeOtLHN+9urg==" Received: by 2002:a05:6820:81d7:b0:69e:361d:30db with SMTP id 006d021491bc7-6a3eefb7042ls2538029eaf.2.-pod-prod-08-us; Sun, 19 Jul 2026 15:18:27 -0700 (PDT) X-Received: by 2002:a05:6808:2381:b0:4a4:934:4232 with SMTP id 5614622812f47-4a4d05ab10fmr6293340b6e.39.1784499507345; Sun, 19 Jul 2026 15:18:27 -0700 (PDT) Received: by 2002:a05:620a:b51:b0:8f9:4d19:af67 with SMTP id af79cd13be357-92ee597637dms85a; Sun, 19 Jul 2026 15:02:21 -0700 (PDT) X-Received: by 2002:a05:620a:4713:b0:92e:4859:49e3 with SMTP id af79cd13be357-930b416d8d2mr1153772585a.49.1784498540964; Sun, 19 Jul 2026 15:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784498540; cv=none; d=google.com; s=arc-20260327; b=hQokhxni4QTHYQTDxgpLqflXyUw1ovCcjxVO12qyaFANrnOeU1Ovo9Adg38rRFE2zo PtK4usc36bCfm3MCe1sn2OowwVcDhQnO/5T/mD73CaGMdRLkYlBm5tjV5SNpfYLxY+7y Bfw9xtRNqoBxlmiMS7VZU0bIY9UJebpbdXuN+74sJ7Ppkm9/QW225glAsT3EcwsbP9dF gy6oHAEYvx4IMisG0xCODduar0JNLm3IVpG13SEX/wBe88H4wD4A95kdCnJWhd2RyYwr MQiEzipw1U7zmPMyZfOV9eMejR8c2ykGgeRYrWZp/zI17etfiho0i0xw6kZRYFPXonbM +7BQ== 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=E8342/4LdpB/s7MKUHQh8Otonaj3l+Vn6cB6Y9p1w5g=; fh=LDhKQOar2Hgy0ZybTq9cTMKeH1hWccLzq8hHpwVcKmQ=; b=mtbBm225TGUMmolPQdpdaUimhnbnTLJj9zdtNazS8g15wxbC7idzoVCo4GbkVAHRbb jqWKcLSHxl0ql5cYHWqF9EOTYm91n+xE25IIjC7cOPSO2CBwPSCjW4cEoY0l3Ufxs4Tf 3xl04z3Thf056N+OpWMVk+w9oddGX7qLX5DCr2IppPnMksuvSdZbPspgnHHzEP9fcQJn FkTItZaltsimP9ZqqHLGGNJ4ytUoobQOnp+sAd/vvpAwxVjqOkBRHAaQRUul4wLEKk4B lNDy7VGonCAwbYigFQMH5v86mDd5PRyner4GrkG8Ohe0TqEnI349jy1YAmWJnSYll/dG 7gTg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=iYk0ysDz; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24428.protonmail.ch (mail-24428.protonmail.ch. [109.224.244.28]) by gmr-mx.google.com with ESMTPS id af79cd13be357-930b54b1883si27211785a.7.2026.07.19.15.02.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 15:02:20 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.28 as permitted sender) client-ip=109.224.244.28; Date: Sun, 19 Jul 2026 22:02:15 +0000 To: Antoine Riard From: "'conduition' via Bitcoin Development Mailing List" Cc: 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: 945294e5bde1155fc9abaac4a4666288b8de1c85 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------c02069e00d15c2c6e1c9c23e497fda4ff6798cf893961d33690ee4d309fa0b7e"; 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=protonmail header.b=iYk0ysDz; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.28 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) --------c02069e00d15c2c6e1c9c23e497fda4ff6798cf893961d33690ee4d309fa0b7e Content-Type: multipart/mixed;boundary=---------------------1a1e2658ad454036bf65a1fa626fa7c8 -----------------------1a1e2658ad454036bf65a1fa626fa7c8 Content-Type: multipart/alternative;boundary=---------------------1d210053e744d95b707f7c314ed1907e -----------------------1d210053e744d95b707f7c314ed1907e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Solid analysis Antoine. However things play out here, activating a PQ sunse= t fork of any kind while in the company of a CRQC=C2=A0is apparently quite = hard to do right without setting the incentives up such that they sabotage = the whole effort.=C2=A0 > If a CQRC entity=C2=A0is able to build a coalition with a 51% majority of= miners, the "upgradedPQ safe" coins might be also at risk [4]. Indeed, suc= h 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 forward the chain. >=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 are > "height-based" burnt and not "hash-based" burnt (BIP90). Checkpoints > have been removed from the latest bitcoind versions. Maybe user-activated > checkpoints or other similar mechanisms might be a more robust defense > against CQRC entities attacking the chain finality. Very neat observation. For such a rollback to occur, the miners would have = to cooperatively elect to stop mining the more mature ("authentic") chain, = where users have already migrated/forked, and instead start mining on an ol= d block (the "revisionist" chain). Any resources they spend on this mining = will have no payoff until the cumulative proof-of-work of the revisionist c= hain surpasses that of the authentic chain. Until then, honest validator no= des will 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 massive double-spend attack as well, since mine= rs who successfully roll back the blockchain in this way would be reorging = their own mining earnings out of existence, some of which they presumably s= old (on the authentic chain) to pay for electricity. This might make the ex= changes they sold the coins to extremely unhappy: The miners are effectivel= y retconning their own deposits. For this to happen, miners must be able to withstand significant capex (on = mining a revisionist chain), while being blackballed by exchanges, and poss= ibly also devaluing the very coins they were bribed with by the CRQC. And e= ven then, it's not clear how - assuming they were able to pull the attack o= ff and remain solvent - the miners would actually use=C2=A0the ill-gotten c= oins, and whether they'd have any value on the other side of a successful d= eep reorg attack. Still, for shallow reorgs (a few blocks) this seems like a worthwhile conce= rn that seriously hampers any tripwire attempts. The best case is if we can= deploy the EC disabling fork before=C2=A0such tempting incentives enter th= e field of play. regards, conduition On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard wrote: > 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 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 coalition > 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 period). >=20 > One can observe that the 2 sunsetting approach, be it "tripwire" or > "flag-day" approaches are introducing a "choke point" to the chain finali= ty, > as in the lack of it a CQRC entity might covertly exfiltrate "legacy" coi= ns, > 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 advantag= e > to the majority of miners (to not loss an exploitation advantage to anoth= er > CQRC entity). >=20 > Finally, in this analysis we're only underscoring the risk of "legacy" > 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 is > relative, or rather only thermodynamically convergent. If a CQRC entity > is able to build a coalition with a 51% majority of miners, the "upgraded > PQ safe" coins might be also at risk [4]. Indeed, such malicious coalitio= n > 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 chain. >=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 are > "height-based" burnt and not "hash-based" burnt (BIP90). Checkpoints > have been removed from the latest bitcoind versions. Maybe user-activated > checkpoints or other similar mechanisms might be a more robust defense > 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 assumpt= ions > (e.g a reliable network to relay the blocks). It might be considered that > the introduction of CQRC computers might not be only a risk for the "lega= cy" > coins, though far more concerning for the chain finality itself. >=20 > Independently of being philosophically "pro" or "contra" in freezing > legacy 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 developmen= t > community [5]. >=20 > Cheers, > Antoine > OTS hash: 496d9c26c6f3d805dae88f487600f46990572fc84c4ca907fb85b5441c235cf= 3 >=20 > [0] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ > [1] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ > [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 ready > 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 can > only forward the reader to the "Formulation of the Economic Problem" > chapter in the "Theory of Games and Economic Behavior" book from Von > Neumann & Morgenstern, 1944 > [5] As quantum raises a number of skeptical 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, or any other major scientific > prize to prove the physical impossibility of a large-scale quantum comput= er >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CALZpt%2BFOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171%3D25C3ryJPQ%40mail.gmail.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= Mh9z4ISxh4iA80hltDJ3_u7ZWSO5pFuMYI9ae0aGIoSXJDdTOi2KiI4Ckm9BfUAY7YEMvTofep7= hyKsA7Qjk6ydqk2GqG9fvOzEym9YQKjc%3D%40proton.me. -----------------------1d210053e744d95b707f7c314ed1907e Content-Type: multipart/related;boundary=---------------------5bb25331d0ccdac70c8ac482ecb3f2b8 -----------------------5bb25331d0ccdac70c8ac482ecb3f2b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Solid analy= sis Antoine. However things play out here, activating a PQ sunset fork of a= ny 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. 

If a CQRC entity is able to build a co= alition with a 51% majority of miners, the "upgraded
PQ safe" coi= ns might be also at risk [4]. Indeed, such malicious coalition
=
could just roll-back the chain state back to the migration heigh= t of
said coin, solve the DL for this coin and unrol= l back forward the chain.

I do not be= lieve that the old chain history would be safe from deep
<= span>reorgs attacks by CQRC capable entities, as soft-fork deployments are<= /span>
"height-based" burnt and not "hash-based" burnt (BIP= 90). Checkpoints
have been removed from the latest b= itcoind versions. Maybe user-activated
checkpoints o= r other similar mechanisms might be a more robust defense
against CQRC entities attacking the chain finality.

Very neat observation. For such a rollback to occur, the mine= rs would have to cooperatively elect to stop mining the more mature ("authe= ntic") chain, where users have already migrated/forked, and instead start m= ining on an old block (the "revisionist" chain). Any resources they spend o= n this mining will have no payoff until the cumulative proof-of-work of the= revisionist chain surpasses that of the authentic chain. Until then, hones= t validator nodes will simply sit idle.

Due to the va= st 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, 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.

For this to happen, miners must b= e able to withstand significant capex (on mining a revisionist chain), whil= e being blackballed by exchanges, and possibly also devaluing the very coin= s they were bribed with by the CRQC. And even then, it's not clear how - as= suming they were able to pull the attack off and remain solvent - the miner= s would actually use the ill-gotten coins, and whether they'd h= ave any value on the other side of a successful deep reorg attack.

Still, for shal= low reorgs (a few blocks) this seems like a worthwhile concern that serious= ly hampers any tripwire attempts. The best case is if we can deploy the EC = disabling fork before such tempting incentives enter the field = of play.

conduition
On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard <antoine.r= iard@gmail.com> wrote:

Hi list,

In this post, I'm = extending on the game-theory problems
underscored for my answer to [ ] t= o other post-quantum
sunsetting scenarios previously mentioned on this l= ist.

Firstly, let's remember the "tripwire" idea [0]. With the
"t= ripwire", if I understand it correctly we introduce a
consensus level pr= oof of quantum computers e.g with a NUMS
puzzle.

This NUMS is com= mitted 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 automatical= ly triggers
a "freeze" of all the "legacy" coins starting at some block<= br>height-defined window in the future.

While it appears feasible en= gineering-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 l= egacy coins to a safe wallet
owned by this entity.

A more sophist= icated scenario, that I was laying out more
recently, a 51% majority coa= lition of miners could coordinate
with a CRQC entity to censor the trans= action inclusion of any
PQ proof, even an inclusion attempt of a PQ proo= f generated by
an honest PQ entity [2].

Exposing again the econom= ic analysis, a year of mining income
is evaluated at around $20B. The nu= mber 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 est= imated
number can be more around 3-4 M, so let's say $215B worth of
t= arget coins (a coin lost to you is not a coin lost to a CRQC
entity...).=

That's something like ~10 years of potential income, that an
eco= nomically 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 hashra= te capabilities [3].

If we assume a PQ coin extraction game with 2 C= QRC entities
availing roughly the same capabilities, they might compete = for
the majority hashrate of the miners, those miners solely driven
b= y economic incentives. The focal point of equilibrium between
the two st= rategies is likely going to be the marginal energy cost
to run a CQRC, a= ssuming that in a fee race a CQRC entity can
offer to the majority of m= iners to burn more of a coin value
as reorg fee.

Secondly, for th= e second approach of sunsetting, the one very roughly
described in BIP36= 1 and based on pure "flag-day" activation, the
security analysis can ext= end to this approach too. Even assuming
a week-long period for a BIP9-li= ke activation mechanism, a coalition
of miners might stil go to reorg in= depth the chain before the
activation of said soft-fork.

Such an= approach is only theoretically increasing the coordination cost
(and on= e would observe the asymmetry of information is selecting a time
horizon= period, as a CRQC might appear at any time during this period).

One= can observe that the 2 sunsetting approach, be it "tripwire" or
"flag-d= ay" approaches are introducing a "choke point" to the chain finality,
as= in the lack of it a CQRC entity might covertly exfiltrate "legacy" coins,<= br>with no knowledge of the miners, or even without coordination with them.=

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 a= dvantage
to the majority of miners (to not loss an exploitation advantag= e to another
CQRC entity).

Finally, in this analysis we're only u= nderscoring the risk of "legacy"
coins, i.e coins that would have not up= graded to a PQ safe format, after
some time horizon. However, in the Bit= coin blockchain world, time is
relative, or rather only thermodynamical= ly convergent. If a CQRC entity
is able to build a coalition with 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 stat= e back to the migration height of
said coin, solve the DL for this coin = and unroll back forward the chain.

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

Current bitcoin mining process and the chain finality is = assumed to be
reasonably secure under the Gambler's Ruin Problem and som= e other assumptions
(e.g a reliable network to relay the blocks). It mig= ht be considered that
the introduction of CQRC computers might not be on= ly a risk for the "legacy"
coins, though far more concerning for the cha= in finality itself.

Independently of being philosophically "pro" or= "contra" in freezing
legacy coins, I do believe the irruption of one or= more CQRC entities
and the potential of disruptions on the Bitcoin netw= ork stability is
a subject deserving a bit more research and more work f= rom the development
community [5].

Cheers,
Antoine
OTS has= h: 496d9c26c6f3d805dae88f487600f46990572fc84c4ca907fb85b5441c235cf3

= [0] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8= /m/8nr6I5NIAwAJ
[1] https://groups.google.com/g/= bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
[2] One might consider the f= ollowing realistic scenario, it
might that even if a CRQC become relevan= t, at first it will
be only operated by big companies let's say in the U= S or China
and they will prefer to keep the existence of such capabiliti= es
hidden for a while for non-economical reasons.
Suddenly, one of th= e actor starts to use those post-quantum
capabilities and the social equ= ilibrium does not hold anymore
with impactful second-order implications = for the Bitcoin ecosystem.
[3] On the low time incentive miner hypothesi= s, one can empirically
observe (as of June '26) than it has limits given= how fast are ready
mainstream mining companies to reallocate their dat= a centers and
sources of energies to more generic high-performance compu= tations
rather than SHA256 hashing.
[4] For the degree of scientifici= ty of "game-theory" in itself, I can
only forward the reader to the "For= mulation of the Economic Problem"
chapter in the "Theory of Games and Ec= onomic Behavior" book from Von
Neumann & Morgenstern, 1944
[5] As= quantum raises a number of skeptical eyebrows in the community,
the fir= st elaboration of quantum physics have been as old as the 30's,
and so f= ar no one has got a Nobel Prize, or any other major scientific
prize to = prove the physical impossibility of 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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt= %2BFOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171%3D25C3ryJPQ%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/Mh9z4I= Sxh4iA80hltDJ3_u7ZWSO5pFuMYI9ae0aGIoSXJDdTOi2KiI4Ckm9BfUAY7YEMvTofep7hyKsA7= Qjk6ydqk2GqG9fvOzEym9YQKjc%3D%40proton.me.
-----------------------5bb25331d0ccdac70c8ac482ecb3f2b8-- -----------------------1d210053e744d95b707f7c314ed1907e-- -----------------------1a1e2658ad454036bf65a1fa626fa7c8 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== -----------------------1a1e2658ad454036bf65a1fa626fa7c8-- --------c02069e00d15c2c6e1c9c23e497fda4ff6798cf893961d33690ee4d309fa0b7e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmpdSVgJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeKndr0qO4rhG9G38c3TgwDptVOINEYNah6qwSb H3cobxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAv0wEAkjXXmGiHN5E2cLDZ +khuyx8ufMWPvrMwNl4KpieIAQMA/iK+hg+iPIZwapht7Q5yEcehX6PMT8Eo VNPjJ0szgogK =Gt3+ -----END PGP SIGNATURE----- --------c02069e00d15c2c6e1c9c23e497fda4ff6798cf893961d33690ee4d309fa0b7e--