MuSig2

设想一笔共同资金，每次付款都要爱丽丝和鲍勃批准。数字签名利用私钥这个秘密数值证明付款获得授权，同时不泄露私钥。传统基于脚本的 Multisig 可能在交易中公开多把公钥和多个签名。使用 MuSig2 时，每个人保留自己的私钥，并为共同签名提供贡献。网络只验证一个结果。节省的是链上记录与验证的成本，参与者之间仍然需要协调。 Jonas Nick、Tim Ruffing 和 Yannick Seurin 在 2020 年 10 月发表的论文中提出了这一协议。 [3] [2] [10]

MuSig2 本身不是 2-of-3 方案，不能让任意两个人替代缺席的第三人。在其 n-of-n 模型中，每名成员都必须参与。离线或拒绝配合的人可以使合作停止。钱包是接收和发送比特币的应用程序或设备。如果钱包需要在这种情况下仍能使用，就必须预先设计另一条花费路径或另一种签名机制；MuSig2 这个名称并不会自动提供备用方案。 [1] [8]

签名前，各方先构造聚合公钥。公钥用于验证签名，不需要保密。第一轮交换公开 nonce，也就是准备签名的一次性贡献。第二轮针对相同消息和上下文生成、交换部分签名，再组合成最终签名。在满足协议条件时，第一轮可以提前完成，即使付款尚未确定也可以。但每名参与者在生成自己的部分签名前，都必须核对具体交易，尤其是收款人、金额和手续费。提前准备不等于同意未知的付款；签完再检查已经太迟。 [1] [3]

如果只是简单相加，攻击者就可能特意选择自己的公钥来利用其他人的公钥。因此，MuSig2 使用根据公钥列表计算出的数值权重，也就是系数。KeyAgg 也考虑公钥顺序；应用可以用 KeySort 统一排序。所有人必须使用相同列表和规则，否则计算出的聚合公钥就不同。 [1] [5]

这里的 nonce 不是挖矿计数器，而是一次性的签名材料：pubnonce 会发送给其他人，secnonce 则留在签名者手中。绝不能把秘密 nonce 重复用于另一次 Sign 调用。重复使用所产生的两个部分签名可能泄露私钥。更换消息或重试看似相同的付款，都不是安全的例外。 [1] [7]

即使密码学计算正确，如果应用重启后从备份恢复了已用过的 secnonce，或把同一份 secnonce 交给两个并行任务，仍然会出问题。Libsecp256k1 在签名时通过覆写使秘密 nonce 失效，但其控制范围外的副本可能绕过保护。状态管理必须在出错、恢复和并发时都防止重复使用。长期签名私钥可以反复使用；一次性要求针对的是 nonce。 [7]

协调者可以收集公开 nonce 和部分签名，帮助各方交换信息。正确使用协议时，这并不会让它代替诚实参与者签名，但它可以破坏流程。每名签名者都必须核查自己签署的内容。部分签名验证有助于查找问题，却需要最初的公开贡献和正确上下文；仅凭聚合 nonce 无法确定责任方。 [1] [7]

最终结果是一个 64 字节的 BIP340 签名。Taproot key path 是一种花费方式：网络针对输出中记录的公钥验证签名，而不披露备用脚本。若不使用默认模式，签名后会附加一个 sighash 类型字节，用来指定签名承诺了交易的哪些部分；修改这些部分会使签名失效。单看签名本身，无法得知参与者人数或各自的公钥。但 MuSig2 不会隐藏金额、付款的所有关联或参与者之间的通信。它也不会自动合并不同输入的签名；输入所引用的是这笔交易要花费的、此前收到的输出。 [5] [6]

除了共同使用的 key path，Taproot 还可以包含脚本条件，例如另一种密钥组合或时间锁。时间锁使某条路径只能在指定时间或区块高度之后使用，并不代替所需签名。区块把交易组成一批，加入共同历史记录。区块高度表示区块在链中的位置。条件必须在创建输出时通过密码学承诺固定下来，输出就是带有花费规则的一笔具体金额。失去签名者后，不能再补充这些条件。Script path 指通过这种脚本花费资金：它会披露相关条件，也可能增加费用。因此，恢复钱包需要保存所选方案的资料，而不只是各自的私钥。 [6] [1] [9]

BIP327 描述协议，而实际接口、备份和可用流程由所用库及钱包决定。应检查版本、测试向量、nonce 管理与待签交易核查方式。支持 Schnorr 签名，并不等于每个钱包都完整支持 MuSig2。共同签名使用现有的 BIP340 和 Taproot 规则；单纯使用 MuSig2 不需要新的共识 opcode。 [4] [7] [2]