From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 26 Jul 2026 16:53:13 -0700 Received: from mail-ot1-f59.google.com ([209.85.210.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wo8ed-0004tt-6j for bitcoindev@gnusha.org; Sun, 26 Jul 2026 16:53:13 -0700 Received: by mail-ot1-f59.google.com with SMTP id 46e09a7af769-7e9fa2cd5c9sf3442999a34.2 for ; Sun, 26 Jul 2026 16:53:10 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1785109984; cv=pass; d=google.com; s=arc-20260327; b=F15QIchKs9vKeCWOoIEBlMT9wXYo8c6sA7hJN6s0PUHcj7vrc2DZqBYKqwPNrtDFRY rdot4EKttNmG1XRWj8BbPGDv2PGJurgBMvi63H0xU+nxG7mHTCzK9mNGLu/CjqwqXUGM XwV0p+UoWUp7jGut/4mqytHh5zYRiJr6j6uErZo1hvNeL7v9N2Bd88sy6n4wIF2k+v5B QM4wXCK56hMZv8ye6BqO8D668py6prG227eszj7/TRLg2ZHhvJhQLbjCqBlyBYJbXcr8 NTl9HkQB/I/R4XW24JwJ1LCNLjChugWCwUheyMz0KNAWvbRZbQGUBaDwOgAnkzbTM+gv e7Fw== 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=SzObonAJPrsL+ZnyGslAyqDhHm5E3wRueGlOvGjgPo0=; fh=X4TV5sNJItZuudPNxcKUi0MgvZ64wQU277f0GUOTKSY=; b=pBUC9zdrsDSPMhNMlINRD/9gQKK2n7ZuQmB7dnz+3A9LZ+r2jV1XG9dheuDTUlvVHR SR0eMlyTeBPDhmdg70s7Xmq25kc0waFOFkPgfWfK6GhnNz3i8Yqfr04Hy/XMJ9neb2Zw 69NcdsrvaL394KEgkAp4B+/qfYJOhim9o0+1nUu2W3BoToaGoDyPSKy1GmhSPrAJRnKF s6+X/Tz9hZRmQrHf0TMUo97gvGmCZdsNGcYe0jSCRFwbomvrm0yEcxKflafqLv0mVwt6 GXLPcVafrK3cVrbd10+9TlZeXhpFGziXkR2g9J6ZB2ciRdbAPUxa9qGBLXaspupMJIkK KsQw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=s1IkWY4F; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1033 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=1785109984; x=1785714784; 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=SzObonAJPrsL+ZnyGslAyqDhHm5E3wRueGlOvGjgPo0=; b=mHWHnqU6SfI4xhIKbQXMEK++dQ8X1GOEjVSbqiJCSxjHbSj3DXUytml+1xsLCF3HVQ eHDPOfERGGgptv0C98dBJP5k3EMrbhk7lUO+M++lASUmwUnJRQhG78RS6Q6tCl1PMBnW xaW4zjlVidEIMckJvBuQ5O4vaizH7GYlowxRT3lgdswPbTru5QFAmzy6Kr6paaGHvHc9 7pEFyIbysAVfUtQ0YNAT+jbDKemxlo1JO3osdVbOvVEOt2i6zh2QcjN7Lx107MtLcgfP sEgV2Ze/rxQc/Wa+OgJZIGQq5zT+gpxdSwNDPaw+M6roL5xyKQC6VTQGWCOEHbKw2Sob jLbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785109984; x=1785714784; 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=SzObonAJPrsL+ZnyGslAyqDhHm5E3wRueGlOvGjgPo0=; b=eX2OPpwD+21VA0oHGFz4ciqDq5265WD4U65Ep6SnqvYNwEhZGSeDPSy2V1YItmz3dX ZA/L+qoVwmfZEcJYyn2rtgn8y+dteZWOV9bFHSp0uQa1RbQouXTUS1KvvX4VgYnlPJlh k5M47Wz/ah9E/7x4rWVtTJIld3fSFRKrO3FEB3kSk5G0P0xQ8GhVMqAGtxT9MXg0ahja 80QwrFpb6emsaMq1smJVa/CsrfowuMG1gWCJMf3GT6kf+VUN5OjL207jXCxQeTS2OKLT jHfFYqn7D6k7Drtk+jmQR4Cu0pN4UcK2klcnEfFhqEd9WPWn8uTpNBmSM6/KjmOG6YPb mxoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785109984; x=1785714784; 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=SzObonAJPrsL+ZnyGslAyqDhHm5E3wRueGlOvGjgPo0=; b=TWG+/CKb27mwUEuwP0mpVMWT7E8JmCOWFobLVYDSeEFeyNArhOyK4VEZ0PTdfhXoIi x1EDwiuAsf4EXzE91nRctrWYQH1v5/VRDvBpqeFDudSUlcuSrpDH400ZoSw7w8BqM4as UJwXsHxa8dE/P9boDjLBSWzWnD42Ou4/WXF3/oy5k1v7YfnJUVcght7rg4HrmT9UYWtM Mir8BdEPDQYDNYIEVneagoKzQjv2+SHx09YksIUXtNsh/8iGHXfYNUI5CWSP8g3Znq2B rdMqz3kiFjxf2esU6e7laz8hHkkj6PgDtveXmpGY4WFNZanZmaqTuJ6Eii6pa1dnQBqH yvqw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+Rpi1DINOp/aFjVqmm+5KMD7HKP/KyxqTmlHaPiuGFNUMZtAld9Cfn93bEPBp96Jg6BpX27x7Np8cRqS@gnusha.org X-Gm-Message-State: AOJu0YwfHuPXqaMMDn3DxWghLr0Kohc05rYcaFSt8QZDGaMJy/FEuE3X yuLk5245BcHz9WmuoOCPbb7aHc6F8gEmWj/9yE3Ena81OweTtwG6vdXs X-Received: by 2002:a05:6820:f008:b0:6aa:e663:93fb with SMTP id 006d021491bc7-6aaff3dc478mr4870421eaf.0.1785109984056; Sun, 26 Jul 2026 16:53:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSiZsekMdg9kPTToCVLrekn+BAsucj7si5yC4GsZ6jQmw==" Received: by 2002:a05:6871:787:b0:456:d5f3:3538 with SMTP id 586e51a60fabf-4579d55fe48ls2315476fac.0.-pod-prod-03-us; Sun, 26 Jul 2026 16:52:57 -0700 (PDT) X-Received: by 2002:a05:6808:30a7:b0:4a4:933:b1a1 with SMTP id 5614622812f47-4ab6a3c842fmr6917262b6e.43.1785109977449; Sun, 26 Jul 2026 16:52:57 -0700 (PDT) Received: by 2002:a05:620a:a:b0:92e:8185:68ce with SMTP id af79cd13be357-93103efcf1fms85a; Sun, 26 Jul 2026 16:46:11 -0700 (PDT) X-Received: by 2002:a05:620a:1713:b0:92b:67e6:4b73 with SMTP id af79cd13be357-932df6c46f7mr601696685a.74.1785109570297; Sun, 26 Jul 2026 16:46:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1785109570; cv=pass; d=google.com; s=arc-20260327; b=fGu6VdbsKr2AbsQFu7GbcY/RvCJFDtRvfev+0ZtyMKwp9AnM/ASDOWSmZBltDjYWJc N0ytgRaCMcrG5SoMeBmiS4KBlFjZatmDJyHiHpPShgxXYdliar7MJRQrMxu7Ng3xg+gA xhI7/05yhqs8WuKJfI558RJqnlpCm61ZMxWNNkL+il24y+H74QjNGXqyfD8r7ngGPxKf dBIYOC9xu03tLG3M2b1Vj9l5nWUDsGPptHM87uwBvtbG0RUTwWA4WlNtgBtqxzZhAzBk 3hSVqQbk+4n7QkG6M9f5rW+SkgyXcPJYXUeVT5b8X1zZxPSyvp31++h67f3u5Leo1MQG EBtQ== 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=TxFs/xSWvCtIMwmYmae4Q0ce0iKmEu7vtFAAkhZlI4w=; fh=0bHi84FqC3bFvg3OktzXjkdMydAZphkE09vTPgIsHrE=; b=ddrxYp0Bfk7gAH56SEiKyNRFHRC7+wwqKkGdAHbChLiw3JERrHDspe01hIT/AhmaW4 vDmGxrI790thh4E6tyxbZ4IdFGWwbkwlzuLnwI2Aecsj9M4Na9ErCaObwVKtNSCLkBfb WPMAUgueGNwtJoaYbPpVcf11Uzkp8OZSh/kCai/pjEEHHPciQaAKU8Ko7LvIO9WlnVHW eG2NVOCaBkerUyyaen9tK9O7J22tZklLGEITZTuH7ZjFE5Rsz6rZ2Cs/hiIuI/DI+RI/ oevCEYgHsJGOLpyl5DWv8iH1mWINpRl2ToqrvmocC9GZetY9HFgovDP6WSbgBaoNgPz3 O1aQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=s1IkWY4F; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1033 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-x1033.google.com (mail-pj1-x1033.google.com. [2607:f8b0:4864:20::1033]) by gmr-mx.google.com with ESMTPS id af79cd13be357-932de64d173si16418685a.7.2026.07.26.16.46.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jul 2026 16:46:10 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) client-ip=2607:f8b0:4864:20::1033; Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-3811f512167so1941188a91.3 for ; Sun, 26 Jul 2026 16:46:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785109569; cv=none; d=google.com; s=arc-20260327; b=iytLYET4zKO4bn3t6haSqyAGKXXqrhcgO4Rao67RBXQvDpVpfI17tfd9HIX69pyEl3 +o4hGe1ISQ9GMNFx+5K2eP5vsrUWOt/fYL87nH4q3eiGy1JBLcScF8fZbpRcVSkVkv96 8GipM5PF/ehH9oSLDGw45sNtid1Y9xLLP4fEQclEUcuefZDCWhNn2nDnbr9AO3MdLsNe Z1WJBlHqmIWFf4E2RSKcAOS2oH8Wf9A8meIyK1kS1mZICWfp3pDsm413fIAKEI6Jehpf OAWjg/cJdTUeoVwIckQanMntXDGsME4chaNEu1tQpwAL/u1XyEhB48NvnoNx+omIPysR M03w== 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=TxFs/xSWvCtIMwmYmae4Q0ce0iKmEu7vtFAAkhZlI4w=; fh=0bHi84FqC3bFvg3OktzXjkdMydAZphkE09vTPgIsHrE=; b=AsYi6Wb0Pxd8bkwK90ibRPtSzumwQ7jOwSi44GJhvIy6dow/37KrRmANN2gU4fQhCj gUMmWX6DHw+wDfxqD4yhpXtSZPS8oPX6q5RNqCniexYfEC/CqJ7AFLSGMv8/SeQV//hG 0AcI606zFU8WAuAbM+QRYDG7iYup9Kd1m6tXkWrR8no+o9sJJAillepxs904wzxaxPjz VRcOfyNf6oshkXI43e1JKjdLsGjs9w87KtMmpf8EGlsHxhtwvIUo/tSqx4fYI/uxyESK 2h1crVnHRUf7CdT1Pf/k1RKGLThX1nPvl/OPqb/0TvK1Bxql2GUODVtOXf/w977+lmpm 91+Q==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AR+sD11XsvoVb4n3FODdMT+37v2cnI0qkdXHY5Mnr3o4XzKA243iaXsv6TRl81VMwXH 3BKDhWEWOssIeSvxpxiGV/UOJr8vcruekYqSgBxHYgaLvjP3u07JSToIWEZDJqN7x9bz95ppxWa qUyyPR9St1ZNTfwaBtt8EbYiNh1y1FUK+z72CHd3ASEiCUPiR5nA60a/HV64ZAtyYokWFT9opY6 65HVdtjxc7xEuwSLZnhmbTFMIOr9dlr+eW6X0FKkuWLQcvYcH1PXtlMzqFz X-Received: by 2002:a05:6a21:7002:b0:3c3:7ac4:dac0 with SMTP id adf61e73a8af0-3c67dae969dmr5730102637.13.1785109569024; Sun, 26 Jul 2026 16:46:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 27 Jul 2026 00:45:57 +0100 X-Gm-Features: AUfX_mwWklxWheRC7q-BcUNc2RgOpHgcfI5WAqOhRjMFQBombzhHkBq42GL5WzA Message-ID: Subject: Re: [bitcoindev] The game-theory problems of PQ sunsetting modes To: conduition Cc: Bitcoin Development Mailing List , btc@ariard.me Content-Type: multipart/alternative; boundary="000000000000bf357806578c3589" 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=s1IkWY4F; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1033 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 (/) --000000000000bf357806578c3589 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Conduition, > Solid analysis Antoine. However things play out here, activating a PQ sunset fork of any kind while in the company of a CRQC is apparently quite hard to do right without setting the incentives up such that they sabotage the whole effort. That's the insight that my post aims to underscore, effectively that activating a PQ sunset fork of any kind might be very hard in the presence of one or more company with a CQRC, at the very least there is a lot of uncertainty due to the incentives. You're correct that the problem appears as soon as you have a company with one CRQC, where it can just go really deep in the history of the chain. As soon as you start to have two CRQC, there is an advantage to burn more EC coins in fees, to reorg to your advantage, so we're back with some notion of chain finality. See more comments on rough ideas to alleviate the issue. > Very neat observation. For such a rollback to occur, the miners would have to cooperatively elect to stop mining the more mature ("authentic") chain, where users have already migrated/forked, and instead start mining on an old block (the "revisionist" chain). Any resources they spend on this mining will have no payoff until the cumulative proof-of-work of the revisionist chain surpasses that of the authentic chain. Until then, honest validator nodes will simply sit idle. Roughly in what you're describing yes. If you're a miner, I think you can play even more sneaky chain games on what you're mentioning about ressources. Let's say you're gaining "coins" on the "authentic" chain, and after the 100 blocks maturity rule, you immediately short them on the market to reinvest your proceedings in the energy cost of the "revisionist" chain (or do a mining halt, as not mining might give an advantage to the "revisionist" chain). You're a miner, if the "authentic" chain wins, that's fine you're already re-sell the matured coin. If the "revisionist" chain wins, you got new fresh coinbase on the "revisionist" chain i.e a double-spend, plus any CQRC "bounty" coming from the exploited coins. I think there is some "mining silent reorg" advantage here. > Due to the vast incentive towards colluding with the CRQC, maybe this would be feasible for some large miners? > > This would essentially be a massive double-spend attack as well, since miners who successfully roll back the blockchain in this way would be reorging their own mining earnings out of existence, some of which they presumably sold (on the authentic chain) to pay for electricity. This might make the exchanges they sold the coins to extremely unhappy: The miners are effectively retconning their own deposits. See my point above, they're only limited by the 100 block maturity rules. Yes, miners would start to be unable to settle "fresh" coins, but also "old" coins (both EC and PQ), as they are at risk of being roll back (at least fo= r the ones who are weeks recent). > For this to happen, miners must be able to withstand significant capex (on mining a revisionist chain), while being blackballed by exchanges, and possibly also devaluing the very coins they were bribed with by the CRQC. And even then, it's not clear how - assuming they were able to pull the attack off and remain solvent - the miners would actually use the ill-gotten coins, and whether they'd have any value on the other side of a successful deep reorg attack. One of the point of the analysis, they might be able to fund their capex, with the exploited coins, if they can get liquidity for them on the exchanges. On the other hand, as long as they're economically solvent, they can keep the EC-exploited coins, until some far future, when the market price them at an interesting price enough, and slowly and covertly sell them out of their balance sheet by then. > Still, for shallow reorgs (a few blocks) this seems like a worthwhile concern that seriously hampers any tripwire attempts. The best case is if we can deploy the EC disabling fork before such tempting incentives enter the field of play. A naive tripwire (there might be more secure design worthy to think more about it), of course sounds it will be always at risk of being keep out of the chain by miners. Even the "we move fast and try to disable EC", assuming it's philosophically acceptable by the community, and I'm among the one disagreeing to do so, as I pointed out in my previous post, the stack of "lost" EC coins might be worth 10 years of bitcoins, that's a lot of reorg budget. So in the hypothesis, you have a "sunset" activation, then 3 months after a CRQC getting out of the box, there is a lot of incentives uncertainty. Even worst, there is even a "Lorentz effect", where the public and well-known "sunset" activation, incentives "advanced adversaries" to reveal the CRQC they were keeping sleeping in the backyard, as they know after the activation the cost structure is altered. I'm thinking there are other solutions that we have not explored yet such a= s PQ-blessed periodic checkpoints. E.g, let's say that every month, by consensus rule, there is a checkpoint published that needs to be finalized e.g being signed by more than % of PQ-safe pubkeys (e.g %1 of the overall coins). As those pubkeys are PQ-safe, they cannot be forged by a CRQC, and a mining coalition would not be able to go deeper than this checkpoint height, capping up the maximum of EC-unsafe coins that could be used as reorg budget. Of course, that would ask for a number of stakeholders in the ecosystem to have online keys for the "checkpoint" finalization, though that % can be kept low [0] [1]. It's just a "rough idea", as somehow it's re-introducing a form of checkpoint (which is meehhhh...but not worse than the sun setting ideas imho). I think there are more imaginative ideas that we can come up on the design table to alleviate the risk of a CQRC acting in coordination with a mining coalition. Notwithstanding the ultimate direction taken, the first primitive that would need it to give us more design flexibility would be the PQ-safe signing algorithm, be it Falcon, SkiSign or whatever. Best, Antoine OTS hash: bdb435e6c81eb762bb6a12a03e2c23a83396a3481b8894af79732c2e2b569682 [0] This also let the door open for a EC coins owner, of which the pubkey has not been revealed e.g P2TR to exfiltrate their old coins towards safer one. [1] The checkpoint would have to be carefully designed to avoid being tampered by a miner, e.g a PQ-signed checkpoint would gain a proof-of-work bonus discount ? I'm already far in the territory of heretical consensus design ideas... Le dim. 19 juil. 2026 =C3=A0 23:02, conduition a =C3= =A9crit : > Solid analysis Antoine. However things play out here, activating a PQ > sunset fork of any kind *while in the company of a CRQC* is apparently > quite hard to do right without setting the incentives up such that they > sabotage the whole effort. > > If a CQRC entity is able to build a coalition with a 51% majority of > miners, the "upgraded > PQ safe" coins might be also at risk [4]. Indeed, such malicious coalitio= n > could just roll-back the chain state back to the migration height of > said coin, solve the DL for this coin and unroll back forward the chain. > > I do not believe that the old chain history would be safe from deep > reorgs attacks by CQRC capable entities, as soft-fork deployments are > "height-based" burnt and not "hash-based" burnt (BIP90). Checkpoints > have been removed from the latest bitcoind versions. Maybe user-activated > checkpoints or other similar mechanisms might be a more robust defense > against CQRC entities attacking the chain finality. > > > Very neat observation. For such a rollback to occur, the miners would hav= e > to cooperatively elect to stop mining the more mature ("authentic") chain= , > where users have already migrated/forked, and instead start mining on an > old block (the "revisionist" chain). Any resources they spend on this > mining will have no payoff until the cumulative proof-of-work of the > revisionist chain surpasses that of the authentic chain. Until then, hone= st > validator nodes will simply sit idle. > > Due to the vast incentive towards colluding with the CRQC, maybe this > would be feasible for some large miners? > > This would essentially be a massive double-spend attack as well, since > miners who successfully roll back the blockchain in this way would be > reorging their own mining earnings out of existence, some of which they > presumably sold (on the authentic chain) to pay for electricity. This mig= ht > make the exchanges they sold the coins to extremely unhappy: The miners a= re > effectively retconning their own deposits. > > For this to happen, miners must be able to withstand significant capex (o= n > mining a revisionist chain), while being blackballed by exchanges, and > possibly also devaluing the very coins they were bribed with by the CRQC. > And even then, it's not clear how - assuming they were able to pull the > attack off and remain solvent - the miners would actually *use* the > ill-gotten coins, and whether they'd have any value on the other side of = a > successful deep reorg attack. > > Still, for shallow reorgs (a few blocks) this seems like a worthwhile > concern that seriously hampers any tripwire attempts. The best case is if > we can deploy the EC disabling fork *before* such tempting incentives > enter the field of play. > > regards, > conduition > On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard < > antoine.riard@gmail.com> wrote: > > Hi list, > > In this post, I'm extending on the game-theory problems > underscored for my answer to [ ] to other post-quantum > sunsetting scenarios previously mentioned on this list. > > Firstly, let's remember the "tripwire" idea [0]. With the > "tripwire", if I understand it correctly we introduce a > consensus level proof of quantum computers e.g with a NUMS > puzzle. > > This NUMS is committed in a honeypot UTXO let's say with > some non-null bitcoin reward to unlock it. When the NUMS > point is solved by a QC entity, it automatically triggers > a "freeze" of all the "legacy" coins starting at some block > height-defined window in the future. > > While it appears feasible engineering-wise, the problem > is more on the game-theory plane of analysis. As it was > previously noted by another commentator than me [1], why > an economically-rational CRQC entity would go to trigger > such an evident "honeypot" UTXO depriving it from further > (covert) extractions of the legacy coins to a safe wallet > owned by this entity. > > A more sophisticated scenario, that I was laying out more > recently, a 51% majority coalition of miners could coordinate > with a CRQC entity to censor the transaction inclusion of any > PQ proof, even an inclusion attempt of a PQ proof generated by > an honest PQ entity [2]. > > Exposing again the economic analysis, a year of mining income > is evaluated at around $20B. The number of legacy P2Pk coins > is evaluated to be around 1.7 M of coins or as of today $107B. > If we go to account the numbers of "coin loss", the estimated > number can be more around 3-4 M, so let's say $215B worth of > target coins (a coin lost to you is not a coin lost to a CRQC > entity...). > > That's something like ~10 years of potential income, that an > economically rational miner might not refuse if a miner has > a credible odd of capturing a share of this magic income to > the prorata of their hashrate capabilities [3]. > > If we assume a PQ coin extraction game with 2 CQRC entities > availing roughly the same capabilities, they might compete for > the majority hashrate of the miners, those miners solely driven > by economic incentives. The focal point of equilibrium between > the two strategies is likely going to be the marginal energy cost > to run a CQRC, assuming that in a fee race a CQRC entity can > offer to the majority of miners to burn more of a coin value > as reorg fee. > > Secondly, for the second approach of sunsetting, the one very roughly > described in BIP361 and based on pure "flag-day" activation, the > security analysis can extend to this approach too. Even assuming > a week-long period for a BIP9-like activation mechanism, a coalition > of miners might stil go to reorg in depth the chain before the > activation of said soft-fork. > > Such an approach is only theoretically increasing the coordination cost > (and one would observe the asymmetry of information is selecting a time > horizon period, as a CRQC might appear at any time during this period). > > One can observe that the 2 sunsetting approach, be it "tripwire" or > "flag-day" approaches are introducing a "choke point" to the chain > finality, > as in the lack of it a CQRC entity might covertly exfiltrate "legacy" > coins, > with no knowledge of the miners, or even without coordination with them. > > After the "choke point", a CQRC entity might alter its strategy of going > overt and start to offer fee bounties to reorg the chain as it's advantag= e > to the majority of miners (to not loss an exploitation advantage to anoth= er > CQRC entity). > > Finally, in this analysis we're only underscoring the risk of "legacy" > coins, i.e coins that would have not upgraded to a PQ safe format, after > some time horizon. However, in the Bitcoin blockchain world, time is > relative, or rather only thermodynamically convergent. If a CQRC entity > is able to build a coalition with a 51% majority of miners, the "upgraded > PQ safe" coins might be also at risk [4]. Indeed, such malicious coalitio= n > could just roll-back the chain state back to the migration height of > said coin, solve the DL for this coin and unroll back forward the chain. > > I do not believe that the old chain history would be safe from deep > reorgs attacks by CQRC capable entities, as soft-fork deployments are > "height-based" burnt and not "hash-based" burnt (BIP90). Checkpoints > have been removed from the latest bitcoind versions. Maybe user-activated > checkpoints or other similar mechanisms might be a more robust defense > against CQRC entities attacking the chain finality. > > Current bitcoin mining process and the chain finality is assumed to be > reasonably secure under the Gambler's Ruin Problem and some other > assumptions > (e.g a reliable network to relay the blocks). It might be considered that > the introduction of CQRC computers might not be only a risk for the > "legacy" > coins, though far more concerning for the chain finality itself. > > Independently of being philosophically "pro" or "contra" in freezing > legacy coins, I do believe the irruption of one or more CQRC entities > and the potential of disruptions on the Bitcoin network stability is > a subject deserving a bit more research and more work from the developmen= t > community [5]. > > Cheers, > Antoine > OTS hash: 496d9c26c6f3d805dae88f487600f46990572fc84c4ca907fb85b5441c235cf= 3 > > [0] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ > [1] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ > [2] One might consider the following realistic scenario, it > might that even if a CRQC become relevant, at first it will > be only operated by big companies let's say in the US or China > and they will prefer to keep the existence of such capabilities > hidden for a while for non-economical reasons. > Suddenly, one of the actor starts to use those post-quantum > capabilities and the social equilibrium does not hold anymore > with impactful second-order implications for the Bitcoin ecosystem. > [3] On the low time incentive miner hypothesis, one can empirically > observe (as of June '26) than it has limits given how fast are ready > mainstream mining companies to reallocate their data centers and > sources of energies to more generic high-performance computations > rather than SHA256 hashing. > [4] For the degree of scientificity of "game-theory" in itself, I can > only forward the reader to the "Formulation of the Economic Problem" > chapter in the "Theory of Games and Economic Behavior" book from Von > Neumann & Morgenstern, 1944 > [5] As quantum raises a number of skeptical eyebrows in the community, > the first elaboration of quantum physics have been as old as the 30's, > and so far no one has got a Nobel Prize, or any other major scientific > prize to prove the physical impossibility of a large-scale quantum comput= er > > -- > 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%2BFOUJF3E7YDk5xh-Cv9k= xduGiuOPVK5x171%3D25C3ryJPQ%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%2BEjD5h9387diQvwtUY9nV-GFgN-Ukp9tY%3DuqBofb-w7Tg%40mail.gmail.com. --000000000000bf357806578c3589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Conduition,

> Solid analysis Antoine. Howe= ver things play out here, activating a PQ sunset fork of any kind while in = the company of a CRQC is apparently quite hard to do right without setting = the incentives up such that they sabotage the whole effort.

That= 9;s the insight that my post aims to underscore, effectively
that activa= ting a PQ sunset fork of any kind might be very hard
in the presence of = one or more company with a CQRC, at the very
least there is a lot of unc= ertainty due to the incentives.

You're correct that the problem = appears as soon as you have a
company with one CRQC, where it can just g= o really deep in the
history of the chain. As soon as you start to have = two CRQC,
there is an advantage to burn more EC coins in fees, to reorg = to
your advantage, so we're back with some notion of chain finality.=

See more comments on rough ideas to alleviate the issue.
=C2=A0<= br>> Very neat observation. For such a rollback to occur, the miners wou= ld have to cooperatively elect to stop mining the more mature ("authen= tic") chain, where users have already migrated/forked, and instead sta= rt mining on an old block (the "revisionist" chain). Any resource= s they spend on this mining will have no payoff until the cumulative proof-= of-work of the revisionist chain surpasses that of the authentic chain. Unt= il then, honest validator nodes will simply sit idle.

Roughly in wha= t you're describing yes. If you're a miner, I think
you can play= even more sneaky chain games on what you're mentioning
about ressou= rces. Let's say you're gaining "coins" on the "authe= ntic"
chain, and after the 100 blocks maturity rule, you immediatel= y short
them on the market to reinvest your proceedings in the energy co= st of
the "revisionist" chain (or do a mining halt, as not min= ing might give
an advantage to the "revisionist" chain).
You're a miner, if the "authentic" chain wins, that's f= ine you're
already re-sell the matured coin. If the "revisionis= t" chain wins,
you got new fresh coinbase on the "revisionist&= quot; chain i.e a double-spend,
plus any CQRC "bounty" coming = from the exploited coins.

I think there is some "mining silent = reorg" advantage here.

> Due to the vast incentive towards c= olluding with the CRQC, maybe this would be feasible for some large miners?=
>
> This would essentially be a massive double-spend attack a= s well, since miners who successfully roll back the blockchain in this way = would be reorging their own mining earnings out of existence, some of which= they presumably sold (on the authentic chain) to pay for electricity. This= might make the exchanges they sold the coins to extremely unhappy: The min= ers are effectively retconning their own deposits.

See my point abov= e, they're only limited by the 100 block maturity rules.
Yes, miners= would start to be unable to settle "fresh" coins, but also "= ;old"
coins (both EC and PQ), as they are at risk of being roll ba= ck (at least for
the ones who are weeks recent).

> For this to= happen, miners must be able to withstand significant capex (on mining a re= visionist chain), while being blackballed by exchanges, and possibly also d= evaluing the very coins they were bribed with by the CRQC. And even then, i= t's not clear how - assuming they were able to pull the attack off and = remain solvent - the miners would actually use the ill-gotten coins, and wh= ether they'd have any value on the other side of a successful deep reor= g attack.

One of the point of the analysis, they might be able to fu= nd their capex, with
the exploited coins, if they can get liquidity for = them on the exchanges. On the
other hand, as long as they're economi= cally solvent, they can keep the EC-exploited
coins, until some far futu= re, when the market price them at an interesting price
enough, and slowl= y and covertly sell them out of their balance sheet by then.

> St= ill, for shallow reorgs (a few blocks) this seems like a worthwhile concern= that seriously hampers any tripwire attempts. The best case is if we can d= eploy the EC disabling fork before such tempting incentives enter the field= of play.

A naive tripwire (there might be more secure design worthy= to think more about it),
of course sounds it will be always at risk of = being keep out of the chain by miners.
Even the "we move fast and t= ry to disable EC", assuming it's philosophically acceptable
by = the community, and I'm among the one disagreeing to do so, as I pointed= out in my
previous post, the stack of "lost" EC coins might b= e worth 10 years of bitcoins, that's
a lot of reorg budget.

S= o in the hypothesis, you have a "sunset" activation, then 3 month= s after a CRQC
getting out of the box, there is a lot of incentives unce= rtainty. Even worst, there
is even a "Lorentz effect", where t= he public and well-known "sunset" activation,
incentives "= ;advanced adversaries" to reveal the CRQC they were keeping sleepingin the backyard, as they know after the activation the cost structure is = altered.

I'm thinking there are other solutions that we have not= explored yet such as
PQ-blessed periodic checkpoints. E.g, let's sa= y that every month, by consensus
rule, there is a checkpoint published t= hat needs to be finalized e.g being
signed by more than % of PQ-safe pub= keys (e.g %1 of the overall coins).

As those pubkeys are PQ-safe, th= ey cannot be forged by a CRQC, and a mining
coalition would not be able = to go deeper than this checkpoint height, capping
up the maximum of EC-u= nsafe coins that could be used as reorg budget. Of course,
that would as= k for a number of stakeholders in the ecosystem to have online keys
for = the "checkpoint" finalization, though that % can be kept low [0] = [1].

It's just a "rough idea", as somehow it's re-= introducing a form of checkpoint
(which is meehhhh...but not worse than = the sun setting ideas imho). I think there
are more imaginative ideas th= at we can come up on the design table to alleviate
the risk of a CQRC ac= ting in coordination with a mining coalition.

Notwithstanding the ul= timate direction taken, the first primitive that
would need it to give u= s more design flexibility would be the PQ-safe signing
algorithm, be it = Falcon, SkiSign or whatever.

Best,
Antoine
OTS hash: bdb435e6c= 81eb762bb6a12a03e2c23a83396a3481b8894af79732c2e2b569682

[0] This als= o let the door open for a EC coins owner, of which the pubkey
has not be= en revealed e.g P2TR to exfiltrate their old coins towards
safer one.[1] The checkpoint would have to be carefully designed to avoid being tamp= ered
by a miner, e.g a PQ-signed checkpoint would gain a proof-of-work b= onus discount ?
I'm already far in the territory of heretical consen= sus design ideas...

Le=C2=A0dim. 19 juil. 2026 =C3=A0= =C2=A023:02, conduition <conduit= ion@proton.me> a =C3=A9crit=C2=A0:
Solid analysis Antoine. However things play out here, activating = a PQ sunset fork of any kind while in the company of a CRQC=C2=A0is = apparently quite hard to do right without setting the incentives up such th= at they sabotage the whole effort.=C2=A0

If a CQRC entity=C2=A0is able to build a coalition wit= h a 51% majority of miners, the "upgraded
PQ safe" coin= s might be also at risk [4]. Indeed, such malicious coalition
<= div>could just roll-back the chain state back to the migration height= of
said coin, solve the DL for this coin and unroll= back forward the chain.

I do not bel= ieve that the old chain history would be safe from deep
reorgs attacks by CQRC capable entities, as soft-fork deployments are
"height-based" burnt and not "hash-bas= ed" burnt (BIP90). Checkpoints
have been remove= d from the latest bitcoind versions. Maybe user-activated
= checkpoints or other similar mechanisms might be a more robust defens= e
against CQRC entities attacking the chain finality.

Very neat observation. For such a rollback to occur,= the miners would have to cooperatively elect to stop mining the more matur= e ("authentic") chain, where users have already migrated/forked, = and instead start mining on an old block (the "revisionist" chain= ). Any resources they spend on this mining will have no payoff until the cu= mulative proof-of-work of the revisionist chain surpasses that of the authe= ntic chain. Until then, honest validator nodes will simply sit idle.=

=
= Due to the vast incentive towards colluding with the CRQC, maybe this would= be feasible for some large miners?

This would essentially be a massive double-spend attack = as well, since miners who successfully roll back the blockchain in this way= would be reorging their own mining earnings out of existence, some of whic= h they presumably sold (on the authentic chain) to pay for electricity. Thi= s might make the exchanges they sold the coins to extremely unhappy: The mi= ners are effectively retconning their own deposits.

For this to happen, miners must be able = to withstand significant capex (on mining a revisionist chain), while being= blackballed by exchanges, and possibly also devaluing the very coins they = were bribed with by the CRQC. And even then, it's not clear how - assum= ing they were able to pull the attack off and remain solvent - the miners w= ould actually use=C2=A0the ill-gotten coins, and whether they'd = have any value on the other side of a successful deep reorg attack.

Still, for shallow reorg= s (a few blocks) this seems like a worthwhile concern that seriously hamper= s any tripwire attempts. The best case is if we can deploy the EC disabling= fork before=C2=A0such tempting incentives enter the field of play.<= /div>

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">regards,
conduition On Sunday, July 12th, 2026 at 12:13 PM, Antoine Riard <antoine.riard@gmail.c= om> wrote:

Hi list,

In this post, I'm extending on the game-theo= ry problems
underscored for my answer to [ ] to other post-quantum
su= nsetting scenarios previously mentioned on this list.

Firstly, let&#= 39;s remember the "tripwire" idea [0]. With the
"tripwire= ", if I understand it correctly we introduce a
consensus level proo= f of quantum computers e.g with a NUMS
puzzle.

This NUMS is commi= tted in a honeypot UTXO let's say with
some non-null bitcoin reward = to unlock it. When the NUMS
point is solved by a QC entity, it automatic= ally triggers
a "freeze" of all the "legacy" coins s= tarting at some block
height-defined window in the future.

While = it appears feasible engineering-wise, the problem
is more on the game-th= eory plane of analysis. As it was
previously noted by another commentato= r than me [1], why
an economically-rational CRQC entity would go to trig= ger
such an evident "honeypot" UTXO depriving it from further<= br>(covert) extractions of the legacy coins to a safe wallet
owned by th= is entity.

A more sophisticated scenario, that I was laying out more=
recently, a 51% majority coalition of miners could coordinate
with a= CRQC entity to censor the transaction inclusion of any
PQ proof, even a= n inclusion attempt of a PQ proof generated by
an honest PQ entity [2].<= br>
Exposing again the economic analysis, a year of mining income
is = evaluated at around $20B. The number of legacy P2Pk coins
is evaluated t= o be around 1.7 M of coins or as of today $107B.
If we go to account the= numbers of "coin loss", the estimated
number can be more arou= nd 3-4 M, so let's say $215B worth of
target coins (a coin lost to y= ou is not a coin lost to a CRQC
entity...).

That's something = like ~10 years of potential income, that an
economically rational miner = might not refuse if a miner has
a credible odd of capturing a share of t= his magic income to
the prorata of their hashrate capabilities [3].
<= br>If we assume a PQ coin extraction game with 2 CQRC entities
availing = roughly the same capabilities, they might compete for
the majority hashr= ate of the miners, those miners solely driven
by economic incentives. Th= e focal point of equilibrium between
the two strategies is likely going = to be the marginal energy cost
to run a CQRC, assuming that in a fee rac= e a CQRC entity can
offer to the majority of miners to burn more of a c= oin value
as reorg fee.

Secondly, for the second approach of suns= etting, the one very roughly
described in BIP361 and based on pure "= ;flag-day" activation, the
security analysis can extend to this app= roach too. Even assuming
a week-long period for a BIP9-like activation m= echanism, a coalition
of miners might stil go to reorg in depth the chai= n before the
activation of said soft-fork.

Such an approach is on= ly theoretically increasing the coordination cost
(and one would observe= the asymmetry of information is selecting a time
horizon period, as a C= RQC might appear at any time during this period).

One can observe th= at the 2 sunsetting approach, be it "tripwire" or
"flag-d= ay" approaches are introducing a "choke point" to the chain = finality,
as in the lack of it a CQRC entity might covertly exfiltrate &= quot;legacy" coins,
with no knowledge of the miners, or even withou= t coordination with them.

After the "choke point", a CQRC = entity might alter its strategy of going
overt and start to offer fee bo= unties to reorg the chain as it's advantage
to the majority of miner= s (to not loss an exploitation advantage to another
CQRC entity).
Finally, in this analysis we're only underscoring the risk of "le= gacy"
coins, i.e coins that would have not upgraded to a PQ safe fo= rmat, after
some time horizon. However, in the Bitcoin blockchain world,= time is
relative, or rather only thermodynamically convergent. If a CQ= RC entity
is able to build a coalition with a 51% majority of miners, th= e "upgraded
PQ safe" coins might be also at risk [4]. Indeed, = such malicious coalition
could just roll-back the chain state back to th= e migration height of
said coin, solve the DL for this coin and unroll b= ack forward the chain.

I do not believe that the old chain history w= ould be safe from deep
reorgs attacks by CQRC capable entities, as soft-= fork deployments are
"height-based" burnt and not "hash-b= ased" burnt (BIP90). Checkpoints
have been removed from the latest = bitcoind versions. Maybe user-activated
checkpoints or other similar mec= hanisms might be a more robust defense
against CQRC entities attacking t= he chain finality.

Current bitcoin mining process and the chain fina= lity is assumed to be
reasonably secure under the Gambler's Ruin Pro= blem and some other assumptions
(e.g a reliable network to relay the blo= cks). It might be considered that
the introduction of CQRC computers mig= ht not be only a risk for the "legacy"
coins, though far more = concerning for the chain finality itself.

Independently of being ph= ilosophically "pro" or "contra" in freezing
legacy c= oins, I do believe the irruption of one or more CQRC entities
and the po= tential of disruptions on the Bitcoin network stability is
a subject des= erving a bit more research and more work from the development
community = [5].

Cheers,
Antoine
OTS hash: 496d9c26c6f3d805dae88f487600f4= 6990572fc84c4ca907fb85b5441c235cf3

[0] https://grou= ps.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ
[1] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNg= AwAJ
[2] One might consider the following realistic scenario, it
= might that even if a CRQC become relevant, at first it will
be only oper= ated by big companies let's say in the US or China
and they will pre= fer to keep the existence of such capabilities
hidden for a while for no= n-economical reasons.
Suddenly, one of the actor starts to use those pos= t-quantum
capabilities and the social equilibrium does not hold anymore<= br>with impactful second-order implications for the Bitcoin ecosystem.
[= 3] On the low time incentive miner hypothesis, one can empirically
obser= ve (as of June '26) than it has limits given how fast are ready
main= stream mining companies to reallocate their data centers and
sources of= energies to more generic high-performance computations
rather than SHA2= 56 hashing.
[4] For the degree of scientificity of "game-theory&quo= t; in itself, I can
only forward the reader to the "Formulation of = the Economic Problem"
chapter in the "Theory of Games and Econ= omic Behavior" book from Von
Neumann & Morgenstern, 1944
[5]= As quantum raises a number of skeptical eyebrows in the community,
the = first elaboration of quantum physics have been as old as the 30's,
a= nd so far no one has got a Nobel Prize, or any other major scientific
pr= ize to prove the physical impossibility of a large-scale quantum computer

--
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%2= BFOUJF3E7YDk5xh-Cv9kxduGiuOPVK5x171%3D25C3ryJPQ%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%2BEjD5h9387diQvwtUY9nV-GFgN-Ukp9tY%3DuqBofb-w7Tg%= 40mail.gmail.com.
--000000000000bf357806578c3589--