Signature Operations (Sigops)

Signature operations, universally shortened to "sigops," are a count of the signature-verifying opcodes inside a transaction's scripts. Because checking an ECDSA or Schnorr signature is computationally expensive relative to other script operations, Bitcoin caps the total sigops allowed in a block to bound the worst-case CPU cost of validating it. This prevents an adversary from crafting a block that is cheap in bytes but ruinously slow to verify — a denial-of-service vector against every full node on the network.

The limits

The consensus block limit is MAX_BLOCK_SIGOPS_COST = 80,000 weighted sigops. For relay standardness, a single transaction may carry at most one-fifth of that — 16,000 sigops cost — or it is rejected as non-standard by default-policy nodes. The counting rules carry history in them: OP_CHECKSIG and OP_CHECKSIGVERIFY each count as one sigop, while legacy OP_CHECKMULTISIG counts as a flat twenty regardless of how many keys it actually checks — unless executed in the post-SegWit "accurate" mode, where the cost reflects the real number of public keys. The pessimistic flat count exists because pre-SegWit counting happened without executing the script, so the node could not know how many keys were involved. Weighting follows the SegWit discount: legacy sigops count four times, witness sigops once, mirroring how block weight itself is measured.

Sigops as a block resource

Sigops act as a second scarce resource alongside block weight, and miners assembling templates must respect both. A block can hit the sigop ceiling before it fills on weight — imagine it stuffed with bare-multisig outputs — so template code like Bitcoin Core's getblocktemplate selects transactions against a two-dimensional budget, and a transaction dense in sigops but light in fees is genuinely less attractive than its feerate suggests. In practice ordinary traffic sits nowhere near the ceiling, which is precisely the design intent: the limit exists for the adversarial case, invisible in the normal one. Pool software and solo-mining stacks inherit this bookkeeping; it is one of several correctness details that make template construction less trivial than "sort by feerate."

Taproot's cleaner model

Tapscript changed the accounting. Under BIP342, each signature-checking opcode in a Taproot script spend consumes from a per-input sigops budget of one signature per 50 witness weight units, rather than counting against the global 80,000-cost ceiling. The elegance is that signature cost becomes directly tied to the witness bytes the spender already paid fees on: you cannot buy disproportionate CPU time without buying proportionate block space. Taproot also dropped OP_CHECKMULTISIG entirely in favour of OP_CHECKSIGADD, which counts sanely and enables batch-verifiable multisig — one more legacy wart removed.

Why it matters beyond protocol trivia

Sigop limits are a small, concrete example of Bitcoin's deepest engineering bias: every rule bounds the cost of verification, because cheap verification is what lets a modest machine in a home validate the same chain as a datacenter. The limits keep the "verify" in verify, don't trust affordable. Sigop accounting is one of several checks a transaction must satisfy to be relayed — see standardness for the full set of policy checks and mempool policy for how nodes apply them.

The limit's history is instructive: the original consensus rule allowed 20,000 sigops per one-megabyte block, a blunt early defense against scripts stuffed with signature checks, and SegWit carried it forward by scaling it four-fold into the weighted 80,000-cost ceiling alongside block weight. Like several of Bitcoin's odder constants, it reads as arbitrary until you see the attack it forecloses — then it reads as a scar with a lesson attached. Most of Bitcoin's consensus constants have a story like this one: someone found the expensive edge case, and the rule is what remains of the argument.