From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 20 Aug 2026 09:46:26 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wx5uK-0004tp-Pg for bitcoindev@gnusha.org; Thu, 20 Aug 2026 09:46:26 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-45952ce9ee0sf33975fac.1 for ; Thu, 20 Aug 2026 09:46:24 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787244378; cv=pass; d=google.com; s=arc-20260327; b=J9jGBm752g2U1pwMn44DeDLxNEHy2+/ySv4M6bFZ5jHKevZbmFDSZklGXV8tXxkFd2 3HJIv1NHCaFLeDrg+BsWqL9kWzyGn/Tk8Du4vF1u9VQg49mbWT8xEGBImM1bGEL7OHBU rupYc4me59YCVTsF1gQ8mGvxJOGsTTsru4NBoSeoM8YJ+CO9BHJHq69RuPL4jauEkfzj wLZGG0JdqEMybX4ggeEROjWScVOeKiNcYYfhgMU9O+DgJs4sIzq5gdKIezIx/MnDg+H+ DLVuaL5wHHDVQVAXizCSkm8wfLlfJ8KVLQ09pHexs5/MKNiEGrnSyoahstwgzUZM7C86 SWww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=QpYj503oXZfrFc5hOC7nU4LxqviTxQfddn2DkxdM1T0=; fh=fDvyyQVhfTmbL1aqpcgHngEpJIZivm1/WgvDJwSIAEM=; b=nd+CGhb8ah2MPX9uR1EVuX7iXiUjJNWhOcX5HQyT+NB7Fs4Z/73FHZsdiaDfPtaw1o SA/VhTI7kXkaynEnXI0wk65jMK83S6lgkqIBLgcUleeoxnvmC+e/ZEZQge9VDwI/INTy jW3ScOe5A8I5IsDB+UTxZVjp2NpJ3aWFyA7cpWapjgloAe0fL97TzWOH67lW8DkYhzCY Y7r5ad5MwbQTT3MJcqD2+fs1ksvT9V+itOajiM5Jm0O1xuLWKtpEpM+DjNMOHTj6vrGb UotYl73OnZhKR1pWMGN/iav9J2JeO3uJfFvCfzoQGX6BapJSrw9rn4PraRMzpgZdUL/z eFXw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=avHOZX3q; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787244378; x=1787849178; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=QpYj503oXZfrFc5hOC7nU4LxqviTxQfddn2DkxdM1T0=; b=Fr3gVAAVyejYYejFo4FSFjUR+3T5GCQs9oyqlbK69sPtw37x8fk4xAwzfCsAQTozj6 DD+RI9OArnZaUwCkv8sYEW8L9vY27wHje5jx/UMMlZesLgZH7P7JzR07dXwXUYeR5PjN 4iX8Bj/yKyhLDkbIdhqZOL0g11wAuvGIvEkaHASjmHzrOzP/iw6K/vuaPjsP7HdTtN5N 2OI/PpNxwhyxglS9qwiY2vmEZHCZZ2gcxfMIuFOP7Akxvo17Hpo2RBuB3v5gi9A9b3fO QpjuRXWILcY8IIUTR0s9MRqZeI/60ibOYhQNod1xKqHOW+KF4CALAZzxjSmENF51jjcS Zhhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787244378; x=1787849178; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=QpYj503oXZfrFc5hOC7nU4LxqviTxQfddn2DkxdM1T0=; b=BtRGPtWvCJwXraMVX7HWYNOYFVard2eqyJEajK52i0mL7DNp26qtxBu5DwW9MHSoIL 0HSHTz1gbWr9S2RpmwBMJheV89iEXPqrjKqLJHIMxZV7eXOVZj12ugl5i/akl43enKwc alh+uFBl02P7ZZKOq7tQiDDj8f6MuTSMoRBMgu3R893uEimPK7eVp2H23IhGCWTsE1xX vTlLgICZ22rl4/3zUJ47ogs2OP5xX/VImzQko0B9rUu3VJkADpwxNa6OQq93u3cGX4KK arIa/snXam74VT0mirJaa0tfLwMg/iOCZFzG+gNatZjeUcNhXb1q7mNKqk60DR87mzSs XDGA== X-Forwarded-Encrypted: i=2; AHgh+RpHl+yFIpr3LHzA0FGKAYqeAZBLBlw8oLNAB49ZK4Nyj3+pTcpPoxTU4lHFxUJL6rX3Wrj45aCbGktp@gnusha.org X-Gm-Message-State: AOJu0YwWjy9YRGydtDjXiExzS0bRgRlJGIYQC9UAGgGU4/2isVE2ShUL tddKw3hYcosoV+sfDfu+DE3TMyRdNhbJfPvVCeVMLXlwDxRC7FuAguCi X-Received: by 2002:a05:6820:150b:b0:6b0:d7aa:5c18 with SMTP id 006d021491bc7-6b13c62bc62mr14100669eaf.29.1787244377826; Thu, 20 Aug 2026 09:46:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfHIDqMGKHj8xgsrop18AJo0vPTlRJ7FobNeY03hz1juQ==" Received: by 2002:a05:6871:ecc5:20b0:454:e0fd:4304 with SMTP id 586e51a60fabf-4631c8b6fc6ls868578fac.1.-pod-prod-05-us; Thu, 20 Aug 2026 09:46:10 -0700 (PDT) X-Received: by 2002:a05:6808:5385:b0:4a4:9e18:607a with SMTP id 5614622812f47-4b2bcb6daf0mr14146319b6e.21.1787244370405; Thu, 20 Aug 2026 09:46:10 -0700 (PDT) Received: by 2002:a05:690c:9203:b0:80b:2194:fea2 with SMTP id 00721157ae682-8445cf2277bms7b3; Thu, 20 Aug 2026 09:33:50 -0700 (PDT) X-Received: by 2002:a05:690c:6e83:b0:841:8f97:e898 with SMTP id 00721157ae682-844e4ed71famr55110027b3.32.1787243629083; Thu, 20 Aug 2026 09:33:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787243629; cv=none; d=google.com; s=arc-20260327; b=MxOU6BO8mePKTRFEQsczRgPHaataZu13fq1nV63Xp2yB+VwYJZWIr0FC9/CnRraEA2 5CEoqxsYEBFY+wSfPc3sjIyzpsNkaHwuUazqvtl2cPWjSlNj0MlkX2e9Ee6C/TYJHqle VoeD5GCJiG6JSOJxiK5TdZNnyL6QwqQP7N80mWo4eodXOZD6ufJBp8fMEVdBs3JKQ4We 85ZrzY5zsBh5+cYrMhfdpB8ywM5hamyNfnYZX0VbXXtZsuL8Vr4r9TyFZ8iQlldGTiXf 6d5RJywuS1ZjkHPOIk0dX/qkoQ61Mf5IzI6b3mCfyKmnUZnD2hU6Z8VWDwaZDx9Ew1Ws Es9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=EI4sJZ072LZZLZOmuOawNOeplSiXbE6y3NHxJYWZzik=; fh=LDhKQOar2Hgy0ZybTq9cTMKeH1hWccLzq8hHpwVcKmQ=; b=pfc4BDXWeL3r2Knj9NiBzU0nFEYSj93Pt/mqKUBpI/a+eM2gWXltonSViicH+tePoi l6CM2RFA4jdw4U8fI9dqjbSfXE6IcvzdRagjyLe1JaQEL7sv+HpzBCnW8FMubNJ50a7B 5SQhiTT8digW3juRT/Kz+d93lyeDV5DY+5wCy2/7ULWQAiLeat6aFSfkcXHJpJBMSq0a U/+wbeVkHXccxV8r3oy7hWqetCOzr/JK52QJ7xH/8uNFV8Uc66BszeBkHiQuqke8c2FQ 9UzKEUoo2paHXSw7aIKT0vjm28D2Az0RtCqxvKGSIBjSr0KWelCl9uy3XsqGBZ1XqZ+6 DIfQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=avHOZX3q; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24428.protonmail.ch (mail-24428.protonmail.ch. [109.224.244.28]) by gmr-mx.google.com with ESMTPS id 00721157ae682-84517b10831si1620537b3.7.2026.08.20.09.33.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2026 09:33:49 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.28 as permitted sender) client-ip=109.224.244.28; Date: Thu, 20 Aug 2026 16:33:42 +0000 To: Antoine Riard From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List , btc@ariard.me Subject: Re: [bitcoindev] post-quantum: solution ideas to "tripwire"game-theory issues + a certificate-based rescue protocol Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 3c747ccaff369f9c65fb4d61f7b98345d6e29c6b MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------b4ee4af6d5aefcef3e7d1143ea4f2708b3400fb6088cde2b6c965ea1403f00fe"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=avHOZX3q; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------b4ee4af6d5aefcef3e7d1143ea4f2708b3400fb6088cde2b6c965ea1403f00fe Content-Type: multipart/mixed;boundary=---------------------b3ed5f014d5a494ab81aa17eb428ebbb -----------------------b3ed5f014d5a494ab81aa17eb428ebbb Content-Type: multipart/alternative;boundary=---------------------3b1e3ffd5db419b3c596a12aa3e99c34 -----------------------3b1e3ffd5db419b3c596a12aa3e99c34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Antoine, > One way to alleviate the problem would be to consider thespent of the NUM= S 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 advan= tage 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 exampl= e, if the honest miners receive a 2x advantage for mining the tripwire, the= n censoring miners would need to hold at least double the hashrate of the h= onest 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 an= d same chain ordering, overruling the most proof of > work ordering. Nodes that don't upgrade would see the new "advantaged" block containing th= e tripwire proof as having an invalid PoW, and would reject it. Granted, this would be a pre-scheduled hard-fork agreed upon presumably wel= l 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 w= ould 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 b= y Q-day. > This group signature constituted of a merkle tree of signatureswould be a= ttach 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.=C2=A0 Plus, as you mentioned, we would run the risk of a dishonest minority collu= ding to trigger the fork early. I especially worry about corporate actors h= ere, 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 co= llusion: Perhaps if we distinguish the set of "active" nodes, and write rul= es that say "if an active node has seen a tripwire proof, they must disrega= rd 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 gene= sis 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 a= ctive synchronized node. Not sure how that'd work. > By leveraging the preimage in some ZK-proof of a PQ-safe schemea legitima= te 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 protoco= l? Pre-registration protocols aren't that useful if we have a rescue protoc= ol, or even just having PQ-safe wallets, because if one can take the proact= ive 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 p= rior to Q-day (i.e. tripwire activation).=C2=A0 > A simple certificate can have a very simple format, e.g: >=20 > <1-byte certificate version> 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=C2=A0proposal,=C2=A0DropKick, which is also O= TS-like in the way commitments are opened. I'll open a new thread soon to d= iscuss that :) regards, conduition On Wednesday, August 19th, 2026 at 6:36 PM, Antoine Riard wrote: > Hello, >=20 > 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. >=20 > 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. >=20 > ## A. NUMS Spend As a Proof of Equivalence of POW >=20 > 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]. >=20 > 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". >=20 > 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_. >=20 > 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). >=20 > 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]. >=20 > All network nodes sharing this consensus mechanism would follow > the new and same chain ordering, overruling the most proof of > work ordering. >=20 > 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". >=20 > 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. >=20 > ## B. Group Signatures of PQ Upgraded Coins >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > 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). >=20 > 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). >=20 > ## C. Chain Timestamped Certificate of Discreet Log Knowledge >=20 > 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. >=20 > The problem with a CRQC it's enabling someone to crack the DL k > of a point K, where K =3D 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. >=20 > 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. >=20 > A simple certificate can have a very simple format, e.g: >=20 > <1-byte certificate version> >=20 > Where the would commit to all the fields of the > certificates. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Cheers, > Antoine > OTS hash: a5a11d42e13724c04d44b953ae5c5f0d152346a7e2041a0a966a62ef148f5ab= 7 >=20 > [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. >=20 > -- > 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/bitcoinde= v/CALZpt%2BHRNFdtWUpg4v2aj9CRMamS7eG9Nem3mdxJq4sZEtOL6w%40mail.gmail.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= UW5dOJNFjgt67sz-2sRUPeMJi0XL6_wSm7zKCmSoj_8IzkQavc-Vo9vwiR7Tbaz7bvP2YrH8b-1= JGm-9jNQXQM8dqsw1f1Sl75SHIOt9cOc%3D%40proton.me. -----------------------3b1e3ffd5db419b3c596a12aa3e99c34 Content-Type: multipart/related;boundary=---------------------431bae62c1a193067383ca27e74c8e46 -----------------------431bae62c1a193067383ca27e74c8e46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,=

<= /div>
= 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<= /span>
work in itself" where the CheckProofOfWOrk() would r= eturn 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 v= ery interesting idea! Essentially this gives a one-time difficulty advantag= e 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 c= ensoring miners would need to hold at least double the hashrate of the hone= st 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 clev= er, 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 ofwork ordering.

Nodes that don'= t upgrade would see the new "advantaged" block containing the tripwire proo= f as having an invalid PoW, and would reject it.

Granted= , this would be a pre-scheduled hard-fork agreed upon presumably well in-ad= vance 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 co= uld argue it'd be acceptable as long as enough nodes have upgraded by Q-day= .

This group signature constituted of a merk= le tree of signatures
would be attach a "weight" based on = the amount PQ signed for the
coins, and if the "weig= ht" is superior to some threshold, the
block attachi= ng this special "one-time" group signature would
a P= OW ordering bonus and the "tripwire" effect would be attached.

I think this would = also be a hard fork for similar reasons. 

<= /span>
Plus, as you mentioned, we would run the risk of a d= ishonest minority colluding to trigger the fork early. I especially worry a= bout corporate actors here, who now control a significant fraction of the s= upply 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 w= e distinguish the set of "active" nodes, and write rules that say "if an ac= tive node has seen a tripwire proof, they must disregard any blockchain tha= t 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 considere= d 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 nod= e. Not sure how that'd work.

=
By leveraging the preimage in some ZK-proof of a PQ-safe s= cheme
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 p= osteriori of the "tripwire" lock in function of
the post-q= uantum transition policy opt-ed in by the coin owner.

Are you describing this as a res= cue protocol, or a pre-registration protocol? Pre-registration protocols ar= en'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 be= tter yet to a PQ-secure address?

A rescue protocol on the other hand must assume zero action from t= he user prior to Q-day (i.e. tripwire activation). 

A simple certificate can have a very simple for= mat, e.g:

<1-byte certificate version> <opt-in tripwire loc= k> <sha256_hash> <signature>

What is the "opt-in tripwire lock" = field here?

The scheme is not bul= letproof, as we cannot have certainty, _if_ and
_when_ a C= QRC will appear, however in its simple logic it could be
<= span>done today (it's like open-timestamp the marginal cost of a certificat= e
is very very low, the witness cost only being encu= mbered at spending).
This idea only to add more colo= r on the painture pallet of the technical
optional t= o protect EC exposed coins.

This sounds similar to my own proposal, DropKick, which is also OTS-like in the way commitments are opened. I'l= l open a new thread soon to discuss that :)


regards,
conduition
On Wednesday, August 19th, 2026 at 6:36 PM, Antoine Riard <antoi= ne.riard@gmail.com> wrote:
Hello,

In this post, I'm detailing (a) = what could be a solution for
the game-theory difficulties of the "tripwi= re" NUMS point and
(b) a second solution for the exact same problem, rel= ying on
different assumptions and (c) a variant of a commit/reveal
re= scue protocol for EC coins based on the strict ordering of
the bitcoin b= lockchain.

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 Pro= of of Equivalence of POW

One of the difficulty previously raised wit= h a PQ-flag
transaction based on a solution to the "tripwire" is the ris= k
of "tx-withold" being coordinated by a majority coalition of
miners= eager to exploit EC coins in coordination with a CQRC [0].

There ar= e 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 gr= eatest proof-of-work
effort invested in it".

If the coalition has= a 51% advantage, or an appromixative
amount of hashrate using other tec= hniques, they can maintain
their advantage on what is getting in the cha= in. No one will
be able to produce an equivalent amount of proof of _wor= k_.

One way to alleviate the problem would be to consider the
spe= nt 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 ch= ain in which the NUMS spent
is included would get a bonus (e.g *20 the l= ast period's difficulty).

By introducing an ordering of the chain am= ong network nodes
based on multiple factors, of which the NUMS spent wou= ld be
a *one-time* accounted for factor, the bar to trigger the
activ= ation 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 ch= ain ordering, overruling the most proof of
work ordering.

This ap= proach 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 stil= l assuming that an entity availing
a CRQC would produce a proof to activ= ate the "tripwire".

It can sounds a high bar for the community to as= sume 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 computerever becomes a reality.

## B. Group Signatures of PQ Upgraded Coin= s

An alternative solution not running in the same issue of
availi= ng 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" signatu= res 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 b= e 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 sp= ecial "one-time" group signature would
a POW ordering bonus and the "tri= pwire" effect would be attached.

This scheme comes with the advantag= e of being CRQC-resistant, as
a CRQC would not be able to forge a signat= ure, 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 CRQ= C, therefore making it a
risk of social blackmail (e.g a proof-of-stake = majority meeting
the threshold deciding to activate the "tripwire" to al= ter the
conditions of spendability of numerous coins at their advantage)= .

A two-phase commit "tripwire" protocol could be designed, wherethe "tripwire" effect is only locked-in (somehow in some analogy
with B= IP9 mechanism), if the threshold is not "challenged" by another
economic= group of coins owner during some period (e.g two to three
months).
<= br>## 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 ha= s been previously discussed would be to use the
chain itself as a public= ation 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 =3D k * G, blu= rring 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 d= iscreet log.

While once a CRQC appears in the wild, it is not possib= le anymore
to assume that anyone in knowledge of the discreet log is th= e
legitimate owner of the coin, a proof of "knowledge anteriority"
co= uld 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 form= at, e.g:

<1-byte certificate version> <opt-in tripwire lock= > <sha256_hash> <signature>

Where the <signature&g= t; would commit to all the fields of the
certificates.

By leverag= ing 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 le= veraged 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 th= e coin owner.

One interesting aspect of this scheme is coin owners c= ould 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 canno= t have certainty, _if_ and
_when_ a CQRC will appear, however in its sim= ple 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 encu= mbered at spending).
This idea only to add more color on the painture pa= llet of the technical
optional to protect EC exposed coins.

Chee= rs,
Antoine
OTS hash: a5a11d42e13724c04d44b953ae5c5f0d152346a7e2041a0= a966a62ef148f5ab7

[0] https://groups.google.com/g/bitcoindev/c/D= EfcMWSdQRY
[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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2= BHRNFdtWUpg4v2aj9CRMamS7eG9Nem3mdxJq4sZEtOL6w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/UW5dOJ= NFjgt67sz-2sRUPeMJi0XL6_wSm7zKCmSoj_8IzkQavc-Vo9vwiR7Tbaz7bvP2YrH8b-1JGm-9j= NQXQM8dqsw1f1Sl75SHIOt9cOc%3D%40proton.me.
-----------------------431bae62c1a193067383ca27e74c8e46-- -----------------------3b1e3ffd5db419b3c596a12aa3e99c34-- -----------------------b3ed5f014d5a494ab81aa17eb428ebbb Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------b3ed5f014d5a494ab81aa17eb428ebbb-- --------b4ee4af6d5aefcef3e7d1143ea4f2708b3400fb6088cde2b6c965ea1403f00fe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqHLFUJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcwGh+s1Or6KLePWk1Y4OW3JnYzzvr61ToXywAw NVOTkxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAO3QD9ElR807TdgXlWQrui I30+scNeMTkj5XL8TtnoBSZ7GgwBAO3ddbJm2AnW1qgjw3r6jg3ue83fnFb4 ap3W6nbsAJUO =iSp+ -----END PGP SIGNATURE----- --------b4ee4af6d5aefcef3e7d1143ea4f2708b3400fb6088cde2b6c965ea1403f00fe--