作者：Bitcoin Design
Payjoin 指的是發送方和接收方通過協作來共同構建一筆比特幣交易。作為一種強大的工具，Payjoin 交易能為用戶提升隱私性、節省手續費，並整合 UTXO。但由於其交互式和同步的特性，Payjoin 也面臨著一些挑戰和權衡。
在支付過程中，Payjoin 交易能夠打破一些鏈上分析的啟發式算法。然而，構建這種交易需要發送方和接收方通過一個端點進行實時協調。
本案例研究將:
- 闡明發送方和接收方各自的動機與目標。
- 分析交易雙方的 Payjoin 用戶體驗（UX），並提出相應的設計方法。
- 提出具體的用戶流程，並儘可能提供可行的設計方案。
本研究的核心結論是：對於接收方而言，雖然初始設置較為繁瑣，但後續每筆交易幾乎無需任何額外操作。
而對於發送方來說，除了要使用支持 Payjoin 的錢包外，幾乎無需額外設置。並且，根據他們的選擇以及具體實現方案的成熟度，其用戶體驗可以做到與普通交易完全相同或幾乎一致。
什麼是 Payjoin？
在 Payjoin 交易中，發送方和接收方會以協作的方式，共同為這筆交易貢獻輸入。Payjoin 機制也被稱為“Pay-to-Endpoint”（P2EP），因為整個協作過程是由接收方運行的一個網絡端點（endpoint）來協調的。這個端點的地址會和支付地址、金額信息一起，通過 BIP-21 格式的 URI 來傳遞。
在 Payjoin 的流程中，雙方會對交易進行編輯、簽名和多次傳遞，直到最終版本確認後才進行廣播。 BIP-78 提案正式定義了一個包含兩輪交互（或在地址共享之外，再進行一輪交互）的協議，正如下處圖示。
背景
本案例研究源於一項設計挑戰，目標是設計一個基於 Payjoin 的發送方支付流程。
Payjoin 對交易雙方的實時協作提出了獨特的挑戰，我們需要一套全新的用戶流程，才能健壯而優雅地實現 BIP-78 所啟用的各項功能。
截至 2023 年初，Payjoin 尚未在比特幣生態中獲得廣泛的採用。
我們的方法
本案例研究遵循了以下步驟：
- 理解發送方與接收方的用戶及技術要求。
- 調研 Payjoin 的具體實現： BlueWallet （發送端）和 BTCPay Server （接收端）
- 基於以上研究，為發送方和接收方設計用戶流程。
理解用戶與需求
從技術上來講，任何在比特幣鏈上進行交易的人都可以使用 Payjoin。本案例研究從以下兩個維度對用戶進行分類：
- 機構（企業、交易所等）與個人
- 支付的發送方與接收方
接收方的目標
- 交易隱私性
- 節省手續費
- 成功交易
作為接收方，我希望：
- 創建一個啟用 Payjoin 的支付鏈接並分享給發送方。
- 能為某個錢包、賬戶或用戶啟用 Payjoin 功能。
- 創建一個熱錢包並將其用於 Payjoin。
- 為新創建的熱錢包充值，使其擁有可供使用的 UTXO。
- 將一個已有的熱錢包連接到我的 Payjoin 設置中。
- 補充主錢包（觀察錢包）的餘額。
- 設置地址替換，以便補充觀察錢包餘額或進行無關支付。
- 監控 Payjoin 的狀態。
- 排查 Payjoin 流程中的錯誤。
發送方的目標
- 交易隱私性
- 優化手續費並控制確認時間
- 交易成功
作為發送方，我希望：
- 使用 Payjoin 進行隱私支付，打破鏈上啟發式分析法。
- 支付時自行選擇是否使用 Payjoin。
- 在交易廣播前查看要支付的手續費。
- 控制交易的確認時間。
- 若 Payjoin 流程失敗，能夠中止交易。
發送方要求
- 一款支持發送 Payjoin 的應用
- 在 Payjoin 交易過程中全程保持在線
發送方通過 Payjoin 獲得隱私保護，通常需要承擔更高的交易手續費。
接收方要求
- 熱錢包
- 熱錢包中有資金
- 一款支持接收 Payjoin 的應用
- 一個在交易期間保持在線的端點
接收方有望獲得以下好處:
- 增強交易的隱私性
- 整合 UTXO 集合
- 節省交易手續費
發送 Payjoin
對於發送方來說，參與 Payjoin 交易的流程相對簡單。只需使用支持 Payjoin 的錢包，並在交易過程中保持在線即可。
調研：分析 BlueWallet
我們分析了 BlueWallet 在 2020 年率先實現的 Payjoin 用戶流程。詳細內容見調研報告.
主要發現如下：
- 在 Payjoin 的交易流程中，隨著交易體積的增加，實際的手續費率會下降，可能影響預估的交易確認時間。
- 該流程產生的交易在移除一個輸入後，其手續費率會變為一個整數，而這可能成為鏈上分析公司識別 Payjoin 的線索。
Payjoin 發送方流程
我們設計了一套新的發送方流程，試圖解決上述問題。
為了創建這套流程，我們假設接收方只提供 UTXO 而不承擔手續費，因為這樣可以讓雙方的流程更簡單和自動化。
簡而言之，我們設計的這套發送方流程要求用戶選擇一個手續費區間，而非具體的手續費金額（或費率），而流程的其餘部分則與普通交易幾乎一致。我們通過這個設計來設置 BIP-78 中規定的 3個可選參數，從而構建一個簡潔而高效的 Payjoin 實現方案。
詳細思路見此文檔.
可通過此 Figjam 文件 查看該流程。詳細過程和考量見此 文件。
Payjoin “握手（Handshake）”
我們引入“Payjoin 握手”這一術語，旨在簡潔地描述發送方與接收方之間自動化的往返交互過程。在此過程中，一份最初僅包含發送方輸入的 PSBT，會轉變為一份包含雙方輸入、已簽名且可廣播的最終交易。
以上步驟對於參與交易的用戶來說並不重要，也無需他們任何一方執行額外的操作。通俗地說，交易雙方甚至無需察覺這一過程，只要在交易過程中保持在線即可。
Payjoin 發送方流程原型
我們的目標是讓這套用戶流程的體驗無限接近於常規流程。對於那些必須有所區別的環節，我們會通過 UI 來指導和幫助用戶。
支持 Payjoin 的錢包會展示一個默認啟用該功能的界面。
用戶會看到一個和常規界面非常相似的手續費區間選擇頁。
接著，屏幕會顯示一個過渡界面，提示用戶 Payjoin 交易正在構建和簽名中。
Payjoin “握手”完成後，進入交易廣播前的最終檢查界面，上面會顯示最終的手續費。
最後，支付成功界面會告知用戶，該 Payjoin 交易已成功廣播。
接收 Payjoin
基於 BIP78 協議，接收方的門檻 要遠高於發送方。 發送方只需要一個兼容的移動錢包，但接收方僅靠移動錢包無法維護一個始終在線的端點。而企業和機構則面臨另一種困境：雖然他們有能力輕鬆地部署一套 Payjoin 接收方案，但對熱錢包的安全顧慮又令其望而卻步。
儘管幾乎所有移動錢包都是熱錢包，為其充值也很簡單，但要專門運行一個在線服務器來進行 Payjoin 握手，無論在技術上還是實踐中都頗具挑戰。這或許是當前阻礙 Payjoin 獲得支持和普及的最大障礙。
調研： BTCPay 商戶/接收端
作者於 2023 年 2 月成功測試了 BTCPay v1.7.12 的 Payjoin 接收功能。
主要發現如下:
- 一旦設置完成，系統會自動生成啟用了 Payjoin 的鏈接。
- 如果用戶選擇添加一個已有的熱錢包，BTCPay 不會像新建熱錢包時一樣在同一頁面提供啟用 Payjoin 的選項。
- 無論是在新建錢包還是添加已有錢包的設置中，如果用戶選擇了觀察（冷）錢包，他們將永遠不會接觸到 Payjoin 功能（因為簽署 Payjoin 交易的過程需要用到私鑰）。
- 商戶只能連接一個比特幣錢包（除非通過 BTCPay Vault），因此使用了冷錢包就無法再設置熱錢包（也就無法使用 Payjoin）。
- 如果熱錢包中的餘額不足以執行 Payjoin 交易，BTCPay 不會提示或警告用戶，從而導致支付失敗。
- 沒有專門用於管理和監控 Payjoin 的地方。
在 BTCPay 上接收 Payjoin 的完整調研見此分析報告。
建議的接收方流程
在此，我們將為可以始終在線的銷售終端（POS，point-of-sale）系統設計一套用戶流程。此流程不適用於移動錢包。
接收方應當能夠在平臺（應用或 POS 系統）的初始配置過程中、或之後任意時間點設置 Payjoin。以下展示的是一個獨立的 Payjoin 設置流程。
集成了初始配置過程的詳細流程圖見此 Figjam 文件 。
請求 Payjoin
一旦 Payjoin 設置生效， 所有支付請求（BIP-21 支付鏈接或二維碼） 都應該包含執行 Payjoin 交易所需的信息（包括端點地址），無需用戶額外操作。
Payjoin 狀態/設置
在設置頁面中開闢一個版塊，提供一個用於管理 Payjoin 設置和監控其狀態的專屬空間，會是個不錯的設計。這個版塊還能為使用冷錢包的用戶提供一個發現並設置 Payjoin 功能的入口。該版塊可以包含以下內容：
- Payjoin 設置流程
- 其它 Payjoin 功能，例如：第三方端點、地址/輸出替換、補充冷錢包餘額等
- 監控 Payjoin 就緒狀態：熱錢包狀態、Payjoin 端點狀態等
洞見
在本案例研究的過程中，我們收穫頗豐，而我們所設計的用戶流程已經應用了其中的許多洞見。
- Payjoin 允許接收方整合 UTXO，長遠來看，這讓參與者能夠支付更低的手續費。這一點對於交易所尤其有用，因為他們最需要這個功能，同時也完全具備部署一套穩健可靠的系統的技術實力。
- 考慮到交易雙方可能需要經歷多達數輪的迭代與協作，本案例研究引入了“Payjoin 握手” 這一術語，用來概括用戶操作之間的所有自動化交互。
- 維護一個始終在線的端點似乎是 Payjoin 實現的最大障礙，文中也列出了一些替代方案。
- Payjoin 雖然對接收方提出了更高的要求，但也為其帶來了更多的好處和機會。
- 輸出替換：這是源自 BIP-78 的一個強大構想。雖具風險，但也能成為 Payjoin 用戶的有力助手。
- 輸出替換：Payjoin 讓接收方可以發佈靜態的支付信息，但在實際收款時使用不同的地址，避免了地址重用。
- Payjoin 接收方無需額外設置錢包，可以直接使用其日常消費錢包作為 Payjoin 的熱錢包。
- Payjoin 實現需要留意用於識別 Payjoin 的“整數費率”分析法，應當自動化處理，無需用戶干預。
新的可能
由於涉及多方協作和眾多不確定的環節（如端點），無論是理解還是實現 Payjoin 都有著較高的門檻，但這也為各式各樣的新功能和服務打開了大門。
以下是一些例子：
- 接收方可以選擇使用第三方端點（關閉地址替換），犧牲一部分隱私來換取便利性。
- 目前有一些激動人心的工作圍繞 無服務端的 Payjoin 實現展開，這一方案非常適合同時支持比特幣和閃電網絡的平臺。
- 接收端的實現方案可以使用地址替換，來讓用戶自行發起支付。
- 可以通過 NFC（或其它無線近場通訊技術）來進行 Payjoin 協作
- 可以利用 BIP-78 增加一輪額外的交互，允許發送方在“握手”後調整手續費，然後發回給接收方進行廣播。
本案例研究深入探討了圍繞 Payjoin 的設計問題，希望能借此激發社區對其多樣化用例和潛在價值的興趣。
致謝:
- 感謝 BTCPay 的 Pavlenex 提供的支持 Payjoin 的 BTCPay 實例，我們用它測試了接收流程。
- 感謝 Nicolas Dorier 審校本案例研究的內容並積極參與 Payjoin 的相關討論。
- 最後，感謝 Dan Gould 的寶貴指導、耐心和熱情。
