理解靜默支付（二）

作者：benma & Sebastian

來源：https://blog.bitbox.swiss/en/understanding-silent-payments-part-two/

前篇見此處

在上一篇文章中，我們學習了靜默支付的技術基礎。現在，該湊近一點，看看靜默支付在硬件簽名器（比如 BitBox）中如何工作了。

我們極度推薦先閱讀本系列的上一篇文章，因為本文建立在上一篇文章所論述的知識之上，具體來說就是私鑰和公鑰的性質以及靜默支付的工作原理。跟上一篇文章一樣，在本文中，我們也用小寫字母來代表私鑰，用大寫字面來代表公鑰。比如：A = a × G 。

回顧一下，當 Alice 要給 Bob 發送一筆靜默支付時，安排給 Bob 的交易輸出，是從 Bob 的靜默支付地址和 Alice 的私鑰中動態派生出來的：

P = B_spend + hash(input_hash × S) × G

其中的 S 就是 Alice 和 Bob 的共享秘密值。Alice 的硬件簽名器可以用自己的私鑰 a 和 Bob 的公鑰 B_scan 將它計算出來：

S = a x B_scan

這裡，Alice 用到的 B_spend 和 B_scan 都是從 Bob 的靜默支付地址中得到的，而 a 是這筆交易的所有輸入的私鑰之和。

創建交易和簽名交易

我們要理解的第一件事情是，靜默支付極大地改變了硬件簽名器在處理比特幣交易時的角色。

在以往的支付形式中，主機錢包（你的電腦或者手機上的軟件，比如 BitBoxApp）創建交易，硬件簽名器（比如你的 BitBox02）只是驗證它和簽名它（提供許可）。

而在靜默支付上，事情不一樣了。硬件簽名器不僅要負責簽名，還要負責生成生成交易的一部分，具體來說就是給 Bob 的交易輸出。這是因為，生成給 Bob 的交易輸出需要 Alice 的私鑰，而且只有她的硬件簽名器才知道這些私鑰。

這一範式轉移帶來了一些新的風險：

• 內存損壞：如果硬件簽名器有 bug ，或者內存故障，可能會派生出不正確的輸出，從而將資金髮送到不可花費的地址，實際上就是弄丟了錢。
• 惡意行為：如果硬件簽名器被篡改了，它可能會在主機錢包不注意的時候創建一個直接發送給攻擊者（而不是 Bob）的輸出。

這個問題可以通過讓主機錢包驗證由硬件簽名器生成的靜默支付輸出的正確性來優雅解決。這在概念上類似於 “anti-klepto” —— 那是另一個要讓主機錢包來驗證硬件簽名器沒有不軌行為的案例。

離散對數相等證明

那麼，主機錢包怎麼驗證由硬件簽名器生成的靜默支付輸出是正確的呢？

主機錢包沒法直接驗證它，因為主機錢包自己無法重新生成出靜默支付輸出。這要麼需要 Alice 的私鑰 a，要麼需要 Bob 的私鑰 b_scan，才能計算出共享秘密值 S，但無論哪一個，主機錢包都是無法得到的。

反過來，我們使用一種密碼學工具來允許主機錢包驗證硬件簽名器所生成的靜默支付輸出，它叫 “離散對數相等（DLEQ）證明”。

一個離散對數相等證據讓你能夠證明，同一個私鑰 a 被用來生成了兩個不一樣的公鑰，雖然這兩個公鑰是通過不同的 “起點”（也叫 “基礎點（base point）”）生成的。

第一個公鑰是 A1 = a x G，其中的 G 是常用的基礎點（生成元）。第二個公鑰是 A2 = a x P2，其中的 P2 是另一個基礎點。證據保證了這兩個公鑰都來自同一個私鑰 a，而無需向驗證者揭曉私鑰本身。

用大白話來說，你證明的是，儘管這兩個公鑰是通過不同的基礎點（G 和 P2）生成的，但它們都用到了同一個秘密值（私鑰 a）。

而用技術屬於來說，這個證據表明，公鑰 A1 對應於基數 G 的離散對數，與 A2 對應於基數 P2 的離散對數，是一樣的。

驗證正確性

讓主機錢包能夠驗證靜默支付輸出正確性的協議如下：

硬件簽名器創建靜默支付輸出，以及一個 DLEQ 證據，證明公鑰 A = a x G 和共享秘密值 S = a x B_scan 中的秘密值是同一個（私鑰 a）。

• 因為 A 和 S 都是從同一個私鑰 a 中派生的，DLEQ 證據保證了公鑰秘密值 S 也是用 Alice 的私鑰生成的。

硬件簽名器發送自己生成的支付輸出 P 以及共享秘密值 S 和 DLEQ 證據給主機錢包。

主機錢包使用以下三者來驗證 DLEQ 證據：

1. 公鑰 A，就是 Alice 要發送的交易的所有輸入的公鑰之和；
2. 來自靜默支付地址的 B_scan，以及
3. S，由硬件簽名器提供

• 如果證據能夠通過檢查，主機錢包就能確信，這個 S 是由 a x B_scan 正確計算而來，即使主機錢包不知道私鑰 a 。

現在，主機錢包可以通過獨立的重新計算，驗證靜默支付輸出：

P = B_spend + hash(input_hash × S) × G

為此，主機錢包需要從 Bob 的靜默支付地址中取出 B_spend、從交易輸入中獨立地計算 input_hash，以及從硬件簽名器中得到的 S（在上一步中，已經得到了驗證）。

• 如果重新計算出的靜默支付輸出與硬件簽名器所返回的輸出一致，那麼主機錢包就可以安全地終局化並廣播交易，因為它知道其中的靜默支付輸出是正確的、沒有被篡改過。

流程總結

• Alice 的硬件簽名器創建靜默支付輸出，並使用一個 DLEQ 證據來證明自己使用的是正確的私鑰。
• 主機錢包驗證證據，以保證共享秘密值是正確計算得出的。
• 主機錢包使用共享秘密值和來自交易的已知輸出，重新計算並驗證靜默支付輸出；如果一切檢查都能通過，就敲定交易。

這一方法表徵了硬件簽名器無法搞小動作，不論是因為硬件損壞還是因為惡意活動。

推出

保證靜默支付安全性的特性，包括在 BitBoxApp 中實現本文所述的正確性檢查，將在 BitBoxApp 的下一個版本 4.45 和 BitBox 固件版本 9.21 中發行。

BitBox02 是第一款支持發送靜默支付的硬件簽名器。如果廣大的生態系統不支持發送靜默支付，想讓其它錢包軟件、交易所、服務商等等說服自己添加對靜默支付的支持，可就難了。這是一個雞生蛋、蛋生雞的問題。我們希望我們可以用這種辦法幫助靜默支付得到採用。

感謝開源協作

我們第一次聽說靜默支付，是在 2023 年 BTC Azores unconference 上，來自 BIP 作者 josibake 和 Ruben Somsen 的演講。這個 BIP 本身收穫了非常多的高質量評審。

當我們開始草擬在 BitBox02 中的實現時，我開始思考上面提到的風險，併發了一條推特，列舉了我的擔心。Josie、Ruben 和 Andrew Toth 很寬指出，DLEQ 證據是一種可能的解決方案，併為我提供了這一主題的一些非常有用的閱讀材料。唯一缺失的拼圖是一個高質量的、經過評審的 DLEQ 實現。

當 Andrew Toth 開始編寫一個詳細描述 DLEQ 的 BIP 草案時，密碼學家 Tim Ruffing 想起 secp256k1-zkp 代碼庫中已經有一個實現，而那時 BitBox02 已經依賴的代碼庫。那是 jesseposner 為另一個使用場景提供的，但幸運的是，這個實現被證明也非常適合靜默支付。

在來自 BIP 的測試界面、上述 DLEQ 實現以及一個有用的參考實現的幫助下（雖然我們不能直接使用這個參考實現，因為硬件簽名器有不同的要求），我們可以順利地在 BitBox 集成對靜默支付的支持。

當這麼多人自願貢獻自己的時間和精力，在開放的環境中打造一些東西，並最終能夠聚沙成塔，總是讓人新潮澎湃。

衷心感謝 Josie、Ruben、Andrew，以及許多幫助我們完成這一特性的其他人。