自从小账本钱包开始用描述符备份，恢复流程少了一步“猜”：有了描述符，钱包知道自己该沿哪些路径派生地址。但实践中恢复失败的报告并没有绝迹，原因藏在描述符不带的一些数字里：扫描该从哪个区块开始？派生多少个连续未用地址后该停？这些参数不写下来，恢复时要么从创世块傻扫（慢得没法用），要么按软件默认值（可能漏钱）。BIP-393 给描述符字符串加了一个便签区，专门装这些数字。
写法像网址查询串
语法非常直白：描述符脚本表达式后面接一个问号，问号里是一组键值对，等号连接、和号分隔，末尾照常拼上井号校验和，形如 wpkh(...)?bh=800000&gl=30#校验码。规则细节都收紧到不能再紧：键只能是小写 ASCII 字母，每个键最多出现一次；值必须是非负十进制整数，不许前导零（零本身除外）、不许负号、不许空值；一个描述符只许一个问号。目前定义了三个键：bh 是区块高度，表示该钱包首次收到资金的位置，实现应从这一高度起扫；gl 是间隙上限，BIP-32 派生钱包在停止派生前可容忍的连续未用地址数；ml 是最大标签索引，供 BIP-352 静默支付钱包扫描之用。遇到不认识的键怎么办？规范的答案是必须忽略、不得拒绝——这保证了未来加新键不会把旧钱包判死刑。
为什么要复用校验和字符集
描述符末尾那串井号校验和是 BIP-380 用一种自定义五点字符表算出来的纠错码，抄错一个字符就能被逮住。BIP-393 选问号、等号、和号做分隔符，正是因为这三个字符本来就在 BIP-380 的输入字符集里，校验和算法一个字都不用改，只把“对井号之前整个字符串计算”这句话照旧执行。副作用也诚实：注释顺序会影响校验和——内容相同但键序不同，校验码就不同，但这只影响字符串比对，不影响语义。
语义是下限，不是快照
规范把注释值定义为下界：它们代表导出备份那一刻、恢复全部资金所需的最小值。钱包用得越久，真实间隙上限只会变大，所以导出的值可能偏旧，恢复端宁可多扫一点也别少扫。这个设计与“必须忽略未知键”合起来，让注释字段成了一个安全的可增长元数据袋。状态上，这是一份 Specification 类 Draft 提案（编号于 2026 年 3 月分配），同样是钱包间的互操作约定，链上节点对注释一无所知也不关心。
恢复现场的三种剧本
第一种剧本最平淡：从硬件钱包导出带注释的字符串，恢复到同款软件，扫描从标注高度开始，几十秒见底。第二种剧本是备份里没有注释的老字符串：恢复端只能按默认间隙与默认起点扫，地址用得越多，漏扫尾部地址的风险越高，此时正确姿势是手动调高间隙上限再扫一遍，确认余额与历史一致。第三种剧本是跨软件恢复：接收方不认识某个新键时，按规范必须忽略并继续工作，钱不会因此找不到，只是少了一点提示——这正是“未知键必须忽略”这条规则保护的场景：格式演进不再需要全体钱包同步换版。
快速问答
问：不带注释的描述符还有效吗？ 答：有效，注释完全可选，旧字符串原样合法。
问：恢复端支持注释但备份端没写，会怎样？ 答：退化到默认行为：按软件默认起始高度与间隙上限扫描，理论上存在漏扫风险。
问：注释能存自由文本吗？ 答：不能，值只能是整数；字符串类信息（比如账户名）不属于这套设计。
风险提示：本文仅描述钱包备份格式约定，不构成投资建议；恢复流程请以你所用钱包的官方文档为准，重要钱包恢复前建议先演练。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。