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.  > If a CQRC entity is able to build a coalition with a 51% majority of miners, the "upgradedPQ 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 forward the chain. > > 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 old block (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 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 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 to extremely unhappy: The miners are effectively 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 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 attack 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. 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 the field of play. regards, conduition On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard wrote: > Hi list, > > 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. > > 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. > > 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. > > 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. > > 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]. > > 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...). > > 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]. > > 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. > > 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. > > 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). > > 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 "legacy" coins, > 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 advantage > to the majority of miners (to not loss an exploitation advantage to another > CQRC entity). > > 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 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. > > 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. > > Current bitcoin mining process and the chain finality is assumed to be > reasonably secure 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 introduction of CQRC computers might not be only a risk for the "legacy" > coins, though far more concerning for the chain 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 network stability is > a subject deserving a bit more research and more work from the development > community [5]. > > Cheers, > Antoine > OTS hash: 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 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 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 email to bitcoindev+unsubscribe@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 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Mh9z4ISxh4iA80hltDJ3_u7ZWSO5pFuMYI9ae0aGIoSXJDdTOi2KiI4Ckm9BfUAY7YEMvTofep7hyKsA7Qjk6ydqk2GqG9fvOzEym9YQKjc%3D%40proton.me.