一条描述符管两条地址线？BIP-389 多路径键表达式

描述符（BIP-380 定义的输出脚本描述符）解决了比特币钱包备份的经典难题：光备份私钥不够，还得知道当初沿着哪些路径生成过地址，否则恢复时可能找不到钱。但绝大多数钱包并不是只有一条路径——它们至少有两套地址：给你对外展示的收款地址，和花出去时产生找零的找零地址。这两套地址的描述符几乎逐字相同，往往只差派生路径里的一层编号（常见的约定是零代表收款、一代表找零）。BIP-389 允许把这种“只差一层”的两条描述符合写成一条。

语法长什么样

在描述符的键表达式里，扩展公钥或私钥后面通常跟一串斜杠分隔的路径步骤，比如某个 xpub 后接 0/* 表示收款链下所有地址。BIP-389 增加了一种可选写法：路径中可以出现一个用尖括号包起来的候选组，形如 <0;1>，表示这一步同时取两个值。整个键表达式在解析时展开成两条普通描述符——第一条在所有位置取候选组里的第一个值，第二条取第二个，其余部分完全复制。规范规定每个键表达式里这种候选组最多出现一次；组内不允许重复的编号；如果一个描述符里有多个键表达式都带候选组，它们的组长度必须一致，展开时同步推进，就像多个键共享通配符时的逐地址同步派生一样。钱包解释器的默认约定是：展开后的第一条用于收款，第二条用于找零。

一条描述符管两条地址线？BIP-389 多路径键表达式图 2 — 一条描述符管两条地址线？BIP-389 多路径键表达式 · 图 2

为什么值得合并

第一是备份体积。完整描述符字符串很长，多路径写法把它砍掉将近一半，对以二维码、纸质卡片、金属板刻字为载体的备份尤其友好。第二是配置出错面。收款和找零写成两条时，用户很容易改对一条漏掉另一条，或者两条的路径抄串；合并成一条后，这类手误在结构上不可能发生。第三是跨设备迁移的语义更清楚：一次导入就同时拿到两条地址线，不存在“先导了收款、找零还没扫”的中间状态。

常见误解

误解一：多路径等于多签。不是。多路径只涉及一个主密钥沿不同分支展开，和几个人共同签名毫无关系，多签描述符（比如 nested 或 sortedmulti 写法）可以和多路径正当地叠加使用。误解二：链上能看出多路径。看不到，展开后的地址线彼此就是普通派生地址，候选组只是备份和导入时的书写技巧。误解三：这是共识规则。BIP-389 是 Informational 类提案、状态为 Draft（编号于 2022 年 7 月分配），链上节点不认识也不关心描述符；它约束的是钱包之间如何交换和展开备份字符串。不支持该语法的钱包应当在导入前拒绝并提示，用户则需要让软件先把组展开成两条标准描述符再导入——这通常是一键完成的。

一次算清的体积账

以一个典型的收款描述符为例：单条字符串往往上百字符，扩展公钥本身就占八十余位，路径与校验和再各占一段。用多路径写法合并收款与找零，省掉的正是第二条里重复的主密钥与函数名部分。对手抄二维码的人来说，这几十位的意义不是美观，而是抄错概率：字符数与出错率近似成正比，合并写法让一次人工抄录的出错面接近减半。金属板刻字同理，字数减少还意味着更小的刻字面积与更低的刻录成本。