* Re: [bitcoindev] post-quantum: solution ideas to "tripwire"game-theory issues + a certificate-based rescue protocol
2026-08-19 22:27 [bitcoindev] post-quantum: solution ideas to "tripwire"game-theory issues + a certificate-based rescue protocol Antoine Riard
@ 2026-08-20 16:33 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 0 replies; 2+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-08-20 16:33 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List, btc
[-- Attachment #1.1.1: Type: text/plain, Size: 13066 bytes --]
Hi Antoine,
> One way to alleviate the problem would be to consider thespent of the NUMS point, that can be a hardcoded value that
> one can commit in a dedicated coinbase output as a "proof of
> work in itself" where the CheckProofOfWOrk() would return true
> for it and the nChainWork of the chain in which the NUMS spent
> is included would get a bonus (e.g *20 the last period's difficulty).
A very interesting idea! Essentially this gives a one-time difficulty advantage to miners who choose to include the tripwire proof, so a "51% attack" to censor that proof would need a much larger share of hashrate. For example, if the honest miners receive a 2x advantage for mining the tripwire, then censoring miners would need to hold at least double the hashrate of the honest miners (e.g a "67% attack"). If the advantage is 4x, then they'd need at least 4x the hashrate (e.g. an "81% attack"), etc.
It's clever, but the main problem is that it's a hard fork, as you mention:
> All network nodes sharing this consensus mechanism would followthe new and same chain ordering, overruling the most proof of
> work ordering.
Nodes that don't upgrade would see the new "advantaged" block containing the tripwire proof as having an invalid PoW, and would reject it.
Granted, this would be a pre-scheduled hard-fork agreed upon presumably well in-advance of the (undefined) fork date, as opposed to an emergency hard fork of the kind that split ETH and ETC back in the day, or the kind that would be needed to reverse a hypothetical mass-quantum-theft event. So maybe you could argue it'd be acceptable as long as enough nodes have upgraded by Q-day.
> This group signature constituted of a merkle tree of signatureswould be attach a "weight" based on the amount PQ signed for the
> coins, and if the "weight" is superior to some threshold, the
> block attaching this special "one-time" group signature would
> a POW ordering bonus and the "tripwire" effect would be attached.
I think this would also be a hard fork for similar reasons.
Plus, as you mentioned, we would run the risk of a dishonest minority colluding to trigger the fork early. I especially worry about corporate actors here, who now control a significant fraction of the supply volume, and might have incentive to jump the gun and ossify bitcoin's cryptography early.
-----
A UASF-like approach is probably the better option here to prevent miner collusion: Perhaps if we distinguish the set of "active" nodes, and write rules that say "if an active node has seen a tripwire proof, they must disregard any blockchain that doesn't include a tripwire proof". Maybe you'd call this a "block policy".
This obviously doesn't work for nodes doing IBD (the first block after genesis would be considered invalid!) or nodes that come online after sleeping a while (they'd reject the first new block after seeing the tripwire proof!) so there would need to be some means to distinguish those cases from an active synchronized node. Not sure how that'd work.
> By leveraging the preimage in some ZK-proof of a PQ-safe schemea legitimate coin owner could be able to prove that her or him
> *knew* the discreet log at some point in time of the bitcoin
> blockchain. This knowledge could be leveraged to allow the transfer
> of the coins a posteriori of the "tripwire" lock in function of
> the post-quantum transition policy opt-ed in by the coin owner.
Are you describing this as a rescue protocol, or a pre-registration protocol? Pre-registration protocols aren't that useful if we have a rescue protocol, or even just having PQ-safe wallets, because if one can take the proactive measure to pre-register, why not simply move one's coins to an address that can be rescued later, or better yet to a PQ-secure address?
A rescue protocol on the other hand must assume zero action from the user prior to Q-day (i.e. tripwire activation).
> A simple certificate can have a very simple format, e.g:
>
> <1-byte certificate version> <opt-in tripwire lock> <sha256_hash> <signature>
What is the "opt-in tripwire lock" field here?
> The scheme is not bulletproof, as we cannot have certainty, _if_ and_when_ a CQRC will appear, however in its simple logic it could be
> done today (it's like open-timestamp the marginal cost of a certificate
> is very very low, the witness cost only being encumbered at spending).
> This idea only to add more color on the painture pallet of the technical
> optional to protect EC exposed coins.
This sounds similar to my own proposal, DropKick, which is also OTS-like in the way commitments are opened. I'll open a new thread soon to discuss that :)
regards,
conduition
On Wednesday, August 19th, 2026 at 6:36 PM, Antoine Riard <antoine.riard@gmail.com> wrote:
> Hello,
>
> In this post, I'm detailing (a) what could be a solution for
> the game-theory difficulties of the "tripwire" NUMS point and
> (b) a second solution for the exact same problem, relying on
> different assumptions and (c) a variant of a commit/reveal
> rescue protocol for EC coins based on the strict ordering of
> the bitcoin blockchain.
>
> Most of the ideas are "rough" (and maybe a bit heretical...),
> the whole is for putting more tools on the design table, on
> what can be done in the face of CQRC adversarie(s) aiming to
> compromise the chain finality, among other attacks goals.
>
> ## A. NUMS Spend As a Proof of Equivalence of POW
>
> One of the difficulty previously raised with a PQ-flag
> transaction based on a solution to the "tripwire" is the risk
> of "tx-withold" being coordinated by a majority coalition of
> miners eager to exploit EC coins in coordination with a CQRC [0].
>
> There are able to dictate what is the chain state, of which
> the "tripwire" spend must included it to trigger effect, as
> according to Satoshi paper, the "majority decision is represented
> by the longest chain, which has the greatest proof-of-work
> effort invested in it".
>
> If the coalition has a 51% advantage, or an appromixative
> amount of hashrate using other techniques, they can maintain
> their advantage on what is getting in the chain. No one will
> be able to produce an equivalent amount of proof of _work_.
>
> One way to alleviate the problem would be to consider the
> spent of the NUMS point, that can be a hardcoded value that
> one can commit in a dedicated coinbase output as a "proof of
> work in itself" where the CheckProofOfWOrk() would return true
> for it and the nChainWork of the chain in which the NUMS spent
> is included would get a bonus (e.g *20 the last period's difficulty).
>
> By introducing an ordering of the chain among network nodes
> based on multiple factors, of which the NUMS spent would be
> a *one-time* accounted for factor, the bar to trigger the
> activation of the effect of the NUMS spent, whatever they are,
> is removed of the assumption of availing the majority of hashrate [1].
>
> All network nodes sharing this consensus mechanism would follow
> the new and same chain ordering, overruling the most proof of
> work ordering.
>
> This approach still raises some problem of its own, as it's one
> thing to have a "tripwire" NUMS spent that would be part of
> consensus rules, it is still assuming that an entity availing
> a CRQC would produce a proof to activate the "tripwire".
>
> It can sounds a high bar for the community to assume there will
> be a nice and kind CRQC-capable entity, just right there at the
> corner to produce such a proof, if real-world quantum computer
> ever becomes a reality.
>
> ## B. Group Signatures of PQ Upgraded Coins
>
> An alternative solution not running in the same issue of
> availing a CQRC would be to rely on a group signatures of
> some threshold of PQ upgraded coins, e.g having more their
> coins to some variant of crystal-dilithium, falcon or whatever.
>
> The idea is on the same line than the one previously introduced,
> a novel merkle tree of PQ "blessing" signatures could be added
> in the commitment extension structure of BIP141 (i.e in the
> commitment hash of the coinbase output's commitment hash).
>
> This group signature constituted of a merkle tree of signatures
> would be attach a "weight" based on the amount PQ signed for the
> coins, and if the "weight" is superior to some threshold, the
> block attaching this special "one-time" group signature would
> a POW ordering bonus and the "tripwire" effect would be attached.
>
> This scheme comes with the advantage of being CRQC-resistant, as
> a CRQC would not be able to forge a signature, without herself
> or himself already availing some significant amount of coins. It
> would be an "indirect oracle" that a CQRC might be active and is
> more robust than the community.
>
> However, this mechanism, a contrario of the NUMS-based can be
> fooled, even in the absence of a CRQC, therefore making it a
> risk of social blackmail (e.g a proof-of-stake majority meeting
> the threshold deciding to activate the "tripwire" to alter the
> conditions of spendability of numerous coins at their advantage).
>
> A two-phase commit "tripwire" protocol could be designed, where
> the "tripwire" effect is only locked-in (somehow in some analogy
> with BIP9 mechanism), if the threshold is not "challenged" by another
> economic group of coins owner during some period (e.g two to three
> months).
>
> ## C. Chain Timestamped Certificate of Discreet Log Knowledge
>
> On the more technical problem of "what can do procrastinators coin
> owners", one train of solution in the line of the commit-reveal
> protocol that has been previously discussed would be to use the
> chain itself as a publication space of discreet log ownerships.
>
> The problem with a CRQC it's enabling someone to crack the DL k
> of a point K, where K = k * G, blurring the ability of the coin
> owner to prove she or he is the legitimate owner of the coins,
> EC cryptography being based on the knowledge of a discreet log.
>
> While once a CRQC appears in the wild, it is not possible anymore
> to assume that anyone in knowledge of the discreet log is the
> legitimate owner of the coin, a proof of "knowledge anteriority"
> could be able to break the tie in multiple transactions claiming
> to be the owner of the coin.
>
> A simple certificate can have a very simple format, e.g:
>
> <1-byte certificate version> <opt-in tripwire lock> <sha256_hash> <signature>
>
> Where the <signature> would commit to all the fields of the
> certificates.
>
> By leveraging the preimage in some ZK-proof of a PQ-safe scheme
> a legitimate coin owner could be able to prove that her or him
> *knew* the discreet log at some point in time of the bitcoin
> blockchain. This knowledge could be leveraged to allow the transfer
> of the coins a posteriori of the "tripwire" lock in function of
> the post-quantum transition policy opt-ed in by the coin owner.
>
> One interesting aspect of this scheme is coin owners could start
> for now building merkle tree of coin certificates and commit them
> in the bip141 commitment structure, a magic number op_return or an
> annex, whatever even if the "proving" consensus logic is only added
> in an ulterior soft-fork.
>
> The scheme is not bulletproof, as we cannot have certainty, _if_ and
> _when_ a CQRC will appear, however in its simple logic it could be
> done today (it's like open-timestamp the marginal cost of a certificate
> is very very low, the witness cost only being encumbered at spending).
> This idea only to add more color on the painture pallet of the technical
> optional to protect EC exposed coins.
>
> Cheers,
> Antoine
> OTS hash: a5a11d42e13724c04d44b953ae5c5f0d152346a7e2041a0a966a62ef148f5ab7
>
> [0] https://groups.google.com/g/bitcoindev/c/DEfcMWSdQRY
> [1] To facilitate P2P communication and discovery of this
> bloc, the nVersion field of the header could commit to a bit.
>
> --
> 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%2BHRNFdtWUpg4v2aj9CRMamS7eG9Nem3mdxJq4sZEtOL6w%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/UW5dOJNFjgt67sz-2sRUPeMJi0XL6_wSm7zKCmSoj_8IzkQavc-Vo9vwiR7Tbaz7bvP2YrH8b-1JGm-9jNQXQM8dqsw1f1Sl75SHIOt9cOc%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 18365 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread