一、把合同藏进哈希里
普通付款到公钥哈希的地址，花费条件一眼见底：签名验证通过即可。P2SH 把条件升了一级：地址锁定的是一段脚本的 160 位哈希，谁想花这笔钱，得先交出一段原文脚本，节点对它现场算哈希、与地址里的承诺比对，对上了才继续逐句执行脚本。这段”先亮哈希、后交原文”的游戏规则，让锁定方在任何一方都不知道花费细节的情况下就能安全收款——因为收款地址由哈希唯一决定，而哈希在数学上无法反推出原文。这套机制由 BIP16 在 2012 年 4 月部署。
二、交易里两个字段的分工
花费一笔 P2SH 时，输入端解锁脚本（scriptSig）的全部工作是”压栈”：按顺序推入签名等数据，最后压入 redeem script 原文。验证节点先把这段原文哈希化，确认它确实等于输出脚本承诺的那 20 字节，然后把原文当作脚本、把之前的栈当作参数，进入正常的脚本执行。换句话说，scriptSig 与 redeem script 是”参数”与”程序”的关系，程序本体要到花费那一刻才第一次出现在链上。这也解释了旧钱包为什么会在”已知脚本哈希”的输入上报地址未知——它见过收款承诺，却没见过解锁原文，直到有人告诉它程序长什么样。
三、序列化：脚本就是一段可数长度的字节
redeem script 是标准的比特币脚本字节串：操作数与操作码按脚本语言的字节码格式排布，例如一个两人三签多签，字节序列依次是签名门槛、三枚公钥、签名总数与校验操作码，外加长度前缀。地址层面的换算链是：脚本原文做 SHA-256，结果做 RIPEMD-160，再按主网版本字节加 Base58Check 校验和包装成 3 开头的地址——中间那次 RIPEMD-160 恰好把脚本压成与老地址同宽的 20 字节，这正是”新脚本穿旧地址”的兼容魔法所在。字节数因此直接进手续费账单：多签人多一个、公钥换一种编码，redeem script 就长几个字节，而这笔账在创建地址时就已注定。
四、隔离见证时代的表亲 P2WSH
隔离见证把”参数”挪出交易主体之后，P2SH 的继承者 P2WSH 用同样思路换了两个零件：承诺改绑脚本的 SHA-256（32 字节），原文改放见证字段。地址兼容性反而更进一步——任何旧软件只要见过一段脚本的哈希，就能向未来才公开的任意复杂脚本付款。多签、时间锁合约、哈希锁这些链下与链上协议大量依赖同一范式：交易先锚定条件摘要，条件原文推迟到花费时出示。理解 P2SH 也就拿到了理解脚本路径承诺的通用钥匙。
五、责任边界提醒
这套”后交原文”结构自带一条安全底线要划清：哈希承诺防的是事后篡改脚本，不替你保证脚本写得对。一个错误的门槛数、一枚输错的公钥，同样能生成合法地址、被哈希忠实地锁定——届时任何工具都无法从哈希推导出原文里错在哪。所以多签地址生成后、大额入账前，先用小额走一次完整的”亮脚本、执行、上链”全流程，是对这套机制最基本的尊重。
六、兼容红利背后的字节代价
P2SH 把”脚本复杂度”折进地址后，链上的代价并没有消失，只是推迟到花费时集中支付：每笔消费都要在输入里交一遍 redeem script 全文，十个签名人的多签金库每花一次钱就重述一次合同全文。长期持有者常见的优化是”进门用 P2SH、出门看时机”——在费率低谷集中归集，或迁移到见证版本消除重复陈述。还要澄清一个流传的误会：“P2SH 地址收不到新脚本类型的款”不成立，地址对上游完全无感；真正的摩擦发生在钱包侧——导入脚本哈希而非脚本原文的钱包，恢复扫描时需要专门的补齐流程（多数现代钱包按 BIP 派生规则自动补，旧备份迁移时仍值得手工核对一遍脚本清单）。写到这里，P2SH 的设计哲学已经呼之欲出：它没有发明承诺，发明的是”让承诺兼容上一代系统”的姿势——协议进化的多数胜利，来自这种新旧字节彼此认得的妥协，而非推倒重来。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。