public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Antoine Riard <antoine.riard@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard
Date: Mon, 07 Jul 2025 21:46:58 +0000	[thread overview]
Message-ID: <MAx6mRL1iR7e7zNHtWs39IvM2y0rSJQxLZEEyic_LAcA-QzuuursCSRH8zuTaqum8rMXYFdyJZO6wGcX5dRP7gyx8iwZNgjFP5VDNxYEJLw=@protonmail.com> (raw)
In-Reply-To: <eb191c75-e245-4c40-8288-1d102477ccfdn@googlegroups.com>

[-- Attachment #1: Type: text/plain, Size: 11422 bytes --]

This limit only concerns legacy signature operations. Off-chain constructions use Segwit inputs, as they would be trivially broken by txid malleability otherwise.

On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard <antoine.riard@gmail.com> wrote:

> 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 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-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 would make a hard-limit
> for the number of participants entering in such construction, 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 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 careful 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 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 available to review and reason. May I kindly note
> there is no reference implementation attached in the current BIP54 document [1]. Even,
> if it's often updated, it's always fruitful to have code under the eyes for review.
>
> This might be the kind of concern (very) far down the line...but preserving the
> evolvability of the consensus rules is a good property to care about, in my humble
> opinion.
>
> Best,
> Riard
> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2
>
> [0] https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/
> [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
>
> Le mercredi 2 juillet 2025 à 09:54:33 UTC+1, Antoine Poinsot a écrit :
>
>> Hi everyone,
>>
>> To mitigate high block validation time, BIP54 proposes to make transactions 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 transaction invalid.
>>
>> No transaction in Bitcoin's history would have both hit the BIP54 sigop 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 ever 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 the hashrate won't create a
>> block containing such a transaction.
>>
>> Doing so gives better guarantees in case BIP54 is ever considered for activation, 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 implements this change, which i
>> hope to get into the upcoming 30.0 release as well as backported to previous 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 "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/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com.

-- 
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/MAx6mRL1iR7e7zNHtWs39IvM2y0rSJQxLZEEyic_LAcA-QzuuursCSRH8zuTaqum8rMXYFdyJZO6wGcX5dRP7gyx8iwZNgjFP5VDNxYEJLw%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 13355 bytes --]

      reply	other threads:[~2025-07-07 22:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-02  8:47 [bitcoindev] Make pathological transactions with more than 2500 legacy signature operations non-standard 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-03 18:18 ` [bitcoindev] " Antoine Riard
2025-07-07 21:46   ` 'Antoine Poinsot' via Bitcoin Development Mailing List [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='MAx6mRL1iR7e7zNHtWs39IvM2y0rSJQxLZEEyic_LAcA-QzuuursCSRH8zuTaqum8rMXYFdyJZO6wGcX5dRP7gyx8iwZNgjFP5VDNxYEJLw=@protonmail.com' \
    --to=bitcoindev@googlegroups.com \
    --cc=antoine.riard@gmail.com \
    --cc=darosior@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox