给比特币脚本列资源上限的文章，多半讲四个共识常量：脚本一万字节、操作码二百零一次、栈深一千、元素五百二十。但普通钱包日常最先撞上的其实不是这四条，而是政策层的三条细线：一笔 P2WSH 花费的见证栈最多 100 项、单项最多 80 字节、被引用的见证脚本本身最多 3600 字节。三个常量写在 v31.0 的 policy/policy.h。本文讲这三条线各拦什么、与共识层的巨大落差从哪来、以及撞线时的读法。
一、三条线分别是什么。MAX_STANDARD_P2WSH_STACK_ITEMS = 100：解锁一个 P2WSH 输出时，见证里的栈元素数量不得超过 100。MAX_STANDARD_P2WSH_STACK_ITEM_SIZE = 80：每个栈元素不得超过 80 字节。MAX_STANDARD_P2WSH_SCRIPT_SIZE = 3600：作为标准交易对待时，见证脚本本身不得超过 3600 字节。对照组是共识层：栈深上限 1000、单个元素 520 字节、脚本总长一万字节——政策线大约收紧了一个数量级。同一文件里还有 Taproot 的对应线：MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE = 80，tapscript 路径的栈元素同样按 80 字节管。
二、80 字节这个数字从哪来。它是”刚好装得下一个签名再加一点余量”的尺寸：一个 ECDSA 签名的 DER 编码通常在 70 字节上下，80 留出了编码裕度。于是这条线的实际含义是：正常签名、正常公钥、正常哈希都能过；想靠”往单个栈元素里塞大段数据”钻空子的写法会被政策拒绝。注意约束的对象是”解锁时压进栈的元素”，不是链上存了多少字节的脚本——见证内容本身有独立的计费折扣，脚本体积由 3600 那条线管。这解释了 1-of-N 大额多签的常见做法：解锁栈里只放 1 个签名与占位符，脚本再大也不受栈项数影响。
三、100 项这条线何时可见。N 把钥匙的 CHECKMULTISIG，解锁要 N 个签名（外加 OP_0 占位），再叠脚本哈希，栈项数大约 N 加二。因此普通的 15 把、20 把钥匙多签离 100 项还很远；真正会顶到线的是”把栈当数据通道用”的写法——逐字节压入几百个小项拼大数的脚本。对这类用法，100 项是政策硬顶，而共识层本来允许一千项：政策层的潜台词是”这种玩法不是我们的用例”。这也和裸多签、超大数据推送一样，属于”合法但不标准”家族——交易不会被共识拒绝，但默认节点不进内存池、不帮你中继。
四、撞线现场怎么读。钱包报 transaction not standard、RPC 返回 -26 且错误串带 bad-witness，配合脚本结构看：栈项数超 100 还是某项超 80 字节，两者修复方向完全不同——前者合并小项、改数据结构，后者通常意味着塞进了不该塞的数据。多签服务商做密钥轮转脚本时值得用脚本尺寸计算器把三条线都跑一遍，尤其是”签名数量加条件分支都多”的升级脚本。
五、为什么政策可以比共识严这么多。比特币节点的默认策略是一句老话：我不中继我不打算为之优化钱包体验的东西。政策线不是安全边界（共识线才是），而是带宽与验证成本的自助护栏；改政策不会分叉网络，只会让你的节点和默认配置的大多数节点之间形成”标准性孤岛”。所以判断一笔交易能不能上链，永远先看共识；判断它能不能顺畅传播，才轮到这三条细线。100 与 80 两个小数字，管的是普通钱包与花哨脚本之间的楚河汉界。
风险提示：本文内容为技术机制科普，不构成任何投资建议、收益承诺或买卖时机判断。涉及协议规则与软件行为的描述以对应软件版本（文中已标注）的官方源码与规范为准。涉及资金操作的，请先在测试网或小额环境验证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。