From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 19 Aug 2026 15:36:48 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwotr-00072q-Gw for bitcoindev@gnusha.org; Wed, 19 Aug 2026 15:36:48 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-45134682038sf998991fac.0 for ; Wed, 19 Aug 2026 15:36:47 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1787179001; cv=pass; d=google.com; s=arc-20260327; b=q75NQzF41SZ8h0fDf+M1VLr1D/FoyqONE7ajoZu9wYR0v7qqv3HZmNgTI9ohj6QYV+ /GgfvPt6qHjDtD2CMh7b5QWCpFT3laCpg96HmYCJdbjGzPP0E0A4+k1CpPzwpkR9HEfk Etwgb6+KdXe7tpe6+XrQwBlnnJNcGnW9XnJBV0dLK604fhrZvrNJgowjPLS43ieuTfZ9 A462kx1HRZbnlK3Ok77+T8J8bP0JGBq44sBJTGd+PQEu1rgidNFFa+ozvkFeckP+RXzq tIYJxBsW0hhK0rWIcP7FMc2KJFdTzOnTXo/PzuGMz1uqtUkd/QYKdFs1b/Va7BESp9b3 R/Vg== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=t+v+TrmuSm8tbTgjN/7BMoAGViaZ7gsFOSCS4aqapDo=; fh=D08IyfvqP02DHlPDQKvQaTVktrqlombo8tWL7A6Ezd8=; b=cnO+xhaLx4Tpv7bNnXO3yIVml278KPcM8j1U3pPdulGcQXxFEKjF67rk0PgRKoECiy JzlNPgScWFckbWkxcWsaUCNj+3rytpg6iyzoEFG336XQM6NFKfF0LqvXvYcPhxFjZKGA coJBoqKzebcPjHZ4vrTdXL5ynhXrD/ha7eLdLKpgBe0KwC8zHfUfBRbcCwF6GznCgEi3 GsXaKsiORyZuEsAkjdF/fLlkpU201I6ARZ/xYXyQMIyq84Aibp/W/8irdCRg0+YLCuCC crgd9T49ZUeisbybkQpzzcVK5FfmcmwHa4rGMy6E6QyaYK0bOJPHnG6jvp6aAv7GgtOY flrw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=FRQAwzON; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787179001; x=1787783801; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :mime-version:sender:from:to:cc:subject:date:message-id:reply-to :content-type; bh=t+v+TrmuSm8tbTgjN/7BMoAGViaZ7gsFOSCS4aqapDo=; b=DfO6S7fVKdYdaXcpm/lOG1TwmnOMjqNdWfDhaVMPyIgKZwFuqISjt2z1WN2EmIH8/w HMVc7wd2t1iaDBpb1cAfkbz9sl60nr46KtyRbq1DU65yVO4MzeGcU2BjkwuPpj547HeV O/1new8/bbj9rKaZAhXM1WELeJQxrrjFUr9O9kXasvjakflXzno0ady24940co0Sn5zK ojJKG7HOYRvg4FovCl/UNgYituDPBlY92UgFMRlBNfe/l5Mnx2XZs6Js/W1ZeFsPk0eK relGr1cx8vJ216y+xnpHxFs75EwRqoXHSGkh+hQrT5VJtHY3iI5Id9JkSjOsJhkDsoRC QOzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787179001; x=1787783801; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=t+v+TrmuSm8tbTgjN/7BMoAGViaZ7gsFOSCS4aqapDo=; b=sZW4S/p6AsHRvf78LxCoUv0P9ddMecbk2ybBjINu7nCRaWdR2HqEhhn6D33YOMH+LG nYtCqVBB7ruo3xA5w/jXgtSESRw0cug0JTkhLMvjvCziplrydJTVXUY8ayc6fWiOoiUk FdxFQ+Hysbr/EXEQgY7pQIaKWEe/5AIxcMQ/ndYvW+AUV3N+7Oijbkfs80EmUiBznIXk obzDxRcVNHNjyEnaJFqgX959rff6rLxY+gpwE0bb0lBQvIDZF87FdQ7OBZlFaOxXVuyx 0zrZk3FidWwcb6/jXkKgb3UcpR4S1+uWOQY0lS0n8DTJmDFGjquA+0W0DFlY7MZE9SCs kPMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787179001; x=1787783801; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :mime-version:x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to :cc:subject:date:message-id:reply-to:content-type; bh=t+v+TrmuSm8tbTgjN/7BMoAGViaZ7gsFOSCS4aqapDo=; b=bSm6TctEhdLFnneJBHE9XXMQQV4DZ357EvmliyAMagR7f43pvN4vm9WTCLnxq7CO/x Noc2BYu4D6D3vOwEvBbTd4IIb38Mf2gYakxkX4NOOvdquBQEwWE5abTJGb06rh442TWD H5pgb6e3UE9x39FaXiDU7Q7O97GcUBtfbsZfGk9CSZebKVi+XoSUUPVkSdmzRBRaYQN2 4NLAYnI+TP9nD6t4ZP709jvH3ubzN0/iy/bfzznbvt8sCdevSyP1UbmXkiyUz+kOAob4 bJ2Qr635CYlLl/G4hWh8AtCBJa25WPdzia5jjBae7vf61CwVXPrH/mhg4kvjVV09Pr/e fD0w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+RrDpZvR6tFN1tPTCTWETHQYDH9xEju+ztBmX1jvg0NhphHBEHt3BXOgAP0kWWEKDOGfBb2Rsg/xYtkf@gnusha.org X-Gm-Message-State: AOJu0YylmoIpka7FFcgSA1kz+xYnyiECvHJ50YuhkzO5qsMOjE0QgAJW dezW/ppTyn8vc8AeWAj23LWHQDBecpFBAFs4DEom/sELTWWI6RPoLaR3 X-Received: by 2002:a05:6870:e089:b0:457:8837:345c with SMTP id 586e51a60fabf-462f64bc3bemr8104119fac.1.1787179001265; Wed, 19 Aug 2026 15:36:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcXkueWCUCpfOMm/oPdFBW8oioI7gzRFE0fsAQnVgQVsQ==" Received: by 2002:a05:6870:d108:b0:456:5850:365e with SMTP id 586e51a60fabf-4631bd1fa0bls326894fac.0.-pod-prod-04-us; Wed, 19 Aug 2026 15:36:37 -0700 (PDT) X-Received: by 2002:a05:6808:19a5:b0:4b2:8dbf:1013 with SMTP id 5614622812f47-4b2bcb1bb9cmr7246789b6e.14.1787178997166; Wed, 19 Aug 2026 15:36:37 -0700 (PDT) Received: by 2002:ab3:5e03:0:b0:30f:146a:f654 with SMTP id a1c4a302cd1d6-30fa640664emsc7a; Wed, 19 Aug 2026 15:27:55 -0700 (PDT) X-Received: by 2002:a05:6512:3d04:b0:5b0:113d:8ad9 with SMTP id 2adb3069b0e04-5b478b8babemr2310730e87.12.1787178473428; Wed, 19 Aug 2026 15:27:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787178473; cv=pass; d=google.com; s=arc-20260327; b=ka+GULPvyqwKRmH82GfQn+OCuHnftLZe2BAh0yu0JCaZxXsfmqEMQ/T1fhZRPdwZ9W HyyFbhws5gHn1dA6KniyBBLZY7pz9fsV89ghPyk3b4st475ApvcKT/445BT1NsgFVANa CTkQbuMDUeCotoAtN3rxyjEq8HSN5wjB92yFbcvcA+nWaE7dQmgIJ6UDQIJdFP6pu1rj eyCeXBuogkfN9xMISvsqDaTPGNtq0qcIiWbVTQYkreO1r2qHuGvBwTMtj/1wr4sdsaAP qooVPDCr0DUp/iJ/llQr9MTJ4rWPfbAT2Zoup/60JjAbPvqqxta39NNLg6+RLZP57vyG mMEA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=9dR+2nHLsO5QrtihlOq4S6nkmu8rMLJuaV1Qpqz45b0=; fh=rkm3bHbFkkqaOCEhDYIrUdh+uNF0aEpt1sjHeEyiFh0=; b=S3AXPsp3h7ZY9q914Jnh0pcZAklq+SJcaxioP8tUTqabglV6QfzppFaFrtTYP5/gGp TzhinuZZPoNpHEEgRwBEdWHm78LslvpblineN96WbGslj6/bD0jAUK2X+NgM47nGpw1O 2azy3c5tN7MaypsLMFjIzVybxdkPNDSQQJXqXmX6tNfLYyGr2dN5JWlRvnwTH8dzeW11 BGPoNqzCt0odseXBFo35zGouAG9qJCvNw0CjCQNnci/IyYfea4YvUB8g0Dky15nnj+ll wQi0g3mDSbbXThQMdOqIqLU9Bu+QUqBD+/8AXUm2QvcwVS86PzumYquRWZ/f/sGNXGWO yK+Q==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=FRQAwzON; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com. [2a00:1450:4864:20::634]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5b47885bfb9si68711e87.2.2026.08.19.15.27.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2026 15:27:53 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) client-ip=2a00:1450:4864:20::634; Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-c16794450aeso222175466b.2 for ; Wed, 19 Aug 2026 15:27:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787178473; cv=none; d=google.com; s=arc-20260327; b=j9Q4ZtZrijOKYe5ks271bFdKgDZltRmFxT8EyzvAvtADiePk9L0CyXumZgiVAao6DG C5i9JFVcS7Z3R3SMzPzgmSPBnNJnShLZ6uXZ92QyFR+NV6+2D5jbjSsJddkBoSXX9V9O N5q5jCLbKYqa8hnnYKT42thm+7Dx2pCuvAFNrt9qcfZ7Rlw5vIU8UWconxYmPBwCRMA9 t+GvXgB8Qy/6pzs8P4yTE3eerbBN2XRqdGOxIsokRZctCfaDDJshEh6C5Xp0mhPlJlea /bUhB0N4OTgEFaT6vnT6S1qeF9d5AkTzsxgUsEtxJ1Ta8S0Bdt3iv7Eo2Bq/ko9+xuO0 dG8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=9dR+2nHLsO5QrtihlOq4S6nkmu8rMLJuaV1Qpqz45b0=; fh=rkm3bHbFkkqaOCEhDYIrUdh+uNF0aEpt1sjHeEyiFh0=; b=ma0glhz/RzKNni6goD3LHSla7FLEmmgGSvnOzHWTtpkWDfiRe5HlYs2sTg00BBwXQK lQbvczHnA9b17JOwWkuUOihfD+Xy/hKbCXTmQhHjjCKhWvTWN3d2vHsN9AEdhl80H6de 78JJds7PCpqskGYDPjWGpsuWcjzZR0Q6WzWLkVIf3rZt1KCTTOrPedYSVDHw5ynFILn4 LW4Ml91gGPqLyDgk1WPuIh2mkVVMIs1PRn5/asuYai4CMMmcRi5dc3OEMWrg3x/Vc1Pu +UNagG+93qiV+mj+K8dOpYyeIlJkup5mLC8cXxwz2dk3ORq5XSMY+aZw0h+98nyYOzMN T4QQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AR+sD13YfpCuM6wZGbGfMnk/GNAUz5oc1416BX3zl7TQq1cbcssZYyEB6Xf9E7WJtUS JMkfANWAeUR2i7nfGPtYYGEJfAK0WWMrHDsBFUDn8ic750sgPlzAfq1rHwRnQlKeKCk7rKEl9V7 eJxvZyz8lZHGVwPYT/zVgtR7RfWZs6gV7zoXPsUUo9AnIPt072qzibxrix+iZaqtDZob1If8u/R 4dguxqznLPswPNd4wvXnLv5QgxT1c2C1Qy17BH0bCiNFnyWKYb/yG8yywHe81Z+jPH6cdutaBX2 lg03ZrTGG74LyuHjeshdkqQFKu6oHoaSzPEJUBjgg4CLaBRPLkriGnk= X-Received: by 2002:a17:907:989:b0:c12:b2db:873d with SMTP id a640c23a62f3a-c23f935372bmr530745466b.5.1787178472448; Wed, 19 Aug 2026 15:27:52 -0700 (PDT) MIME-Version: 1.0 From: Antoine Riard Date: Wed, 19 Aug 2026 23:27:37 +0100 X-Gm-Features: AcwNN1VfaxZZYVGNeK71lzJR15ZMlH_pe3GynObzsXKLhlPpp-he1OuZ9IGV7oo Message-ID: Subject: [bitcoindev] post-quantum: solution ideas to "tripwire"game-theory issues + a certificate-based rescue protocol To: Bitcoin Development Mailing List Cc: btc@ariard.me Content-Type: multipart/alternative; boundary="000000000000002a3306596dea53" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=FRQAwzON; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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: -0.5 (/) --000000000000002a3306596dea53 Content-Type: text/plain; charset="UTF-8" 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. --000000000000002a3306596dea53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

In this post, I'm detailing (a) what cou= ld be a solution for
the game-theory difficulties of the "tripwire&= quot; NUMS point and
(b) a second solution for the exact same problem, r= elying 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 bi= t 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
com= promise the chain finality, among other attacks goals.

## A. NUMS Sp= end As a Proof of Equivalence of POW

One of the difficulty previousl= y raised with a PQ-flag
transaction based on a solution to the "tri= pwire" 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 effe= ct, as
according to Satoshi paper, the "majority decision is repres= ented
by the longest chain, which has the greatest proof-of-work
effo= rt invested in it".

If the coalition has a 51% advantage, or an= appromixative
amount of hashrate using other techniques, they can maint= ain
their advantage on what is getting in the chain. No one will
be a= ble to produce an equivalent amount of proof of _work_.

One way to a= lleviate the problem would be to consider the
spent of the NUMS point, t= hat can be a hardcoded value that
one can commit in a dedicated coinbase= output as a "proof of
work in itself" where the CheckProofOfW= Ork() 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= 9;s difficulty).

By introducing an ordering of the chain among netwo= rk 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 assum= ption of availing the majority of hashrate [1].

All network nodes sh= aring this consensus mechanism would follow
the new and same chain order= ing, overruling the most proof of
work ordering.

This approach st= ill raises some problem of its own, as it's one
thing to have a &quo= t;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, j= ust right there at the
corner to produce such a proof, if real-world qua= ntum computer
ever becomes a reality.

## B. Group Signatures of P= Q Upgraded Coins

An alternative solution not running in the same iss= ue 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 vari= ant of crystal-dilithium, falcon or whatever.

The idea is on the sam= e line than the one previously introduced,
a novel merkle tree of PQ &qu= ot;blessing" signatures could be added
in the commitment extension = structure of BIP141 (i.e in the
commitment hash of the coinbase output&#= 39;s commitment hash).

This group signature constituted of a merkle = tree of signatures
would be attach a "weight" based on the amo= unt 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 b= eing CRQC-resistant, as
a CRQC would not be able to forge a signature, w= ithout herself
or himself already availing some significant amount of co= ins. It
would be an "indirect oracle" that a CQRC might be act= ive and is
more robust than the community.

However, this mechanis= m, 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-st= ake majority meeting
the threshold deciding to activate the "tripwi= re" to alter the
conditions of spendability of numerous coins at th= eir advantage).

A two-phase commit "tripwire" protocol cou= ld be designed, where
the "tripwire" effect is only locked-in = (somehow in some analogy
with BIP9 mechanism), if the threshold is not &= quot;challenged" by another
economic group of coins owner during so= me period (e.g two to three
months).

## C. Chain Timestamped Cert= ificate of Discreet Log Knowledge

On the more technical problem of &= quot;what can do procrastinators coin
owners", one train of solutio= n in the line of the commit-reveal
protocol that has been previously dis= cussed would be to use the
chain itself as a publication space of discre= et 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, blurring the ability= of the coin
owner to prove she or he is the legitimate owner of the coi= ns,
EC cryptography being based on the knowledge of a discreet log.
<= br>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 o= wner 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> &l= t;sha256_hash> <signature>

Where the <signature> woul= d 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 c= ould be able to prove that her or him
*knew* the discreet log at some po= int in time of the bitcoin
blockchain. This knowledge could be leveraged= to allow the transfer
of the coins a posteriori of the "tripwire&q= uot; lock in function of
the post-quantum transition policy opt-ed in by= the coin owner.

One interesting aspect of this scheme is coin owner= s could start
for now building merkle tree of coin certificates and comm= it them
in the bip141 commitment structure, a magic number op_return or= an
annex, whatever even if the "proving" consensus logic is o= nly added
in an ulterior soft-fork.

The scheme is not bulletproof= , as we cannot have certainty, _if_ and
_when_ a CQRC will appear, howev= er in its simple logic it could be
done today (it's like open-timest= amp the marginal cost of a certificate
is very very low, the witness cos= t only being encumbered at spending).
This idea only to add more color o= n the painture pallet of the technical
optional to protect EC exposed co= ins.
=C2=A0
Cheers,
Antoine
OTS hash: a5a11d42e13724c04d44b953a= e5c5f0d152346a7e2041a0a966a62ef148f5ab7

[0]=C2=A0https://groups.google.com/g/b= itcoindev/c/DEfcMWSdQRY
[1] To facilitate P2P communication and disc= overy of this
bloc, the nVersion field of the header could commit to a b= it.

--
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/CALZpt%2BHRNFdtWUpg4v2aj9CRMamS7eG9Nem3mdxJq4sZEtOL6w%40ma= il.gmail.com.
--000000000000002a3306596dea53--