From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 26 Aug 2026 15:22:25 -0700 Received: from mail-ot1-f57.google.com ([209.85.210.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wzM0k-00086i-WF for bitcoindev@gnusha.org; Wed, 26 Aug 2026 15:22:25 -0700 Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-7e6b73b3920sf2056099a34.0 for ; Wed, 26 Aug 2026 15:22:22 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1787782937; cv=pass; d=google.com; s=arc-20260327; b=mwH/Hf36qvcDDKBlaKoDC3ArWKSqO8PFp7GutLD4J0usa+nNDN4ELvOgfgXJ3351iI giTBAsY5+tHAYyYN8Q8+XqUhHYeqypXY+LCGnBQkJyUmEebGomXehCrbjij5vOeQymd3 LmWQQuxA+ej/NKTQgoYxrXuvtUzlrXZSXiVLlWLpOFfcPNN11PUUfiMfPyAsDRXVfdJ/ IODHDt6AJSJGUB5T806y41Lu9EYEzjt8np7/8yDl3yTBOIoxghCZ/B4xFdHQQukPwKui qhiz+MuuoMahQKJC63+dIwlh1rWKfULmb+lMgiuVl4IYLcTjMiVfGKBTUqhU5+aUDl2t bD+w== 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 :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=Erx0Z6PDrb+tbWNzjL4Z7kcdD7o/NjbgsYI9nQeqQR8=; fh=jwhmQxTPVcxIcd1jcIcwHf5kusOWVxWhQsmXZWycUNM=; b=e0GnBjDR4WNjIf5alfHS7MxLnP8RLdN6RjxOuMwlxjk9tP5OYmnFNgqAvUvmcx9/c+ 8TBmB2YmXHAauW32O/EqfIwqxGZ7stONdpZCzDHwVZRYNaEobkLnZrfiWGMhad668VzK oUUEaUHGzQiGn7sQP8EzK+PjIUQ3sUnftXnB9SwGOo8nuUym/nDuU/r/Jdo+Lp62d8+L Lq73y3QlA3jslk7MIL0UeiTZ0FBYGDvdjtNABusPvLHxhBiDMdieZNLbue/jKV4c09Oe itWJ8VDhOLxjcfMLxfsofvm85t6WcvtC8Kjy8Am9r8+Ea/8YoEwSPOf2qBL1lslHfsS/ ntQQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=MLCJRMQa; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1029 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=1787782937; x=1788387737; 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 :in-reply-to:references:mime-version:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Erx0Z6PDrb+tbWNzjL4Z7kcdD7o/NjbgsYI9nQeqQR8=; b=xNmOVUui7F3UQpyHnyAV4JOqfpuIjsYSJLu3ozXHQhesTFqPOS3FxOJxhMjA7+/bZy hRFJ3OaRB2LP72qLroNmpcfuIGsNhoEFdRFBV8NPE7R0efSG7gVbxBSdbl06Hb00Y7wA Y1i747P4lJU5jUxnT1Lhxz4yGPms8l6sIhM3u7gwwq17G6tN+LA/iyT0YO7FzYfGuPGH S+JK2V7IuRJ8NHDz3TjgQPCBmMhhuFaoSdnq3PCYO9JD+CiBQ1tYJsMtwYQmIHpluHJN buuanlr3qM6FysVL9489ixRqB5zWdJwUB66ifZcNQofNGxhUkP/fjF3rpGhB8qJzkTWO Nn+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787782937; x=1788387737; 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 :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Erx0Z6PDrb+tbWNzjL4Z7kcdD7o/NjbgsYI9nQeqQR8=; b=Ot+Zs33gM0zjX+p5BXLe7uh75dHKvXpG686zqBs3E0ekBxgzeHXXAoEDZVhanvV8lQ h2NSGUrZNIVkwKe/221hREEnR0uc2AhaEm3KTp9zXBfrfvf0NTXhG7pSamv+gIczvlQm tpNx9TYTCUS8TiAS0aZPpMrDFBSVURLjSeN3rm/bNONFF9zcBpVF9IQL81aF3dRW1TQn Zp8S7hm368roJ0c9KOFcIpYAQKqQwYC3YvNKTnPLuhY7XjmjSpHj+E5JIdQ9HN5lZUI9 y+HBfM7gqeazm5hxBucg0F9VM3bvZydyjnsllVw9mvBgVXF9mMC/zA874l7WBzlxoUSC m/Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787782937; x=1788387737; 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 :in-reply-to:references:mime-version:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Erx0Z6PDrb+tbWNzjL4Z7kcdD7o/NjbgsYI9nQeqQR8=; b=Tt5l9hNT5GHAsB6Fc6idZWGzPB0L2nS3o1j75t/bDOcY207sk+HUVeqOQlBzTIcsmu z5n/Xc9y8/2MiBEFQAsEH6I1Aebh+UmLgsHak6usewDBjK3yXKb+TjuZjWmvsqWD+AnN KPcsoBXYo/nNkt7SfBaBgfX02jXr7BnWSfG5RqzesajuIGreQmXfYiJKcfga3mrRRh7X aQ4aCVI5yJtWMyRjNyfbuVQYPuv8tOzhXrb8Mz8kyadByqEfAmQjyxiSOYlL0t2Uld7k Ww7S1COo0MxAowrFL3HUff7gc3P2TM0FFTbxd7D4vTkgvT2dIxZ0M4D8C+CDRmwD+aFW tQXg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+Rqd6a/1Bn3bKqRV+flA+jCx5jw7SpkCe0bjTR/e2iyTZ2NhEgRYIrQIeRGLK2+cXPyt/lERPUNUSWdo@gnusha.org X-Gm-Message-State: AFuF++mG3ilDwzkSlaySyEYGM/xlr10blW6jL5RsH4oaONCI4pkocwn+ FUHMbJMMLOVfWzK+BLJ7DNVT1OZW7/CCfLcygh/VGCN9F21D2TAJrdLQ X-Received: by 2002:a05:6820:4de3:b0:6b0:44c8:daec with SMTP id 006d021491bc7-6b1ac589d2emr4614809eaf.25.1787782936856; Wed, 26 Aug 2026 15:22:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfLGiH7cIggZimbtdl+J+V1uysjzlQwaFIg68doc5AGSA==" Received: by 2002:a05:6871:e9d3:10b0:462:f6e1:1510 with SMTP id 586e51a60fabf-46713402f73ls108266fac.2.-pod-prod-04-us; Wed, 26 Aug 2026 15:22:12 -0700 (PDT) X-Received: by 2002:a05:6808:c164:b0:496:2b3:ae71 with SMTP id 5614622812f47-4b366b59758mr12086725b6e.18.1787782932839; Wed, 26 Aug 2026 15:22:12 -0700 (PDT) Received: by 2002:a05:690c:442a:b0:848:c909:19b5 with SMTP id 00721157ae682-85752b6bfadms7b3; Wed, 26 Aug 2026 14:55:13 -0700 (PDT) X-Received: by 2002:a05:690e:1182:b0:66c:85e3:7f1a with SMTP id 956f58d0204a3-66d25815694mr3419617d50.50.1787781312475; Wed, 26 Aug 2026 14:55:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787781312; cv=pass; d=google.com; s=arc-20260327; b=h6bb9PGl6WasEwMmOyn1RJ4vqc6II8Oz85Q4NpiHnFs00iQINix4AkvaynPf95tmLl jOQHnqsnzmyWxnRrSIS7IGCWskhKZ1rEBR19I+iUcnjiI9uaxdI7++HTgiUJgmbEZTHH w4ufKEi30HnnapI6JMWibQNaknv4z+UPkVWDSDeP75daAnW7PGrDZ2GQvN5nm9xwmSRU 46+bdUYYNDthSOReTkRb95e9hBy6TEY3LvyBdXMm0AyOc4o9ix5CmQjHDPGW7auDi7Bb tbmi1BFm+c2Be1wW/i9OfCgXck61Si5LhpbjAmM95nC6boiFgAtJVj5u5TW7DKg3PDxn 1qcA== 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:in-reply-to:references :mime-version:dkim-signature; bh=groUEvDZZoPreemM0ThAAyW4ltxchXhmzeYSg5ADN4Y=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=NGIwq8h/eZENU3NIkkIughEKCruEZGwIxoh2s006oBYDZ0H/cKoUDcXlnz2Ydl8T79 6IXXcGAAhJRVgUaz5anZa9uZrRMCSC2bfUbRqYuxHWycZNfpz3F2+tymLyf7wyM0NKnp hJNzdc5GZZDWB8EnIc21fCo3YQ5vAr92yJ5j/EST3uqjQvKfRqPTmJsRMAHmcBqLWKY4 tiOI83ixC8qcZwBx8/63wjAuIc8LBog6Gd6XWuDPHmGXWcGLxB0O4tvla56TLBaBQCpo 1ExBpVAK/0nbHaXj1kwzWmPoVfmTthT+4aT8a2whe4C4CuppsFcOM4TLEcS6dX2y8C71 PiAA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=MLCJRMQa; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1029 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-pj1-x1029.google.com (mail-pj1-x1029.google.com. [2607:f8b0:4864:20::1029]) by gmr-mx.google.com with ESMTPS id 956f58d0204a3-66d24545f50si119630d50.2.2026.08.26.14.55.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Aug 2026 14:55:12 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) client-ip=2607:f8b0:4864:20::1029; Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-39686abd426so1166517a91.1 for ; Wed, 26 Aug 2026 14:55:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787781311; cv=none; d=google.com; s=arc-20260327; b=qvVpPMPdsZjpUVWlRPoTeCqYVAn7pwfHVY/TMjZLYmFdbvN7D/hhDeGUA/YdFFW55V 0AdWYPuzotZznackQ6urZoQpr4olXaA29s7wprCgXkyDa3e/9fqcqEdX2osbiP88EH3c I0ZxAXMUfjP2sX+3TgcwuuCK+IjKFltZrGKi/oFbSljaoAorP52rekEeJB0coDyK+9n8 6hB2g6e5kJsqzyPRVo0CpqDXklDrS0ka6a7BZ9XjlK2/L61wEYs6jj7YvGyNgeYfaOe1 7ijdB60JzMHgpbiPI/JIDw7paHm7lBWphoGMOzVcbXdHIRcznTa1rYYObTbsdI+AnoVs T49g== 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:in-reply-to:references :mime-version:dkim-signature; bh=groUEvDZZoPreemM0ThAAyW4ltxchXhmzeYSg5ADN4Y=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=nd/KKe7k78heDbjfeRz31hhTZEEEELhU0hADFjO7a1ruRLAaXJZ70SDfIWIQy4wNUP j319z4SPhKd1H7r0hMQEU9SjCA7u5X8LWgfFDQ0cAxq1oxLgRP73xPkMMxJXGMToPEjO lP/3XP1g0I6OIaKMgMeyyqEVhq1ispB2ZcLVqkbNq+YIQgPgn9lGsIKdQfeh1IiiqTAQ 4S+JRjTRgQD3B6tFV3QAdoeX3IJ8cr+67XHa4UXggmXlRwxcairKHWmNg0XvgZwcOXEK 3hwdJrTYD9CC/ppl6Ur3Ffcqmrwmtk6v/tTAxgat1QkkeCTRrMHMXzIpMHDgYuPYCwl7 ivrQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AR+sD11IRNfXQKygIBwRQ0UmfOCtvWiFBt8KMCud+xPRQ76FwFDiEYds+FAIklYv9Q+ 39H74LPdftlolJB5GcbmMqz+bTpM/WybRHaLmdP7DCtyE3PHqDqpy+c5k4c4XSxxCP7PUXGOfPY Y17/yc3ZiRPL+v9OYQHqKfq278xLAmSazRishvPlfCl9oI3AYnYOX0DQpiGyZDWj3kEHoAyfD3r 3+7VKAedLqQG4gHhDEepG71O1gtGLJb/p0ZJxHbSMcRqI3SDNo63HmZTjftNuVYjfSKrqIu+8sH tQENgd2EQV0iJajj6bNnSumbB88FtvmbGxA2pxQs9GXagw== X-Received: by 2002:a17:90b:524a:b0:380:540:d499 with SMTP id 98e67ed59e1d1-3966d1ba7bbmr21797931a91.6.1787781311277; Wed, 26 Aug 2026 14:55:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Wed, 26 Aug 2026 22:54:59 +0100 X-Gm-Features: AcwNN1UI-s_R6s-txcp9D02996nQeMDGu_ekWuwkzaJYFq0cNc00DI9lhJEGilQ Message-ID: Subject: Re: [bitcoindev] post-quantum: solution ideas to "tripwire"game-theory issues + a certificate-based rescue protocol To: conduition Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000feaf380659fa459f" 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=MLCJRMQa; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1029 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 (/) --000000000000feaf380659fa459f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Conduition, > It's clever, but the main problem is that it's a hard fork, as you mentio= n 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 (>=3D 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 w= ell in-advance of the (undefined) fork date, as opposed to an emergency har= d 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 ge= nesis would be considered invalid!) or nodes that come online after sleeping a wh= ile (they'd reject the first new block after seeing the tripwire proof!) so the= re 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 soun= ds it can be resolved by having a good ordering of the soft-fork activation effec= t, where there would take effect at a clean transition block, and the "tripwir= e" proof can be just replayed after. Note, if we reorg of this depth back to genesis I believe we'll already hav= e issues far earlier with any buried soft-fork activation. > or even just having PQ-safe wallets, because if one can take the proactiv= e 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 tak= e proactive measure to pre-register, it's bitcoin and social convergence on consensus is never guaranteed. We have no guarantee that the community *will* converg= e 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=C3=BBt 2026 =C3=A0 17:33, conduition a= =C3=A9crit : > 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 4= x, > 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 mentio= n: > > 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 cryptograph= y > 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 thos= e > 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 resc= ue > protocol, or even just having PQ-safe wallets, because if one can take th= e > 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> > > > > 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 =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. > > 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: a5a11d42e13724c04d44b953ae5c5f0d152346a7e2041a0a966a62ef148f5ab= 7 > > [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%2BHRNFdtWUpg4v2aj9CRM= amS7eG9Nem3mdxJq4sZEtOL6w%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/= CALZpt%2BHKO%2B64J8EaRR-ih__aE%2Bj-uJAMq79%2BCPVKOvkw9V_Lyw%40mail.gmail.co= m. --000000000000feaf380659fa459f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
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 t=
he old
ordering mechanism. However, if there is a super-majority of the miners
running the new ordering mechanism (>=3D 95%), one can make the assumpti=
on
that non-upgraded nodes won't see that much further updates on the chai=
n.

Due to the proof-of-work "gravity", at some temporal point, non-u=
pgraded
nodes are going to start to select the chain including the "tripwire&q=
uot; 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-f=
orth. One way to
alleviate this would be some form of merge-mining where the "no-tripwi=
re"
chain's blocks could be replayed on the "tripwire" chain...th=
ough 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 "tripwir=
e"
proof, whatever the staged spending policy that is active by this proof.

> Granted, this would be a pre-scheduled hard-fork agreed upon presumabl=
y 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 t=
hat would be needed to reverse a hypothetical mass-quantum-theft event.=20

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 cryptogra=
phy
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=
=20
mechanisms to  be made more robust. Though I'm sharing the same worry t=
han
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 min=
er
collusion: Perhaps if we distinguish the set of "active" nodes, a=
nd 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". M=
aybe 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&#=
39;s
multi-staged soft-fork activation too.

> This obviously doesn't work for nodes doing IBD (the first block a=
fter genesis
would be considered invalid!) or nodes that come online after sleeping a wh=
ile
(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 synch=
ronized
node. Not sure how that'd work.

AFAICT, the problem you're mentioning would only appear transitively du=
ring the
soft-fork activation of new accouting rules for a "tripwire" proo=
f. It sounds it
can be resolved by having a good ordering of the soft-fork activation effec=
t,
where there would take effect at a clean transition block, and the "tr=
ipwire"
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 proac=
tive 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* converg=
e 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 custo=
m 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 u=
ser prior to Q-day (i.e. tripwire activation).=20

A rescue protocol still have to assume that the community will converge on =
a soft-fork
activation before a hypothetical Q-day.=20

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

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 &=
quot;tripwire"
proof is included in the chain. This would still require some secondary reg=
istered
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-li=
ke in the way
> commitments are opened. I'll open a new thread soon to discuss tha=
t :)

Cool, I'll have a look, using chain time as some sort of conveying info=
rmation is an interesting idea.

Best,
Antoine=20
OTS hash: 959e84871689e6ee1f8e19ae50727549164d6f2e881f5cef3a9fe3700c0e6f21<=
/font>

Le=C2=A0jeu. 20 ao=C3=BBt 2026 =C3=A0=C2= =A017:33, conduition <conduition= @proton.me> a =C3=A9crit=C2=A0:
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 retur= n true
for it and the nChainWork of the chain in whi= ch the NUMS spent
is included would get a bonus (e.g *20 = the last period's difficulty).

A very intere= sting idea! Essentially this gives a one-time difficulty advantage to miner= s 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 clever, but the main problem is that it's a hard fork, as = you mention:

All network no= des sharing this consensus mechanism would follow
the new = and same chain ordering, overruling the most proof of
wor= k ordering.

Nodes that don't upgrade would se= e the new "advantaged" block containing the tripwire proof as hav= ing an invalid PoW, and would reject it.

Granted, this would be a = pre-scheduled hard-fork agreed upon presumably well in-advance of the (unde= fined) fork date, as opposed to an emergency hard fork of the kind that spl= it 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 si= gnature constituted of a merkle tree of signatures
would b= e attach a "weight" based on the amount PQ signed for the<= /div>
coins, and if the "weight" is superior to some th= reshold, the
block attaching this special "one-= time" group signature would
a POW ordering bonu= s and the "tripwire" effect would be attached.

I think this would also b= e a hard fork for similar reasons.=C2=A0

=
Plus, as you mentioned, we would run the risk of a dishone= st minority colluding to trigger the fork early. I especially worry about c= orporate actors here, who now control a significant fraction of the supply = volume, and might have incentive to jump the gun and ossify bitcoin's c= ryptography 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 &= quot;if an active node has seen a tripwire proof, they must disregard any b= lockchain 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 firs= t block after genesis would be considered invalid!) or nodes that come onli= ne after sleeping a while (they'd reject the first new block after seei= ng 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 so= me ZK-proof of a PQ-safe scheme
a legitimate coin owner co= uld be able to prove that her or him
*knew* the disc= reet log at some point in time of the bitcoin
blockc= hain. This knowledge could be leveraged to allow the transfer
<= div>of the coins a posteriori of the "tripwire" lock in fun= ction of
the post-quantum transition policy opt-ed in by t= he coin owner.

<= div>Are you describing this as a rescue protocol, or a pre-registration pro= tocol? Pre-registration protocols aren't that useful if we have a rescu= e protocol, or even just having PQ-safe wallets, because if one can take th= e 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 mus= t assume zero action from the user prior to Q-day (i.e. tripwire activation= ).=C2=A0

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

<1-byte c= ertificate version> <opt-in tripwire lock> <sha256_hash> <= ;signature>

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

The scheme is not bulletproof, as we c= annot 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 spe= nding).
This idea only to add more color on the pain= ture pallet of the technical
optional to protect EC = exposed coins.

This sounds similar to my own=C2=A0proposal,=C2=A0DropKick, which is also OT= S-like in the way commitments are opened. I'll open a new thread soon t= o 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 &qu= ot;tripwire" NUMS point and
(b) a second solution for the exact sam= e problem, relying on
different assumptions and (c) a variant of a commi= t/reveal
rescue protocol for EC coins based on the strict ordering ofthe bitcoin blockchain.

Most of the ideas are "rough" (an= d 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) aimi= ng to
compromise the chain finality, among other attacks goals.

#= # A. NUMS Spend As a Proof of Equivalence of POW

One of the difficul= ty previously raised with a PQ-flag
transaction based on a solution to t= he "tripwire" is the risk
of "tx-withold" being coor= dinated by a majority coalition of
miners eager to exploit EC coins in c= oordination with a CQRC [0].

There are able to dictate what is the c= hain state, of which
the "tripwire" spend must included it to = trigger effect, as
according to Satoshi paper, the "majority decisi= on is represented
by the longest chain, which has the greatest proof-of-= work
effort invested in it".

If the coalition has a 51% adva= ntage, or an appromixative
amount of hashrate using other techniques, th= ey 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 N= UMS point, that can be a hardcoded value that
one can commit in a dedica= ted coinbase output as a "proof of
work in itself" where the C= heckProofOfWOrk() would return true
for it and the nChainWork of the cha= in in which the NUMS spent
is included would get a bonus (e.g *20 the la= st 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
ac= tivation of the effect of the NUMS spent, whatever they are,
is removed = of the assumption of availing the majority of hashrate [1].

All netw= ork 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-capab= le entity, just right there at the
corner to produce such a proof, if re= al-world quantum computer
ever becomes a reality.

## B. Group Sig= natures 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 i= s on the same line than the one previously introduced,
a novel merkle tr= ee of PQ "blessing" signatures could be added
in the commitmen= t extension structure of BIP141 (i.e in the
commitment hash of the coinb= ase output's commitment hash).

This group signature constituted = of a merkle tree of signatures
would be attach a "weight" base= d on the amount PQ signed for the
coins, and if the "weight" = is superior to some threshold, the
block attaching this special "on= e-time" group signature would
a POW ordering bonus and the "tr= ipwire" effect would be attached.

This scheme comes with the ad= vantage 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, t= his 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 onl= y locked-in (somehow in some analogy
with BIP9 mechanism), if the thresh= old is not "challenged" by another
economic group of coins own= er during some period (e.g two to three
months).

## C. Chain Time= stamped Certificate of Discreet Log Knowledge

On the more technical = problem of "what can do procrastinators coin
owners", one trai= n of solution in the line of the commit-reveal
protocol that has been pr= eviously discussed would be to use the
chain itself as a publication spa= ce of discreet log ownerships.

The problem with a CRQC it's enab= ling 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 owne= r of the coins,
EC cryptography being based on the knowledge of a discre= et log.

While once a CRQC appears in the wild, it is not possible an= ymore
to assume that anyone in knowledge of the discreet log is the
= legitimate owner of the coin, a proof of "knowledge anteriority"<= br>could be able to break the tie in multiple transactions claiming
to b= e 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 <signat= ure> would commit to all the fields of the
certificates.

By le= veraging 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 lo= g 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 &quo= t;tripwire" lock in function of
the post-quantum transition policy = opt-ed in by the coin owner.

One interesting aspect of this scheme i= s coin owners could start
for now building merkle tree of coin certifica= tes and commit them
in the bip141 commitment structure, a magic number = op_return or an
annex, whatever even if the "proving" consensu= s 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 a= ppear, 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 E= C exposed coins.

Cheers,
Antoine
OTS hash: a5a11d42e13724c04d= 44b953ae5c5f0d152346a7e2041a0a966a62ef148f5ab7

[0] https://groups.= google.com/g/bitcoindev/c/DEfcMWSdQRY
[1] To facilitate P2P communic= ation 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 &= quot;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/CALZpt%2BH= RNFdtWUpg4v2aj9CRMamS7eG9Nem3mdxJq4sZEtOL6w%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/CALZpt%2BHKO%2B64J8EaRR-ih__aE%2Bj-uJAMq79%2BCPVKOvk= w9V_Lyw%40mail.gmail.com.
--000000000000feaf380659fa459f--