给比特币钱包加”要几个人签字才动钱”的门槛，最直接的办法是用多签脚本。今天大家熟悉的两条路线，一条是 BIP-11 那种把公钥压进脚本、末尾挂一条 OP_CHECKMULTISIG 一次性数签名的写法，另一条是隔离见证与 Taproot 时代用 OP_CHECKSIGADD 逐个累加的写法，多签换了个写法：multi_a 与 sortedmulti_a 描述符里的逐把验签 专门讲过后者。夹在中间还有一桩很少被提起的旧事：2012 年 1 月立项、由 Luke Dashjr 起草的 BIP-19，标题里就写明它是 Low SigOp——低签名操作数版本的多签。它的动机不是功能，而是计费。
计费才是 BIP-19 想解决的问题
比特币对每个区块能做的签名校验总量有约束，落点在一个叫”签名操作”（sigops）的计费单位上。问题在于 OP_CHECKMULTISIG 无论里面塞了几把公钥，在旧规则里都被固定按 20 次签名操作计费。后果很直接：一个区块里能容纳的多签交易总数被压得很低——按这条规则算下来，一整个区块最多约一千笔多签交易。BIP-19 的思路是干脆别用那条昂贵的指令，改用一条条便宜的 OP_CHECKSIG 拼出来：既然单条 OP_CHECKSIG 只计 1 次签名操作，那把 n 个签名拆成 n 次独立 OP_CHECKSIG 累加，账本上就公平得多，多签也就不再天然地比单签贵一大截。这与后来大家用 签名操作也要折算体积：bytespersigop 默认 20 权重的那本验证成本账 讲的 bytespersigop 折算思路是同一类关切：让验证成本和脚本体积对齐。
脚本模板长什么样
全签（n-of-n，所有人都得签）的脚本是连续 n 个 {公钥} OP_CHECKSIGVERIFY——每条校验一次签名，任何一次不过就当场中止。门限签（n-of-m，够数即可）的模板稍有讲究：第一个公钥接一条 OP_CHECKSIG，从第二个开始每把公钥接 OP_SWAP 公钥 OP_CHECKSIG OP_ADD，最后写一个 n OP_EQUAL。含义是把每个公钥的签名校验结果（通过压 1、不通过压 0）一路加上去，加到末尾和门槛值比一次，相等才放行。这套写法完全复用已有的操作码，不新增任何脚本能力，所以老客户端本来就把这种交易当成非标准类型在处理。
为什么停在 n 不超过 3
BIP-19 给自己划了硬边界：上面这套累加写法只适用于 n 不超过 3 的情形。原因藏在解锁脚本的尺寸里。当年的中本聪客户端有个规矩——解锁脚本超过 200 字节的交易既不中继也不打包；为了让三把钥匙的多签塞得下三个签名，BIP-19 提出把这条上限提高到 500 字节，并明写这是为容纳三签交易而做的配套改动。钥匙再多，签名和公钥串起来的字节数就顶破这个窗口，累加脚本也跟着变长，所以它天然只适合小门限多签。这也解释了为什么它没能长成通用方案。
它为什么没走通
BIP-19 的最终状态是 Closed，而不是部署或被谁正式取代。回头看，它输在两处。一是时代选择：真正把多签做成主流标准的是 BIP-11 的 OP_CHECKMULTISIG 路线，多签的第一份标准答卷：BIP-11 与 OP_CHECKMULTISIG 的 2011 年，生态、钱包、脚本工具都围着它建，BIP-19 这种为省签名操作数而另起炉灶的写法没有获得同等的落地势能。二是更根本的解法从别处出现：签名操作数滥用的账，最终是靠隔离见证把见证数据从计费体积里剥出去、加上 裸多签的标准性红线：为什么链上只放行三把钥匙以内的多签 讲的裸多签标准性约束、以及后面按字节的折算规则一并收拾的，没人再需要靠手写累加脚本去省那点计费。今天 BIP-19 的价值，主要是让你在读老脚本和一些钱包历史时，认得出那种没有 OP_CHECKMULTISIG、却靠 OP_ADD 数签名的小门限多签长什么样。
在钱包里认出它
如果你在导出脚本工具的输出里看到一串 OP_CHECKSIG、OP_SWAP、OP_ADD 交替出现、末尾挂着 OP_n OP_EQUAL 的脚本，就可以按 BIP-19 模板去理解了：这是一段用累加器数签名的低签名操作数多签，钥匙数量大概率不超过三把。decodescript 一类的解码工具会把它的操作码逐条列出来，对照本提案的模板即可确认结构；真要花这种输出，构造解锁脚本时按顺序把各个签名连着填进脚本字段即可，不需要像传统 OP_CHECKMULTISIG 那样多垫一个占位空值。这类脚本的现存数量很少，但正因为少，遇到时更需要能一眼认形，而不是当成格式损坏的乱码放弃。
风险提示：本文描述脚本机制与提案历史，不构成投资建议；多签结构与费用政策都可能随节点软件版本变化，涉及资产处置前请以实测与官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。