Thanks for the bench.cpp, I had a look on benchmark_sha256 and benchmark_signature_validation.
Though here few more thoughts on the 1-bit cost from the view of a DoSing peer.
Currently, we have 2 caches the signature cache and the m_script_execution_cache.
If a script has already an entry at CheckInputScripts(), bitcoin core returns true:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2185
If there is already a cache entry, and the script includes signatures (and I believe all scripts currently used for spends are using an asymmetric keypair as a lock), all the signatures are going to be pre-processed by the SignatureChecker: https://github.com/bitcoin/bitcoin/blob/master/src/script/sigcache.cpp#L63 (ECDSA) or https://github.com/bitcoin/bitcoin/blob/master/src/script/sigcache.cpp#L76 (Schnorr).
From the view of the DoSing peer, currently if you’re doing DoS with a script-based signature, for each signature associated with a pubkey committed in a redeemscript, there is a computing cost to generate fresh signature, as one has to re-generate a DER-encoded signature of the same length (IsValidSignatureEncoding() i.e > 9 bytes or < 73 bytes or CheckSchnorrSignature() i.e 64 or 65 byte), even if the signature verification check yields it’s consensus invalid. Relayed and announced invalid transactions are cached in the m_inventory_known_filter.
With a world with a hash-only lock, this is not the same computing cost anymore at all for a DoSing peer, as there is just one 1-bit to tweak in the whole CTV MAX_BLOCK_WEIGHT block. On the other hand, a signature-based DoS, you’re very quickly limited by the size and malleability space of the signature, which it’s itself constrained by the pubkey type committed in an already confirmed coin (when it’s not a chain of tx validated in the same block).
If this reasoning is correct, and please point out if there are not flaws, I could be worthy to add some policy-only rule for CTV spend, e.g MAX_CTV_INPUT_SPEND_WEIGHT or something similar, that can be accordingly adjusted in the idea.
I have no idea in terms of inputs what is the biggest transactions considered for a CTV-spend for hypothetical CTV use-cases so far.
