From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 12 Jul 2025 17:46:26 -0700 Received: from mail-yb1-f189.google.com ([209.85.219.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uakrI-0004z4-Na for bitcoindev@gnusha.org; Sat, 12 Jul 2025 17:46:26 -0700 Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e8973c943d6sf6315475276.0 for ; Sat, 12 Jul 2025 17:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752367578; x=1752972378; 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=9Wfg/YTvVYvzlKBN7afJVPKCLwR7GoZDNvWJmDoUgSA=; b=objTII0C1gndrAiJuHa12VVJvIl5i/993CzTLKjrPJcqOuwUr9+TFgp8Bv2GlTGd+o XPxpvSF7J4uW1BYe8PpTZRDbJT8fF9OmOhKBZFJLdtzttTGPEAoOd7VUnDZTVwrkHlVY fF4gqlt9SCi+wuqj20I1jLt/BNTj8Mc9XGPlD2d0RAFg3rqAQPs25jo0yMm+NciIREV6 3bru2Lu9KcK6e46+hvFxXQ7yTxD6wcQAUhslr1r0W7L1Oss3thmOp84uHfBIyaGreXU0 cXrgz8mAXig1V8y4iJxg/qnVHa4I12ajz9eYYbyv/7YQS+B1mwIPm4ppigFexo2EJps6 a2+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752367578; x=1752972378; 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=9Wfg/YTvVYvzlKBN7afJVPKCLwR7GoZDNvWJmDoUgSA=; b=JfaeNOCoYMEJ2MfgCGjkgWHfiiIODhIuUCPvJ+OR/SNllmSuAjihY0/KPHyndgl5ud Q3iPW7OVqqT6HCF/W0ZS1FKig8/Ik3thqPRO9Ow9rkmigggsFg6J3xoxybDInUBFX1xY X4tWxfscPcQ0w/YWN0ArAfF09puckDUmh+QhvcvapyP6tOfk+cSE3h63QSQYqkA1sRk2 jFXTnEeZPFFMT8XLNfAZ0RPSV7hN3LfCqEBur38ImdQVOvSP/X2qvvWSZkgDZABGeiPy JalsLsRyWYixmQXa+JUES2/ODQ4bJjAlBraimCeY9r5fX8/B4Nj135nbX8A7tOKcV80y J59g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752367578; x=1752972378; 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=9Wfg/YTvVYvzlKBN7afJVPKCLwR7GoZDNvWJmDoUgSA=; b=fsRXDsWENi9acbyXvpqwKdTnigNKESVYbZu/Xu6bk0pYvojp47LTfCkIvo/uOZbFDv SyBZh+bcl9nFPIYrO8e7D2qJA3GZykUt97FgFADWxpvY8NucNcn8y52wIAlhJhy8vPwv mY7sjkVIKkJRpWIgvJqjpzZeTdEe5oQCACKvOZHkBRJzQXhdiDZE4b8HSQzHR8Hlg6qd 03fL8fXNQw03dmbBfSdnVp0szXjV5NET41c+SEgjTEbwzRn45ZRHSVzAydMKLhEMrlw+ ouVHcUPXX5S7RoiKPecLt8a0bVhSbLsVqWXFt0QRQDaRq/PkAD/XdBvU0ODEWo8xrZg6 hAXg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWBgxUuJZoDPHrHd8FwaVNiDENqmGZYiBWU9Kle3/jasMB40lvIv7gyvSdWB4wkBAkVn2JuhoX2AO1G@gnusha.org X-Gm-Message-State: AOJu0YyQ0ISuLMfFw3HlTRjLvJuCeqOyp9j3m+XaWYyKH6YedvEA2GeX 6DggI9u3msvtwcs46yI8prylUpv4LLt1Uv1x4s8iJ93YOf7gBuhUewk3 X-Google-Smtp-Source: AGHT+IEiy9u4DWEeBIcc6hAPownlJgiGuo7SutOlu/iCrV8tGKS63oHWNhmgCdotvBHrM3danB8I7Q== X-Received: by 2002:a05:6902:2683:b0:e7d:9ec3:bce4 with SMTP id 3f1490d57ef6-e8b8521f0ecmr10754410276.20.1752367578294; Sat, 12 Jul 2025 17:46:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdZLRohRExK58mw/Zxonxg0QdHBNxUZA7wmleSmXf0tuA== Received: by 2002:a25:df57:0:b0:e87:c996:a10 with SMTP id 3f1490d57ef6-e8b778de239ls402476276.1.-pod-prod-07-us; Sat, 12 Jul 2025 17:46:14 -0700 (PDT) X-Received: by 2002:a05:690c:9518:b0:70c:b882:2e9 with SMTP id 00721157ae682-717d78afa11mr88037117b3.3.1752367574231; Sat, 12 Jul 2025 17:46:14 -0700 (PDT) Received: by 2002:a05:690c:2b08:b0:717:9718:f4dc with SMTP id 00721157ae682-7179718f94ems7b3; Fri, 11 Jul 2025 21:12:40 -0700 (PDT) X-Received: by 2002:a05:690c:61c8:b0:708:6a2c:147b with SMTP id 00721157ae682-717d78af809mr84275837b3.7.1752293559427; Fri, 11 Jul 2025 21:12:39 -0700 (PDT) Date: Fri, 11 Jul 2025 21:12:39 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA=@protonmail.com> Subject: Re: [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_194882_1000047287.1752293559120" 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_194882_1000047287.1752293559120 Content-Type: multipart/alternative; boundary="----=_Part_194883_1859520430.1752293559120" ------=_Part_194883_1859520430.1752293559120 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot, Not necessarily, if you go to multi-sign the first input of your=20 second-stage txn with SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence are=20 not commited. The second input can be a legacy input, even if it's altered in-flight (e.g= =20 flipping the S component of the ECDSA sig), it's breaking your sig hash for the=20 second input, but not the sighash for the "contract" multi-signed input. Very practical= =20 for doing unilateral fee-bumping. It's a problem if you do multi-stage for an off-chain construction, as the= =20 third order tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and=20 implicitly the parent txid of the malleable second input. ... Anyway, the current BIP54 says the following nothing about legacy inputs: "A limit is set on the number of potentially executed signature operations= =20 in validating a transaction. It applies to all transactions in the block except the=20 coinbase transaction. For each input in the transaction, count the number of CHECKSIG and=20 CHECKMULTISIG in the input scriptSig and previous output's scriptPubKey, including the P2SH=20 redeemScript". I do think it would be clearer to say that Segwit spends are logically=20 excluded due to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size() != =3D=20 0 in `VerifyScript()`) and b) a witness program must be a data push and as such= =20 it's never a scriptCode that can contain a CHECKSIG ops. Accounting is=20 implicitly always 0 for Segwit spends. There is no definition of what make a spend a "legacy" input, other than=20 it's not a Segwit spend. Technically, the CHECKSIG operations are committed in the= =20 witness program, which is itself part of the scriptPubkey... While indeed,=20 currently the code is properly dissociating the verifcation of the legacy spends from the=20 witness program, it's hard to say the limit is correctly implemented in the complete lack of= =20 available code. The limit could be implemented in EvalScript(), but I'm not sure it's=20 exactly what you have in mind. Thanks by advance if there is code and specification=20 defining more precisly what is understood as a legacy input under this BIP proposal. ... I think there are some implications about all of this for some use-cases=20 designers, e.g for massive Coinjoin, if in the collaborative transaction construction= =20 any party proposes a scriptpubkey with a huge number of sigs to reach the limit, now= =20 if you don't verify the script sanity against this new rule, you might have=20 contributed an input in a transaction that is never going to be valid. Some kind of=20 denial-of-service, and the reason initially opt-in rbf was proposed to be remove. While this is not a concern for lightning (bc the dual funding spec=20 explictly requests segwit input at `tx_add_input` reception), I'm not sure for any=20 coinjoin or multi-party tx construction stuff that might be affected by a new DoS=20 vector as soon as this starts to be a policy rule spread substantially on the=20 network. It's not to say that this limit shouldn't be deployed, but in my opinion=20 it's wise to advertise more towards multi-party use-cases maintainers and devs= =20 the potential implications of the deployment of this rule, as soon as it's=20 policy. Best, Riard OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc902 Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9crit= : > This limit only concerns legacy signature operations. Off-chain=20 > constructions use Segwit inputs, as they would be trivially broken by txi= d=20 > malleability otherwise. > On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard =20 > wrote: > > Hi Poinsot, > > Thanks for the collection of historical txn hitting the proposed new limi= t. > > 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= =20 > a hard-limit > for the number of participants entering in such construction, without=20 > other tricks that > are consuming more block space. One can note the downside on funding tx o= f=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=20 > limit and it's > very needed. At the same time, we should be careful of not closing too=20 > 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= =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 script= s=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=20 > document [1]. Even, > if it's often updated, it's always fruitful to have code under the eyes= =20 > for review. > > This might be the kind of concern (very) far down the line...but=20 > preserving the > evolvability of the consensus rules is a good property to care about, in= =20 > my humble > opinion. > > Best, > Riard > OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2 > > [0]=20 > https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail.gmail.= com/=20 > > [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= =A9crit : > >> Hi everyone,=20 >> >> To mitigate high block validation time, BIP54 proposes to make=20 >> transactions which require more than=20 >> 2500 legacy signature operations invalid by consensus. The 2500 figure= =20 >> was chosen as the tightest=20 >> value that did not make any non-pathological currently standard=20 >> transaction invalid.=20 >> >> No transaction in Bitcoin's history would have both hit the BIP54 sigop= =20 >> limit and been standard=20 >> according to today's Bitcoin Core policy[^0]. But what happened in the= =20 >> past doesn't matter as much=20 >> as the fact that it is possible today to create a pathological standard= =20 >> transaction that is=20 >> BIP54-invalid.=20 >> >> This opens up a major DoS vector against unupgraded miners if BIP54 ever= =20 >> gets activated in these=20 >> conditions. Therefore i propose to make such transactions non-standard= =20 >> and hold off activation of=20 >> BIP54 until we have good reasons to believe that the vast majority of th= e=20 >> hashrate won't create a=20 >> block containing such a transaction.=20 >> >> Doing so gives better guarantees in case BIP54 is ever considered for=20 >> activation, and comes at=20 >> virtually no cost since these pathological transactions have never been= =20 >> used and serve no purpose=20 >> beyond increasing the cost of validation. Bitcoin Core PR #32521=20 >> implements this change, which i=20 >> hope to get into the upcoming 30.0 release as well as backported to=20 >> previous versions.=20 >> >> Best,=20 >> Antoine Poinsot=20 >> >> [^0]: Here the full list of historical transactions that would have hit= =20 >> the BIP54 sigops limit:=20 >> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2=20 >> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683=20 >> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179=20 >> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0=20 >> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6=20 >> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09=20 >> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e=20 >> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f=20 >> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327=20 >> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f=20 >> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc=20 >> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3=20 >> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3=20 >> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08=20 >> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363=20 >> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841=20 >> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf=20 >> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34=20 >> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e=20 >> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b=20 >> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007=20 >> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d=20 >> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e=20 >> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3=20 >> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a=20 >> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235=20 >> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629=20 >> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530=20 >> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5=20 >> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60=20 >> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57=20 >> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7=20 >> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311=20 >> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2=20 >> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f=20 >> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a=20 >> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7=20 >> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9=20 >> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f=20 >> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921=20 >> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597=20 >> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d=20 >> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8=20 >> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711=20 >> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6=20 >> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec=20 >> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda=20 >> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652=20 >> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e=20 >> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508=20 >> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261=20 >> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2=20 >> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663=20 >> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436=20 >> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7=20 >> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d=20 >> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649=20 >> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4=20 >> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1=20 >> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4=20 >> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640=20 >> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9=20 >> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404=20 >> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b=20 >> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b=20 >> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5=20 >> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd=20 >> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517=20 >> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4=20 >> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd=20 >> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04=20 >> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3=20 >> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f=20 >> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef=20 >> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e=20 >> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545=20 >> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b=20 >> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0=20 >> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276=20 >> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d=20 >> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c=20 >> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8=20 >> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641=20 >> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf=20 >> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278=20 >> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a=20 >> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521=20 >> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c=20 >> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b=20 >> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15=20 >> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797=20 >> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9=20 >> > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-1d10= 2477ccfdn%40googlegroups.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/= e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com. ------=_Part_194883_1859520430.1752293559120 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot,

Not necessarily, if you go to multi-sign the first i= nput of your second-stage txn with
SIGHASH_SINGLE | ANYONECANPAY, the = hashPrevouts and the hashSequence are not commited.
The second input c= an be a legacy input, even if it's altered in-flight (e.g flipping
the= S component of the ECDSA sig), it's breaking your sig hash for the second = input,
but not the sighash for the "contract" multi-signed input. Very= practical for doing
unilateral fee-bumping.

It's a problem= if you do multi-stage for an off-chain construction, as the third ordertx, even with SIGHASH_SINGLE would commit to `outpoint` field, and impli= citly the
parent txid of the malleable second input.

...
Anyway, the current BIP54 says the following nothing about legacy = inputs:

"A limit is set on the number of potentially executed si= gnature operations in validating
a transaction. It applies to all tran= sactions in the block except the coinbase transaction.
For each input = in the transaction, count the number of CHECKSIG and CHECKMULTISIG in theinput scriptSig and previous output's scriptPubKey, including the P2SH = redeemScript".

I do think it would be clearer to say that Segwit= spends are logically excluded due
to a) a Segwit spend's scriptSig mu= st be always empty (`scriptSig.size() !=3D 0 in
`VerifyScript()`) and = b) a witness program must be a data push and as such it's
never a scri= ptCode that can contain a CHECKSIG ops. Accounting is implicitly always
0 for Segwit spends.

There is no definition of what make a spe= nd a "legacy" input, other than it's not
a Segwit spend. Technically, = the CHECKSIG operations are committed in the witness
program, which is= itself part of the scriptPubkey... While indeed, currently the code
i= s properly dissociating the verifcation of the legacy spends from the witne= ss program,
it's hard to say the limit is correctly implemented in the= complete lack of available code.

The limit could be implemented= in EvalScript(), but I'm not sure it's exactly what
you have in mind.= Thanks by advance if there is code and specification defining
more pr= ecisly what is understood as a legacy input under this BIP proposal.
<= br />...

I think there are some implications about all of this f= or some use-cases designers,
e.g for massive Coinjoin, if in the colla= borative transaction construction any party
proposes a scriptpubkey wi= th a huge number of sigs to reach the limit, now if you
don't verify t= he script sanity against this new rule, you might have contributed
an = input in a transaction that is never going to be valid. Some kind of denial= -of-service,
and the reason initially opt-in rbf was proposed to be re= move.

While this is not a concern for lightning (bc the dual fun= ding spec explictly
requests segwit input at `tx_add_input` reception)= , I'm not sure for any coinjoin
or multi-party tx construction stuff t= hat might be affected by a new DoS vector
as soon as this starts to be= a policy rule spread substantially on the network.

It's not to = say that this limit shouldn't be deployed, but in my opinion it's
wise= to advertise more towards multi-party use-cases maintainers and devs thepotential implications of the deployment of this rule, as soon as it's = policy.

Best,
Riard
OTS hash: c236ba440e27f6bf89db9d21= f1650d945c92fc941bb9177dbf06bbbac2afc902
Le lundi 7 juillet 2025 =C3=A0 23:25:0= 2 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:
This limit only concerns legacy signature operations. Off-c= hain constructions use Segwit inputs, as they would be trivially broken by = txid malleability otherwise.
=20
=20
=20
On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard <antoin...@gmail.com> wrote:
Hi Poinsot,

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

The only long-term downside coming i= mmediately out of mind, if the rule becomes consensus
in the future, it&= #39;s the implicit limitation it would make on the multi-party dimensionsof off-chain constructions. In the past, I made really rough math for 100= 0-sized participants
payments pools, where for the funding_tx, you have = the 1000 participants contributing
one input with one sig for each [0]. =

In my understanding the new limit of 2500 signatures operation woul= d make a hard-limit
for the number of participants entering in such cons= truction, without other tricks that
are consuming more block space. One = can note the downside on funding tx of high-order
off-chain construction= , if a max tx size consensus limit is introduced in the future.

Of c= ourse, 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 careful of not clo= sing too much doors for
future off-chain constructions and long-term tx = throughput scalability.

I do believe, it's always technically po= ssible in the future to introduce new opcode
or segwit versions scripts = (e.g grafroot or entroot-based pool construction), which
wouldn'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 code availa= ble to review and reason. May I kindly note
there is no reference implem= entation attached in the current BIP54 document [1]. Even,
if it's o= ften updated, it's always fruitful to have code under the eyes for revi= ew.

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

Best,
Riard
OTS hash: a= 2bb9a1faf79309b039d8ae7e0b951644ca0adb2

[0] https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail.g= mail.com/
[1] https://github.com/bitcoin/bips/blob/maste= r/bip-0054.md

Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine P= oinsot a =C3=A9crit :
= 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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-= 1d102477ccfdn%40googlegroups.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/bitcoind= ev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com.
------=_Part_194883_1859520430.1752293559120-- ------=_Part_194882_1000047287.1752293559120--