Make pathological transactions with more than 2500 legacy signature operations non-standard

[Antoine Poinsot]

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

[Antoine Riard]

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/
[1] https://github.com/bitcoin/bips/blob/master/bip-0054.md

[Antoine Poinsot]

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

--
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.

[Antoine Riard]

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

[Antoine Poinsot]

Hi Antoine,

Could you please clearly describe the "attack" with a clear threat model? I don't think what you describe is an issue under any realistic threat model, much less how it would only materialize with BIP54's sigop limit but not with the existing sigop limit.

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

The BIP54 specifications are written from the perspective of an implementer and clearly states "count the number of [sigops] in the input scriptSig and previous output's scriptPubKey". Signature operations in these fields preceded Segwit (which requires the scriptSig to be empty and the prevout's scriptPubKey to be pushonly).

I think there are some implications about all of this for some use-cases designers,

e.g for massive Coinjoin

Any remotely sane transaction would run into the standardness size limit before running into this limit. Only a pathological transaction which tries to increase its validation cost may run into this limit while being standard according to today's Core policy. See https://github.com/bitcoin/bips/blob/master/bip-0054.md#user-content-fn-7-21829941cd04259d86862ad3baa11d05.

Best,
Antoine

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com.

[Antoine Riard]

Hi Poinsot,

> Could you please clearly describe the "attack" with a clear threat model? I don't think what you describe is an issue under any
> realistic threat model, much less how it would only materialize with BIP54's sigop limit but not with the existing sigop limit.

Yes, for sure. So let's say you have a Coinjoin collaborated among 10 pseudonymous peers (...they rely as much as they can on
the chain as the source of truth to preserve the overall pseudonymity so hardness to evaluate "trustworthiness" of a specific peer),
where there is a single peer randomly designated as the coordinator. Each peer contributes an input towards the common transaction.

Let says the 1st participant is the coordinator, the 2nd to 9th participant are participants only contributing P2WPKH, for which
the new MAX_TX_LEGACY_SIGOPS is not a problem at all. The 10th participant deliberately contribute a legacy input with empty junk
OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS_PER_MULTISIG while being space-wise efficient.

This legacy input is of minimal satoshi value (<= to inputs 1th to 9th while still > to Coinjoin protocol-defined limit),
so the cost for the malicious 10th participant is minimized. All the inputs are assembled together in the multi-party transaction,
however this transaction is now policy invalid in reason of MAX_TX_LEGACY_SIGOPS due to the single redeem script contributed by
the 10th input.

In the lack of awareness of the policy rule by the coordinator, or by any participant if the Coinkoin protocol is fully distributed
among participants, identifying the source of error can be a hard task. Unless the latest flavour of the policy rules are run, it
might be just a generic policy error caught by the coordinator, or even worst if the transaction is just flow with a raw TX message,
in the lack of REJCT msgs to discover the source of non-propagation.
 
Of course there is always the option to bypass the policy rules by reaching out to a miner private API, though if you''re doing
a coinjoin it is less than optimal to maximize confidentiality of the flow.

Note this threat model has been already considered in the past here:
that://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2021-May/003033.txt

Those are the reasons e.g for lightning only segwit inputs are accepted to be contributed for a collaborative transaction and
other limits are checked to sanitize the flow towards policy rule ("MAY fail the negotiation if `script` is non-standard" at
`tx_add_output` reception).

Currently, the problem would exist though only if the built Coinjoin transaction would have more than 80k sigops. The reduction
to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reduction in the cost to mount that DoS attack for an adversary. I think it's
cheaper fee-wise to contribute an input to reach the ~2500 limit, than the upper 80k limit itself.

In my view, it's not really the responsibility of a full-node to care about that kind of issues for downstream softwares. However,
mentioning in release notes that the limit might affect tx collaborative construction for downstream softwares devs and that action
might have to be taken at their appreciation (as they're the ones with the best know-how about their protocols) can be a courteous
note. IMHO, assuming those kinds of threat models are realistic, it would be welcome to be more verbose everytime there is a
_tightening_ of the policy rules. Even if the _tightening_ is in view of a future consensus change, there are all the transitory
phase during which there are more exposures to those kinds of DoS.

> The BIP54 specifications are written from the perspective of an implementer and clearly states "count the number of [sigops] in
> the input scriptSig and previous output's scriptPubKey". Signature operations in these fields preceded Segwit (which requires the
> scriptSig to be empty and the prevout's scriptPubKey to be pushonly).

Yes, I read again BIP141 around writing my previous email. BIP141 clearly says that "a push of a version byte, plus a push of a
witness program. The scriptSig must be exactly empty or validation fails." So unless you have a different validation logic which
is introduced in an unknown future for any segwit spends (OP_01 to OP_16 version byte + a push of the witness program), I don't
see how the limit could be understood to be applied to segwit spends, and more concerning implemented by mistake to concern segwit
spends. For bitcoin core, the code is very proper here in `VerifyScript` and commented accordingly.

I'm still thinking it would be good BIP stylistic to have BIP54 making an explicit referral to BIP141 to define "legacy" inputs
by opposition to "segwit" inputs, which have a precise technical definition. Less a BIP is ambiguous, better it is.

> Any remotely sane transaction would run into the standardness size limit before running into this limit.

No, I'm not sure of that. I was having fun recently with scriptsig junking transaction leveraring OP_CHECKMULTISIG:
https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42
It sounds you can generate transaction which are perfectly standard (i.e under MAX_STANDARD_TX_WEIGHT) with a very high
number of sigops stuffed within. I don't remember checking all the policy rule scenarios, but MAX_STANDAD_TX_WEIGHT is
one of the rule you _cannot_ disable or turn off on the CLI iirc.

Best,
Riard
OTS hash: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac71

[Antoine Poinsot]

Antoine,

Attempting to contribute a non-standard input to a multiparty transaction creation protocol is not an "attack" nor something you can prevent participant are not trusted. I am not sure where this is going.

Regarding the test at the end of your email, it is spending p2wsh inputs. The newly introduced limit only applies to inputs spending legacy scripts. That said, it is indeed possible to create a transaction which is standard today but would run in this new limit. Otherwise introducing the limit wouldn't be necessary in the first place. My point is just that any such transaction would be pathological. Examples are constructed in the tests of the PR linked in OP. Your test, although it's using Segwit input, is also a good example of the type of pathological transactions i am talking about.

Best,
Antoine

On Monday, July 21st, 2025 at 6:14 PM, Antoine Riard <antoin...@gmail.com> wrote:

Hi Poinsot,

> Could you please clearly describe the "attack" with a clear threat model? I don't think what you describe is an issue under any
> realistic threat model, much less how it would only materialize with BIP54's sigop limit but not with the existing sigop limit.

> The BIP54 specifications are written from the perspective of an implementer and clearly states "count the number of [sigops] in
> the input scriptSig and previous output's scriptPubKey". Signature operations in these fields preceded Segwit (which requires the
> scriptSig to be empty and the prevout's scriptPubKey to be pushonly).

Yes, I read again BIP141 around writing my previous email. BIP141 clearly says that "a push of a version byte, plus a push of a
witness program. The scriptSig must be exactly empty or validation fails." So unless you have a different validation logic which
is introduced in an unknown future for any segwit spends (OP_01 to OP_16 version byte + a push of the witness program), I don't
see how the limit could be understood to be applied to segwit spends, and more concerning implemented by mistake to concern segwit
spends. For bitcoin core, the code is very proper here in `VerifyScript` and commented accordingly.

I'm still thinking it would be good BIP stylistic to have BIP54 making an explicit referral to BIP141 to define "legacy" inputs
by opposition to "segwit" inputs, which have a precise technical definition. Less a BIP is ambiguous, better it is.

> Any remotely sane transaction would run into the standardness size limit before running into this limit.

No, I'm not sure of that. I was having fun recently with scriptsig junking transaction leveraring OP_CHECKMULTISIG:
https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42
It sounds you can generate transaction which are perfectly standard (i.e under MAX_STANDARD_TX_WEIGHT) with a very high
number of sigops stuffed within. I don't remember checking all the policy rule scenarios, but MAX_STANDAD_TX_WEIGHT is
one of the rule you _cannot_ disable or turn off on the CLI iirc.

Best,
Riard
OTS hash: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac71

[Antoine Riard]

Hi Poinsot,

> Attempting to contribute a non-standard input to a multiparty transaction creation protocol is not an "attack" nor something you can prevent participant are not trusted

I agree there is a sense of proportion to have for sure. It's not an attack in the sense of loss of funds
for a second-layers failing to include a time-sensitive tx, typically a commiment tx. But if you're a participant
in a multi-party flow and you're deliberately contributing a non standard input to a collaborative tx, because
you know that the software of the collaborative tx finalizer won't verify and tx propagation will fail, what it
is if it's not DoS attack, I don't know.

One has to put itself in the shoes of a LSP, for which liquidity to allocate is scarce (in a world where
`MAX_MONEY` is true), and of which its propagation collaborative tx allocating liquidity is DoSed. E.g if you
take core-lightning, i think a software you're familiar with, it implements such standardness script sanitization
during the collaborative flow construction (in `common/interactivetx.c`):

            /* BOLT #2:
                         * The receiving node: ...
                         * - MAY fail the negotiation if `script`
                         *   is non-standard */
                        if (!is_known_scripttype(scriptpubkey, tal_bytelen(scriptpubkey)))
                                return tal_fmt(ctx, "Script is not standard");

For the how to you sort trusted vs non-trusted participant in a collaborative txn flow, on the image
of a coinjoin or lightning dual-funding, it's not a solved problem. Especially if the idea is to automate
as much as you can of the protocol flow, without necessarily Bob the sysadmin manually clicking on each
`tx_add_input` proposal from each multi-party tx participant to allow them in at 3AM in the morning...

Of course Bob can be very successful in sorting standard vs non-standard input, but still he would have to
be aware of the standardness rules, documented somewhere.

See that old email, the alternatives the end which is detailing this DoS threat model in a realistic fashion:
https://gnusha.org/pi/bitcoindev/CALZpt+HXB=xh3qtxJFM7yUzRu1uj-pPtLQmT=5QV0dN...@mail.gmail.com/

> Regarding the test at the end of your email, it is spending p2wsh inputs. The newly introduced limit only applies to inputs spending legacy scripts. That said, it is indeed possible to create a transaction which is standard today but would run in this new limit. Otherwise introducing the limit wouldn't be necessary in the first place. My point is just that any such transaction would be pathological. Examples are constructed in the tests of the PR linked in OP. Your test, although it's using Segwit input, is also a good example of the type of pathological transactions i am talking about.

True, my test spending p2wsh inputs. But it was a demo on how you can generate space-wise efficient scriptsig junking tx under
the MAX_STANDARD_TX_WEIGHT by leveraging the MAX_PUBKEYS_PER_MULTISIG account limit. MAX_SCRIPT_SIZE is the same for legacy and
SegWit V0.

The point being, and in my understanding where we're diverging, is that this new limit should be in a best effort reflected
in multi-party tx softwares that are accepting contributing input for collaborative tx flow. Lack of adherence of this new
limit might lead them to exposure the style of DoS described above, as they might start to take part in pathological tx
post 0.30.

I fully grant it's somehow lightweighted by the fact it generally takes 2 or 3 releases of bitcoin core to have a new policy
rule widely deployed on the network, and until then it's okay if the multi-party tx stack do not upgrade its own full-node
(i.e the initial tx broadcaster), as it's should still find among its tx-relay peers "pathological"-acceptance nodes for a while.

Best,
Riard
OTS hash: 610a08345b4e79f0203904948b2ad2f689140ae0373732b31d6d981756e2e698