在比特币多签方案里，MuSig2 是一条特殊的路线：几个签名人先把各自的公钥聚合成一个公钥，链上看起来就是一把普通钥匙的普通支出，外部无法从交易形态上认出这是几个人共管。这个伪装顺带带来一个工程难题——隐私最佳实践要求每个收款地址只用一次，而聚合公钥是固定的，每生成一个新地址，理论上都要所有签名人重新交换一轮公钥、重新聚合一次。BIP-328 就是为解决这个摩擦而写的约定。
问题从哪来
普通单签钱包的做法是：备份里存一个扩展公钥（xpub），之后凭它就能沿着 BIP-32 派生路径不断算出新地址，全程不需要私钥参与。脚本多签（比如传统 CHECKMULTISIG）也有类似机制：各方把自己的 xpub 交出来，钱包在本地对每一方做同样路径的派生，再拼出多签脚本。MuSig2 如果照搬这个思路，意味着每个新地址都要各方把整条路径上的公钥逐个发一遍、再逐个聚合，签名人多的时候沟通成本很高。
合成扩展公钥的做法
BIP-328 的观察是：MuSig2 的聚合公钥在数学形态上与随机公钥无法区分，那它原则上也可以塞进 xpub 的编码格式里。方案是一个纯约定：拿聚合公钥构造一个合成的 xpub，把版本字段里的深度设为零、子元素编号设为零，链码则固定为字符串 MuSig2MuSig2MuSig2 的 SHA-256 哈希。所有按此规范实现的软件都使用同一段固定链码，因此任何一个只掌握聚合公钥的人都能重建出同一个 xpub 字符串，然后像普通钱包一样对它做未硬化派生，批量算出收款地址。
签名环节需要补一个环节。BIP-32 的未硬化派生会把父密钥和一个修正量（CKDpub 里算出的 IL 值）相加得到子密钥，聚合公钥上没有聚合私钥，没法直接加。规范的处理是：每个签名人自己算出对应路径的 IL 修正量，以 plain 模式（不做 x-only 修正）放进 MuSig2 的会话上下文，签名算法会在合成部分签名的过程中把这些修正量逐层应用上去。对签名人来说，这只是在原有聚合流程里多加几个修正项，不需要额外轮次。
边界与隐私含义
第一条硬边界：由于不存在聚合私钥，这种合成 xpub 只能做未硬化派生。凡是路径里带硬化标记的步骤都无法在这条链路上推导。第二条：链码是公开的固定常数，不构成任何秘密，这个方案的安全性完全依赖聚合公钥本身和 MuSig2 协议，而不是链码的隐蔽性。第三：任何人拿到这个 xpub，都能像拿到普通 xpub 一样列出整条地址序列，所以它的泄露后果与普通观察密钥同级——能看不能花。
还要注意 BIP-328 是 Informational 类型、状态为 Complete 的规范（提案编号于 2024 年 6 月分配），它定义的是实现之间的互操作约定，不改变比特币的共识规则：链上验证只看最终那个聚合公钥和签名，不关心地址是怎么派生出来的。也就是说，即使你的钱包不支持 BIP-328，只要对端支持，交易照常生效，只是双方管理地址的方式不同。
快速问答
问：这和给聚合公钥写进描述符的方案是什么关系？ 答：那是另一层问题——如何让钱包的描述符语言认识 musig 结构；BIP-328 解决的是聚合公钥之后如何低成本地发新地址。两者可以配合，但互相独立。
问：签名人之一离线了还能收新地址吗？ 答：能。合成 xpub 派生地址只需要聚合公钥，各方在真正动用这笔钱的签名会话里才需要全部到场。
问：为什么链码不能随便选一个？ 答：因为各方要从聚合公钥重建出同一个 xpub，链码必须全球统一，随便取会让不同钱包算出不同的地址集。
风险提示：本文仅为密钥管理与协议机制的科普说明，不构成任何投资建议；涉及资金的多签方案请在专业人士协助下部署与测试。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。