* [bitcoindev] Make pathological transactions with more than 2500 legacy signature operations non-standard
@ 2025-07-02 8:47 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-03 18:18 ` [bitcoindev] " Antoine Riard
0 siblings, 1 reply; 4+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-07-02 8:47 UTC (permalink / raw)
To: Bitcoin Development Mailing List
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/49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard
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 ` Antoine Riard
2025-07-07 21:46 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
0 siblings, 1 reply; 4+ messages in thread
From: Antoine Riard @ 2025-07-03 18:18 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10615 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 11769 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard
2025-07-03 18:18 ` [bitcoindev] " Antoine Riard
@ 2025-07-07 21:46 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-12 4:12 ` Antoine Riard
0 siblings, 1 reply; 4+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-07-07 21:46 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard
2025-07-07 21:46 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2025-07-12 4:12 ` Antoine Riard
0 siblings, 0 replies; 4+ messages in thread
From: Antoine Riard @ 2025-07-12 4:12 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 15201 bytes --]
Hi Poinsot,
Not necessarily, if you go to multi-sign the first input of your
second-stage txn with
SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence are
not commited.
The second input can 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 order
tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and
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
in validating
a transaction. It applies to all transactions in the block except the
coinbase transaction.
For each input in the transaction, count the number of CHECKSIG and
CHECKMULTISIG in the
input 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 must be always empty (`scriptSig.size() !=
0 in
`VerifyScript()`) and b) a witness program must be a data push and as such
it's
never a scriptCode that can contain a CHECKSIG ops. Accounting is
implicitly always
0 for Segwit spends.
There is no definition of what make a spend 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
is properly dissociating the verifcation of the legacy spends from the
witness 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 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
designers,
e.g for massive Coinjoin, if in the collaborative transaction construction
any party
proposes a scriptpubkey with a huge number of sigs to reach the limit, now
if you
don't verify the 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 remove.
While this is not a concern for lightning (bc the dual funding spec
explictly
requests segwit input at `tx_add_input` reception), I'm not sure for any
coinjoin
or multi-party tx construction stuff that 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
the
potential implications of the deployment of this rule, as soon as it's
policy.
Best,
Riard
OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc902
Le lundi 7 juillet 2025 à 23:25:02 UTC+1, Antoine Poinsot a écrit :
> 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 <antoin...@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-...@mail.gmail.com/
> <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+...@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/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17827 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-07-13 0:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2025-07-12 4:12 ` Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox