BIP-11
应用层｜Deployed（已采用）｜把“需要 N 个公钥中的至少 M 个签名才能花费”的交易，定为可被节点默认转发、矿工默认打包的标准交易类型。
一、档案卡
| 编号 | BIP-11 |
|---|---|
| 标题 | M-of-N Standard Transactions |
| 作者 | Gavin Andresen <[email protected]> |
| 指定日期 | 2011-10-18 |
| 讨论日期 | 2011-10-02 |
| 层级 | Applications（应用） |
| 类型 | Specification |
| 状态 | Deployed（已采用） |
| 阅读版 | https://bips.dev/11 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki |
二、放在哪一族
多签与标准交易族的早期关键文档。协议里早已有 OP_CHECKMULTISIG，但在 BIP-11 之前，这类交易属于“非标准”：多数节点不转发，矿工也未必打包，实际很难用。
BIP-11 把它推进为标准交易（在 n ≤ 3 的限制下）。后续演进包括：
BIP-13：P2SH 地址格式
BIP-16：Pay to Script Hash，把复杂脚本哈希进地址，多签更易用
再往后：SegWit、Taproot、描述符与现代多签钱包实践
理解 BIP-11，是理解“为什么比特币能做多人授权、托管、企业资金管控”的起点。
三、它要解决什么
3.1 受保护钱包（Wallet Protection Service）
采用 2-of-2：一把签名来自用户电脑上的钱包（可能已中毒），另一把来自钱包保护服务（WPS）。用户发起转账时，客户端把拟交易发给 WPS；WPS 再向用户确认“是否本人发起、金额与收款是否正确”，双方都签才生效。
文档特别提醒：用户应要求 WPS 提供所用私钥的备份，并离线安全保存，以免服务商倒闭后资金被锁死。客户端与 WPS 如何通信，不在本 BIP 范围内。
3.2 三方托管（买方、卖方、仲裁方）
采用 2-of-3：买方、卖方、可信仲裁人各提供一个公钥。买方把币打入 2-of-3 的 CHECKMULTISIG 输出，并把交易 ID 告知卖方与仲裁人。
- 履约顺利：卖方先签名，买方再联署，资金付给卖方；
- 发生争议：仲裁人与买方或卖方中的任一方合作，即可决定资金去向。
三方如何交换公钥与签名，同样不在本 BIP 范围内。
3.3 其他
凡是“赎回资金需要不止一个签名”的场景——公司资金需多人签字、共享账户、简单治理安排等——都可以落在 M-of-N 模型上。
核心障碍不在操作码（OP_CHECKMULTISIG 已存在），而在网络策略：非标准交易难以进内存池、难以被挖出。BIP-11 要做的，就是把限定条件下的多签交易升为标准类型。
四、规则本身
4.1 标准锁定脚本（scriptPubKey）
节点应转发、矿工应纳入区块的标准形式为：
m <pubkey> ... <pubkey> n OP_CHECKMULTISIG
其中：
- m：至少需要多少个有效签名；
- n：提供的公钥个数，且 n ≤ 3；
- 中间为 n 个公钥。
限制 n ≤ 3，是为了在当时客户端限制下仍可实用，并控制脚本体积与验证成本。
4.2 标准解锁脚本（scriptSig）
OP_0 <signatures> ...
前面的 OP_0 是占位：OP_CHECKMULTISIG 存在历史缺陷，验证时会多弹出一个栈元素，必须先压一个无用值，否则校验失败。多出来的这 1 字节，是刻意保留兼容、避免另造一套更重操作码序列的代价。
4.3 体积限制调整
当时的 Satoshi 客户端对 scriptSig 有约 200 字节的转发/挖矿上限，放不下实用的 3 签交易。BIP-11 配套将上限提高到 500 字节，以容纳 3 签名场景。
4.4 设计取舍（Rationale）
为何继续用 OP_CHECKMULTISIG，而不是多个 OP_CHECKSIG 拼出来？
它已启用，是支持多签场景最直接的方式。反对意见之一是：旧客户端与矿工把一次 CHECKMULTISIG 计为 20 个 sigops，而区块有 20,000 sigops 硬顶，理论上每块最多约 1,000 笔这类多签。用多个 CHECKSIG 可以计得更“省”。
回应是：此类交易预期会与 OP_EVAL 等机制结合并被更准确计数；且随着交易量上升，区块大小与 sigops 规则本身也需要再评估。另一条较弱的反对是栈弹出 bug——用 1 字节 OP_0 即可兼容，替代方案往往更费字节。
4.5 实现说明
旧客户端与矿工早已能验证 OP_CHECKMULTISIG，只是当非标准交易处理。BIP-11 改变的是“标准策略”（是否默认转发与挖矿），不是共识里“这种脚本是否合法”的底层定义。
五、谁必须动
普通持币人：不必改节点。若使用多签钱包或托管产品，由钱包软件生成符合标准的脚本即可。
钱包开发者：需能构造 m-of-n（n≤3）的标准 scriptPubKey，以及带 OP_0 占位的 scriptSig；并正确处理 2-of-2、2-of-3 等常见模板。
全节点与矿工（策略层）：将此类交易视为标准：转发进内存池、允许打进区块。仍不支持的节点可能拒收，导致广播困难。
共识层：本 BIP 不修改共识规则。OP_CHECKMULTISIG 本来就合法；变的是“标准交易”政策。
因此：不升级的旧节点在共识上仍承认这些交易一旦上链；但在策略上可能不帮你传播未确认交易。
六、现在算不算数，以及一个常见误读
状态为 Deployed。它是比特币多签能在主网实用的早期基础。今天日常多签更多通过 P2SH、P2WSH、Taproot（含多签与脚本路径）等形态出现，地址与隐私、手续费、可塑性等性质更好，但“ M-of-N 共同授权”的语义一脉相承。
裸多签（bare multisig）在部分场景仍可见，但现代钱包更倾向把脚本藏进哈希（P2SH/SegWit）或 Taproot 树中。
常见误读：
“ BIP-11 发明了多签操作码。”
不对。OP_CHECKMULTISIG 原先就有。BIP-11 做的是：在 n≤3 的前提下，把这类交易定为标准，并放宽 scriptSig 大小限制，让网络默认转发和打包。没有这一步，多签很难在真实支付与托管里落地。
七、延伸
- 阅读版：https://bips.dev/11
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki
- 相关：BIP-13 地址格式、BIP-16 P2SH
- 仓库总目录：https://github.com/bitcoin/bips