Sigops Limit

What Is the Sigops Limit?

The sigops limit is a consensus rule that restricts how many signature operations (sigops) a single Bitcoin block can contain. Signature verification: checking that an elliptic curve digital signature matches a public key and message: is by far the most CPU-intensive operation during block validation. Without a cap, an attacker could fill a block with thousands of signature checks, forcing every full node on the network to spend minutes (rather than seconds) verifying a single block.

The original limit was set at 20,000 sigops per block, introduced early in Bitcoin's history as a denial-of-service mitigation. When SegWit activated via BIP-141, the counting system changed to a weighted model with a budget of 80,000 weighted sigops. The limit works alongside the block size limit and block weight cap to bound the computational cost of validating any block.

How It Works

Every opcode in Bitcoin Script that triggers a signature check consumes sigops from the block's budget. When a miner assembles a block template, the total sigops across all included transactions must not exceed the limit. Transactions that would push the block over the sigops budget are excluded, just as transactions that would exceed the block weight cap are excluded.

Opcode Sigops Costs

Different opcodes consume different amounts of sigops:

Legacy counting is conservative: OP_CHECKMULTISIG defaults to 20 sigops regardless of how many keys are actually involved, unless the preceding opcode is a small push (OP_1 through OP_16). This overestimation wastes block capacity but keeps validation safe.

SegWit Weighted Counting

BIP-141 introduced a weighted sigops system that mirrors the witness discount:

• Legacy sigops (in scriptPubKey and scriptSig) cost 4 weighted sigops each
• SegWit v0 sigops (in P2WPKH and P2WSH witness scripts) cost 1 weighted sigop each
• The block-wide budget is 80,000 weighted sigops, equivalent to 20,000 legacy sigops or 80,000 SegWit sigops

The 4:1 ratio matches the weight discount for witness data (1 weight unit) versus non-witness data (4 weight units). This alignment means SegWit transactions get proportionally more sigops capacity per byte of block space they consume.

Tapscript Per-Input Budget

Tapscript (BIP-342) replaced the block-wide sigops limit with a per-input budget for Taproot script-path spends:

sigops_budget = 50 + (total_serialized_witness_size_in_bytes)

// Each successful signature check costs 50 budget units
// If budget drops below 0, the script fails

// Example: a Taproot input with 200 bytes of witness data
// Budget = 50 + 200 = 250
// Can support 250 / 50 = 5 signature checks

This design ties sigops capacity directly to witness size (and therefore to fees), creating a natural economic limit. Larger witnesses cost more in fees but earn a larger sigops budget. The ratio of 50 weight units per sigop derives from the block limits: 4,000,000 weight units divided by 80,000 sigops.

Tapscript also disabled OP_CHECKMULTISIG entirely, replacing it with OP_CHECKSIGADD. The old multisig opcode used a trial-and-skip key matching approach that is incompatible with Schnorr batch verification, so it was removed in favor of a design that supports future batch validation optimizations.

Sigops Exhaustion as an Attack Vector

Sigops exhaustion is a theoretical denial-of-service attack where a malicious miner crafts a block packed with the maximum number of expensive signature verification operations. The attack exploits an asymmetry: the miner already knows the block is valid (they built it), but every other node on the network must independently verify every signature.

The problem is compounded for legacy (non-SegWit) transactions by quadratic sighash scaling. For legacy inputs, the amount of data hashed for each signature grows with the overall transaction size. Doubling the transaction size doubles both the number of sigops and the data hashed per sigop, creating O(n²) complexity. In practice, specially crafted legacy blocks have required over 2 minutes to validate on modern hardware.

SegWit (BIP-143) solved the quadratic hashing problem for SegWit inputs by ensuring each byte only needs to be hashed at most twice, reducing complexity to O(n). However, legacy inputs remain vulnerable, and roughly 10% of current transactions still use legacy formats.

Example: Worst-Case Block Construction

// A malicious miner could construct a block like this:
// 1. Create large legacy transactions (~400KB each)
// 2. Fill each with OP_CHECKSIG operations
// 3. Each signature hash covers most of the transaction data
// 4. Quadratic scaling: 2x size = 4x validation time
//
// Result: a valid block that takes ~120 seconds to validate
// on a modern laptop, vs. ~1-2 seconds for a normal block
//
// Impact: honest miners fall behind the chain tip while
// verifying, giving the attacker a head start on the next block

The Great Consensus Cleanup Fix

The Great Consensus Cleanup proposal, originally introduced by Matt Corallo in 2019 and refined by Antoine Poinsot as BIP-54, directly addresses the sigops exhaustion problem. The fix introduces a per-transaction limit of 2,500 legacy sigops across all inputs.

This per-transaction cap complements the existing block-wide limit:

• The block-wide limit of 80,000 weighted sigops remains unchanged
• Individual transactions cannot exceed 2,500 legacy sigops in their inputs (scriptSig, scriptPubKey, and P2SH redeemScript combined)
• Coinbase transactions are exempt from the per-transaction limit
• The threshold was chosen as the tightest value that does not invalidate any non-pathological standard transaction

The result is a roughly 40x reduction in worst-case block validation time, from approximately 120 seconds down to around 10 seconds. Bitcoin Core already enforces this limit as a standardness rule (rejecting non-standard transactions at the mempool level), and BIP-54 elevates it to a consensus rule that miners must also respect.

Use Cases and Practical Implications

Transaction Construction

Wallet developers and transaction builders must account for sigops when constructing transactions. A transaction with too many sigops may be rejected by the mempool or excluded from block templates:

• Standard P2WPKH transactions use 1 sigop per input, making sigops a non-issue for typical payments
• Complex multisig setups using legacy OP_CHECKMULTISIG can consume up to 20 sigops per input, limiting how many multisig inputs fit in a single transaction
• Taproot key-path spends require zero sigops from the block budget (the signature is verified as part of the key-path validation, not counted as a script sigop)
• Using MuSig2 or FROST for multisig reduces the on-chain footprint to a single signature, consuming only 1 sigop instead of N

Mining and Block Assembly

Miners evaluate transactions by their fee rate relative to both weight and sigops consumption. A transaction that uses many sigops relative to its fee may be deprioritized in block template construction because it consumes a disproportionate share of the sigops budget.

The effective fee rate calculation in modern block assembly considers sigops as a secondary constraint alongside weight. When the sigops budget is close to exhaustion, the marginal cost of including a high-sigops transaction rises because it may crowd out other fee-paying transactions.

Layer 2 Protocols

Layer 2 systems like the Lightning Network and Spark interact with sigops limits through their on-chain transactions. Channel open and close transactions must fit within sigops budgets just like any other transaction. Protocols that use Taproot key-path spends benefit from the per-input budget model, which is more permissive for typical cooperative operations.

Risks and Considerations

Legacy Script Vulnerability Window

Until BIP-54 activates as a consensus rule, the legacy sigops limit remains exploitable by malicious miners willing to create slow-to-validate blocks. While the attack has no direct financial payoff (the miner still produces a valid block), it can degrade network performance and increase the risk of temporary chain reorganizations as nodes fall behind the chain tip during extended validation.

Backward Compatibility

Any change to sigops counting rules requires a soft fork because it tightens existing consensus rules. Transactions that were previously valid might become invalid under stricter limits. The BIP-54 threshold of 2,500 legacy sigops per transaction was specifically chosen to avoid invalidating any transaction pattern seen in the wild, but exotic scripts that push up against the old limits would need restructuring.

Interaction with Fee Markets

During periods of high network congestion, sigops-heavy transactions compete for a limited budget. If the sigops limit fills before the weight limit, some block space goes unused. In practice, this rarely happens because most modern transactions use SegWit or Taproot with efficient sigops consumption, but it remains a theoretical constraint for blocks dominated by legacy multisig transactions.

Counting Complexity

Bitcoin now has three distinct sigops counting regimes: legacy (block-wide, 4x weighted), SegWit v0 (block-wide, 1x weighted), and Tapscript (per-input budget). This complexity increases the surface area for implementation bugs in alternative node software and makes the consensus rules harder to reason about. Developers building on Bitcoin Script must understand which counting regime applies to their transaction type.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.