This guide explains BIP 11 M-of-N transactions in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 11 M-of-N transactions made a limited form of bare multisignature output standard for relay and mining. It used CHECKMULTISIG directly in the output script so any M signatures from N listed public keys could spend.
- Why it matters: BIP 11 established practical standard bare multisignature relay, but modern multisig should use a supported script wrapper, explicit descriptors and independently verified custody controls. The M-of-N equation is only one layer of a recoverable signing system.
- Current position: The proposal is deployed historically, but modern custody normally wraps policies in P2SH, SegWit or Taproot constructions that improve address handling, weight and privacy.
BIP 11 M-of-N transactions in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the proposal as giving each transaction a limited allowance of computer work. Simple operations use a little of that allowance and expensive operations use more. If a script uses the whole allowance, validation stops.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Taproot:
- A Bitcoin upgrade that added new signature and script options for spending outputs.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
What M-of-N means
N public keys are committed in the locking script and the spending condition requires at least M valid signatures. A two-of-three policy can tolerate one unavailable key while preventing a single key from spending. The arithmetic says nothing about who controls each key, how devices are separated or how recovery is governed; those remain custody-design decisions.
Bare multisignature script
The output script places M, the public keys, N and CHECKMULTISIG directly on chain. A spender supplies the required signatures plus the historical dummy stack item consumed by CHECKMULTISIG. Every node sees the complete key set at funding time. This is distinct from script-hash designs that reveal the redeeming policy only when an output is spent.
Standardness versus consensus
BIP 11 changed the standard transaction policy used for relay and mining, within scripts that consensus could already evaluate. A non-standard transaction can still be consensus valid if a miner includes it. Wallets should not rely on that distinction casually: weak relay support can make a valid transaction difficult to propagate or fee-bump during an incident.
Key-count and sigop constraints
The proposal constrained bare multisig to small key counts to limit signature-operation cost and encourage predictable relay. CHECKMULTISIG contributes sigops that block construction must count. A transaction fitting the weight limit can still violate sigop constraints. Template builders validate the complete script and resource rules rather than estimating only bytes or fee rate.
A wallet policy limit may be stricter again, so relay, block validity and product support should be reported separately.
Why P2SH became preferable
P2SH lets the funding output commit to a script hash and uses a compact address, moving the full redeem script into the spending input. It improved sender usability and deferred script data. Native SegWit and Taproot later changed cost and privacy trade-offs again. Bare BIP 11 output is therefore historical context, not the default modern multisig recommendation.
Custody risks beyond the script
Cosigners need independent keys, verified wallet policy, secure backups, change recognition and a tested recovery quorum. Malware can propose an authorised but fraudulent destination to every signer. A coordinator can withhold data or reorder keys. Each hardware display should verify the transaction, while descriptors record key origins, script type and derivation paths.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is BIP 11 M-of-N Standard Transactions?
BIP 11 M-of-N transactions made a limited form of bare multisignature output standard for relay and mining. It used CHECKMULTISIG directly in the output script so any M signatures from N listed public keys could spend.
Is BIP 11 M-of-N Standard Transactions active or supported today?
The proposal is deployed historically, but modern custody normally wraps policies in P2SH, SegWit or Taproot constructions that improve address handling, weight and privacy.
Why does BIP 11 M-of-N Standard Transactions matter?
BIP 11 established practical standard bare multisignature relay, but modern multisig should use a supported script wrapper, explicit descriptors and independently verified custody controls. The M-of-N equation is only one layer of a recoverable signing system.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 11 established practical standard bare multisignature relay, but modern multisig should use a supported script wrapper, explicit descriptors and independently verified custody controls. The M-of-N equation is only one layer of a recoverable signing system.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
