Page MenuHomePhabricator
Create Task
Maniphest T657

New sigops counting
Closed, ResolvedPublic
Actions

Description

Some ideas on how to properly count sigops. Let's call it sigops2.

  • Obviously, sigops2 should only be counted during actual input script execution. That means no counting in scriptpubkey, coinbase scriptsig, ...
  • Let's take advantage of NULLFAIL:
    • NULL signatures should count as no sigops2.
    • Make it so that sigops2 can be counted without evaluating any signature verifications (but otherwise executing script).
    • So, ECDSA M-of-N multisig should count as N sigops2 (unless null sigs), while Schnorr M-of-N multisig should count as M sigops2 (unless null sigs).
  • Even though CHECKSIG is more expensive hashing-wise than CHECKDATASIG, we count both as one sigops2.
  • A sensibly chosen sigops2 *density limit* evaluated *per-tx* makes sense as it means we don't need to worry about sigops2 limits in block validation / template creation at all. If it got into mempool, it's good!
    • This should not be so strict however, that regular activity needs to pad the transactions. A reasonable lower limit: 1-of-6 P2SH multisig with ECDSA would count as 6 sigops, at only 318 bytes! So the current block density limit of sigops1 (1 per 50 bytes) also makes sense for sigops2.
    • At the ultimate limit of reasonable use we can consider 1-of-20 P2SH multisig which clocks in at 799 bytes
    • Bare multisig is so rare that it's fine to ask them to pad. Note that even a 2-of-3 bare multisig spent using ECDSA is 187 bytes per input even; you need unusual cases of bare multisig to get high density (1-of-3 when spent using ECDSA: 114 bytes per input).
    • It is easily possible to make weird scripts that have high density (<sig> <pub> OP_DUP2 OP_CHECKSIGVERIFY OP_DUP2 OP_CHECKSIGVERIFY OP_DUP2 OP_CHECKSIGVERIFY ...). These are the abusive cases that we want to exclude -- not just when they fill entire blocks, but we also want to exclude them from mempool and from mining entirely!!
  • If public signature aggregation (SigAgg) -- one schnorr signature for many pubkeys -- is introduced, this will add a new wrinkle. Note that SigAgg still requires elliptic curve operations on each pubkey, so it's not massively cheaper and we still need to assign some kind of resource consumption.