升级为什么会卡在半路
2012 年春天之前，比特币激活新共识规则有一套粗糙但好用的办法：新规则写死在软件里，从某个区块高度起所有节点执行。P2SH——按脚本哈希付款的多签与复杂脚本封装方案（BIP16）——如果照这个套路，会立刻要求旧节点能验证的新交易它们验证不了，形成新旧节点互不认账的硬分叉。为了让没升级的节点继续把新交易当作普通脚本输出对待，作者 Gavin Andresen 设计了一套向后兼容的激活机制，这也是比特币历史上第一次把什么时候强制执行写进矿工支持率的观察窗口，而不是写死一个高度。
BIP16 原文的激活设计
按 BIP16 文档的规定，升级后的矿工在产出区块时，在 Coinbase 交易的输入脚本里写入字符串 P2SH 作为投票标记；官方在 2012 年 2 月 1 日检查此前七天，若约一千个区块里有五百五十个以上带标记——即大约百分之五十五的算力支持——那么时间戳晚于 2012 年 2 月 15 日世界标准时间零点的区块，其中的 P2SH 交易必须被完整验证；如果多数算力迟迟不达标，部署就会推迟甚至被否决。实际历史里投票很快通过，P2SH 按这条时间线成为标准脚本类型，今天以 3 开头的多签地址就是它的直接产物。
向后兼容带来的尺寸天花板
P2SH 的兼容设计还留下一个今天仍然有效的细节。旧节点不认识 redeem script 的语义，但脚本规则本身不能动——任何被压进脚本栈的数据仍然受五二零字节上限约束。于是规范写明：花一笔 P2SH 时，解锁用的 redeem script 本身不得超过五二零字节。具体到最常见的多签：OP_CHECKMULTISIG 本身允许二十个公钥，但用三十三字节压缩公钥时，每个公钥连同一个长度前缀占三十四字节，加上脚本头尾三个控制字节，十五个公钥正好 513 字节，第十六个就会把 redeem script 顶破五二零字节红线。今天钱包默认把多签嵌套进隔离见证，尺寸压力才松开。
快读算术
按区块高度激活的规则，生效时点与矿工是否升级无关，风险是升级不足时出现分叉；按支持率加时间戳激活，给了市场一个明确的协调窗口：谁不升级，最迟在某个时间戳之前必须作出选择。P2SH 用七天观察窗换来了软分叉的安全性，代价是把什么算多数写进了规范条文，之后的 BIP34、BIP9 把这套办法改成了写入区块版本位的长期投票机制，思路一脉相承。
从一次激活到一套机制
BIP16 的字符串投票只用了这一次，但它提出的问题长期存在：软分叉需要在什么时候从可选变成强制？此后的 BIP34 把投票位写进区块版本号，BIP9 进一步做出带截止期与超时状态机的版本位框架，让协调窗口可以参数化。回看这条演进线，P2SH 的历史地位不止是第一个多签地址格式，更是比特币第一次把升级何时生效本身变成一个需要协调的协议参数，今天每次软分叉的投票窗口设计都从这里出发。
快速问答
问：P2SH 是硬分叉还是软分叉？ 答：软分叉。旧节点继续视 P2SH 输出为标准脚本模板，不会因为交易里出现新形态而拒绝整个区块。
问：Coinbase 里的投票标记还有用吗？ 答：那种字符串式投票是 BIP16 的一次性设计，后续版本位机制（BIP9）取代了它。
问：为什么今天的地址多以 bc1 或 3 开头？ 答：3 开头是 P2SH 的标准形态，多签脚本常被封装其中。
常见误区
一是把支持率激活记成矿工投票决定规则内容，他们只决定何时开始强制，内容早在规范里；二是以为时间戳生效后旧节点就断网，它们仍能同步合法链，只是不能自己生产合格的块；三是把五二零字节上限当成多签人数永远的上限，隔离见证与 Taproot 已把可用空间重新划分。
风险提示：本文为协议历史科普，不构成任何投资建议；涉及地址与脚本兼容性的资产操作，请以钱包当期说明为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。