BIP352：靜默支付的現在和未來

作者：Anony

“靜默支付（Silent Payments）” 是一種為實現靜態收款標識符同時兼顧隱私性要求而提出的解決方案。使用它，支付接收者只需公開一個穩定不變的標識符（可以視為一種特殊的地址），發送者將在支付發送過程中為接收者創造出不重複的新比特幣地址。

本文嘗試解釋其基本概念、第一個關於靜默支付的比特幣強化提議 BIP352 ^[5]，並基於 BIP352 的規範展望靜默支付的採用方式。

靜默支付的基本概念

為理解靜默支付的概念，我們先來回顧 “鏈上” 比特幣（也即以區塊鏈為交易確認方式）的支付過程：

1. Alice 嘗試給 Bob 支付，於是向 Bob 請求一個 Bob 能夠使用的比特幣腳本（地址是這樣的腳本的一種緊湊、防止錯誤的表現形式 ^[1]）；
2. Bob 給 Alice 回覆一個地址；
3. Alice 將該地址複製到自己的比特幣錢包軟件中，補充完其它交易細節後廣播交易、讓交易獲得區塊鏈確認；
4. Bob 的軟件在收到新的區塊中，根據 Bob 存儲的信息（比如地址）掃描匹配的交易；如果命中，則存儲交易的信息，並將相關的交易輸出標記為自身可以使用的資金。

此過程跟以下幾點有關聯：

1. 隱私性。如果 Bob 給出的是一個已經使用過的地址，那就會增加該地址被 “去匿名化（deanonymization）” —— 被第三方偵測出該地址的真實主人 —— 的風險。這種損害隱私性的習慣稱作 “地址複用”，複用得越多，去匿名化的風險也就越嚴重。
2. 交互性。在上述過程中，Bob 會跟 Alice 交互，給 Alice 提供地址。可以看出，這種交互一定程度上是一種麻煩，但考慮到隱私性，其價值又是顯而易見的：Bob 可以藉由這種交互的機會，給出新的地址、避免地址複用。
3. 備份便利性。只要 Bob 不是在收到支付後立即花掉，就會讓比特幣在自己的地址中停留，這就產生了備份該地址的密鑰信息的需要。考慮到隱私性，Bob 應該為每一筆新支付生成一個新地址，但是如何便利地備份呢？

在當前的比特幣保管方案中，BIP-32 分層確定性錢包方案，解決了上述隱私性與備份便利性的矛盾 ^[2]：Bob 使用的密鑰都從同一個種子經過確定的步驟派生出來；由於這些密鑰都有同一個源頭，因此 Bob 只需備份這個種子即可（最多需要額外備份極少量的派生步驟信息）；而由於派生的步驟具有單向性，第三方無法從這些密鑰的公鑰中推斷出他們屬於同一個源頭，也很好地保證了隱私性。

唯一尚不如人意的地方是，交互需求依然存在。每一個支付者都必須先跟 Bob 建立通信、獲得一個新地址，然後才能發起支付。有沒有能夠實現靜態的收款標識符（地址）、又不犧牲隱私性的辦法呢？

靜默支付概念的提出者 Ruben Somsen 曾在一場演講中集中地討論可能的解決方案 ^[3]，靜默支付也屬於其中之一，而且顯示了一種特殊的（可以說有些激進的）取捨：通過增加接收者 Bob 的掃描負擔（即上述支付過程第 4 個步驟的複雜性），來消除交互需要。

靜默支付運用了一個叫做 “迪菲-赫爾曼 密鑰交互（Diffie–Hellman key exchange）” 的概念（它跟 “公鑰密碼學” 的概念同齡！ ^[4]）：如果 Alice 和 Bob 各有一對公私密鑰對，那麼他們只需知曉對方的公鑰，憑藉一個簡單的操作，就可以獲得一個只有他們彼此知曉的共享秘密信息：以己方的私鑰乘以對方的公鑰。

由於私鑰與公鑰間的數學關係，當 Alice 拿自己的私鑰乘以 Bob 的公鑰時，得到的數值會跟 Bob 以自己的私鑰乘以 Alice 的公鑰得出的結果相同。

我們以基於橢圓曲線的公私鑰為例，Alice 的公鑰 A 是私鑰 a 與橢圓曲線點 G 運行點乘法得到的；Bob 的密鑰對類同。那麼：a.B = a*b.G = b*a.G = b.A。這叫做 “ECDH（橢圓曲線上的 DH 密鑰交換）”。

根據定義，只有知曉其中一個私鑰的人才能獲得這個秘密值，所以其他人都不知道，只有他們彼此知道。

設想一下，如果 Bob 提前公開了自己的一個公鑰，那麼 Alice 無需再與他交互，就可以憑藉自己的私鑰，得出一個新的秘密值，然後憑此秘密值派生出一個新的公鑰（再派生出相應的地址）。比如說，這個新公鑰是 Bob 的公鑰加上共享秘密值的哈希值的橢圓曲線點：New PK = B + H(a.B).G；這個公鑰背後的私鑰是：New sk = b + H(b.A)。顯然，只有 Alice 和 Bob 才能知道這個公鑰是如何構造出來的，因為其中用到了只有他們知曉的共享秘密值；而且，只有 Bob 才能花費這個地址裡的資金（因為其私鑰 b 只有他知道，Alice 也不知道）。

這種辦法滿足了上述三個要求：（1）只要 Alice 不復用私鑰，就不會得到相同的地址；（2）Alice 不再需要跟 Bob 交互，可以直接構造出只有 Bob 能夠花費的地址；（3）Bob 也不需要為每一個新地址備份密鑰材料，因為從一定意義上來說，它們也都是從同一個種子（密鑰對）中派生出來的。

然而，問題是，Alice 怎麼告訴 Bob 自己用到了哪一對密鑰呢？如果 Bob 不知道 Alice 的公鑰，這一套把戲不就沒法玩下去了嗎？

這就是靜默支付與以往的類似概念更激進的地方：它要求 Alice 使用交易輸入中用到的公鑰，而不用其它手段傳達這些信息（比如額外的 OP_RETURN 交易輸出），從而，運用了上述密鑰交換技巧的交易在外觀上跟不使用這類技巧的交易看起來毫無分別！這就最大限度地滿足了隱私性的要求，而發掘隱秘信息的任務就完全交給了 Bob。

以上就是靜默支付的基本概念。接下來，我們看看 BIP352 如何為上述靜默支付的骨架增加血肉、使之成為一種可用的技術，其各項規範又如何影響支付接收者 Bob 的掃描負擔。

BIP352：第一個靜默支付 BIP

BIP352 編寫得很好，在概述部分遵循了逐步推進的流程，詳述部分也相當嚴謹。為平衡介紹其中內容的需要和本文的目的，將其主要設計目的和抉擇重述如下：

• 生態兼容性
  • BIP352 使用 Bech32m 編碼法 ^[6] 來編碼靜默支付的收款地址。
    • 這一設計使得支持 P2TR 輸出的比特幣軟件無需額外實現新的編解碼方法，只需微調就可以從靜默支付地址解碼出所需的信息。
    • 這一設計同樣使我們可以定義多種版本的靜默支付協議。BIP352 就被定義為 “v0 的靜默支付協議”。
• 保管安全性
  • 在 BIP352 靜默支付地址中包含的不是一個公鑰，而是兩個公鑰，分別稱作 “掃描公鑰” 和 “花費公鑰”。掃描與自己有關的支付需要知曉 “掃描私鑰”，但不需要知道 “花費私鑰”。
    • 因此使用者可以將花費私鑰存儲在更安全的設備（比如設計良好的簽名器）中。
• 隱私性
  • 將交易輸入的 “輸出點（outpoint）” 也加入共享秘密值的推導。輸出點是一個 UTXO 的唯一標識符，由創造該 UTXO 的交易的 id 以及該 UTXO 在交易輸出間的序號組成。
    • 這一設計避免了 Alice（支付發起方）複用 地址/公鑰 給 Bob（支付接收方）帶來的影響。只要交易 ID 不重合 ^[7]，各 UTXO 的輸出點就都是唯一的，即使使用了相同的公鑰，派生出來的共享秘密值也將不同，從而不會給 Bob 生成相同的地址。
  • 全部輸入都參與共享秘密值的推導。取得所有交易輸入的輸出點中最小的那一個，來推導共享秘密值。並且，Alice 也使用所有符合要求的輸入所用的私鑰，來推導共享秘密值。
    • 這一設計也有助於避免 Bob 辨識出哪個輸入來自 Alice。
  • 兼容儘可能多的輸入類型。BIP352 將 “P2PKH”、“P2WPKH”、“P2SH-P2WPKH” 和 “P2TR” 都定義為符合要求的輸入，也即支付者可以拿這些地址類型上的資金來發起靜默支付。
    • 瞭解比特幣輸入類型的讀者可以看出，這幾乎囊括了所有單公鑰控制的標準化腳本。對輸入類型的要求越少，也就意味著可能發起靜默支付的用戶群體規模越大，同時也意味著它跟常規支付的差異越小、越不可能被辨識出來。
    • 同時，因為上一點的要求，支付者在構造靜默支付的交易時，必須確保自己能讓每一個符合要求的交易輸入的私鑰都能參與共享秘密值的推導。
  • 在接收者比特幣地址的派生中使用額外的序號，允許支付者在一筆交易中將真實的支付額分散在多個不同的地址中。
    • 這可以用來對付基於資金數額的猜測。
• 掃描便利性/管理便利性
  • 上述 “使用全部輸入” 的設計也便於 Bob 掃描支付。
  • 僅允許為 Bob 安排 P2TR 輸出。
  • 允許 Bob 使用同一組掃描密鑰和花費密鑰生成多個靜默支付地址，辦法是通過額外的標籤生成多個花費公鑰。
    • Bob 無需額外的備份，就可以生成多個靜默支付地址、為不同的 支付方/支付目的 安排不同的地址。

以上即是 BIP352 的大致內容。

基於上述設計，支付接收者 Bob 在區塊鏈上掃描與自己有關的靜默支付交易時的流程大致如下：

1. 首先，Bob 要先找出一個區塊中潛在的靜默支付交易（在 BIP352 中被稱為 “eligible transaction”）；
   • 潛在交易的判斷標準有三個：（1）具備 P2TR 輸出；（2）包含至少一個上述允許使用類型的輸入；（3）不得包含比隔離見證 v1 更高版本的輸入。在這裡，只有第一個標準的應用僅需交易本身的信息；後面兩個標準都要求我們獲得輸入的前序輸出的腳本公鑰，才能執行判斷，而這種信息是隱式的，並不會在交易中體現出來。
2. 而後，Bob 需要遍歷一筆潛在交易的所有輸入，一方面要找出最小的輸出點，另一方面要從上述可使用類型的輸入中提取出公鑰並加總起來；
   • 這一過程會得出共享秘密值推導所需的兩個關鍵信息，一個是包含了最小輸出點信息的哈希值，在 BIP352 中叫做 “input_hash”；另一個則是所有合格輸入的公鑰之和，在 BIP352 中記作 “A”。
3. 最後，Bob 要運用 input_hash、A 和自己的掃描私鑰派生出共享秘密值，再根據自己的花費公鑰派生出一個公鑰和對應的 P2TR 腳本；然後檢查該交易的輸出中存不存在這樣的 P2TR 輸出，如果有，則將這樣的交易和輸出保存下來，標記為自己可以花費的資金，如果沒有，則表明該交易與自己不相關。

敏銳的讀者可以發現，上述 1 和 2 兩個步驟，正是BIP352 在 “靜默支付” 的基礎概念上做出的兩個關鍵設計的直接後果：（1）在派生支付發送方和接收方的共享秘密值時，使用全部交易輸入的信息；（2）儘可能支持多種輸入類型。這樣的掃描負擔，顯然會影響靜默支付的採用（或者說，這種成本會限制其應用場景）。

接下來，我們討論 BIP352 靜默支付錢包可能的工作模式，並使用比較法來理解其掃描負擔。

兩種工作模式和掃描負擔

分析上述接收者掃描流程可以發現：不論掃描者是 Bob 還是 Carol，他們都要運行掃描的前兩個步驟，並且在兩個步驟結束時得到的結果是相同的。也就是說，因為 BIP352 靜默支付 “使用所有輸入”，所以，一筆交易是否是潛在靜默支付交易，以及（如果是）其 input_hash 和 A，是一種對所有靜默支付接收者都同樣有用的信息，一種可以複用的信息（實際上，接收者只需要獲得這兩者的乘積）。由此，可以想象的一種工作模式是 “服務端-客戶端 模式” ：由服務端運行掃描的前兩個步驟，並給客戶端提供得到的結果；客戶端僅根據本地的密鑰信息運行最後一個步驟。這種模式就類似於常規錢包中的 “全節點-輕節點” 模式，可以大大減少客戶端的工作量。

與之相對的是 “集成模式”，即不分拆工作量，三個步驟都由同一臺計算機完成。

然而，更細緻地考慮上述掃描步驟，並聯系起全節點的工作模式，你會有更進一步的發現：

掃描步驟 1 和 2 需要獲得一筆交易的所有輸入的腳本公鑰，用於判斷輸入的腳本類型，並根據腳本的類型執行相應的公鑰提取步驟，僅憑暴露在交易中的信息，包括 “腳本簽名（ScriptSig）” 和 “見證（txinwitness）”，是不夠的。然而，全節點在驗證新到達的區塊中的交易時，本身也要求這些信息，並且，獲得這些信息僅需要在 UTXO 集中搜索，不需要訪問歷史區塊和歷史交易（不觸發較深的硬盤讀取）。

也就是說，如果在驗證新區塊內交易的同時執行上述掃描步驟，那就是順帶的，額外開銷完全來自於計算（輸入輸出的類型檢查、公鑰提取、共享秘密值推導、ECDH，等），客觀來說這些計算量也不會太大；然而，如果我們使用一個單獨的進程來運行掃描，則不僅要付出額外的計算開銷，還需要額外的、較深的硬盤讀取，因為新區塊一旦驗證完成，其中的交易的輸入的腳本公鑰就不再能從 UTXO 集中獲得，只能通過訪問歷史交易來獲得（並且，這裡還多一項存儲空間開銷：為區塊鏈上的所有交易編制索引，如果這樣的索引不存在，則實際上無法讀取歷史交易，而同步 驗證-掃描 模式並不需要為歷史交易編制索引）。

由於這種顯著的開銷區別 ^[8]，我們補充 “集成模式” 的定義：掃描步驟作為區塊驗證的附屬步驟，與區塊驗證同步完成。

請注意，補充完定義之後，“集成模式” 和 “服務端-客戶端 模式” 的合集就不構成全集：有一種可能是，不分拆掃描的工作量，但掃描工作依然在一個獨立的進程中完成。

構造這兩種模式的定義僅僅是為了便於我們通過比較來理解 BIP352 靜默支付接收者的掃描負擔：由於定義的準確性，他們都有合適的比較對象，集成模式可以跟基於全節點的常規錢包作比較；服務端-客戶端 模式可以跟基於 BIP158 區塊過濾器 ^[9] 的輕節點的常規錢包作比較。

為此，我們對網絡中出現的交易的數量與比例，以及錢包所控制的地址的數量，作出以下假設：

• 平均每個區塊包含 n 筆交易，它們總共有 m 個交易輸入和 o 個交易輸出；
• 至少包含一個 P2TR 輸出的交易佔比為 p，而 P2TR 輸出佔單區塊內所有輸出的比例為 q；
• 靜默支付錢包僅公開 1 個靜默支付地址；
• 常規錢包包含 20 個 P2TR 地址；
• 僅考慮交易輸出中出現本錢包地址的情形（接收支付的情形）。

在上述假設下，基於全節點的常規錢包的掃描負擔是：20 * o * q，也即對區塊中每一個 P2TR 輸出運行 20 次地址匹配檢查。而集成模式中的靜默支付錢包的掃描負擔是：n * p * I + o * q * 1，第一項是靜默支付掃描的前兩個步驟帶來的開銷，它是以交易為單位的，這裡的 I 是對一筆交易執行類型檢查、公鑰提取、ECDH 等操作所需的計算量，這裡假設是一個常數；第二項則是對這些潛在交易的每一個 P2TR 輸出執行地址匹配檢查所需的計算量，給定錢包主人只公開過 1個靜默支付地址，就只需要執行 1 次。

至於基於輕節點的常規錢包，我們知道其工作模式是先驗證區塊過濾器；如果過濾器顯示區塊內沒有自己關心的輸入和輸出，則不再下載完整的區塊；如果區塊過濾器顯示有（這裡存在一個極小的誤判可能），則下載並檢查地址匹配。我們把驗證區塊過濾器的負擔當成一個常數（這不影響比較），則其掃描負擔是：1/x * 20 * o * q，這裡的 1/x 就是過濾器命中的概率，該值必定大於 BIP158 區塊過濾器的誤判概率，但實際大小取決於本錢包收取的交易在區塊間的分佈。

而基於 服務端-客戶端 模式的靜默支付錢包，其掃描負擔是：n * p * I_1 + o * q * 1。這個式子之所以跟集成模式這麼相似，是因為：服務端僅僅只是完成了一部分掃描工作，而對每一筆可能的交易，客戶端都仍需執行一部分工作（具體來說是 ECDH）（它只是 I 的一部分，因此記為 I_1），而對 P2TR 輸出的地址匹配檢查，則完全無法從服務端的工作中受益，因此保持原樣。

總結上面的分析：

1. 常規錢包的掃描負擔很大程度上是由同類型輸出的數量決定的，但靜默支付錢包的掃描負擔則有一部分（甚至是主要的部分）跟合格交易的數量有關，兩者不便於直接對比；但從計算複雜性的角度看，靜默支付的掃描負擔絕大概率是更大的。具體來說，這種負擔跟包含 P2TR 輸出的交易的佔比有關；佔比越大，靜默支付錢包的掃描負擔越大；
2. 常規錢包和靜默支付錢包都可以從轉向 輕節點/客戶端 模式獲得顯著的好處；
3. 靜默支付錢包與常規錢包的掃描負擔的差異在客戶端模式下會更大，也即更容易讓用戶感受出性能差異。靜默支付錢包可能更適合穩定的桌面端，而非日常使用的移動端。

靜默支付的現在和未來

性能/成本 毫無疑問會影響一項技術的採用。從上述分析中我們可以知道，不論在哪一種工作模式下，靜默支付錢包都要付出相對常規錢包更大的代價。可以說這也在我們的意料之中，因為這是 “靜默支付” 的先天特性。至少，在人們設想的應用場景（接受捐贈、以機構身份接受支付）中，靜態收款方式的好處應該能蓋過其額外開銷。而且，給定 服務端-客戶端 的可能性，一部分工作量是可以複用的。

當前，多個項目在嘗試實現 BIP352 靜默支付錢包，比如：

• 在 Bitcoin Core 中實現 BIP352：https://github.com/bitcoin/bitcoin/issues/28536
• Dana Wallet 移動端靜默支付錢包：https://github.com/cygnet3/danawallet

此外，開發者們也正在為了讓靜默支付能夠兼容 coinjoin 交易而增加多種規範。在 coinjoin 交易中，多個參與者會各自為交易提供輸入並指定輸出；根據 BIP352，為了讓這樣的交易承載靜默支付，支付者必須讓每一個合格輸入的私鑰都參與共享秘密值的推導；同時，這不能造成真實私鑰的洩露；此外，還需要工具能夠在各方之間傳遞被構造的交易的信息（接收者的腳本必須在每一個參與者都參與計算之後才能得出）。與此相關的規範有：

• BIP374 離散對數等式證據：https://github.com/bitcoin/bips/pull/1689
  • 離散對數等式證據可以讓私鑰持有者證明自己知道一個私鑰而不暴露這個私鑰是什麼。
• BIP375 使用 PSBT 發送靜默支付：https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki
  • 定義可在多方簽名的靜默支付交易協作中傳遞信息的 “PSBT（待簽名的比特幣交易）” 數據格式。

人們還在探索與靜默支付有關的協議設計空間。

（完）

腳註

1. https://www.btcstudy.org/2024/11/22/bitcoin-address-types-its-essentials-and-its-economics/ ↩

2. https://www.btcstudy.org/2023/10/25/a-guide-for-recovering-your-bitcoin-wallets/ ↩

3. https://www.btcstudy.org/2022/10/19/on-various-non-interactive-payments/ ↩

4. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ↩

5. https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki ↩

6. https://www.btcstudy.org/2024/11/22/bitcoin-address-types-its-essentials-and-its-economics/#Bech32m ↩

7. https://www.btcstudy.org/2024/04/17/transaction-security-improvement-from-soft-forks/#BIP30%EF%BC%9A%E7%A6%81%E6%AD%A2%E5%87%BA%E7%8E%B0%E7%9B%B8%E5%90%8C%E7%9A%84%E4%BA%A4%E6%98%93-ID ↩

8. 這種顯著的開銷差異可能解釋了為何一些開發者決心在 Bitcoin Core 中實現 BIP352。見：https://github.com/bitcoin/bitcoin/issues/28536 ↩

9. https://www.btcstudy.org/2022/04/18/how-neutrino-works-by-Suredbits/ ↩