协议演进 / BIP/比特币改进提案 / BIP-19
BIP-19
与 BIP-11 同目标的低 SigOp 版本：不用 OP_CHECKMULTISIG，而用一串 OP_CHECKSIG 加总计数拼出 M-of-N，以绕开每个多签被计 20 次签名操作的区块上限。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-19 |
|---|---|
| 标题 | M-of-N Standard Transactions (Low SigOp) |
| 作者 | Luke Dashjr <[email protected]> |
| 指定日期 | 2012-01-30 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/19 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki |
二、放在哪一族
M-of-N 多签标准交易族，是 BIP-11 的“同题竞争稿”。
BIP-11（2011，Gavin Andresen，状态 Deployed）已经把基于 OP_CHECKMULTISIG 的 M-of-N 交易定为标准。本页要解决的不是“能不能多签”，而是 BIP-11 路线的一个计量代价：每次 OP_CHECKMULTISIG 在区块签名操作（sigop）上限里按 20 次计，于是每区块最多只能装约 1,000 笔这类多签交易。
BIP-19 的办法是换一种拼法：不用 OP_CHECKMULTISIG，改用多个 OP_CHECKSIG——每个只计 1 次 sigop——把通过的签名数加总再与门槛比较，以同样的 M-of-N 语义换取更好的可扩展性（标题中的 “Low SigOp” 即指此）。
它与 P2SH 一族（BIP-16 等）是平行关系：P2SH 管“怎么把复杂条件藏进哈希”，本页管“多签脚本本身怎么写更省计量”。最终 BIP-11 的形式成为通行标准，本页状态为 Closed。
三、它要解决什么
动机场景与 BIP-11 相同，原文照录了两类用例：
3.1 受保护钱包（Wallet Protection Service）
采用 2-of-2：一把签名来自用户电脑上的钱包（可能已中毒），另一把来自钱包保护服务（WPS）。用户发起转账时，客户端把拟交易发给 WPS，由其再向用户确认是否本人发起、细节是否正确，双方都签才生效。原文同样提醒：用户应要求 WPS 提供所用私钥的备份并离线安全保存，以免服务商倒闭后资金被锁死。客户端与 WPS 的通信方式不在本 BIP 范围内。
3.2 三方托管（买方、卖方、仲裁方）
采用 2-of-3：买方、卖方、可信仲裁人各提供一个公钥，买方把币打入 2-of-3 输出并把交易 ID 告知另两方。履约顺利时卖方先签、买方联署，资金付给卖方；发生争议时，仲裁人与买卖任一方合作即可决定资金去向。三方如何交换公钥与签名，同样不在本 BIP 范围内。
与 BIP-11 的区别不在“要解决什么”，而在“用什么脚本解决”：核心障碍是 OP_CHECKMULTISIG 的 sigop 计数太贵——按 20 次计，一个区块装不下多少多签交易，长远会限制这类用例的规模。
四、规则本身
4.1 两种新的标准 scriptPubKey 形式
定义两类会被客户端转发、会被矿工打包的标准交易类型，且只适用于 n ≤ 3 的情形。
全部签名都要到齐（N-of-N）：对每个公钥重复“验签且必须通过”：
( {pubkey} OP_CHECKSIGVERIFY )*n
只需一部分签名（部分门槛）：用 OP_CHECKSIG 逐个验签（每个在栈上留下 1 或 0），配合 OP_SWAP 调整栈序、OP_ADD 累加通过数，最后与所需数目 n 比较是否相等：
{pubkey} OP_CHECKSIG ( OP_SWAP {pubkey} OP_CHECKSIG OP_ADD )*(n-1) n OP_EQUAL
直观理解：CHECKSIG 拼法把“数签名”这件事拆开手算——验一个、记一分，加总到门槛即通过；CHECKSIGVERIFY 拼法则是一个签名不过、整笔失败。
4.2 模板
原文列出的 scriptPubKey 模板包括：
{pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY
{pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY
{pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL
{pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL
即 2 个与 3 个公钥的“全签”模板，以及 2 个与 3 个公钥参与的“计数”模板。
4.3 解锁脚本与体积
花费的 scriptSig 就是签名串：
...signatures...
与 BIP-11 相同的配套修改：当时客户端不转发、不打包 scriptSig 超过 200 字节的交易，为容纳 3 签名场景，上限提高到 500 字节。
4.4 设计理由（Rationale）
原文承认 OP_CHECKMULTISIG 本已可用、也是最直截了当的做法，BIP-11 已如此规定。换拼法的唯一理由是计量：OP_CHECKMULTISIG 一次按 20 个 sigop 计入区块上限（20,000 次），每区块最多约 1,000 笔多签；而 OP_CHECKSIG 每个签名只计 1 次，可扩展性更好。
实现上没有新操作码：用到的操作旧客户端与矿工早已支持，只是此前被当作非标准交易类型。
五、谁必须动
普通持币人：无直接变化。用多签钱包或托管产品时，由钱包软件生成符合本模板的脚本即可。
钱包开发者：若走本路线，需能构造 4.2 的 CHECKSIG / CHECKSIGVERIFY 模板（n ≤ 3），并按顺序放入签名；与使用 OP_CHECKMULTISIG 的 BIP-11 模板不可混用。
全节点与矿工（策略层）：把这两类交易视为标准：转发进内存池、允许打进区块。
共识层：不修改共识规则。用到的操作码原本全部合法，本提案与 BIP-11 一样，改的只是“标准交易”的认定。
六、现在算不算数，以及一个常见误读
状态为 Closed：未获采用，已经关闭。M-of-N 多签的通行标准仍是 BIP-11 基于 OP_CHECKMULTISIG 的形式（状态 Deployed）；后来多签的实际使用又主要经由 P2SH（BIP-16）等形态承载。本页保留的价值，是记录下当年对 sigop 计量成本的一次认真回应：语义没错、拼法可行，但社区没有为“省计量”改换已经落地的标准拼法。
常见误读：
“BIP-19 是 BIP-11 的升级版，后来取代了它。”
不对。两者的关系是并行竞争：BIP-11 先行且被采用，BIP-19 提出低 SigOp 的替代拼法，最终状态为 Closed。标题里的 “Low SigOp” 是它的卖点，不是它的结局——判断哪份是现行标准，要看状态字段，不能只看谁的方案“更优”。
七、延伸
- 阅读版：https://bips.dev/19
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki
- 相关：BIP-11 M-of-N 标准交易（被采用的形式）、BIP-16 P2SH
- 仓库总目录：https://github.com/bitcoin/bips