Block sigop limit

Signature checking costs a node time, so consensus meters that work in its own budget rather than charging it against block space. BIP141 set the meter at 80,000 units and priced every legacy signature operation at four of them, quadrupling an older ceiling of 20,000. A normal single key or Taproot withdrawal spends a handful of units, so the ceiling is invisible to almost everyone who moves coins.

How it works

The block sigop limit is a running total, added up transaction by transaction as a node connects a block, and a block whose total passes 80,000 is invalid.

Nothing is executed to produce it: a node scans script bytes and tallies opcodes, so a signature check in a branch the spend never takes is charged in full. The pessimism is deliberate: a node has to know a block is affordable before it verifies anything.

Three tallies are summed, and they do not all land on the same transaction. The legacy tally reads a transaction's own input scripts and its own output scripts, multiplied by four, so an operation written into a scriptPubKey is billed to whoever creates the output rather than to whoever spends it later. The pay to script hash tally reads the redeem script a spending input reveals, also multiplied by four. The witness tally counts at face value: one unit for a P2WPKH input, and a P2WSH script charged exactly as it would have been under P2SH.

One difference between those scans costs real money. The P2SH and witness readings apply BIP141's discount, where OP_CHECKMULTISIG preceded by OP_1 to OP_16 counts as one to sixteen rather than the flat twenty; the legacy scan never applies it. A bare two of three multisig output is charged the full twenty operations, eighty units of budget, and charged at creation.

Tapscript left the budget altogether. BIP342 took tapscript signature operations out of the block wide 80,000 and gave each script its own allowance: 50 units, plus the serialized size of that input's witness, decremented by 50 every time a signature opcode runs with a real signature attached. Fifty is four million weight divided by eighty thousand sigops, the ratio between the two ceilings.

Where you see it

Relay policy meets the block sigop limit well before consensus does, through three Bitcoin Core constants tighter than the network rule.

One transaction may claim no more than a fifth of the block budget, 16,000 units. A standard pay to script hash input may reveal a redeem script holding at most 15 signature operations. A third count reads non witness operations where they can actually run rather than where they sit, and stops relay above 2,500 per transaction; it reads the scriptPubKey being spent, which the block wide tally already charged at creation.

The limit also reaches your fee. Bitcoin Core's bytespersigop setting, 20 by default, replaces a transaction's weight with the larger of its real weight and its sigop cost times twenty, so a transaction heavy in signature operations for its size is priced as bigger than it is. Creating a bare multisig output is the ordinary way to trip it.

Miners meet the budget as a second constraint alongside weight, which BIP342 gives as its reason for taking tapscript out: two ceilings make block construction harder than one. Core reserves 400 units for the coinbase outputs before filling a template.

Block sigop limit vs block weight

Block weight counts data and the block sigop limit counts verification work, and a block is full the moment it reaches either ceiling. Weight is the ceiling an ordinary block hits first, because a P2WPKH input costs one unit and a Taproot spend adds nothing at all, so the sigop budget decides the outcome only for a block loaded with old style script. Divide one ceiling by the other and you get 50 weight units per signature operation, the ratio BIP342 reused to price the tapscript budget and the closest thing the protocol has to an exchange rate between bytes and signature checks.