Sigop Budget (Tapscript)

The sigop budget is Tapscript's mechanism (BIP 342) for limiting the computational cost of signature checking within a single spending input. Instead of counting signature operations against a rigid block-wide ceiling the way legacy Bitcoin does, Taproot gives each script-path input its own allowance: 50 plus the total serialized size in bytes of that input's witness (including its CompactSize length prefix). A bigger witness — which already costs more in fees — buys a proportionally bigger budget for signature verification. Small script, small budget; the two can never drift far apart.

How the budget is spent

Every time the script executes a signature-checking opcode — OP_CHECKSIG, OP_CHECKSIGVERIFY, or the Tapscript-native OP_CHECKSIGADD — with a non-empty signature, the budget is decremented by 50. The moment it would go below zero, script execution fails immediately. Opcodes called with an empty signature cost nothing, which is a deliberate and elegant detail: in a multisig or conditional script, the branches and key slots you do not use are free. A 2-of-5 multisig spend pays for two real signature checks, not five potential ones — the budget follows actual verification work, not script structure. Since every real Schnorr signature adds at least 64 witness bytes, honest spends effectively fund their own verification with room to spare; only scripts contrived to check signatures without carrying them run out.

Why tie it to witness size

The design neutralizes an old denial-of-service vector. In legacy script, an attacker could craft transactions dense with signature operations, forcing every validating node to perform disproportionate elliptic-curve work per byte of block space; Bitcoin's answer was a crude global cap (80,000 weighted sigops per block) that complicated mining and block assembly. Tapscript's per-input budget makes validation cost intrinsically proportional to the fees a spender already pays for witness weight, so a transaction simply cannot pack in more verification work than its own size justifies. Crucially, Tapscript sigops do not count toward the legacy block-wide limit — the per-input budget supersedes it entirely. For miners this is a quiet simplification: block template construction no longer has to juggle a separate sigop constraint for Taproot spends, because fee-per-weight already prices in the verification burden. Anyone running a full node gets the corresponding guarantee that no block can weaponize Taproot scripts to bog down validation — a defense that protects modest home-node hardware most of all, and with it the network's decentralization.

Designed for a future it cannot see

The sigop budget is one of two forward-looking design choices in Tapscript, the other being the upgrade hooks described under OP_SUCCESS. Together they let Bitcoin's script layer grow — new opcodes, new signature modes, bigger scripts — without re-litigating resource limits at each step, because the budget rule scales automatically with whatever witnesses future scripts carry. It is a characteristically Bitcoin piece of engineering: a one-line accounting rule, invisible to every normal user, that quietly guarantees the cost of validating the chain stays tied to the fees paid to write to it.

The budget also illustrates a broader Bitcoin design pattern worth internalizing: resource limits phrased as local, per-unit rules compose better than global ceilings. A per-input allowance needs no coordination between transactions, no special cases in mempool acceptance, and no strategy games between miners assembling competing templates — each input carries its own arithmetic and passes or fails alone. Protocol designers reach for this shape whenever validation cost must track economic cost, and Tapscript's version has run in production since Taproot's activation in November 2021 without incident. For script authors the practical guidance is short: carry a signature for every check you execute, and the budget will never be the thing that fails your spend.