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’*：

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

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

签名流程的细节

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

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

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

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

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

• 如果已经存在一个会话，将在持久化内存中删除旧会话。

• 在易失性内存中创建一个新会话。

      设备产生一个刷新的随机数randroot，并保存在当前会话中。

      设备为第i个输入和第j个公钥生成随机性：randi,j=SHA256(randroot||i||j)。

• 根据NonceGen算法计算每一个（secnonce,pubnonce）。

       在完成阶段（所有的pubnonce都已返回之后），会话的秘密值randroot复制到持久化内存。

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

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

• 会话的一个复制本存储到易失性内存，然后该会话从持久化内存中删除。

       对每一个输入/musig公钥对(i,j)：

    使用上述的同步随机性算法randi,j重新计算nonce公开值/nonce秘密值

• 验证包含在PSBT中的nonce公开值与重新同步计算出的值相匹配。

• 根据BIP-0327继续签名流程，生成签名碎片。

安全考量

避免状态复用

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

同步随机性的安全性

同步生成randi,j并不是问题，因为randroot的值是秘密的，而且不会离开设备。这保证了不同的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 的承诺。