导出的公钥藏不住来历？SLIP-0032 扩展序列化格式与 xpub 的区别

xpub 的一个先天缺陷：不知道自己从哪来

BIP-32 定义的扩展公钥（xpub 开头的 Base58 串）携带深度、父指纹、子序号、链码和密钥本体，但有一个尴尬：一个派生到 m/44’/0’/0’ 的节点序列化后，载荷里只写”深度 2、序号 0”和一个父指纹数字，并不写明完整路径。接收这串 xpub 的钱包要靠外部附注（描述符、配置项、人工记录）才知道该在树的哪个位置接着派生；一旦附注丢了或配错位置，同一串密钥会被接到错误的子树上，扫出来的地址全体对不上。SLIP-0032（2017 年 9 月提出，状态 Draft）就是对这个序列化解法本身的重做。

三处改动，各自解决什么

第一，把完整 BIP-32 路径直接写进载荷。规范给的字节结构是：1 字节深度，随后 4 乘深度字节的路径逐项大端编码，再是 32 字节链码，最后 33 字节密钥数据（公钥用 serP 压缩形式，私钥前缀一个 0x00 字节再放标量）。路径进载荷的直接收益是”钱包可以检查导出的密钥是否来自预期的树位置”——这正是标题意义上”公钥藏不住来历”：任何拿到扩展密钥的人都能独立还原它派生自哪条路径，伪造挂载位置不再可行。第二，删掉父指纹字段。规范原话是这字段几乎没被钱包用到、徒增序列化计算，而且在父密钥未知时根本算不出来。第三，编码从 Base58 换成 BIP-173 的 Bech32，人类可读部分仍用 xpub 与 xprv 两个前缀，校验能力更好、字符集更规整。

对照测试向量看差别

规范用 abandon…about 这颗著名测试助记词做了对照表。根节点（深度 0、路径为空）的 SLIP-32 十六进制载荷以 00 开头，只有 1 字节深度加链码加密钥；换到 m/0 节点，载荷开头变成 01 00000000——深度 1 加一个大端 0；m/1 节点开头是 01 00000001。同一条路径下的 legacy_bip32_xprv 仍是熟悉的 xprv9… 长串，而 slip32_prv_bech32 形如 xprv1qyqqqqq… 的小写串，前缀段把路径映射进字符里。两份编码指向同一密钥材料，唯一区别是路径信息的自描述程度。顺带说明：abandon 序列是 BIP-39 文档级测试向量，不是任何真实用户的助记词。

与输出描述符、watch-only 的谱系关系

把路径写进密钥这件事，后来在比特币生态有了更大规模的呼应： Bitcoin Core 的输出描述符在 xpub 外面用方括号标注 [指纹/路径]，让钱包描述”从哪棵树的哪个位置派生”；多签备份的常见教训”光抄五份 xpub 不够、必须连路径一起抄”，根源正是 BIP-32 载荷不自含路径——路径怎么读、每段数字什么意思，BIP-44钱包派生路径怎么读？有逐段拆解。SLIP-0032 的解法更激进——不靠外部标注，改格式本身。但要清醒：它是 Draft，未成为任何主流钱包的默认导出格式；社区实际收敛的路径是描述符加 mixtape 式的外挂标注，而不是替换序列化层。今天的实用价值有两点：其一，理解为什么硬件钱包导出公钥时总让你确认一段 derivation path——那是在给不自含路径的老格式补附注；其二，看到 xpub1 或 xprv1 开头的 Bech32 串时能认出这是 SLIP-0032 实验格式而不是普通 xpub，避免把它当 BIP-32 串直接粘进钱包造成解析失败；为只读监控配置扩展公钥时，观察钱包是什么？为何不能转账？讲的”只能看、不能转”边界同样是第一原则。

核对与备份纪律

不管你用哪种格式，三条纪律不变。备份扩展公钥必须与派生路径、用途（收款链还是找零链）三者成套记录，缺路径的 xpub 在换钱包时是半成品。导出时逐项核对设备屏幕上显示的 depth 与路径段，任何一环对不上就中止——密钥内容一致而挂载位置错误的后果，比导出失败更隐蔽。若未来遇到支持 SLIP-0032 的工具链，先用小额账户验证：同一节点用老格式加附注、新格式自描述两种方式各导入一次观察地址序列是否一致，确认理解无误后再用于主账户。对普通用户，现阶段更稳妥的仍是描述符体系：生态支持面大、文档多、误操作路径清晰。