熱門比特幣錢包面臨失去對新硬體設備的支持，因為關鍵安全橋樑停止接受新設備

比特幣硬體錢包介面（Bitcoin HWI），一個廣泛使用的將錢包軟體連接到硬體簽名設備的介面，正朝著退休的方向發展，而其維護者所提到的Rust項目作為有前景的繼任者，尚未展示出生產交接的能力。

比特幣核心的硬體錢包介面（HWI）維護者在8月18日表示，該項目實際上已經進入維護模式多年，並且大部分是單獨進行的努力。HWI將不再接受新設備或功能，除了MuSig2所需的工作。一旦該工作完成，維護者預計將發布一個可能是該項目的最後版本，然後將HWI保持在最小維護狀態，直到合適的替代品準備就緒。

HWI是錢包軟體用來發現硬體設備、檢索公鑰、顯示接收地址並將部分簽名的比特幣交易發送到如Ledger、Trezor、Coldcard、BitBox或Jade等設備以供批准和簽名的橋樑。通知中提到的繼任候選者BHWI，旨在通過Rust實現來保留HWI風格的命令輸出。

這兩個過渡都尚未完成。HWI尚未被存檔，沒有設定退休日期，通知中也沒有說明支持的硬體錢包將停止運作或用戶的比特幣存在風險。當前的壓力落在那些打包HWI、調用其命令行或依賴它來吸收設備、操作系統和供應商協議變更的團隊上。

HWI的獨立邊界為何重要

HWI既是一個Python庫，也是命令行工具。它為常見的硬體錢包操作提供了一個介面，而不需要為每個供應商實現單獨的實現。

它的最初目標是將硬體錢包支持帶入比特幣核心。這一整合是通過外部簽名者邊界達到用戶的，而不是將HWI放入比特幣核心中。比特幣核心的外部簽名者文檔描述了一個可配置的命令，並以HWI作為示例，而HWI的比特幣核心指南顯示HWI被用於密鑰檢索和交易簽名，與核心錢包一起使用。

HWI的維護者表示，Python阻止了確定性構建，即比特幣核心用於發布二進制文件的可重現構建過程，因此使HWI無法與比特幣核心一起發送。這種分離也使HWI在原則上是可替換的：另一個程序可以實現比特幣核心的外部簽名者合約。CryptoSlate對比特幣核心22.0的報導描述了2021年外部簽名者支持的到來。

然而，兼容的命令表面僅僅是遷移的一部分。應用程序仍然需要打包替代品，測試它們所暴露的設備和操作，並決定當固件或操作系統行為變更時誰擁有修復權。

BHWI通過Rust核心而非Python應用程序來解決打包約束。其設計可能使來自多個編程環境的可重現分發和使用變得更容易，但每個下游項目仍然必須驗證替代品是否涵蓋其自己的命令集、設備矩陣和發布過程。比特幣核心可以在其外部簽名者邊界後測試另一個符合的命令；其他消耗HWI命令行的軟體必須執行自己的兼容性工作。

這一區別使得維護公告變成了一個繼承問題，而不僅僅是簡單的庫狀態變更。HWI的介面可能是共享的，但其消費者並不都是以相同的方式使用或分發它。

下游地圖顯示三種類型的曝光：直接的 Python 依賴性、圍繞 HWI 命令行的包裝器，以及已經維護獨立後代實現的項目。

Specter Desktop 作為 Bitcoin Core 錢包的協調者，是最明顯的直接依賴。其項目描述解釋了其對 Bitcoin Core 和硬體錢包的關注，而其源碼固定了一個特定的 HWI 版本。BTCPay Server Vault 採取了不同的路徑：其本地服務通過圍繞 HWI 的命令行請求的包裝器暴露連接的簽名設備。即使替代品接受熟悉的命令，兩者仍然需要進行集成測試。

Wasabi 是一個專注於隱私的錢包，提供了一個打包示例。一個七月的項目問題報告指出，Apple Silicon 構建包含 x86_64 HWI 可執行文件，這提高了 HWI 支持的設備檢測、枚舉、地址顯示和簽名的風險，因為對 Rosetta 的依賴變得不再可行。該問題涉及打包的可執行文件，而不是簽名設備的故障。

Sparrow 是一個桌面錢包，顯示了為什麼過渡可能會分裂，而不是集中於單一的繼任者。Lark 最初是 Python HWI 的 Java 移植，現在提供 Sparrow 的硬體錢包路徑。因此，Sparrow 並不是直接的 Python-HWI 遷移案例，但它仍然負責來自同一接口的獨立實現。

新的硬體模型是 HWI 冻結可能變得可見的地方。其支持矩陣涵蓋了 Ledger、Trezor、BitBox、KeepKey、Coldcard 和 Blockstream Jade 模型。不同設備和固件的能力各不相同，包括交易類型、地址顯示和設備管理操作。替代品必須匹配所需的設備操作對，而不僅僅是重現命令名稱。

上游代碼與下游可用性之間的差距已在支持記錄中顯現。HWI 在二月份發布了 3.2.0 版本，支持 BitBox02 Nova。四月份的 Specter 用戶報告涉及使用 HWI 2.4.0 的設置，但無法檢測到 Nova。Specter 的問題未確定是固定版本、包裝、固件還是本地環境導致的故障，但時間順序顯示，上游支持和下游可用性可能會出現分歧。

根據 HWI 的新政策，面對下一個不受支持的模型的供應商或錢包團隊可以維護一個分支，構建一個單獨的集成，採用另一個接口或讓該組合不受支持。消失的是在共享上游項目中實現變更的正常路徑。

BHWI 有一個測試負責人，而不是生產交接

BHWI 通過一個 Rust 的無 I/O 核心來解決 HWI 的架構限制，將傳輸和運行時選擇留給調用者。它的工作空間包括異步、命令行和 WebAssembly 層，其命令行包構建了一個 hwi 二進制文件，旨在保留與 Python-HWI 兼容的輸出。該庫仍標記為項目正在進行中。

當前項目快照列出了 BitBox02、Coldcard、Jade 和 Ledger 型號。它最強的已發佈兼容性證據較窄。BHWI 的對等文檔描述了差異測試和最終門檻，將未修改的 HWI 3.2.0 設備套件與 BitBox02、Coldcard、Ledger 和 Jade 的 BHWI 進行比較。

這些測試降低了替代命令對於涵蓋設備返回不同結果的風險。它們並未展示 HWI 更廣泛矩陣中的生產行為、每個主機平台、每種包裝格式或完整的下游錢包流程。BHWI 的 README 和對等文檔也未提及已經作為 HWI 的生產替代品發貨的錢包。

剩下的差距既是組織性的也是技術性的。HWI 的維護者將存檔條件設置為適當的替代品，而 BHWI 已定義了一個架構和不斷增長的測試面。錢包團隊仍需決定其涵蓋的設備路徑是否足夠，如何分發它，以及誰將維護他們發貨的集成。

最終的 HWI 發布可能會建立一個固定的上游邊界。新的設備、固件行為或主機平台可能需要下游補丁，而沒有正常的回到 HWI 的路徑。捆綁 Python HWI 的項目需要包裝和發布計劃。命令行消費者需要對自己的調用進行兼容性測試。像 Sparrow 和 Lark 這樣的項目面臨著關於是否繼續其獨立堆棧的單獨決策。

HWI 的庫可能會保持開放，直到合適的繼任者出現，但其貢獻凍結已經生效。繼任風險在下一個兼容性變更到來時開始，並且共享橋樑不再接受它。

本內容僅供參考，不構成任何金融、投資、法律或稅務建議。文中提及的任何活動、獎勵、線上活動或相關資訊，不應被視為對購買、出售或交易任何加密資產的推薦、招攬或邀請。加密資產具有高波動性，存在價值損失風險。WEEX服務、產品及相關活動的可用性可能因地區而異。用戶在參與前有責任確保符合當地適用法律法規。