From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 05 Jul 2026 15:07:41 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wgV00-0004m1-0U for bitcoindev@gnusha.org; Sun, 05 Jul 2026 15:07:40 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-448bb8bd2efsf4701469fac.0 for ; Sun, 05 Jul 2026 15:07:39 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1783289254; cv=pass; d=google.com; s=arc-20260327; b=Pl4DPkoWiuLAgF6tgvXeEmEp9Tv7OA65rdWRx76aKGXUU7zTaxTpaFzMT+0h+B011h 2chBkurqy1707nT04LbbH+OyoYgAj72EWGWAlKgdx/MdMbU5XDffPS3nWLPG0uLB4/bS Kc2a7Xp+ifmNX13aDVmhDbalWO9eIxU0Z7m6+IQNVnX7ybAM1bTWZaKPXeqBs9+joq7A R5Lg7WnVqfWzh3H0QHe9p4AA7H3W+bi2AQm20nBFlk2vksXUN8M51sL62tTCrBjW4zLl F65rUESPHa3Xmk/kWryLhcL6MLVYmrZH9s+YDIQxKCyOmzuc2slHYcXn/f139Nr4Moyh qORQ== 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=pQxj0OccF84kh1zhlGdQHcYG2ayie9txJjsP+WQHQXY=; fh=ZiiQZsXMN0GHoCGqroDrao4LXKHn+gUZ18fJPevfz9E=; b=GJ1Q0QqR2gHAw2BSPG8EFTpHomsirgT7uJJLpR6eKvd7FBspxly7ToSSXgt9MqHoSR 2XFK2xD2beTvzpnfK7nYsBKI//RRcU85gKW1rQ/mBekLQqKdKq4azN0qvN+7Gtj96HYv 36RU4FJVHIyhdTobRdf8fw0oixp+Kl60GDAKAPMIJcz3udWp/vhpBgDqPQ/yZeORAS3C leblnO2Vy3S7QlS3jwnm8rs2gy0uhGnYsfKqm+xX2Ae66LXk2yo245HL3VWbnsFObILB 6xrDisPcmvh3nsyCcWCwYkjqwp3ND+9X0SGL/1fpNWV0Z1t4lte6ledf7KoJrDixzp2l 2BZA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=pI11007s; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::52a 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=1783289254; x=1783894054; 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=pQxj0OccF84kh1zhlGdQHcYG2ayie9txJjsP+WQHQXY=; b=gozzZexhR1GitIrYoFokJcGHLFvtsYA5Ou2FgiPxDaQoqX+A9+3i8/zM2okC7xgHLR bdF+GrEyAKMeSWn1tRC6P/B7iK0CQciFpvgYgGRPQ7+r2HdB7PEV5xvPgjr2bD0pGAvq 36kpxjG3nlU+y/YaQS3797Rf0vsYLfHYR9Sll6ElIZYCNZ/huR8EtGVK94zumOvEOF9j qPrnTY2N3yR6X8E8yX0x7B8fxWBZxTDrtRHSMnXphSfj8GpG3Ll8DIEwAMFptVQLsT/v 698v0nQRX72sFeL3zirdpgu7lw7xQZJnoh3spu0AKfrAsokXyBGSY5GsZKEvzqtQDHlK 2vDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783289254; x=1783894054; 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=pQxj0OccF84kh1zhlGdQHcYG2ayie9txJjsP+WQHQXY=; b=svTL8gFazVilDYTIG0b4tlhfcq1oGFiWd3/BcMhPwv3OMzSfYVW/NUnz+Yl4BWqr77 3VjiX+1Qxm7miOYVykT/Kbga9a3hpBUVzdApj+zJZw/1jEu7unjSnluCnTpvrrxD2IB4 Wr/DQAKBm95mib/T7/YQA0Yt5CIFsxXesDXs1nfTuq7bhQ3hkWog3p+coVsDkqJYVBPi l3fLdctZuAU8OK7pTRV1oKa34PQVD1K0LyBVI9eewF1zupVCKytZ1KR/vrvI9iu1sk8p j40PDb1SKu2hfTmEPJs1wfSAtYpiw5fhcpY1GtY7u/wFuYkiQk3MZfuTWizaVpWRcPtG grIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783289254; x=1783894054; 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=pQxj0OccF84kh1zhlGdQHcYG2ayie9txJjsP+WQHQXY=; b=ai77m/EGyJvgM9+TtjM0iqRWZsjOOoSK/cyRevAQBC1M2W1xcPELUDTklHVT/5oh5R 2Q9Puf5NlL4FFzPuXP2JWOv4wZBPiUHvfAldKhEvquhW9fvkqzQnKcD1TNanUV3a5pPL bojBjDuhItz+PA2zZzEIoV/JaBf/PGO4Bp1eUTv1n0Ttu4iEVx+/I3am3F64LuIltqYu JGfItX4HLQHtTMgvbhNNbZdicrHsqbE89VMO83VhdBeVgPK27lZJcw93gdjyw0sEM3hs suy6r4TclBxUKYAD3aYke2TXG60ysFgqWwTPXxcD/smVGUFa+6uXHnsut+5yUoil42bd GtGQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+RpG+5JcYqJ9xtwELlIBW9hmyjb9pDcIbP0KkwB9x/piXqvZXG/g8UmWmBz9vNHsSbYOOfR3zSyjMLr6@gnusha.org X-Gm-Message-State: AOJu0YwD9puL0PB11LNmZth5HlfGAhuWQ5WsoEpD3P28JsDvxftaxUrw 9MVf+xorZX5q2rFhQ9wbaxExWmCtTurdp2xsoCJ0Ae4WJBGp1Oy6cewu X-Received: by 2002:a05:6870:aa97:b0:442:892:9aea with SMTP id 586e51a60fabf-44d18455b29mr4551038fac.32.1783289253552; Sun, 05 Jul 2026 15:07:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUet9aIY8W7doYdIN03daakHNz+MaVjcTdNIqa4SdM0/IA==" Received: by 2002:a05:6870:558e:b0:448:7f88:4529 with SMTP id 586e51a60fabf-44d01034dedls1142890fac.1.-pod-prod-07-us; Sun, 05 Jul 2026 15:07:27 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9NLr/UzRLYkHWyXgz0sqQ0DwnipVoAgK7H5EZm9mQF5RyYhwgm1E/ZNdpmHGFDKKHisH36maigZiS7@googlegroups.com X-Received: by 2002:a05:6808:3195:b0:487:6206:54f1 with SMTP id 5614622812f47-499bd39e91amr5483990b6e.39.1783289247545; Sun, 05 Jul 2026 15:07:27 -0700 (PDT) Received: by 2002:a05:620a:e1b:b0:8f9:4d19:af67 with SMTP id af79cd13be357-92a546a07d0ms85a; Sun, 5 Jul 2026 14:55:20 -0700 (PDT) X-Forwarded-Encrypted: i=3; AHgh+Ro+gGCUq4ib9p3D/yaYGTQhnzbh8x4kYrexZ97WzBAYqMuqUwXa1f/MYHY851dWUQbC+0TrFDTj3Bg3@googlegroups.com X-Received: by 2002:a05:6214:76b:b0:8e9:f62b:8f8d with SMTP id 6a1803df08f44-8f74caaee96mr132064286d6.51.1783288519407; Sun, 05 Jul 2026 14:55:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1783288519; cv=pass; d=google.com; s=arc-20260327; b=bDaTruYDhMxnc4o16nsqtOesG25tsnX5nFnMN4m1OLnFq0lq5WTErquzWXelWCQ5/Z DCdZyERaB9Rl7hyC5nDy1zmEQs3CoqREu/QdmzNHlCVwyKql3G1g7nVs+4iFwto4BhgR d/8hRQ04Vj2sGqWVZ1/nBQFKfFi6DehHsZHtuX8WK90godtVIviT8ZBJzv8xlMZwa9Dq 0GBs52moBj68e70hGLAQk7/ykImjh2VfyxpTt8IJ6KaHqzBmePNGLbnPnKiWNi6DfTuq UcDgF2Is/F2wm6MsRz/YXk3dlN6rqBU7VwcMrf+ywIm7KkPYHNVG6CRjRrsEW5fpjWFY v3pw== 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=mIslVxqjthpSG/erQXyCKPzrQJXJDcpIMDqwsZ25/1o=; fh=ERMGzNswutaUjwionPeEhIBDHK/ojmkcRQV3TaPCQQk=; b=CaKl3Rqx3Tm2fCDTwnRUjn12nAG092nWxlaEwHN/BqQyHs61PxOw/dNZ5JvlB0oYBY KfCuK/25e/5ajFh34SS9Eo/kAfWPKHit3xnOwVcw/AXaNVAM0SqyPVow0yoPVcn2ZkZN +NqxXD/f56Qfx4UkSM3Kzz+FYI2JSyNvfDJ/QZ4Ufy4p3DVAnY59wEOQ6wXhrmJIrW4b UlQr8dDwGrKq32RusPiLErJmDZGuIzBqaZD0KeNmk0laJy+9k4cldw7qeBZQztczbvzo f6+G4cOXnwHA2TuSVlb6DDzDpg/c6e6tK9g4BXVupkHQn1hIxu269ZYclPZdjYeIAvgY bNdw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=pI11007s; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::52a 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-pg1-x52a.google.com (mail-pg1-x52a.google.com. [2607:f8b0:4864:20::52a]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8f4b17fffdcsi4046366d6.8.2026.07.05.14.55.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Jul 2026 14:55:19 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) client-ip=2607:f8b0:4864:20::52a; Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-c9aea40d799so971287a12.0 for ; Sun, 05 Jul 2026 14:55:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783288518; cv=none; d=google.com; s=arc-20260327; b=d6oU2kHSlXiyJuhbsZhT7YIQkwNaFKe/lYrrh1cnAFb7ibOXK7pSkSudmFh2arJPY6 tnhAd8hdHtUUt3rvPy+ENoLsz3DLiX4tGOpa4JPYV8sGUiWXDa2jVLpZ1Qucy3Cutard ZlEzFAYUiOgRf1ZVxwEQ+nFQeMXclMSRWr4Um3raxC8hr5ORhjBKIsdorCtmapvFaM7R G1niUWf83defs4PkYQ93DU1Q8N1y5kZTf+qgFkr/e6toLg8DOtirrwRystJV+LLEhLmo f3R50gGWYQ07PYbTxSiIKiQ/ilr7s8HLQWxtkXLt663ZWOe1wtjPt8vnLkeodiI34HR6 fu4w== 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=mIslVxqjthpSG/erQXyCKPzrQJXJDcpIMDqwsZ25/1o=; fh=ERMGzNswutaUjwionPeEhIBDHK/ojmkcRQV3TaPCQQk=; b=OqfFiF59QuqTDcvnSlJJn3Y5GBj9cqTscRLG5kD5IhO1xzceZd+mCe9OzFPftH7aRP I5fKs1+fy3ayRp8JMGpQQFRWAVWZfKA7GRTJO/UvZPJRPh8yGPifIVbG8Rxfb9M65/9X lFr2TqAXQ7QlgxN2+r1lF3D0NE2M2b3l+FA2C6I15XK3BDyFBqn6xz9Cp447filKTfoW jLTS5/VX13uGX+yjNem/KGstOSDtX9eSbSguZeXfnZ7irDicNBY4lOVXjKV73j1gTyI6 PWCb395ZU/IaFtYuYUbvZd9NFEIIJ3QljVRwgaSscOTFFVWlNcFrWIzPlaYSkibnXEw8 h60g==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AHgh+RrbvTiU2DawH4b2ET653YRfgaXEZDGlxe8ADxJBn5bv+bDBqIG+WzdinaJtNOTKR6yJDKD8yghshEuc@googlegroups.com X-Gm-Gg: AfdE7clhfNuIjP5xLNBUiFgK+zhew9Ptqnh2TSkTJeuD7euYVd5tMKkaHDixWs4Uqg5 7UfIhRShyBeFx6KVaXawjIxgwflPJ6WBA9SBLR6QbFc7iF84xfgpVzbxcqq6kxeS/ecYkZhODTc ACzxctbS6+3udNjEeRSQaWCih1X8N8EdRvviy/Tp8av6fPitdx+t2phD+5VD4eU5qoHwK7O+KIq MNYf1FKfq/DaA6mPdhF+vzkZm7rREaxsWDO64aaJvsKZBk1yRginqjWn4jarWbrvktySEAb X-Received: by 2002:a05:6a20:b40b:b0:3b3:d0f:7883 with SMTP id adf61e73a8af0-3c03e1f3834mr7911849637.7.1783288518295; Sun, 05 Jul 2026 14:55:18 -0700 (PDT) MIME-Version: 1.0 References: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> In-Reply-To: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> From: Antoine Riard Date: Sun, 5 Jul 2026 22:55:06 +0100 X-Gm-Features: AVVi8CdpaTh4_33Vb6W4vCo9kLX2jNu3Fm_GHOq8E750cX7-iMk820AXJivTweI Message-ID: Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) To: Sjors Provoost Cc: Pieter Wuille , conduition , Nagaev Boris , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000aa43990655e43692" 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=pI11007s; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::52a 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: 2.6 (++) --000000000000aa43990655e43692 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pieter, Thanks for the observations. When I was saying there is a problem with the game theory, it's that strikingly, any activation of the tripwire logic would rely on a "flag" transaction being mined in the chain for the network nodes starting to enforce at the block N or N+1 or whatever the EC disabling threshold. Any "flag" transaction can be itself re-orged out of the chain to purely disable the effects of the EC disabling threshold, therefore make it null and void as an effect. One might see it as a competing race between a group of "sunsetting" users and a (majority) coalition of miners in coordination with a CRQC adversary, where the latter have an interest and the hashrate capabilities to do a tx-withold [0]. In pure terms of satoshi fee denominated calculus, empirically global miners have won an average of $20 B yearly. If we only consider that P2PK are going to be frozen by the tripwire effect, as for most of them it might be assumed they will never move to a safer format, we talk already about 1.7 M of coins or as of today valuation $107 B (the information is on the chain and can be verified). That's $107B can "burn" in revenue or income that a CRQC-enabled miners coalition to constantly reorg-out the "flag" tx out of the chain. In other terms, something like 5 years of income, and I kindly do not count all the loss coins that are likely to amount to a far bigger "tripwire" neutralization budget. In the name of what a majority of miners will gracefully let on the table an opportunity of massive income ? Leveraging Shor the exploitation might be even done anonymously as the mining process is done. Not even certainty, by who the EC-protected coins could be covertly exfiltrated. That's the most striking problem when you think about the math with any "tripwire" approach, or even an "hourglass" one relying on a "flag" transaction [1]. I'm ruling out "checkpoints" and any other trust-the-dev approach, as that's even worst [2]. As you're introducing post is resounding, what the miners are saying now, there are no guarantees on how they would use their hashrate down the road, potentially 10 or 20 years from now. Beyond, and to answer back your point, I still think you can manage an escape hatch of the "tripwire" effect, it's all depends how the script tripwire logic is implemented, but if you have two OP_SUCCESS of different kinds before your EC CHECKSIG, you can always have a "soft-fork" after the "tripwire" to return true on the stack, with an EC or hashlock as a success (I agree using undefined op_success in a script is not safe at all) [3]. Best, Antoine OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66 [0] See naumenkog's https://www.bitmex.com/blog/txwithhold-smart-contracts [1] This is sad, as the "hourglass" depending how the parameters are chosen was a more acceptable trade-off than pure sunsetting. [2] Given the amounts at stake to sunset, as a group of developers you would just paint yourself a target, there are more even funds at stake that Satoshi herself / himself is assumed to have. [3] There is no security proof in BIP341 on the unforgeability of the NUMS point, if it binds in the ROM or whatever. Le sam. 4 juil. 2026 =C3=A0 13:47, Sjors Provoost a = =C3=A9crit : > > > On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote: > > [...] > > > * Just publishing the DLP in a transaction (e.g. OP_RETURN with a > > specific marker). This is smaller than a full transaction input + > > signature. > > > > * Similarly, but publishing in the coinbase, and requiring relay using > > a separate message. Less places a node needs to check, but I'm > > concerned about the difficulty of testing infrastructure that relay of > > such a message works > > [...] > > > > > On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns > > wrote: > > > >> A slight variant of this approach would be to have a 128 byte value > "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is a > BIP340 signature of m by P. That would allow the victim of post-quantum > theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire, = in > addition to someone who has direct access to a CRQC. > > > > Indeed, I had considered something similar, but see above for why I'm > > not convinced supporting non-cooperative CRQCs is that useful. > > > > Also, in my view the tripwire isn't really a security feature on itself > > (it's not expected to trigger...), but more something that sets > > expectations around the output type for prospective users. > > > > In that sense, the question is really whether supporting > > non-cooperative CRQCs helps set that expectation more than only > > cooperative ones, which are definitely easier to support. > > > >> I think it could make sense to have the tripwire be included in the > block via the coinbase witness commitment output, rather than having it b= e > locked to a transaction, so you only having to check the coinbase for the > magic rather than every transaction. That would require a separate P2P > message to relay the necessary ECDL-break proof to miners, and would > probably need stratumv2 or a getblocktemplate update in order for the nod= e > to be able to tell pools to actually include that info in the coinbase. > > > > I worry this is untestable, really. You'd need things like > > fake-tripwires to be supported through the same message which don't > > require an ECDLP break, and still propagate. And then that needs DoS > > protection measures, > > I whipped something up last weekend: > https://github.com/Sjors/bitcoin/pull/121 > > It seems straightforward, but maybe I missed something: > - for test code we use a fake NUMS point, so we can generate "proof" > without a quantum computer > - a p2p message floods the proof > - nodes ignore the message if they already have *any* valid proof > - verifying p2p proof candidates might need some rate limiting, but it's > as cheap as verifying a transaction signature > - mining code includes the proof in a coinbase op_return, until the freez= e > activates > - with stratum v2 (and ipc mining clients in general this works out of > the box, a small change is needed for getblocktemplate clients) > - since the proof is not in the header, we can't use the normal bip9 styl= e > header scan to see if the rule activated. Instead the prototype stores it > in a file along with a merkle inclusion proof, which is read when the nod= e > restarts. > > With this mechanism it doesn't really need to be in the coinbase > transaction, but that does seem more convenient and miners can censor it > anyway. > > - Sjors > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/002f2395-7d5d-4cb6-852c-e991= aa1f0eb3%40app.fastmail.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%2BFMHG3yoOCXPfMhS%3DKFF9bn%2BrCi9NL836GDRp1CKTBXRA%40mail.gmail.com. --000000000000aa43990655e43692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pieter,

Thanks for the observations.

When= I was saying there is a problem with the game theory,
it's that str= ikingly, any activation of the tripwire logic
would rely on a "flag= " transaction being mined in the chain
for the network nodes starti= ng to enforce at the block N or
N+1 or whatever the EC disabling thresho= ld.

Any "flag" transaction can be itself re-orged out of t= he chain
to purely disable the effects of the EC disabling threshold,therefore make it null and void as an effect. One might see
it as a com= peting race between a group of "sunsetting" users
and a (major= ity) coalition of miners in coordination with a
CRQC adversary, where th= e latter=C2=A0have an interest and the
hashrate capabilities to do a tx-= withold [0].

In pure terms of satoshi fee denominated calculus, empi= rically
global miners have won an average of $20 B yearly. If we onlyconsider that P2PK are going to be frozen by the tripwire effect,
as fo= r most of them it might be assumed they will never move to
a safer forma= t, we talk already about 1.7 M of coins or as of
today valuation $107 B = (the information is on the chain and can
be verified).

That's= $107B can "burn" in revenue or income that a CRQC-enabled
min= ers coalition to constantly reorg-out the "flag" tx out of thechain. In other terms, something like 5 years of income, and I
kindly d= o not count all the loss coins that are likely to amount
to a far bigger= "tripwire" neutralization budget.

In the name of what a m= ajority of miners will gracefully let on
the table an opportunity of mas= sive income ?

Leveraging Shor the exploitation might be even done an= onymously
as the mining process is done. Not even certainty, by who the<= br>EC-protected coins could be covertly exfiltrated.

That's the = most striking problem when you think about the math
with any "tripw= ire" approach, or even an "hourglass" one relying
on a &q= uot;flag" transaction [1]. I'm ruling out "checkpoints" = and
any other trust-the-dev approach, as that's even worst [2].
<= br>As you're introducing post is resounding, what the miners
are say= ing now, there are no guarantees on how they would use
their hashrate do= wn the road, potentially 10 or 20 years from now.

Beyond, and to ans= wer back your point, I still think you can
manage an escape hatch of the= "tripwire" effect, it's all depends
how the script tripwi= re logic is implemented, but if you have
two OP_SUCCESS of different kin= ds before your EC CHECKSIG, you
can always have a "soft-fork" = after the "tripwire" to return
true on the stack, with an EC = or hashlock as a success (I agree
using undefined op_success in a script= is not safe at all) [3].
=C2=A0
Best,
Antoine
OTS hash: 4bc91d= 8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66

[0] See n= aumenkog's https://www.bitmex.com/blog/txwithhold-smart-contracts
[1] Th= is is sad, as the "hourglass" depending how the parameters are ch= osen
was a more acceptable trade-off than pure sunsetting.
[2] Given = the amounts at stake to sunset, as a group of developers you
would just = paint yourself a target, there are more even funds at stake
that Satoshi= herself / himself is assumed to have.
[3] There is no security proof in= BIP341 on the unforgeability of the
NUMS point, if it binds in the ROM = or whatever.

Le=C2=A0sam. 4 juil. 2026 =C3=A0=C2=A013:= 47, Sjors Provoost <sjors@sprovoos= t.nl> a =C3=A9crit=C2=A0:


On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote:

[...]

> * Just publishing the DLP in a transaction (e.g. OP_RETURN with a
> specific marker). This is smaller than a full transaction input +
> signature.
>
> * Similarly, but publishing in the coinbase, and requiring relay using=
> a separate message. Less places a node needs to check, but I'm > concerned about the difficulty of testing infrastructure that relay of=
> such a message works

[...]

>
> On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns
> <aj@erisian.= com.au> wrote:
>
>> A slight variant of this approach would be to have a 128 byte valu= e "aRsm", such that P =3D N+a*G, N is the BIP-341 NUMS point, and= Rs is a BIP340 signature of m by P. That would allow the victim of post-qu= antum theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwi= re, in addition to someone who has direct access to a CRQC.
>
> Indeed, I had considered something similar, but see above for why I= 9;m
> not convinced supporting non-cooperative CRQCs is that useful.
>
> Also, in my view the tripwire isn't really a security feature on i= tself
> (it's not expected to trigger...), but more something that sets > expectations around the output type for prospective users.
>
> In that sense, the question is really whether supporting
> non-cooperative CRQCs helps set that expectation more than only
> cooperative ones, which are definitely easier to support.
>
>> I think it could make sense to have the tripwire be included in th= e block via the coinbase witness commitment output, rather than having it b= e locked to a transaction, so you only having to check the coinbase for the= magic rather than every transaction. That would require a separate P2P mes= sage to relay the necessary ECDL-break proof to miners, and would probably = need stratumv2 or a getblocktemplate update in order for the node to be abl= e to tell pools to actually include that info in the coinbase.
>
> I worry this is untestable, really. You'd need things like
> fake-tripwires to be supported through the same message which don'= t
> require an ECDLP break, and still propagate. And then that needs DoS <= br> > protection measures,

I whipped something up last weekend:
https://github.com/Sjors/bitcoin/pull/121

It seems straightforward, but maybe I missed something:
- for test code we use a fake NUMS point, so we can generate "proof&qu= ot; without a quantum computer
- a p2p message floods the proof
- nodes ignore the message if they already have *any* valid proof
- verifying p2p proof candidates might need some rate limiting, but it'= s as cheap as verifying a transaction signature
- mining code includes the proof in a coinbase op_return, until the freeze = activates
=C2=A0 - with stratum v2 (and ipc mining clients in general this works out = of the box, a small change is needed for getblocktemplate clients)
- since the proof is not in the header, we can't use the normal bip9 st= yle header scan to see if the rule activated. Instead the prototype stores = it in a file along with a merkle inclusion proof, which is read when the no= de restarts.

With this mechanism it doesn't really need to be in the coinbase transa= ction, but that does seem more convenient and miners can censor it anyway.<= br>
- Sjors

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe<= /a>.
To unsubscribe from this group and all its topics, send an email to bit= coindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.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.co= m/d/msgid/bitcoindev/CALZpt%2BFMHG3yoOCXPfMhS%3DKFF9bn%2BrCi9NL836GDRp1CKTB= XRA%40mail.gmail.com.
--000000000000aa43990655e43692--