盲化的双人 Musig2
关于 Musig2 Schnorr 多重签名协议实现的提案，其中有 2 个参与方，但其中一个协同签名方无法得知：1) 完整的共享公钥，或 2) 生成的最终签名。
在以下描述中，私钥（域元素）用小写字母表示，椭圆曲线点用大写字母表示。G 是生成点，点乘表示为 X = xG，点加表示为 A = G + G。
H() 是哈希函数。
Schnorr 签名
在标准的 Schnorr 签名协议中，签名者生成一个私钥（域元素）x 和相应的公钥 X = xG。
为了对消息 m 进行签名，签名者生成一个临时密钥/nonce（域元素）r 和相应的公共点 R = rG。
签名者计算 e = H(X||R||m) 和 s = e.x + r。签名是 (R,s) 对。
双人 Musig2
双人 Musig2 协议的工作方式如下：
参与方 1 生成私钥 x1 和公钥 X1 = x1G。参与方 2 生成私钥 x2 和公钥 X2 = x2G。公钥集合为 L = {X1,X2}。密钥聚合系数为 KeyAggCoef(L,X) = H(L,X)。共享（聚合）公钥 X = a1X1 + a2X2，其中 a1 = KeyAggCoef(L,X1)，a2 = KeyAggCoef(L,X2)。
为了对消息 m 进行签名，参与方 1 生成 nonce r1 和 R1 = r1G。参与方 2 生成 nonce r2 和 R2 = r2G。这些被聚合成 R = R1 + R2。
然后，参与方 1 计算 c = H(X||R||m) 和 s1 = c.a1.x1 + r1。
然后，参与方 2 计算 c = H(X||R||m) 和 s2 = c.a2.x2 + r2。
最终签名是 (R,s1+s2)。
盲化的双人 Musig2
如果参与方 1 不需要独立计算和验证 c = H(X||R||m)（因为它们在任何情况下都无法得知消息），那么在这种情况下，阻止参与方 1 了解完整公钥或最终签名是很容易的。
1) 密钥聚合仅由参与方 2 执行。参与方 1 只需将 X1 发送给参与方 2。
2) Nonce 聚合仅由参与方 2 执行。参与方 1 只需将 R1 发送给参与方 2。
3) 参与方 2 计算 c = H(X||R||m) 并将其发送给参与方 1，以便计算 s1 = c.a1.x1 + r1。
参与方 1 永远不会得知 (R,s1+s2) 或 m 的最终值。
密钥更新
为了在状态币在用户之间转移时更新服务器（参与方 1）的密钥份额，每个密钥的密钥聚合系数必须设置为 1。Musig2 协议中此系数的目的是防止“流氓密钥攻击”，其中一方可以选择一个从他们自己的密钥和另一方公钥的倒数派生的公钥，从而使他们能够单方面生成对聚合密钥的有效签名。但是，正如 musig2 论文中指定的那样，可以通过一方提供与其提供的公钥相对应的私钥知识证明来防止这种情况。这可以简单地以签名的形式提供，无论如何，该签名是通过在 mercury 协议中对状态链状态进行签名而生成的。
当接收状态币时，为了验证币地址（即聚合公钥）是否在之前的拥有者和服务器之间正确共享，客户端必须验证以下内容：
1) 从服务器检索此币的当前公钥（份额）X1。
2) 检索发送者的公钥（份额）X2。
3) 验证 X1 + X2 = P，即状态币的地址。
4) 验证发送者是否拥有用于生成 X2 的私钥：这是通过验证来自 X2 的接收者公钥 X3 的状态链签名来完成的。
这证明了地址 P 是与服务器一起生成（聚合）的，并且只能与服务器合作签名，即之前的拥有者不能拥有完整密钥。
为了更新密钥共享，可以使用以下协议：
- 服务器（参与方 1）生成一个随机的盲化 nonce
b 并发送给客户端（参与方 2）。
- 客户端执行
transfer_sender 并将他们的私钥添加到 nonce：t1 = b + x2
- 客户端将
t1 作为 transfer_msg_3 的一部分发送给接收者（使用接收者公钥 X3 = x3G 加密）。
- 接收者客户端解密
t1，然后减去他们的私钥 x3：t2 = b + x2 - x3。
- 接收者客户端将
t2 作为 transfer_receiver 的一部分发送给服务器。
- 服务器然后更新私钥份额
x1_2 = x1 + t2 - b = x1 + b + x2 - x3 -b = x1 + x2 - x3
所以现在，x1_2 + x3（新的服务器密钥份额与新的客户端密钥份额的聚合）等于 x1 + x2（旧的服务器密钥份额与旧的客户端密钥份额的聚合）。
- 服务器删除
x1。
