社区
融资信息
专题
链上生态
词条
播客
活动
OPRR
硬核 | 一起了解比特币混币方案：TumbleBit
原文标题：《硬核 | 一起了解比特币混币方案：TumbleBit》
原文来源：Nervos
TumbleBit 是 17 年发表在 NDSS 的文章，是一个兼容比特币的中心化混币协议，是解决比特币交易可链接问题的协议，TumbleBit 可以扩展区块链的交易量，也可以扩展区块链的交易速度。在本篇文章中，热爱研究的 Nervos 小伙伴马宇峰详细分析了 TumbleBit 的总体框架结构，它的解谜协议和谜题协议，并且介绍了针对 TumbleBit 不可关联性的一些攻击。快来 Get 新技能吧。
总体框架结构
由于 TumbleBit 需要兼容比特币这种仅支持非图灵完备语言的区块链，它的链上部分需要的密码学原语很少也很简单。此外虽然是中心化的协议，但即使是恶意的 Tumbler 也不能偷币，并且在不和参与用户共谋的情况下也不能找到交易输入和输出的链接关系。和 coinjoin、coinshuffle 这种区中心的混币协议相比，TumbleBit 的优点在于不需要交易方与其他用户交互，交互只发生在交易双方和 Tumbler 之间。
TumbleBit 可以将发给一方的许多交易聚合为两笔链上交易，并且这些交易不需在区块链上存储或验证，因此可以扩展区块链的交易量，并且 TumlbeBit 的链下交易可以在秒级时间内完成，因此也可以扩展区块链的交易速度。
TumbeBIt 的主要思想很简单：它使用链下解谜来替代链上支付。当 Alice 想要给 Bob 支付一笔钱时，Alice 给 Bob 一个谜题的解，这个谜题是 Bob 和 Tumbler 交互产生的，这个谜题的解是 Alice 和 Tumbler 交互产生的。每解一个谜，Alice 转给 Tumbler 一个比特币，Tumbler 再转给 Bob 一个比特币。
TumbleBit 协议构造如上图所示。TumbleBit 协议以 epoch 为周期运行，需要注意的是所有参与 TumbleBit 协议的人都知道每个 epoch 周期内各个阶段的时间。每个 epoch 分为三个阶段：
第一是 Escrow 阶段，这个是链上托管的阶段。在这个阶段收款人 Bob 告诉 Tumbler 在这个 epoch 内最多接收 3 个比特币，然后 Tumbler 构造一笔托管交易 
这是一个 2-of-2 的多签交易，解锁条件为 Bob 和 tumbler 签名或者超过 tw2 后由 Tumbler 签名取出，然后 Bob 和 Tumbler 之间通过运行一个链下的 Puzzle-Promise 协议让 Bob 获得 promise-puzzle 对，也就是图中的 （c，z)，
是 Tumbler 对这笔交易的签名，c 是用对称密钥
对签名加密的密文，我们称 c
为 promise， z
是一个 RSA puzzle，是用 Tumbler 的公钥对对称密钥 加密后的密文，协议运行完成后 Tumbler 将 
交易发到链上，付款人 Alice 在这个阶段也发送一笔托管交易 
，这也是一笔 2-of-2 的多签交易，解锁条件为 Alice 和 Tumbler 的签名，或者超过时间 tw1 后由 Alice 取回；
第二是 Payment 阶段，这个是链下支付阶段。在这个阶段 Bob 将 puzzle 盲化后发送给 Alice，盲化 puzzle 的目的是为了防止 Tumbler 将交易方关联起来，盲化方法很简单，就是选取一个盲因子 r，
然后用 Tumbler 的公钥对 r
加密后乘上原来的 puzzle 
Alice 拿到盲化的 puzzle 后和 Tumbler 运行一个 RSA-Puzzle-Solver 协议，拿到盲化 puzzle 的解，发给 Bob，由于 RSA 算法具有乘法同态性，对盲化 puzzle 解密后就是 
除以 r 即可得到 
, 然后解密就能得到签名 
;
最后是 Cash-out 阶段，这个是链上进⾏的提现阶段。Alice 拿回剩余的 2 个⽐特币，⽀付 Tumbler ⼀ 个⽐特币，Tumbler 拿回剩余的 2 个⽐特币，⽀付 Bob ⼀个⽐特币。
解谜协议
本文会重点介绍一下 RSA-puzzle-solving 协议，这是一个公平交换协议。当且仅当 Tumbler 给 Alice 一个 RSA puzzle 的解时，Alice 支付给 Tumbler 一个比特币，这个协议除了可集成在 TumbleBit 协议上以外，也可以在其他场景中作为公平交换协议独立运行。
这个协议的核心思想是 Tumbler 解迷 Alice 的 puzzle 之后，将这个解用对称密钥 k
加密得到密文 c，然后使用比特币支持的哈希算法计算 k
的哈希为 h，之后将（c，h）发送给 Alice, Alice 收到之后发送交易
解锁条件为提供 h
来拿到这个比特币，
公开后 Alice 就可以拿到 k了，用 k 对 c
这个协议面临一个挑战，就是不使用零知识证明的条件下找到一种办法能够让 Alice 验证密文 c
图 2. RSA-puzzle-solving 协议
协议的具体细节如上图所示，公共输入是 Tumbler 的 RSA 公钥（e，N）, Alice 的输入是 puzzle
首先 Alice 准备真 puzzle 集合，包含 m
第二步，Alice 准备假消息集合，里面包含 n
接下来 Alice 对混合真假 puzzle 的集合进行随机排序，得到一个新的集合，并记下真 puzzle 和假 puzzle 所对应的下标，然后将这个新集合发送给 Tumbler；
Tumbler 对新集合的每个元素都解密，然后将得到的明文用不同的对称密钥加密得到新密文，之后将所有的新密文以及新密文所对应的密钥的哈希发送给 Alice；
Alice 将假 puzzle 的下标以及假 puzzle 中的随机数原文发给 Tumbler, Tumbler 验证集合 F 中的 puzzle 确实是假消息 (如果是真消息的话，Alice 没有密钥是不可能知道 y
Alice 解密假 puzzle, 判断 Tumbler 是否欺骗了 Alice. 如果验证通过，Alice 构造并公开交易 
, 解锁条件为超过 tw1 由 Alice 签名解锁，或 Tumbler 提供所有真 puzzle 对应的密钥；
然后 Alice 将真 puzzle 以及所有盲因子发给 Tumbler, Tumbler 验证所有的真 puzzle 是否对应同一个 puzzle，如果验证通过就发布 
交易来拿到比特币，
里面包含所有的真 puzzle 密钥；
最后 Alice 通过真 puzzle 密钥来解谜。
可见这个协议只有当 Tumbler 打开的假谜题都是正确的，且所有没打开的真谜题都是错误的时候，Alice 才拿不到一个正确答案，这个概率是
。
上述协议如果直接用到 TumbleBit 上的话会存在三个问题：第一个是上述协议只支持 Alice 获得一个 puzzle 的解，应该扩展为可获得任意数量 Q 个谜题的解；第二是这个协议应该完全发生在链下，目前协议需要两个链上交易 
和 
; 第三个是 
交易比典型的交易都长，因为它包含 m
解决方法是：
第一，在 escrow 阶段，Alice 发送 
抵押 Q 个比特币，
的解锁条件为 Alice 和 Tumbler 的签名或超过时间 tw1 后由 Alice 签名解锁；
然后在支付阶段，Alice 可以买至多 Q 个 puzzle 的解，Tumbler 维持一个计数器来计算已经给 Alice 提供了几个解。现在假设 Alice 正在询问第 i
1. Alice 构造并签署交易 
发给 Tumbler, Tumbler 收到这个交易后既不签名也不公开；
交易指向 
交易，也就是将 
交易的输出作为 
交易的输入，即将 
交易的比特币转到 
交易中，
交易输出有两个，一个是发给 Tumbler 的 i
个比特币，当然这个交易需要 Tumbler 提供密钥才能解锁；
3. Tumbler 不使用 
交易来发送密钥，而是直接将密钥发给 Alice;
4. Alice 验证密钥是否正确，如果正确，Alice 签署一个在提现阶段使用的交易
如果 Alice 作弊收到正确密钥后不发送 
，那么 Tumbler 可通过公开 
和 
来获得应得的比特币，代价是 
和 
比常规交易大，需要多付些手续费。经过这些修改后的 RSA-puzzle-solving 协议可以用在比特币上了。
谜题协议
接下来讲一下 puzzle-promise 协议，这个协议是在 escrow 阶段运行在收款人 Bob 和 Tumbler 之间的链下协议，目标是让 Bob 获得一个 promise-puzzle 对(c,z)
这个协议的挑战是如果 Tumbler 仅仅发送一个
(c,z) 给 Bob, 那么 Bob 就不知道 c 是否是正确签名的加密，也不知道 z
我们仍然可以通过 cut-and-choose 来应对这个挑战。但是和 RSA-puzzle-solving 协议不同的是 Bob 会得到许多 puzzle-promsie 对，而 cut-and-choose 保证的是至少有一对是正确的（保证全部正确的概率低于至少一对是正确的概率），而 Bob 一次只能问 Alice 一个谜题，TumbleBit 通过 RSA 商链的技术来解决这个问题，通过使用 RSA 商链技术可以保证 Bob 拿到一个谜题的解后能得到所有的谜题的解。
图 3. Puzzle-promise 协议
篇幅所限，下面我们简单地介绍一下 cut-and-chosse：
Bob 通过对 
个格式不同但含义相同的 
交易作为真集合，然后在准备
个假交易集合，将这两个集合合并打乱后发给 Tumbler，Tumbler 对集合中的每个元素都签名，并使用不同的密钥进行加密，将所有 puzzle-promise 对发给 Bob 后 Bob 发送假消息集合给 Tumbler。
Tumbler 验证假消息集合真实性，如果验证通过将假集合对中的对称密钥发给 Bob，Bob 用此密钥解密签名，验签正确后 Tumbler 开始准备 RSA 商链。所谓的商链就是 Tumbler 用后一个对称密钥除以前一个对称密钥，得到 
个商（上图第 9 步），然后将这些商发送给 Bob。
Bob 利用 RSA 算法的同态性验证这些商的正确性，如果验证通过，将第一个 puzzle 发给 Alice，拿到解 
后乘以 
就得到了
个交易的签名。虽然这些交易不同，但只是填充部分不同，因此 Bob 只能使用一个 
交易来取现。
不可关联性
到这里完整的 TumbleBit 协议部分就介绍完了，接下来看一下 TumbleBit 的不可关联性。我们先看一下 Tumbler 的视角如下图所示，Tumbler 看不到交易间的关联性，但是能看到付款人在哪个时间和自己交互的，因此结合一些额外信息，可以对交易间的关联性进行分析。我们下面介绍一些针对 Unlinkable 的攻击，这些攻击中有些是能避免的，有些是没有很好的方法避免的。
图 4. Tumbler 视角
天花板攻击 Alice 和 Tumbler 共谋可以制造 ceiling attack，ceiling attack 被称为天花板攻击。它假设在某时刻比如 
, Alice 向 Bob 支付一个比特币，但是 Bob 已经达到的接收上限，因此拒绝了 Alice 的付款请求。Alice 把这个消息告诉 Tumbler，Tumbler 可以排除 
时刻后的交易是发给 Bob 的可能。如果 Alice 不与 Tumbler 共谋的话 Tumbler 是不知道 Bob 啥时候达到接受上限的。
这种攻击是有好几种解决办法的，比如：Bob 在 escrow 阶段让自己的接收上限远高于这个预期内能接收的钱；或者可以错开 TumbleBit epoch 的时间，同时运行几个 TumbleBit epoch，Bob 一个 epoch 内的额度用完的话，就用下一个 epoch 的额度。
Bob 和 Tumbler 共谋
Bob 和 Tumbler 共谋：Bob 告诉 Tumbler 自己发给 Alice 盲化 puzzle, 这样 Tumbler 可以知道 Alice 的身份（尤其适用于 Alice 和 Bob 不知道对方身份的场景，比如使用 tor 协议）。解决方法很简单，Alice 对 Bob 发给自己的盲化 puzzle 做二次盲化后再和 Tumbler 运行 RSA-Puzzle-solving 协议，然后将解去盲发给 Bob 即可。
Potato 攻击
Potato 攻击是指考虑外界信息，假设 Bob 是卖土豆的，一个土豆 7 比特币，且 Tumbler 知道没有其他人卖 7 比特币的东西，那么 Tumbler 就可以排除一些交易（比如 Calor 总共只有 6 笔交易，则她被排除，而 Alice 在短期内刚好有 7 笔交易，那么可以推测 Alice 在买土豆）。解决方法有添加冗余交易，Alice 建立一个收款地址，买土豆的同时给自己的地址转一笔钱，或者买土豆的同时再买些其他东西。
Intersection attacks
Intersection attacks：unlinkability 仅仅定义在一个周期内，并不能排除周期之间的一些关联。下面要讲的中止攻击就属于这种攻击。中止攻击 Abort attacks 中止攻击：Tumbler 可以通过中止交易获得一些信息。比如 Tumbler 注意到在几个周期里：Alice 一直在发起单笔交易而 Bob 一直达到额度上限，然后在下一个周期里，Tumbler 中止 Alice 的支付并发现 Bob 不再达到额度上限，那么 Tumbler 能猜测 Alice 在和 Bob 交易。
中止攻击
Abort attacks 中止攻击：Tumbler 可以通过中止交易获得一些信息。比如 Tumbler 注意到在几个周期里：Alice 一直在发起单笔交易而 Bob 一直达到额度上限，然后在下一个周期里，Tumbler 中止 Alice 的支付并发现 Bob 不再达到额度上限，那么 Tumbler 能猜测 Alice 在和 Bob 交易。
小结
虽然存在种种限制，但是如果交易足够多，那么交易的不可连接性还是可以保证的。
笔者认为 TumbleBit 的缺点主要是两个，第一是系统中所有用户都使用同一「面额」的钱，怎样定义面额就些困难。如果面额定义的很小，大额支付需要很多线下交互，不过可以通过在系统内多运行几个 Tumbler，每个 Tumbler 提供不同的面额来解决；第二是需要 Tumbler 事先抵押钱。这个可以通过收取手续费来解决，接收方按照要求 Tumbler 抵押的额度来付手续费。
如果不考虑金额的隐私性，TumbleBit 是一个非常优秀的混币方案。
原文链接
欢迎加入律动 BlockBeats 官方社群：
Telegram 订阅群：https://t.me/theblockbeats
Telegram 交流群：https://t.me/BlockBeats_App
Twitter 官方账号：https://twitter.com/BlockBeatsAsia
