P2MS Consensus Limits

While Bitcoin is theoretically very flexible, it has strict limits on how large a multisig script can be. These limits prevent attackers from creating "Nuke Transactions" that could crash a node by forcing it to verify thousands of signatures at once.

1. Standardness vs. Consensus

There are two layers of rules in Bitcoin:

• Consensus Rules: Hard rules. A block that breaks these is invalid and will be rejected.

• Standardness Rules: Policy rules. Nodes will refuse to relay or accept into mempool transactions that break these, even if they are technically valid.

2. The 3-Key Relay Limit

For "Bare" P2MS (where the keys are in the ScriptPubKey), most nodes will only relay transactions with N \u2264 3.

• If you try to send a 4-of-4 bare multisig, it likely won't even reach a miner.

• This limit exists because bare multisig scripts are stored in the UTXO Set, and large scripts cause "UTXO Bloat."

3. The 20-Key Consensus Limit

The absolute maximum for OP_CHECKMULTISIG is 20 keys.

• Even if you use P2SH (which hides the script), the script itself cannot list more than 20 public keys.

• This is a hard limit in the Bitcoin source code to prevent CPU exhaustion.

4. SigOp Limits

Every signature verification is called a SigOp (Signature Operation).

• A block is limited to 80,000 SigOps.

• A 20-of-20 multisig uses 20 SigOps. Miners must carefully calculate the number of SigOps in a transaction to ensure their block remains within these consensus bounds.

Context	Limit	Rule Type
Bare P2MS Relay	3 Keys	Standardness
Absolute Max Keys	20 Keys	Consensus
Max Block SigOps	80,000	Consensus

In the final section, we will build a Python P2MS Auditor.