三方保管的「记账」缺口
MuSig2（BIP-327）把多个签名者的公钥聚合成一枚公钥，链上只看到一把普通钥匙的普通签名，参与人数和门限结构全部隐形。数学和协议都已经就位，但钱包工程上缺一块：你如何用一行文本记录「这枚聚合公钥是用 A、B、C 三把钥匙按什么规则算出来的」？没有标准写法时，每个多签钱包各自发明配置格式，换钱包、恢复备份、跨工具协作时全靠人工对账——对聚合密钥来说，参与者公钥的集合与排序规则写错一个字，产出的就是另一枚完全不同的公钥，钱会安静地停在谁也找不到的地方。
BIP-390 填的正是这个坑：在输出脚本描述符（BIP-380 那套文本格式）里加一个 musig() 关键字，把「聚合谁、怎么派生」写成可移植、可校验的标准语句。提案由 Ava Chow 撰写，2024 年 6 月获得编号，状态为草案（Draft）。
语法长什么样
基本形式是 musig(KEY, KEY, …, KEY)，KEY 可以是任意合法的描述符键表达式（公钥、xpub 带派生路径都行）。规则有几条硬边界：musig() 只能出现在 tr()、rawtr() 或 sp() 表达式内部当作一把钥匙用，不能嵌进另一个 musig()，因为「聚合的聚合」会让参与者身份在链上审计时失去唯一解。所有参与者公钥必须先用 KeySort 算法排序再聚合——哪怕描述符里写的是乱序，聚合结果也要求一致，因为 MuSig2 在哲学上处理的是「一个集合」，书写顺序只是实现细节。把排序规则写进标准还有实际的救急价值：用户丢备份时，钱包只需找回成员名单，不必猜对当初输入的顺序。
描述符还能带派生：musig(三把 xpub)/序号/路径/* 的写法下，先聚合出成员聚合公钥，再像普通密钥一样按 BIP-32 风格逐地址派生——每个收款地址都用同一组成员密钥派生出各自的子钥再聚合，一套配置管住整条地址链。
为什么值得为「语法」写一份 BIP
比特币工程史反复证明：资金安全的最后一公里常常是文本格式。PSBT 统一了交易的传阅格式，描述符统一了钱包的记账格式，BIP-390 则把 MuSig2 的钥匙构成纳入同一描述语言。对最终用户，收益在三处。恢复：任何兼容钱包导入同一段描述符，都能重建出同一组地址，不再依赖单一厂商的内部数据库。审计：多签组织可以明文写出金库的地址由哪几位董事的公钥聚合而成，链上监控与合规脚本能按标准语法核对。升级：成员换钥匙时，改动是一行文本的替换，而不是整个钱包推倒重来。
快速问答
问：musig() 和 sortedmulti 多签是一回事吗？ 答：不是。sortedmulti 是「链上摆明多把钥匙 + 门限规则」，链上能看出是多人共管；musig() 聚合后链上只有一把钥匙，参与结构不可见。前者透明成本是隐私和费用，后者把这两项都省了，代价是签名协议多了两轮交互——两种路线的取舍是「可见性换效率」。
问：现在钱包支持吗？ 答：描述符生态本身已成熟，MuSig2 的密码学库也已发布，但把 musig() 关键字内建进主流钱包配置界面的进程较新。评估一款多签工具时可以直接问：聚合密钥用不用标准描述符表达、换工具后能否无损恢复。
一次配置的完整旅程
设想一个三人董事会金库的落地流程：三位董事各自生成 xpub 交给治理委员会，委员会按 KeySort 排好顺序写进一条含 musig() 的描述符，导入协调钱包后派生出第一枚金库地址。两年后一位董事退休：把新 xpub 换进描述符、重新聚合、给旧金库地址做一笔迁移交易，配置文件改动只有一行。对比之下，若当年钥匙构成散落在厂商私有数据库里，同样一次换人要做的是全量导出、逐条对哈希、跨工具重建。文本标准的价值不体现在日常，而体现在这些「非日常时刻」。
风险提示
本文是协议机制科普，不构成投资建议。多方保管涉及权责与密钥治理，部署大额共管资产前请核验工具对标准的支持程度并做小额全流程演练。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。