同样是隔离见证那套编码，比特币地址写作 bc 开头，莱特币是 ltc，Cosmos Hub 干脆用整词 cosmos，Alaya 用 atp、Agoric 用 agoric。这些开头不是各项目随手起的，而是有一份集中登记——SLIP-0173《给 BIP-173 注册人类可读部分》，作者 Clark Moody，2017 年 5 月起草，状态 Active，一直维护至今，表里已经收录了约三百种链的条目。
为什么 BIP 里放不下这张表
要理解 SLIP-0173 为什么存在，先要分清它和 Bech32和Bech32m如何区分？ 讲的 BIP-173 是两件事。BIP-173 定义编码格式本身——那种把数据压成 32 个字符、带校验和、有个人类可读前缀的 bech32 写法，规定格式该长什么样。但一个具体链该用哪个前缀，是链自己的身份问题，不是格式问题。比特币改进提案仓库不愿意替全世界的币分配前缀值，于是这份登记职责被推给了 SatoshiLabs 维护的 SLIP 序列。SLIP-0173 的存在理由，正是这份提案文档里明写的那句：BIP 仓库不想处理除比特币以外各种币的前缀分配，那就由这份 SLIP 来当这个主体。
bc、tb、bcrt：三套前缀对应三张网
表里每一行是一条链，横向分主网、测试网、回归测试网三栏。比特币那一行填的是 bc、tb、bcrt：你在主网钱包里看到的 bc1 开头的隔离见证地址用 bc，测试网同类地址换成 tb 开头，本地跑节点做开发回归测试时用 bcrt。为什么要分这么细？因为地址的前缀参与校验和计算，一条网络生成的地址几乎不可能在另一条网络上通过校验，这层区分是一道免费的防错保险——你误把主网地址贴进测试网钱包、或反过来，多半会被格式校验当场拦下，而不是把钱发进一个语义错乱的地方。莱特币那一行同理写着 ltc、tltc、rltc，前缀规律是主网裸名、测试网加 t、回归测试另起一套。
顺带收纳的 codex32 前缀
这份 SLIP 还多管了一件事：codex32 格式。codex32（BIP-93）是沿用 bech32 同样的”人类可读前缀 + 32 字符集”的思路，但用更强的校验支持纠错。于是 SLIP-0173 顺手把 codex32 用到的前缀也登记了：Core Lightning 硬件安全模块存的密钥用 cl，BIP-32 主种子用 ms。把前缀放在同一张表里管，是为了让同一套校验和编码规则有唯一权威的前缀出处，避免两处各写一份、日后打架。
查一条新链前缀的正确姿势
当你拿到一个没见过开头的隔离见证地址，别猜它是不是”记错了”。正确顺序是：先确认这条链是否采用 BIP-173/350 那套 bech32 编码（不是所有链都用），若是，再到 SLIP-0173 表里按链名找它的 mainnet、testnet、regtest 三栏，比对地址开头是否命中主网栏。表里没有这条链，多半说明它要么没在 bech32 体系内注册，要么用了自己那套前缀而不走这份登记。核对前缀这一步，能帮你在向一条不熟的链转钱前，先排除掉”把测试币当主网币”这一整类低级但昂贵的错误。
这张表是怎么长出来的
SLIP-0173 没有官方分配委员会：它的收录方式是提交者向仓库提拉取请求、由维护者审核后合入，属于先到先得加人工把关的开源登记流程。这带来两个实际影响。一是延迟与遗漏：一条新链可能已经上线发地址、却还没进表，所以”表里没有”不能反推”这个地址是假的”，需要回到该链自己的规范去核。二是登记不覆盖全部地址生态：表里的前缀只适用于确实采用 BIP-173 那套 bech32 编码的链，大量老链、非 bech32 链根本不在表内；同一张表也允许一条链为不同用途注册多个前缀，条目多、更新频繁，靠记忆判断开头字符的归属并不可靠，仍应以逐条查表为准。把这张表当成”查证起点”而不是”最终裁判”，是使用它的正确姿势。
风险提示：本文描述地址编码与前缀登记机制，不构成投资建议；前缀正确不代表转账一定安全，收款链是否真按 bech32 处理该地址仍需以该链官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。