From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 04 Jul 2025 07:38:54 -0700 Received: from mail-yb1-f185.google.com ([209.85.219.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uXhYy-0001V6-OG for bitcoindev@gnusha.org; Fri, 04 Jul 2025 07:38:53 -0700 Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e8973c943d6sf2630073276.0 for ; Fri, 04 Jul 2025 07:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1751639926; x=1752244726; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=qvJo0s818iYvI7XAVkQIUDLtYm1NGucKrm7HPvu0UF4=; b=KB6yQRIS70yig5MXBST0zINrlJ2FxZ8ZDpl70OVDOeAa9Qaisp8dFYclY11d0fSvT8 ayQ0SH0/W06RF5LTnlluI7Rn8ELJQKcJUvjcUTEBoQY/zb9RFURe8opXo6/KG2rmGbHB 1xGh5z9OG7BHYn3FW1iKQqxgn/kRou5xnfse9OUBz1WUopNQg0PRDAkJM8sgWEND0IPE m/9EXsDTP1Udr07WDrTExtYQGXqwRfIAlaFludiqdedN+t5VR3Te7ZWxCncCdTdP4qZi Og0LO/fMz0EYV+vssTHp9r8dxHqxxi1ZMv6vz0kowcIurf91R8+QG7l0uGaSo0a0cE6x hT2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751639926; x=1752244726; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=qvJo0s818iYvI7XAVkQIUDLtYm1NGucKrm7HPvu0UF4=; b=bP+OMSmGfb7okkFqaXqBKda7IEUoMhi4nLt7tWqwiVNItxY6nXmihradZDagA3SDVN yVuEy1nJn1U2TNluLCzRL245GgZHTs0r4uCepPS7YRMxMDJkaL6+J1gB0e/U9wb+Cb4S 7wgNviojHvxuwy1LmcxA7eKSak0kTUSRBUb2kjt4jfFjYaHSr7J2OFzCZpDGQDZxXV3R cNXfVTIeOHwWF8DX9RkN6hGA5O3jcQkZapqP9nrbptXFa69Ym0u/4FNX6QUnX96hHSpn s/t9K+Gac6Ivqu4XrEn9e31DfUohrW6o185maqTMoOlwIBUjbofATD63FrZJd7PEzawy bHiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751639926; x=1752244726; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=qvJo0s818iYvI7XAVkQIUDLtYm1NGucKrm7HPvu0UF4=; b=pUh+r5/dqaohzQnQq82+HThfXvyCoESHkTd1HQhebNlV1rfZRgHVzkMS+x0/jXGPHE AboBpXzgwOE2r5rslwpjLdnJP/QsKnbIIyXDjjqJhO8UgdWZMM3waPmrHAaClNp/F0wE vwgyDRLLI5GZx+c6cvcst6n5bTgPC8CZQo0XvthoCQJN3HyJDEQTFy+8TtOXhRKRS34A RdEv8h0AjhcZbAH8fCHhNtdOG6cJaTwF+Ktra4lkyWBGsWPnCIrZuSuxyVZaBZcvypqW mYOeZWR1xMOJzTX1aZ9Ya31cLAiq7uDQgUT/m4/fpaNG8dHE0W2GtmTzbkckPsAXR5JO 9VHg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXyGNA8kysMBGgZKg6nsEOhjFb8vgzgvjfiGMGyagk3wJLg+smWIrozfRAPMMA1mLkAeUiLl+bqE2fw@gnusha.org X-Gm-Message-State: AOJu0YxRaRcQrPYCf3RF0+N5yfrAaB78D9kIXwezcLUReDKVR4gb/Zuy X2fuHi17UwOAXVLaWo6ZuoxnC0e7ekvcyGjB4Ob5rOLUjAjFj5lhyljq X-Google-Smtp-Source: AGHT+IGhdbdA2iK/31OZqGqLj9Kd0WR3C1bBgcjkISoN+PGYR5G8zOY/ZoqLWpzcLwt2UydR4kflDQ== X-Received: by 2002:a05:6902:2708:b0:e87:9bab:8ce with SMTP id 3f1490d57ef6-e899d1c898fmr4319940276.23.1751639926094; Fri, 04 Jul 2025 07:38:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdSjX43IO1iUxvxgh60PjDReX0PIfn2OPQS5Xrv3jMUxQ== Received: by 2002:a25:b84b:0:b0:e82:307f:5561 with SMTP id 3f1490d57ef6-e89a3896af8ls459284276.2.-pod-prod-06-us; Fri, 04 Jul 2025 07:38:41 -0700 (PDT) X-Received: by 2002:a05:690c:6186:b0:702:d85:5347 with SMTP id 00721157ae682-71668e6c6ecmr34211237b3.36.1751639921165; Fri, 04 Jul 2025 07:38:41 -0700 (PDT) Received: by 2002:a05:690c:3149:b0:710:fccf:6901 with SMTP id 00721157ae682-7164e5fe800ms7b3; Thu, 3 Jul 2025 11:18:20 -0700 (PDT) X-Received: by 2002:a05:690c:720a:b0:70d:fe74:1800 with SMTP id 00721157ae682-71658ffd651mr65630387b3.15.1751566698676; Thu, 03 Jul 2025 11:18:18 -0700 (PDT) Date: Thu, 3 Jul 2025 11:18:18 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA=@protonmail.com> References: <49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA=@protonmail.com> Subject: [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_400142_1276248023.1751566698288" X-Original-Sender: antoine.riard@gmail.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 (/) ------=_Part_400142_1276248023.1751566698288 Content-Type: multipart/alternative; boundary="----=_Part_400143_1394053503.1751566698288" ------=_Part_400143_1394053503.1751566698288 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot, Thanks for the collection of historical txn hitting the proposed new limit. The only long-term downside coming immediately out of mind, if the rule=20 becomes consensus in the future, it's the implicit limitation it would make on the=20 multi-party dimensions of off-chain constructions. In the past, I made really rough math for=20 1000-sized participants payments pools, where for the funding_tx, you have the 1000 participants=20 contributing one input with one sig for each [0].=20 In my understanding the new limit of 2500 signatures operation would make a= =20 hard-limit for the number of participants entering in such construction, without other= =20 tricks that are consuming more block space. One can note the downside on funding tx of= =20 high-order off-chain construction, if a max tx size consensus limit is introduced in= =20 the future. Of course, I do not deny the DoS rational of introducing the 2500 sig limit= =20 and it's very needed. At the same time, we should be careful of not closing too much= =20 doors for future off-chain constructions and long-term tx throughput scalability. I do believe, it's always technically possible in the future to introduce= =20 new opcode or segwit versions scripts (e.g grafroot or entroot-based pool=20 construction), which wouldn't be subject to the new limit, and as such more scalable. If I'm=20 correct, I think it's all about how the limit is implemented to parse current scripts= =20 to be spent. But it's hard to say without code available to review and reason. May I=20 kindly note there is no reference implementation attached in the current BIP54 document= =20 [1]. Even, if it's often updated, it's always fruitful to have code under the eyes for= =20 review. This might be the kind of concern (very) far down the line...but preserving= =20 the evolvability of the consensus rules is a good property to care about, in my= =20 humble opinion. Best, Riard OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2 [0]=20 https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWs= wqbfAnRdA@mail.gmail.com/ [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =C3=A9c= rit : > Hi everyone, > > To mitigate high block validation time, BIP54 proposes to make=20 > transactions which require more than > 2500 legacy signature operations invalid by consensus. The 2500 figure wa= s=20 > chosen as the tightest > value that did not make any non-pathological currently standard=20 > transaction invalid. > > No transaction in Bitcoin's history would have both hit the BIP54 sigop= =20 > limit and been standard > according to today's Bitcoin Core policy[^0]. But what happened in the=20 > past doesn't matter as much > as the fact that it is possible today to create a pathological standard= =20 > transaction that is > BIP54-invalid. > > This opens up a major DoS vector against unupgraded miners if BIP54 ever= =20 > gets activated in these > conditions. Therefore i propose to make such transactions non-standard an= d=20 > hold off activation of > BIP54 until we have good reasons to believe that the vast majority of the= =20 > hashrate won't create a > block containing such a transaction. > > Doing so gives better guarantees in case BIP54 is ever considered for=20 > activation, and comes at > virtually no cost since these pathological transactions have never been= =20 > used and serve no purpose > beyond increasing the cost of validation. Bitcoin Core PR #32521=20 > implements this change, which i > hope to get into the upcoming 30.0 release as well as backported to=20 > previous versions. > > Best, > Antoine Poinsot > > [^0]: Here the full list of historical transactions that would have hit= =20 > the BIP54 sigops limit: > - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2 > - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683 > - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179 > - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0 > - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6 > - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09 > - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e > - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f > - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327 > - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f > - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc > - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3 > - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3 > - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 > - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363 > - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841 > - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf > - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34 > - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e > - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b > - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007 > - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d > - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e > - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3 > - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a > - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235 > - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629 > - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530 > - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5 > - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60 > - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57 > - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7 > - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311 > - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2 > - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f > - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a > - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7 > - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9 > - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f > - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921 > - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597 > - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d > - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8 > - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711 > - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6 > - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec > - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda > - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652 > - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e > - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508 > - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261 > - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2 > - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663 > - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436 > - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7 > - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d > - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649 > - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4 > - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1 > - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4 > - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640 > - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9 > - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404 > - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b > - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b > - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5 > - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd > - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517 > - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4 > - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd > - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04 > - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3 > - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f > - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef > - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e > - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545 > - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b > - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0 > - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276 > - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d > - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c > - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8 > - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641 > - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf > - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278 > - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a > - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521 > - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c > - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b > - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15 > - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797 > - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9 > --=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/= eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com. ------=_Part_400143_1394053503.1751566698288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot,

Thanks for the collection of historical txn hitting = the proposed new limit.

The only long-term downside coming immed= iately out of mind, if the rule becomes consensus
in the future, it's = the implicit limitation it would make on the multi-party dimensions
of= off-chain constructions. In the past, I made really rough math for 1000-si= zed participants
payments pools, where for the funding_tx, you have th= e 1000 participants contributing
one input with one sig for each [0]. =

In my understanding the new limit of 2500 signatures operation = would make a hard-limit
for the number of participants entering in suc= h construction, without other tricks that
are consuming more block spa= ce. One can note the downside on funding tx of high-order
off-chain co= nstruction, if a max tx size consensus limit is introduced in the future.
Of course, I do not deny the DoS rational of introducing the 2500= sig limit and it's
very needed. At the same time, we should be carefu= l of not closing too much doors for
future off-chain constructions and= long-term tx throughput scalability.

I do believe, it's always = technically possible in the future to introduce new opcode
or segwit v= ersions scripts (e.g grafroot or entroot-based pool construction), whichwouldn't be subject to the new limit, and as such more scalable. If I'm = correct, I
think it's all about how the limit is implemented to parse = current scripts to be
spent.

But it's hard to say without c= ode available to review and reason. May I kindly note
there is no refe= rence implementation attached in the current BIP54 document [1]. Even,
if it's often updated, it's always fruitful to have code under the eyes fo= r review.

This might be the kind of concern (very) far down the = line...but preserving the
evolvability of the consensus rules is a goo= d property to care about, in my humble
opinion.

Best,
= Riard
OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2

[0= ] https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tn= WswqbfAnRdA@mail.gmail.com/
[1] https://github.com/bitcoin/bips/blob/m= aster/bip-0054.md

Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoi= ne Poinsot a =C3=A9crit=C2=A0:
Hi everyone,

To mitigate high block validation time, BIP54 proposes to make transact= ions which require more than
2500 legacy signature operations invalid by consensus. The 2500 figure = was chosen as the tightest
value that did not make any non-pathological currently standard transac= tion invalid.

No transaction in Bitcoin's history would have both hit the BIP54 s= igop limit and been standard
according to today's Bitcoin Core policy[^0]. But what happened in = the past doesn't matter as much
as the fact that it is possible today to create a pathological standard= transaction that is
BIP54-invalid.

This opens up a major DoS vector against unupgraded miners if BIP54 eve= r gets activated in these
conditions. Therefore i propose to make such transactions non-standard = and hold off activation of
BIP54 until we have good reasons to believe that the vast majority of t= he hashrate won't create a
block containing such a transaction.

Doing so gives better guarantees in case BIP54 is ever considered for a= ctivation, and comes at
virtually no cost since these pathological transactions have never been= used and serve no purpose
beyond increasing the cost of validation. Bitcoin Core PR #32521 implem= ents this change, which i
hope to get into the upcoming 30.0 release as well as backported to pre= vious versions.

Best,
Antoine Poinsot

[^0]: Here the full list of historical transactions that would have hit= the BIP54 sigops limit:
- 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
- bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683
- 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179
- 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0
- ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6
- 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09
- 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e
- d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f
- 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327
- 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f
- b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc
- c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3
- 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3
- bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
- ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363
- ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841
- dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf
- 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34
- 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e
- ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b
- 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007
- dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d
- 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e
- e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3
- 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a
- 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235
- c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629
- 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530
- 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5
- f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60
- 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57
- 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7
- 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311
- 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2
- bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f
- a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a
- fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7
- 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9
- 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f
- d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921
- 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597
- 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d
- cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8
- 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711
- 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
- 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec
- 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda
- 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652
- e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e
- b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508
- 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261
- 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2
- fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663
- 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436
- 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7
- 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d
- 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649
- 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4
- d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1
- e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4
- a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640
- f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9
- 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404
- 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b
- c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b
- e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5
- 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd
- 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517
- d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4
- 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd
- 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04
- 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3
- bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f
- 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef
- 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e
- 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545
- b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b
- 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0
- 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276
- e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d
- 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c
- b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8
- 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641
- 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf
- e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278
- c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a
- 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521
- 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c
- 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b
- 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15
- d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797
- b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9

--
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/bitcoind= ev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com.
------=_Part_400143_1394053503.1751566698288-- ------=_Part_400142_1276248023.1751566698288--