MuSig2 签名会话中的状态最小化

作者：salvatoshi

来源：https://delvingbitcoin.org/t/state-minimization-in-musig2-signing-sessions/626

BIP-0327 以巨大篇幅讨论了在运行 MuSig2 签名会话时保存一些状态的必要性。然而，在 BIP-0327 中， “签名会话” 仅仅是 “产生一个签名的过程”。

在一个钱包的标准签名流程中，将 “会话 ”理解为完整签名一笔交易的过程，会更加合理。有可能一笔交易的所有输入，都会通过同一次 “descriptor containing musig()” 来获得，而签名者会一次性为所有输入产生 nonce 公开值（pubnonce）/签名。

因此，在 BIP-0327 流程中，你需要预期同一时间 每个输入都会激活至少一个 MuSig2 会话。在考虑硬件签名设备的支持时，这就在一定程度上带来了挑战：这需要为无法限制数量的签名会话持久保存状态，比如，一个钱包要接收大量小额 UTXO 的时候。可持久保存信息的存储空间，对嵌入式的硬件签名设备来说通常是稀缺资源；而草率的方法很可能就是根据硬件本身的限制，给交易的输入数量施加一个上限。

在这篇文章中，我草拟了一种方法，兼容于且建基于 BIP-0327，旨在定义一种只需在设备上持久化存储少量状态的 PSBT 层面的会话。这一方法通过为每一个单独的 MuSig2 会话同步生成必要的状态，将花费自 MuSig 钱包的 PSBT 的签名流程补充完整了。

使用同步随机性的签名流程

BIP-0327 状态的同步生成

本节将介绍本方法的核心思想，而下一节会在签名设备的语境下提供更精确的描述。

在 BIP-0327 中，签名设备需要保存的内部状态本质上是 secnonce（nonce 秘密值），该值又是让一个随机数 rand’ 进入 NonceGen 算法计算出来的，并且可以选择加入其它依赖于被签名交易的参数。

而本方法的核心思想是，计算出一个全局的随机数 rand_root；然后，为第 i 个输入和 “wallet policy” 所定义的、设备需要用于签名的第 j 个 musig() 密钥定义出用在 NonceGen 中的 *rand’*：

$$rand_{i,j} = SHA256(rand_root||i||j)$$

在拼接过程中，为了避免混淆，i 和 j 使用固定长度的编码。这个数值将在 NonceGen 算法中作为对应的输入/公钥对的 rand’ 值。

参数 j 使我们可以处理包含了涉及相关签名设备多于一个 musig() 公钥表达式的 wallet policy。

签名流程的细节

本节介绍的是 PSBT 层面会话的处理，它将在 BIP-0327 的默认签名流程基础上插入。

我们假设签名设备要处理一个 PSBT 层面的会话；这个流程可以推广到处理多个并行的 PSBT 层面会话，每个会话都会计算和存储一个单独的 rand_root。

在下列段落中，“会话 ”一词总是指代 PSBT 层面的签名会话；一个会话包含自身的 rand_root，可能还包含签名设备希望在处理签名过程中保存的其它辅助数据。

第一阶段：nonce 公开值的生成

一个 PSBT 发送给一个签名设备，该 PSBT 不包含任何 nonce 公开值。

如果已经存在一个会话，将在持久化内存中删除旧会话。
在易失性内存中创建一个新会话。
设备产生一个刷新的随机数 $rand_root$，并保存在当前会话中。
设备为第 $i$ 个输入和第 $j$ 个公钥生成随机性：$rand_{i,j} = SHA256(rand_root||i||j)$。
根据 NonceGen 算法计算每一个 （secnonce, pubnonce）。
在完成阶段（所有的 pubnonce 都已返回之后），会话的秘密值 $rand_root$ 复制到持久化内存。

第二阶段：碎片签名的生成

一个 PSBT，包含了所有的 nonce 公开值，发送到设备。

会话的一个复制本存储到易失性内存，然后该会话从持久化内存中删除。
对每一个输入/musig 公钥对 $(i,j)$：
- 使用上述的同步随机性算法 $rand_{i,j}$ 重新计算 nonce 公开值/nonce 秘密值
- 验证包含在 PSBT 中的 nonce 公开值与重新同步计算出的值相匹配。
- 根据 BIP-0327 继续签名流程，生成签名碎片。

安全考量

避免状态复用

仅在第一阶段的结尾存储会话到持久化内存中，并且在第二阶段开始之前就删除它，可以简化审计，并确保不会出现跨签名会话的状态复用。

同步随机性的安全性

同步生成 $rand_{i,j}$ 并不是问题，因为 $rand_root$ 的值是秘密的，而且不会离开设备。这保证了不同的 $i$ 和 $j$ 所生成的数值对攻击者来说是不可预测的。

PSBT 的熔融性

如果要给 NonceGen 函数传入可选的参数，它们将依赖于 PSBT 中呈现的交易数据。因此，无法保证它们会在下一次到来的 PSBT 中保持不变。

但是，这并不构成一个安全风险，因为这些参数在 NonceGen 函数中只是额外的熵源。恶意的软件钱包无法以可预测的方式影响 nonce 秘密值/公开值。改变任何用在 NonceGen 中的参数都会导致第二节点出错，因为重新计算出的 nonce 公开值 将与 PSBT 中的不一致。

（译者注：即，PSBT 中包含的 nonce 公开值是签名设备在第一阶段中计算出来的；而第二阶段传入的 PSBT 中如果使用了不同的交易数据，设备将根据这些交易数据计算出不同的 nonce 公开值。）

推广到多个 PSBT 签名会话

上述方法假设了，在处理一个会话的时候，不会为包含了 musig() 公钥的一个 wallet policy 的另一个 PSBT 启动签名。

但可以将这种方法推广到任意数量的并行签名会话。每个会话都可以通过哈希（在实用性上）足以唯一定义被签名交易的信息（保证出现在第二阶段的 PSBT 所提供的信息未改变）来计算出一个 会话 id，从而区别每一个会话；举个例子，可以是对 PSBT 所包含的待签名交易的 txid 以及用于签名的 wallet policy 的承诺。

致谢

感谢 Yanick Seurin 在该话题上的不计其数的讨论，以及对本文草稿的审核。错误由我自己负责。

salvatoshi 2024-04-07
https://www.btcstudy.org/2024/04/07/state-minimization-in-musig2-signing-sessions/