This guide explains BIP 19 M-of-N Standard Transactions (Low SigOp) 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 19 proposed standard multisignature transaction templates built from CHECKSIG, CHECKSIGVERIFY, SWAP, ADD and EQUAL rather than CHECKMULTISIG. The goal was to avoid the historical rule that charged an unqualified CHECKMULTISIG as twenty signature operations.
- Why it matters: BIP 19 explored a clever way to reduce multisignature sigop cost with existing opcodes, but it closed without becoming the modern standard. Current custody should use maintained descriptor and PSBT workflows with explicit recovery controls.
- Current position: The proposal is Closed and is not the format to choose for modern multisignature custody.
BIP 19 M-of-N Standard Transactions (Low SigOp) 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.
- PSBT:
- A portable format for passing an unsigned or partly signed Bitcoin transaction between tools and signers.
- 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.
The sigop motivation
Bitcoin limits signature operations per block to bound validation cost. At the time, CHECKMULTISIG could be conservatively charged as twenty sigops, sharply limiting transaction density. BIP 19 explored equivalent small quorum policies composed from individually counted CHECKSIG operations to make the accounting closer to the actual number of keys.
All-signatures template
For an N-of-N policy, each public key was followed by CHECKSIGVERIFY, requiring every signature to pass in sequence. Failure stopped execution immediately. The simple shape reduced sigop overcounting but exposed every public key and produced a non-standard construction that wallets still had to coordinate correctly.
Threshold template
The proposed M-of-N form evaluated signatures against public keys, used SWAP to arrange stack items, added the Boolean results and compared the total with the threshold. Stack order and signature matching were consensus execution details, not explanatory notation. A missing or reordered item could invalidate an otherwise intended quorum.
Policy boundaries
The templates were limited to small key counts and accompanied by a larger standard scriptSig allowance. Existing nodes could evaluate the opcodes as consensus-valid script, yet old relay and mining policy would not treat the construction as standard. Broadcast reliability therefore depended on adoption beyond raw script validity.
Custody examples and limits
The BIP discussed wallet protection services and buyer-seller-agent escrow. Those examples assume communication, identity, backups and dispute processes outside Script. A two-of-two service can strand funds when the provider disappears unless the user retains a tested recovery route; a two-of-three escrow is only as fair as its key and evidence procedures.
Why modern designs differ
BIP 11 standardised small bare CHECKMULTISIG, P2SH improved sender usability, and later SegWit and Taproot constructions changed weight and privacy options. Descriptors and PSBT now coordinate policies more reliably. BIP 19 remains a useful resource-accounting experiment rather than a maintained wallet target.
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 19 Low-SigOp Multisignature?
BIP 19 proposed standard multisignature transaction templates built from CHECKSIG, CHECKSIGVERIFY, SWAP, ADD and EQUAL rather than CHECKMULTISIG. The goal was to avoid the historical rule that charged an unqualified CHECKMULTISIG as twenty signature operations.
Is BIP 19 Low-SigOp Multisignature active or supported today?
The proposal is Closed and is not the format to choose for modern multisignature custody.
Why does BIP 19 Low-SigOp Multisignature matter?
BIP 19 explored a clever way to reduce multisignature sigop cost with existing opcodes, but it closed without becoming the modern standard. Current custody should use maintained descriptor and PSBT workflows with explicit recovery controls.
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 19 explored a clever way to reduce multisignature sigop cost with existing opcodes, but it closed without becoming the modern standard. Current custody should use maintained descriptor and PSBT workflows with explicit recovery controls.
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.
