今天说起原生隔离见证地址，想到的都是 bc1 开头那一串。但在隔离见证还没定稿的 2015 年底，还有一套完全不同的方案摆桌上：它不引入新编码，沿用大家熟悉的 base58，只用一个版本字节让每种见证程序版本各自拥有一个独特前缀。这份提案编号 142，作者是 Johnson Lau。它落选了，但那份文本里关于兼容性的推理，比它的编码细节更值得读。
编码规则：一个版本字节换一串前缀
提案针对的是隔离见证规范里那两种输出：把 20 字节哈希锁进去的单一公钥型，和把 32 字节脚本哈希锁进去的脚本哈希型。地址的构成按顺序是：1 字节地址版本、1 字节见证程序版本、1 字节零填充、20 或 32 字节的哈希、4 字节校验和；校验和就是前面这段序列化结果做双 SHA-256 之后取前 4 个字节。主网上，单一公钥型用地址版本 6、脚本哈希型用 10，测试网分别是 3 和 40。见证程序版本是一个 0 到 16 之间的一字节值，当时只有版本 0 定义，1 到 16 留给未来。那串零填充不是冗余：规范说明它的作用正是保证每个见证程序版本都会得到互不相同的地址前缀。长度也因此固定——20 字节哈希对应 36 个字符，32 字节的对应 53 个字符。提案附表列出了每种版本的前缀：主网版本 0 的两种地址分别以 p2 和 QW 开头，往后每个版本各占一个前缀。它给的例子也很直白，同一把公钥编成旧式模板地址是 1 开头那一串，编成这套方案就成了 p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm。
一个反直觉的诚实：它主动放弃兼容
这份提案的兼容性一节写得很干脆：本方案不是向后兼容的，但旧实现会把新地址类型报为无效，并拒绝创建交易。这句话值得多看两遍——它把“旧钱包遇到不认识地址应该怎么办”写成了明确的失败方向：报错、拒付，而不是猜着转。后来那条被采纳的编码方案在这一点上做得更极端，明确让旧软件对新版本地址判为无效，以免带着错误校验规则把钱烧进自己认不出的输出，详见 ‘+L(2026091000094)+‘。两套方案的取舍不同，但这一条判断标准是共用的，也是今天所有地址格式演进都沿用的纪律。它同样给出向前兼容：同一套编码可以容纳未来 20 与 32 字节的见证程序版本，不必为每个新版本再定一种编码。
它为什么落选
提案自己的动机写得清楚：想推动大家尽快用上更省空间的原生见证输出，并认为这套写法是各类软件最省事的迁移方式——毕竟从钱包到浏览器到商户，base58 地址的处理逻辑早就铺满了。它甚至在理由部分替这个旧格式说了句公道话：那些并非最优的 base58 模板地址，仍是整个生态通吃的标准。落选的原因不在提案文本里，但从后来的走向可以看出结构：base58 这套编码本身缺少对新版本地址的安全扩展能力，校验和也不能表达版本信息；而这些短板正是那套新编码被专门设计出来要解决的问题。一个只为省事的过渡方案，输给一个重新设计编码根基的方案，是这个话题里真正的教训。
对今天的用户留下什么
第一，地址前缀不是装饰，它携带版本与格式信息。看到不认识的开头，正确反应是“我这边可能不支持”，而不是“大概能收”。第二，长度可以作为粗筛：一套编码规则下的地址长度是固定的，异常长度往往意味着粘贴残缺或拼接错误；地址校验和如何逮住错字，见 ‘+L(2026090100030)+‘。更直接的做法始终是整体替换而不是逐字符比对，逐字符比对的视觉疲劳正是相似地址骗局的着力点，见 ‘+L(10218)+‘。第三，历史上有过“看着像旧地址、其实是新格式”的方案，所以任何“只要前缀差不多就能收”的经验都不可靠：能由软件按规则判定无效，就不要交给人眼判断。
一句风险提示
本文是历史技术档案，讲的是从未部署的提案细节，那些以 p2 开头的地址不是任何现网钱包支持的收款地址，不要拿它们试转账，也不要相信任何以“特殊格式地址”为卖点的收款指引。所有编码细节以提案原文为准，状态核验于本文写作时；这里不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。