一把多签能装多少钥匙：CHECKMULTISIG 的二十与 multi_a 的九百九十九 图 1
一把多签能装多少钥匙：CHECKMULTISIG 的二十与 multi_a 的九百九十九 · 图 1

“我们建一个 15 把钥匙、3 把点头就能动钱的多签。“——这句话能不能落地，取决于一串数字上限：脚本操作码对公钥数量的硬性限制、钱包描述符对多签参数表的校验，以及签名操作计费带来的隐性天花板。比特币走到 Tapscript 之后，这些上限出现了两套答案：二十，和九百九十九。本文按 v31.0 源码把两把尺子各自的适用范围讲清楚。

二十：老操作码的共识上限

传统多签操作码 OP_CHECKMULTISIG 在执行时先读出栈上的公钥个数，随即核对一个范围：不大于一，且不大于常量 MAX_PUBKEYS_PER_MULTISIG。这个常量在 src/script/script.h 里定义为二十，解释器的这条判断属于共识校验——超过二十把钥匙的多签脚本不是”不常见”，是全网无效。钱包侧的描述符语法同样执行这条线：multi() 与 sortedmulti() 的解析器遇到超数直接报错，错误信息明说”多签钥匙数必须在一到二十之间”。裸多签还有一道更早的关口——标准性只放行三把钥匙以内的裸多签输出，所以现实中的大多签都住在 P2SH 或隔离见证封装里。

九百九十九：拆分式操作码的新配额

Tapscript 禁用老的多签操作码，改用可加式的新操作码逐个累进地验签。公钥数量不再需要写死在脚本里的一个字节参数上，于是配额被重新划给：常量 MAX_PUBKEYS_PER_MULTI_A 在同一个头文件里定义为九百九十九，multi_a() 与 sortedmulti_a() 描述符按它校验，超数报错信息与二十版对仗工整。Miniscript 的解析层也执行同一上限。需要注意，九百九十九是语法与结构层的天花板，不是推荐配置——它存在的首要目的是给解析器一个有界输入。

真正先撞到的三堵墙

从二十放宽到九百九十九，为什么没人真建上千把钥匙的多签？第一堵是脚本体积：每把公钥三十来字节，千把钥匙意味着三万多字节的脚本，而脚本本体自身有尺寸上限，费用更会按字节与权重翻倍地涨。第二堵是签名操作计费：验签次数计入交易与区块的签名操作预算，区块有全局成本上限，标准交易有自己的配额——块空间会替你把夸张的多签拒收。第三堵是协议细节：multi_a 里的公钥一律是 x-only 形态，钥匙管理方案得先适配这一点。

怎么选

二十以内的多签，老路线生态兼容最广：钱包、硬件设备、PSBT 工具链对传统多签的支持最成熟。超出二十、或者想要”看起来像普通单笔支付”的大规模门限结构，才需要进入 Taproot 脚本树与 multi_a 的领地，并预先做体积与费用的纸面演算。真正超过一百把钥匙级别的协作保管，工程上更多走门限签名聚合路线——那已经是签名算法层面的课题，不在本文的两把尺子之内。

钱包与设备侧的连锁影响

钥匙数上限不只是脚本层的数字，它会沿工具链一路传导。多数硬件签名设备与协作钱包对单脚本公钥数有自己的支持上限，往往比二十还小；导出描述符、跨工具恢复、多方案备份时，最窄的那一环决定实际可部署的规模。规划二十把钥匙级别的冷钱包，先把每家设备的上限、固件版本与描述符兼容性列成一张表，比先定结构再返工要省事得多。反过来，九百九十九这一档在今天的工具生态里能走多远，答案更多取决于你的签名流程能否处理超长脚本与全部 x-only 公钥——数字放宽了，工程没有自动跟着放宽。

风险提示：本文讨论脚本结构与共识上限，不构成投资建议；上限数值与报错行为以比特币核心 v31.0 源码为准，涉及资金结构变更前请以目标软件的当前版本文档复核。

参考来源