Hello Conduition, > It's clever, but the main problem is that it's a hard fork, as you mention
Yeah, I think there could be some ways to roll it as a soft-fork, in a transparent way for non-upgraded nodes and that way maintain a common ordering of the blocks. The issue is effectively that non-upgraded nodes won't apply the chain ordering bonus to the "tripwire" proof, as they would still run the old ordering mechanism. However, if there is a super-majority of the miners running the new ordering mechanism (>= 95%), one can make the assumption that non-upgraded nodes won't see that much further updates on the chain. Due to the proof-of-work "gravity", at some temporal point, non-upgraded nodes are going to start to select the chain including the "tripwire" block, just because it has the most proof-of-work, even if those nodes see no pow for the "tripwire" block itself. Now, there is a turtle in the turtle, as the miners can jump from the "tripwire" chain to the "no tripwire" chain, back-and-forth. One way to alleviate this would be some form of merge-mining where the "no-tripwire" chain's blocks could be replayed on the "tripwire" chain...though we start to be in the (very) ugly land of consensus activation design... Note, BIP9 in its design surface opens the door to multi-stage soft forks, so there could be an early phase where all the miners have to commit to a new coinbase output with an empty "tripwire" proof placehodler. What you wish to dissociate is the survenance of a CRQC altering the miners incentives games and therefore the inclusion odds of a "tripwire" proof, whatever the staged spending policy that is active by this proof. > 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. I think you can do that with a soft-fork, if you go as deep of designing merge-mining mechanisms to minimize miners equivocation, at the time of the "tripwire" activation. The problem of a hard fork it's a pandora box concerning the social consensus, that personally I prefer not to consider. > 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. Yeah, I was just mentioning the proof-of-stake idea to have more tools on the design table, if it ever can be useful or combined with other technical mechanisms to be made more robust. Though I'm sharing the same worry than you, it could be leveraged by a dishonest minority, where dishonesty would be defined by the lack of the survenance of a CRQC. > 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". You can have this translated in consensus rules, iirc this was the LOT idea that was discussed for taproot activation. See my point above about BIP 9's multi-staged soft-fork activation too. > 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. AFAICT, the problem you're mentioning would only appear transitively during the soft-fork activation of new accouting rules for a "tripwire" proof. It sounds it can be resolved by having a good ordering of the soft-fork activation effect, where there would take effect at a clean transition block, and the "tripwire" proof can be just replayed after. Note, if we reorg of this depth back to genesis I believe we'll already have issues far earlier with any buried soft-fork activation. > 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? That's an excellent question, as a pre-register protocol. While one can take proactive measure to pre-register, it's bitcoin and social convergence on consensus is never guaranteed. We have no guarantee that the community *will* converge on a PQ-safety address, even if I guess you and me are hoping so for a PQ-safe scheme whatever it is. On the other hand a pre-register protocol that is a wallet-policy and custom blocks validation for now, opens more door to have a rescue consenensus soft-fork happening *at a latter time* once you have a CQRC adversary popping up in the wild. > A rescue protocol on the other hand must assume zero action from the user > prior to Q-day (i.e. tripwire activation). A rescue protocol still have to assume that the community will converge on a soft-fork activation before a hypothetical Q-day. > What is the "opt-in tripwire lock" field here? An opt-in field if you wish to have your EC coins to be "frozen" or not (until you come with a ZK PQ safe of ownership of the coin at a latter time), once a "tripwire" proof is included in the chain. This would still require some secondary registered coin cache to have the effect being applied, though I believe this could be done leveraging the BIP141 commitment extension mechanism. > 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 :) Cool, I'll have a look, using chain time as some sort of conveying information is an interesting idea. Best, Antoine OTS hash: 959e84871689e6ee1f8e19ae50727549164d6f2e881f5cef3a9fe3700c0e6f21 Le jeu. 20 août 2026 à 17:33, conduition <[email protected]> a écrit : > Hi Antoine, > > 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). > > > 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 follow > the 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 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. > > > 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 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. > > > 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 < > [email protected]> 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 [email protected]. > 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BHKO%2B64J8EaRR-ih__aE%2Bj-uJAMq79%2BCPVKOvkw9V_Lyw%40mail.gmail.com.
