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> Where the 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.