比特币脚本允许的最复杂花费条件远不止”一个签名”，但链上能看到的输出形态却一直收敛在少数几种标准模板里。其中有一条容易被漏掉的规则：裸多签（bare multisig）输出在标准性政策下有一个隐藏的尺寸上限——只放行不超过 3 个公钥的多签。这条规则藏在策略代码里，解释了为什么老教程里的”4 个 key 直接写进脚本”在新节点上会默默变成不可中继的孤儿交易。
先区分三个概念。共识规则规定脚本本身的结构上限：单个脚本不超过一万字节，单条 CHECKMULTISIG 的公钥数不超过 20，每条脚本的操作码不超过 201——这些是写进共识的硬边界，任何形态的脚本都受管。标准性规则则是另一层：节点自愿只中继和打包”标准交易”，目的是压制fee估算异常、可延展性攻击和资源滥用。P2PKH、P2SH、P2WPKH、P2WSH、裸多签、OP_RETURN 载数据，各自有独立的标准性判定函数。共识上合法但标准性上不过关的交易照样能出块（只要有人挖），只是普通节点不收不传，你几乎不可能靠它进链。
裸多签的标准性判定在比特币核心的策略代码里有一条清晰分支：把脚本识别为 MULTISIG 类型后，取 n 值判断——n 小于 1 或大于 3 直接判不标准，m 大于 n 也判不标准。换句话说，1-of-1 到 3-of-3 的裸多签才有机会通过标准性这关，而能不能过关还受另一个开关 -permitbaremultisig 节制（默认开启；关掉它，连小尺寸裸多签也不再标准）。这条尺寸上限的官方口径写在代码注释里：Support up to x-of-3 multisig txns as standard，没有歧义。
为什么卡在 3？看历史背景更清楚。裸多签的脚本直接展开在输出里：验证一笔 m-of-n 交易，节点要把 n 个公钥和 m 个签名都在脚本执行中过一遍，签名验证成本与 n、m 线性相关；脚本占的字节也按公钥数线性膨胀。P2SH 出现后，多签的标准出路变成”把长脚本塞进赎回脚本、链上只露 20 字节哈希”，代价是脚本哈希那一层信任，收益是固定输出尺寸和更平的验证成本。政策制定者的取舍因此顺理成章：保留少量小尺寸裸多签的兼容性，把大尺寸多签统统引导进 P2SH 或后来的 P2WSH。今天主流钱包生成的多签收款一律走 P2SH/P2WSH，裸多签基本只剩历史残留与实验用途。
对使用者的实际影响集中在两个场景。第一，读旧地址、搬旧资金：早年某些服务发过裸多签地址，若脚本正好是 x-of-3，花费时大概率一切正常；若是更大的 n，你可能撞上”交易做好却发不出去”的怪事——节点回 txn-not-standard 或干脆静默丢弃，出路是走能接受非标准交易的通道（如自行运营的节点配 acceptnonstdtxn，仅限测试网心态），或换接收方。第二，自建多签工具链：不要为了省一层哈希就生成大尺寸裸多签输出，不仅中继受歧视，未来标准性政策收紧时也最先把这类形态挤出默认路径。
还有一个连带知识点：标准性判定的公钥数检查依赖”脚本恰好是规范形状的 CHECKMULTISIG”。形状稍有偏离（比如操作数顺序不规范、用了嵌套结构伪装多签）就落入 NONSTANDARD 或其他类别，判定路径完全不同。decodescript 是检查这一层的顺手工具，能把脚本归类到 whichType 结果里，先看清类型再谈花费，可以避免很多”脚本能跑通却没人中继”的深夜排障。
风险提示：标准性政策属于节点软件的可调策略，与共识规则不同，可能随版本与配置变化；涉及历史地址资产处置前，请以所用版本实测与官方文档为准。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。