比特币地址长什么样，是链上世界最容易被忽视又最容易出事的设计。早年沿用的 Base58 地址靠截断哈希做校验，能防打字错误，但对整段截断、换位成对出错等情形检测能力有限。BIP-173 在 2017 年 3 月提出（文件头标注状态 Deployed、类型 Informational，作者 Pieter Wuille 与 Greg Maxwell 等），定义了 Bech32 编码，其中一条不起眼的硬规定——整个字符串最长 90 个字符——决定了隔离见证地址生态的很多工程细节。
按 BIP-173 规范，一个 Bech32 串由三部分组成：人类可读部分（HRP，比特币主网是 bc）、分隔符数字 1、数据部分，整体不得超过 90 个字符；HRP 本身限长 1 到 83 个 US-ASCII 字符。字符集也被特意收窄为 32 个字母数字（排除了 1、b、i、o 这几个肉眼易混字符），规范要求整个串要么全小写要么全大写，混用直接判非法。校验和采用博斯–乔赫里–霍克文黑姆（BCH）码：附录里记录了这套生成多项式的挑选过程——从数万个候选码里，按“93 字符内检测 3 个错误、更短长度内检测 4 个错误、5 字符窗口突发错误的最好最坏情形”等条件层层淘汰，最终选出的码在 90 字符以内对随机错误的漏检率约十亿分之零点九。规范还坦率写明：这套码能撑到 1023 字符，但超过约 89 字符（不含分隔符）后，换用其他设计更划算，所以没有把长度用满。
为什么要较真这条长度上限？因为比特币的地址正在变长。v0 隔离见证的 P2WSH 地址接近上限，BIP-350 用修订的 Bech32m 校验和承载 v1（Taproot）输出，bc1p 地址同样逼近常见排版工具的显示宽度。当地址被塞进二维码、短信、表格单元格这些会自动换行的载体时，90 字符的上限就变成真实的排版问题：某些工具按固定宽度折行，另一些工具粘贴时吞掉换行符，钱可能格式正确地流向错误地址。Bech32 的错误检测恰好能兜住一部分事故——它能发现任意单字符错误和多数换位，但校验和不是神，它只保证字符串内部自洽，不保证这是一个“你本来想发的地址”。
日常防御可以写得很具体：转账前核对首尾各六个字符，而不是扫一眼长度；大额先拆两笔测试；遇到“地址过长/非法字符”报错，回到源头重新完整复制，绝不手工删中段凑长度——Bech32 的长度报错往往意味着复制源本身被截断。90 字符的天花板短期内不会消失，它是编码设计里为纠错能力预留的空间，也是钱包排版永远要绕开的硬边界。
把 90 字符的账算细一点，能看清这条上限其实留得很紧。Bech32 总长等于 HRP 加数字 1 加分段：主网隔离见证地址的 HRP 只占两个字符（bc），数据段 38 到 58 个字符，P2WPKH 地址常见 42 字符、P2WSH 接近 62 字符，离 90 仍有距离——上限真正约束的是带更长 HRP 的衍生场景：测试网前缀 tb、签名消息与支付协议里整段编码、以及 SLIP-0173 为各币种注册的各类可读段组合。BIP-173 附录还专门收录了“83 字符 HRP 顶格”的测试向量，说明起草者把 HRP 吃满、数据段随之逼近总限的极端形态当作必须通过的边界用例。也就是说，90 不是给普通地址的舒适值，而是给整个编码族划的硬顶；具体到某类地址，真正先撞上的往往是某个软件按 64 或 80 字符设的显示宽度。规范在动机部分对旧编码的批评同样适用于长度讨论：base58 时代的地址错误检测只有“碰巧保留校验位”一种防线，新格式用字符集与 BCH 校验把防线加厚，长度上限则是为这条防线保证效力的代价——三件事是一体的，只记长度不记校验，等于背了结论丢了证明。
本文为机制说明，不构成任何投资建议，也不构成对任何平台、合约或标准实现的背书。文中功能与规则描述以对应版本的官方文档为准，阅读时可能存在版本滞后。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。