Enforcing Weight and SigOps Limits in Candidate Block Construction

When a miner builds a candidate block template, their selection algorithm is bounded by two separate multidimensional consensus constraints: Block Weight Limits and Signature Operations (SigOps) Limits. If a candidate block violates either of these parameters, it is classified as invalid and will be instantly rejected by validating nodes on the network.

This guide details how these resource limits are calculated and how miners solve the multidimensional knapsack problem during block construction.

---

⚖️ 1. Block Weight Limits and Witness Discounts

Prior to the SegWit upgrade in 2017, blocks were restricted by a static limit of 1 Megabyte ($1,000,000\text{ bytes}$) of raw serialized data. Today, blocks are regulated based on Weight Units (WU), with a maximum consensus cap of 4,000,000 WU.

                        SEGWIT BLOCK WEIGHT CALCULATIONS

 ┌───────────────────────────────────────┬─────────────────────────────────┐
 │ Base Transaction Data (Non-Witness)    │ Witness Data (SegWit Signatures)│
 │ • Inputs, Outputs, Tx Headers         │ • Witness stack arrays, Sigs    │
 │ Weight: 4 WU per Byte                 │ Weight: 1 WU per Byte           │
 └───────────────────────────────────────┴─────────────────────────────────┘

The Weight Formula

The total weight of a transaction (and ultimately the entire block) is defined by separating non-witness base bytes from SegWit witness bytes:

$$\text{Weight} = (\text{Base Size in Bytes} \times 4) + (\text{Witness Size in Bytes} \times 1)$$

Virtual Size (vSize)

To map this back to standard byte-metric measurements, wallets and block explorers use Virtual Size (vSize), which is simply transaction weight divided by 4:

$$\text{vSize} = \frac{\text{Weight}}{4}$$

This 4-to-1 witness discount encourages users to adopt SegWit addresses, reducing blockspace congestion while expanding the effective block capacity up to approximately 2.3 Megabytes of raw data under standard transaction distributions.

---

🔒 2. SigOps Limits (Signature Operations)

While block weight limits restrict bandwidth and disk storage, SigOps Limits protect a node's CPU from validation exhaustion.

A SigOp (Signature Operation) represents a single cryptographic signature verification execution (such as OP_CHECKSIG, OP_CHECKSIGVERIFY, or OP_CHECKMULTISIG). Cryptographic signature operations are highly CPU-intensive. If a miner were to construct a 4,000,000 WU block stuffed entirely with complex multisig scripts, validating nodes could take several minutes to verify the block, locking up the network.

The Consensus Cap

To prevent this, Bitcoin Core limits the total number of SigOps in a single block to a maximum of:

$$\text{SigOp Limit} = \mathbf{20,000 \text{ SigOps}}$$

How SigOps are Counted

• Legacy Scripts: Standard public key scripts count as 1 SigOp per execution block.
• Multisig Scripts (OP_CHECKMULTISIG): Counts as $N$ SigOps where $N$ represents the maximum public key limit in the multisig group (e.g., a 2-of-3 multisig counts as 3 SigOps).
• SegWit and Taproot: SegWit introduces a refined counting mechanism where SigOps are counted based on the actual number of signatures included in the witness vector.

---

🎒 3. Solving the Multidimensional Knapsack Problem

The miner's block assembly engine must act as a greedy multidimensional knapsack optimizer.

The Problem

The miner wants to fill a container (the block) to maximize the total fee value $V$, while staying within two independent resource boundaries: $$\begin{aligned} \text{Maximize: } & \sum_{i=1}^{n} \text{Fee}(Tx_i) \ \text{Subject to: } & \sum_{i=1}^{n} \text{Weight}(Tx_i) \le 4,000,000 \text{ WU} \ \text{And: } & \sum_{i=1}^{n} \text{SigOps}(Tx_i) \le 20,000 \text{ SigOps} \end{aligned}$$

The Miner's Approach

1. High Feerate, Low SigOps: The algorithm prefers transaction packages with a high ratio of fee to weight, and low SigOp validation requirements.
2. SigOp Exhaustion: If the block reaches 20,000 SigOps before hitting 4,000,000 WU, the miner must stop adding signature-heavy transactions. They will instead fill the remaining blockspace with low-SigOp transactions (e.g., standard SegWit transactions) even if those transactions carry lower overall feerates.