Page MenuHomePhabricator

New sigops counting
Open, Needs TriagePublic


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.

Event Timeline

markblundeberg updated the task description. (Show Details)
markblundeberg updated the task description. (Show Details)
markblundeberg updated the task description. (Show Details)May 21 2019, 22:45
markblundeberg updated the task description. (Show Details)May 21 2019, 23:11