原文標題:《硬核 | 一起了解比特幣混幣方案: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 自己發給 Alice 盲化 puzzle, 這樣 Tumbler 可以知道 Alice 的身份(尤其適用於 Alice 和 Bob 不知道對方身份的場景,比如使用 tor 協議)。解決方法很簡單,Alice 對 Bob 發給自己的盲化 puzzle 做二次盲化後再和 Tumbler 運行 RSA-Puzzle-solving 協議,然後將解去盲發給 Bob 即可。
Potato 攻擊是指考慮外界信息,假設 Bob 是賣土豆的,一個土豆 7 比特幣,且 Tumbler 知道沒有其他人賣 7 比特幣的東西,那麼 Tumbler 就可以排除一些交易(比如 Calor 總共只有 6 筆交易,則她被排除,而 Alice 在短期內剛好有 7 筆交易,那麼可以推測 Alice 在買土豆)。解決方法有添加冗餘交易,Alice 建立一個收款地址,買土豆的同時給自己的地址轉一筆錢,或者買土豆的同時再買些其他東西。
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