今天说起比特币多重签名，很多人第一反应是 P2WSH 地址或者助记词钱包里的「2/3 签名」设置。但在 2011 年，多签还是一件没有规矩的事：验证脚本里的 OP_CHECKMULTISIG 操作码从创世起就存在，任何节点都会执行它，可钱包不认、节点不中继、矿工不爱收——「能用」和「被网络当作正常交易」是两回事。BIP-11《M-of-N Standard Transactions》就是填这个坑的，作者 Gavin Andresen，2011 年 10 月立项，状态 Deployed。
它做的事情说起来只有一句话：把形如 m {pubkey}... n OP_CHECKMULTISIG 的锁脚本承认为「标准交易类型」，愿意中继、也愿意进块。但魔鬼全在细节里，这份 2011 年的短文档留下了三个值得一提的工程决定。
第一个是数量上限：n 不得超过 3。当时客户端对 scriptSig 的大小有一条 200 字节的非正式上限，两三个公钥加签名的组合已经逼近这个尺寸。BIP-11 顺手把中继上限抬到 500 字节，刚好容下三个签名——文档里对「为什么不干脆更多」的态度很务实：先用起来，限额的事等交易量逼上来再说。后来公钥排序、P2SH、隔离见证一步步把多签做成了今天的样子，但「先小步标准化、再解尺寸封印」的节奏就是从这儿开始的。
第二个决定是给一个真 bug 打补丁。OP_CHECKMULTISIG 在执行时会从栈上多弹出一个它并不需要的槽位，这是中本聪时代就写进实现的缺陷。代价是每个多签花费脚本都得在最前面垫一个 OP_0 当替死鬼，白白多占一个字节。文档专门算过这笔账：垫一格只花 1 字节，任何绕开 CHECKMULTISIG 的替代写法至少多花好几个字节的操作码，于是「将错就错」成了标准答案。今天你在任何多签交易的 scriptSig 开头看到那个多余的 OP 0，就是在给 2011 年这个决定付租金。
第三个争论是签名操作计数。老实现把一个 OP_CHECKMULTISIG 粗粗记作 20 个 sigop，而每个区块的 sigop 硬上限是 20000，算下来全块最多装一千笔多签。反方建议干脆用多个 OP_CHECKSIG 拼，计数更准；BIP-11 的回应是把希望寄托在当时的 OP_EVAL 提案和未来的规则修正上，主张别为一时的粗计放弃现成的操作码。sigop 计价后来确实被反复修正，这段账也随隔离见证的重算规则翻篇。
文档的动机部分还留下两份 2011 年的用户剧本：其一是「钱包保护服务」，你电脑上的钱包加一家托管方各持一把钥匙凑 2-of-2，付款时客户端把草拟交易发给托管方核对再联署——文档提醒用户一定要求托管方给一份私钥的离线备份，否则对方倒闭资金就冻住。其二是买方、卖方、仲裁人三方各持一把钥匙的 2-of-3 担保交易：买卖双方正常成交时两人合签放款，起了争议则由仲裁人配合法庭外裁决归属。这两个场景正是今天混合托管、企业金库与去中心化担保的原型，十多年过去结构几乎没变。
常见误区有两处。一是把 BIP-11 当成多签的共识规则本身：OP_CHECKMULTISIG 的验证语义不是它定的，它定义的是「什么交易算标准、值得中继与打包」，属于应用与政策层。二是以为 n 上限 3 是协议限制：那只是当年标准交易的判定条件，共识规则本身宽松得多，今天 P2WSH 里十几个公钥的多签照样合法，只是往往不再「标准」，费率与中继待遇会受影响。
快速问答。问：那多签地址长什么样？答：BIP-11 年代多签输出直接把公钥列表写进锁脚本，整个脚本自身被哈希成一个普通脚本地址。要等 P2SH（BIP-16）普及后，多签才普遍以「脚本哈希藏进 20 字节承诺」的形态出现，再往后隔离见证把公钥列表挪进 witness 字段。问：那个 OP_0 现在还需要吗？答：需要，兼容性要求它永远留在多签花费脚本的最前面。问：为什么不用多个 CHECKSIG 拼？答：能用，但每拼一个都要重复写金额条件与签名校验，尺寸和费都不划算，工程上输给了一个字节的前置垫子。
风险提示：本文为协议机制与历史科普，不构成投资建议；多签地址一旦生成，找回规则就固化在链上，配置前请确认每个签名方的密钥托管与灾备方案。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。