论文笔记：ValueShuffle-ixing Confidential Transactions for Comprehensive Transaction Privacy in Bitcoin

《ValueShuffle: Mixing Confidential Transactions for Comprehensive Transaction Privacy
in Bitcoin》
DiceMix的后续文章，将CoinShuffle++扩展到与机密交易兼容。

Intro

在CoinJoin的基础上，设计了ValueShuffle，这是第一个与机密交易兼容的硬币混合协议，这是对比特币协议的一种改进，可以在区块链中隐藏支付价值。

• ValueShuffle确保了混合参与者的匿名性以及他们的支付值的机密性，即使是针对其他可能恶意的混合参与者。
• 通过将CoinJoin与机密交易和额外的隐形地址相结合，ValueShuffle提供了全面的隐私(付款人匿名，收款人匿名和支付价值隐私)，而不会打破当前比特币系统的基本设计原则或功能。
• 假设将Confidential Transactions集成到比特币协议中，ValueShuffle 使不同价值的资金混合以及在同一笔交易中混合和花费资金成为可能，这克服了以前的硬币混合协议的两个主要限制

能否设计一个P2P的硬币混合协议，使一组互不信任的用户能够创建一个CoinJoin保密交易，而不泄露输入和输出之间的关系或他们彼此的支付值?

第一个与CT兼容的币混合协议。ValueShuffle是P2P币混合协议CoinShuffle++ [34]的扩展，后者是将高效的消息混合协议DiceMix [34]应用于基于CoinJoin的币混合设置的结果。由于ValueShuffle成功地结合了币混合、SA和CT，所得到的货币提供了全面的隐私，即付款人匿名、收款人匿名和价值隐私。

通过克服当前混币方法的两个主要限制来实现这一目标。

• 所有形式的币混合都严重限制于混合相同价值的资金。将价值隐私添加到币混合中完全消除了这一限制，但也带来了一个挑战，即向网络证明在混合中没有创建资金，因为支付价值不再明确。
• 用户需要通过先将资金发送到自己的新地址来混合它们（在CoinJoin交易中），在此之后，用户才能将混合资金在第二笔交易中支付给收款人。在ValueShuffle中，我们依靠SA和CT使用户能够直接将资金发送到CoinJoin交易中预期的接收者，这可以说是CoinJoin最理想的使用方式。

Building Blocks

ValueShuffle的三个构建块：peer-to-peer mixing, Confidential Transactions, and Stealth Addresses.

ValueShuffle

Security and Privacy特征

• 不可链接性:在协议创建的CoinJoin事务中，给定一个输出和两个属于诚实用户的输入，攻击者无法判断这两个输入中哪一个支付给了输出。
• CT兼容性:该协议生成CoinJoin交易，而不会损害CT提供的诚实用户的个人价值隐私。
• 防盗窃:每个诚实用户的资金要么按预期转移给收款人，要么留在诚实用户那里。
• 终止:协议为诚实用户终止

威胁模型：认为攻击者控制了所有恶意用户。但是，对于不可链接性，需要$f<n-1$，其中$n$是未被剔除的用户的集合，以确保存在有意义的匿名集。

• 攻击者还控制公告板，这使他能够阻止来自诚实用户的消息。
• 仅对于终止属性，我们假设公告板是诚实的。

技术挑战与解决方案

注意：为了简化模型，所有交易都只有一个输入和一个输出，没有交易费

基本设计：

• 从高层次的角度来看，执行ValueShuffle的用户运行DiceMix不仅混合了他们的输出地址(就像在CoinShuffle++中所做的那样)，还混合了他们的输出三元组，即由输出地址(或脚本)、CT值承诺和相应的范围证明组成的三元组。
• 如果DiceMix成功运行，那么它将把一组匿名三元组传递给应用程序定义的确认机制，该机制将确认混合的结果。
• 与CoinShuffle++一样，ValueShuffle中的确认机制是对CoinJoin交易进行集体签名，要么通过收集签名的普通列表，要么通过执行交互式协议来创建聚合Schnorr签名[41]。

处理中断

识别破坏性用户很简单:拒绝签署最终CoinJoin交易或提供错误签名(或在Schnorr聚合签名的情况下提供错误的部分签名)的用户显然具有破坏性

混合输出三元组的新鲜度

回想一下，DiceMix要求混合消息(即我们的示例中的输出三元组)是新鲜的，并且具有足够的熵来确保匿名性。这正是我们能够利用一次性地址和CT的地方：新的不可链接输出地址+机密交易的承诺方案的随机性+范围证明的随机性。因此，输出三元组的所有三个组件都可以新生成。

Multiple-Payer CT.

在有多个支付方的混合交易中，可验证交易的天真构造将要求用户向彼此透露承诺中使用的随机性，从而损害承诺的隐藏属性。
解决这个问题：

• 用户可以运行一个安全的求和协议（加性秘密共享的标准安全求和协议），共同计算他们的随机值的和$r_{\Delta }={\sum }_i{r}_i-r_i^{\prime }$，$r_i$表示用户$i$输入值承诺的随机性，$r_i^{\prime }$表示同一用户$i$输出值承诺的随机性。
• 所有用户都可以将$r_{\Delta }$作为显式的公开随机性值添加到交易中，并且整个交易再次有效，可以通过检查是否公开验证$\oplus c_i=\oplus c_i^{\prime }\oplus Com(0,-r_{\Delta }).$（抵消承诺中的所有随机性，来验证输入输出balance）
• $r_{\Delta }$可以通过基于加性秘密共享的标准安全和协议获得，其中每个用户$i$广播她的值$r_i-r_i^{\prime }$被掩码(pad)隐藏，每个pad与另一个用户共享。然后将来自所有用户的消息组合在一起，这样共享密钥就可以抵消，并获得总和$r_{\Delta }$。这种机制在本质上相当于DiceMix中已经使用的DC-net.

处理安全和协议中断。

恶意用户不仅可以破坏输出三元组的混合，还可以通过创建与输入承诺值不匹配的输出值承诺来破坏安全求和协议，这可以在创建CoinJoin事务时检测到

解决：和DC-NET中类似地利用牺牲匿名性来检查并剔除破坏者。
类似于牺牲DC-net中用于混合输出三元组的匿名性，我们可以牺牲DC-net中用作安全求和协议的匿名性。对于每个用户$i$，她声称的是$r_i-r_i^{\prime }$。利用CT的验证方程，所有诚实的用户都可以很容易地单独检查每个用户i的平衡属性，即检查用户i的输出承诺是否与输入承诺一致。请注意，这种方法不会显示用于用户i的输入承诺或输出承诺的随机值，这会导致她的预期支付值泄露。

结合P2P混合和安全求和。

由于DiceMix和安全求和协议在结构上是相似的(依赖于dc -net)，可以优化它们的组合。

首先，我们可以依赖于一个密钥交换，并为P2P混合和安全求和协议派生独立的子密钥。这意味着，如果两个协议中的一个被终止，那么另一个也必须被终止，因为用于密钥交换的是相同的临时密钥，必须被披露。

在DiceMix中混合长消息

虽然DiceMix目前的形式对于小消息m是实用的(例如，CoinShuffle++使用的$|m|=160$位)，但对于我们需要的大小的消息来说，它太慢了;我们需要$|m|\approx 20,000$比特来混合CT所需的相当大的范围证明。最昂贵的计算步骤是多项式分解，并且要求每个消息都是有限域的一个元素，因此有限域的大小必须约为$2^{|m|}$。

解决：将$m$分成几块$m=m_1||...||m_l$，在DiceMix的基本混合步骤的不同并行运行中混合这些块

挑战：如何再次重新组合消息，因为混合确保不可能知道哪些块属于一起(即属于同一个用户)。

解决：在$1<i\le l$的每一个$m_i$前面加上前缀$F(m_1)$，其中F是一个抗碰撞哈希函数，这样:$m_1^{\prime }=m_1,m_i^{\prime }=m_1||m_i$

需要考虑权衡计算和通信:更大的分块减少了所需的并行混合实例的数量，但需要更高的多项式分解的计算成本。

支持任意脚本

Overview of ValueShuffle

用户$i$三元组：$i{n}_i=(c_i=Com(x_i,r_i)，{\pi }_i,v{k}_i)$，$c_i$-随机性$r_i$对输入值$x_i$的承诺，${\pi }_i$-$c_i$的范围证明，$v{k}_i$-$i$用户拥有的比特币地址。假设每个用户只有一个输入三元组，并且没有费用。

ValueShuffle的执行：$runs$
每次包含四个阶段：

1. Output Generation
   每个用户i在本地生成她的输出三元组$ou{t}_i=(c_i^{\prime }=Com(x_i^{\prime },r_i^{\prime }),{\pi }_i^{\prime },add{r}_i^{\prime })$（$add{r}_i^{\prime }$接收者的新一次性地址）
2. Mixing and Secure Sum.

• 用户并行运行一个P2P混合协议来混合他们的输出三元组$ou{t}_i$和一个安全求和协议来私下计算和$r_{\Delta }={\sum }_i{r}_i^{\prime }-r_i$
• 通过添加显式随机值$r_{\Delta }$，可以将输入和输出消息组合起来，以确定地形成一个(仍然是未签字的)CoinJoin事务

3. Check.
   用户检查结果CoinJoin交易的有效性，即

• 查验${\pi }_i^{\prime }$对于承诺$c_i^{\prime }$
• 检查预期交易的整体余额是否正确：$\oplus c_i=\oplus c_i^{\prime }\oplus Com(0,-r_{\Delta }).$
• 每个用户都验证她的输出三元组是混合结果的一部分，即没有硬币被交易窃取。

4a. Confirm
如果所有检查都通过，则交易有效，并要求用户对其签名。
拒绝签署交易的用户是破坏性的。如果发生这种情况，它们将被排除，并开始新的协议运行。
4b. Blame
如果Confirm失败，执行Blame来检测恶意用户。

• 每个用户$i$广播用于混合和安全求和协议的secret，从而揭露值$r_i-r_i^{\prime }$.
• 每个其他用户$j$都可以重新计算用户$i$的混合和安全求和步骤，并检测她是否忠实地遵循了协议规范。然后将暴露的恶意用户剔除在协议之外，并开始新的运行。

Performance

$4+2f$ rounds，和CoinShuffle++一样（DiceMix）

ValueShuffle Protocol

构建块

• Digital Signatures.
• Non-interactive Key Exchange .
  $NIKE.KeyGen(id)\leftarrow (nsk,npk)$
  $NIKE.SharedKey(i{d}_1,i{d}_2,ns{k}_1,np{k}_2,sid)=NIKE.SharedKey(i{d}_2,i{d}_1,ns{k}_2,np{k}_1,sid)$ 输出一个shared key
  $NIKE.ValidatePK(npk)$输出true，如果$npk$是NIKE.KeyGen输出空间的合法公钥。
  $NIKE.ValidateKeys(npk,nsk)$输出true，如果$nsk$是公钥$npk$的私钥
  实例化：Static Diffie-Hellman key exchang e N I K E . S h a r e d K e y ( i d 1 , i d 2 , x , g y ) = K ( ( g x y , { i d 1 , i d 2 } , s i d ) ) NIKE.SharedKey(id_1, id_2, x, g^y)=K((g^{xy},\{id_1,id_2\},sid)) NIKE.SharedKey(id1​,id2​,x,gy)=K((gxy,{id1​,id2​},sid))（K是hash）
• Hash：H,G,F，作为随机谕言机
• Confidential Transactions（CT）
  • 非交互式承诺方案$(Com、Open)$。
    $Com(m,r)\leftarrow c$, $Open(param,c,m,r)\leftarrow true/false$
    加性同态承诺方案：$Com(m_1,r_1)\oplus Com(m_2,r_2)=Com(m_1+m_2,r_1+r_2)$
    实例化：Pedersen commitments
  • 范围证明$(RPCreate、RPVerify)$
    $\pi :=RPCreate(m,r)$,$b:=RPVerify(\pi ,c)$，如果$pi$是对于$c$的有效范围证明，返回true.
• Confirmation.
  • 确认子协议ConfirmTx()使用CoinJoin来执行实际的混合。算法$CoinJoinTx()$创建一个CoinJoin交易，算法$Submit(tx，\sigma [])$向比特币网络提交包含相应签名$\sigma []$的交易$tx$。
  • ConfirmTx()产生一个带有每个用户一个签名的CoinJoin事务。
  • （可替代方案是可能的，例如，如果Schnorr签名在比特币中可用，则可以使用两轮聚合Schnorr签名协议来签署交易。在这种情况下，可以预先执行两轮协议的第一轮(与ValueShuffle的主要部分并行)，因为这一轮不依赖于混合的输出，因此ConfirmTx()实际上仍然只需要一轮，而完整的协议仍然只需要4 + 2f轮。）

ValueShuffle

安全性

不可链接性

不可链接性源于DiceMix中的发送方匿名性:由于每次运行都新生成输出三元组，因此DiceMix保证诚实的用户形成适当的DC-net。这反过来又确保了攻击者无法区分用户i的输出三元组是属于i还是属于其他诚实的用户j。

CT兼容性

ValueShuffle使用(并在责备阶段实际显示)属于用户i的唯一CT秘密是她的值$r-{\sum }_k{r}_k^{\prime }$。由于$r,r_k^{\prime }$都是随机的，这个sum值不会泄露任何$r,r_k^{\prime }$的值，因此不影响输入承诺或任何单个输出承诺的隐藏属性。

Termination

DiceMix本身提供了终止，本文的扩展不会影响这个属性。

这主要归结为确保在每个协议运行中都可以检测到恶意用户。

• 如果一个用于混合输出三元组的DC-net被破坏，那么恶意用户将被识别出来。这源于DiceMix的终止和每个消息块都是不可预测的观察。
• 如果用于计算$r_{\Delta }$的DC-net被破坏，那么责备阶段将丢弃输出三元组，并且恶意用户将通过检查她的个人balance属性来识别。
• 如果提供了错误的范围证明，那么责备阶段将丢弃输出三元组，并且可以通过检查谁提供了错误的范围证明来识别恶意用户。
• 在所有其他情况下，事务将通过构造有效，因此拒绝签名的用户是恶意的(或脱机)，因此可以被排除在进一步运行之外。

盗窃阻止

协议必须确保诚实的用户不会遭受金钱损失(忽略交易费用)。ValueShuffle确保了防盗窃，因为输出三元组和随机性的混合不涉及资金转移。**在CoinJoin交易形成之前，每个诚实的用户都会检查她的输出地址和相应的承诺值是否包含在内，然后才会签署交易。**由于CoinJoin交易只有在每个用户都签署了交易(从而确认她的资金没有被盗)后才有效，因此ValueShuffle提供了防盗窃功能。