协议演进 / BIP/比特币改进提案 / BIP-328
BIP-328
把 MuSig2 聚合公钥配上固定链码做成合成 xpub，让多签各方只需一份扩展公钥即可派生新的聚合公钥。本 BIP 目前处于已完成状态。
一、档案卡
| 编号 | BIP-328 |
|---|---|
| 标题 | Derivation Scheme for MuSig2 Aggregate Keys |
| 作者 | Ava Chow <[email protected]> |
| 指定日期 | 2024-06-04 |
| 层级 | Applications（应用） |
| 类型 | Informational（信息类） |
| 状态 | Complete（已完成） |
| 阅读版 | https://bips.dev/328 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0328.mediawiki |
二、放在哪一族
MuSig2 配套族，紧贴 BIP-327 与 BIP-32 之间。
BIP-327：MuSig2 多签标准，产出与普通公钥无异的聚合公钥，本篇的派生对象正是这种聚合公钥
BIP-32：分层确定性钱包，定义扩展公钥（xpub）、链码与 CKDpub 子公钥派生，本篇借用整套派生机制
它解决的是多签实践中的一个具体环节：脚本多签时代，各方共享各自的 xpub、分别派生再拼脚本；换到 MuSig2 后，如何同样做到“一套密钥、不断派生新地址”。本篇给出的答案是只派生聚合公钥本身。
三、它要解决什么
多位共同签名者用 MuSig2 造出一个聚合公钥，它与随机公钥不可区分。遵循“每笔收款用新地址”的最佳实践，各方需要不断生成新的聚合公钥。
直白的做法是：每位签名者都生成多份公钥，每需要一个新聚合公钥就重新聚合一次。这类似脚本多签里各方共享 xpub、派生后拼出多签脚本的做法，可行，但要管理多份扩展公钥，存储与计算负担都更重。
既然 MuSig2 的聚合公钥本身看起来就是一个普通公钥，能不能只拿这一份公钥当 xpub 来派生？本篇就是把这一简化写成规范：从单个扩展公钥派生，而不是从许多扩展公钥派生再聚合，从而降低生成新聚合公钥所需的存储与计算。
四、规则本身
4.1 合成 xpub 的构造
从 BIP-327 的普通（plain）聚合公钥构造一个合成 xpub（synthetic xpub）：
- 深度（depth）设为 0；
- 子编号（child number）设为 0；
- 链码固定为字节串
868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965，即文本MuSig2MuSig2MuSig2的 SHA256。
所有遵循本规范的合成 xpub 都必须使用这个固定链码。构造完成后，即可像对待任何普通 xpub 一样，从它派生非硬化（unhardened）子公钥。
4.2 只能非硬化派生
不存在“聚合私钥”这种东西——私钥始终分散在各位签名者手中。因此，从聚合公钥出发只能做非硬化派生，硬化派生不可能，这也是本方案的固有限制。
隐私上也要清醒：只要有聚合公钥就能造出合成 xpub，所以这种聚合公钥享有与普通 xpub 相同的隐私顾虑——泄露 xpub 意味着别人能推导出你全部派生地址并加以关联。
4.3 签名时如何计入派生
为某个派生子密钥签名时，所有签名者都必须算出 BIP-32 派生在该子密钥上用到的微调（tweak）。具体来说，CKDpub 每一步算出的 I_L 值，就是那一步的微调；这些微调被放进 BIP-327 的会话上下文，每个的微调模式都设为普通微调（is_xonly_t = false）。运行 Sign 算法时，微调会被应用到部分签名上，最终签名对派生后的子聚合公钥有效。
4.4 测试向量
原文给出三组测试向量：每组包含一个聚合公钥、由它构造的合成 xpub，以及从该 xpub 派生出的若干子公钥，供实现者核对构造与派生是否正确。另附一份 Python 参考实现，放在该 BIP 的辅助文件中。
五、谁必须动
普通持币人：无直接操作。使用 MuSig2 多签钱包时，地址轮换由钱包按本方案在后台完成；但要意识到合成 xpub 与普通 xpub 一样敏感，不要随意公开。
钱包开发者：需要按固定链码构造合成 xpub、只做非硬化派生，并在签名时把每一级派生的 I_L 作为普通微调传入 BIP-327 会话上下文。原文称合成 xpub 一旦造出，即与 BIP-32 完全向后兼容，签名者能为任意派生子密钥产出签名。
全节点与矿工：无事可做。派生发生在钱包内部，链上看到的只是普通的 Taproot 输出与签名。
共识层：不涉及。本篇是信息类文档，规范的是钱包侧的密钥管理约定。
六、现在算不算数，以及一个常见误读
状态为 Complete（已完成），类型为 Informational（信息类）。含义是这份派生方案已经定稿成文，可供 MuSig2 钱包按同一规则实现互操作；它不是共识规则，也没有“激活”一说。原文未统计各钱包的实际采用情况，本页不臆测。
常见误读：
“有了合成 xpub，就等于有了一个聚合私钥，可以像单签一样做硬化派生。”
不对。原文明确：不存在聚合私钥，所以只能做非硬化派生。各位签名者的私钥从不合并，派生只动公钥一侧，签名时再由各方把派生微调计入各自的部分签名。
七、延伸
- 阅读版：https://bips.dev/328
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0328.mediawiki
- 相关：BIP-327 MuSig2 多签、BIP-32 分层确定性钱包
- 仓库总目录：https://github.com/bitcoin/bips