From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: btc@ariard.me
Subject: [bitcoindev] The game-theory problems of PQ sunsetting modes
Date: Sun, 12 Jul 2026 19:34:40 +0100 [thread overview]
Message-ID: <CALZpt+FOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171=25C3ryJPQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 7032 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 8435 bytes --]
next reply other threads:[~2026-07-12 19:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-12 18:34 Antoine Riard [this message]
2026-07-19 22:02 ` [bitcoindev] The game-theory problems of PQ sunsetting modes 'conduition' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+FOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171=25C3ryJPQ@mail.gmail.com' \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=btc@ariard.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox