由于关键安全桥停止接受新设备，流行的比特币钱包面临失去对新硬件设备的支持的风险

BHWI 对四个设备系列进行了奇偶校验测试，但没有指定的生产钱包部署。

比特币 HWI 将在 MuSig2 剩余工作完成后停止接受新设备和功能。

比特币 HWI 是一种广泛使用的用于将钱包软件连接到硬件签名设备的接口，它正在走向退役，而其维护者称其为有希望的继任者的 Rust 项目尚未展示出生产交接。

比特币核心硬件钱包接口（HWI）的维护者在 8 月 18 日表示，该项目多年来实际上一直处于维护模式，并且很大程度上是一个单独的努力。 HWI 将不再接受超出 MuSig2 所需工作的新设备或功能。一旦这项工作完成，维护人员预计将发布一个可能是该项目的最后一个版本，然后将 HWI 保持在最低限度的维护状态，直到准备好合适的直接替代品。

HWI 是钱包软件用来发现硬件设备、检索公钥、显示接收地址并将部分签名的比特币交易发送到 Ledger、Trezor、Coldcard、BitBox 或 Jade 等设备以供批准和签名的桥梁。通知中指定的后继候选者 BHWI 旨在通过 Rust 实现保留 HWI 风格的命令输出。

这两种转变都不完整。 HWI 未存档，未设置停用日期，并且该通知没有表示支持的硬件钱包将停止工作或用户的比特币面临风险。直接的压力落在了打包 HWI、调用其命令行或依赖它来吸收设备、操作系统和供应商协议变化的团队身上。

为什么 HWI 的单独边界很重要

HWI 既是一个 Python 库，也是一个命令行工具。它为软件提供了一个用于常见硬件钱包操作的接口，而不需要为每个供应商单独实施。

其最初的目标是为比特币核心提供硬件钱包支持。该集成通过外部签名者边界到达用户，而不是通过将 HWI 放置在 Bitcoin Core 中。 Bitcoin Core 的外部签名者文档描述了一个可配置命令并使用 HWI 作为示例，而 HWI 的 Bitcoin Core 指南显示 HWI 与 Core 钱包一起用于密钥检索和交易签名。

HWI 维护者表示，Python 阻止了确定性构建（Bitcoin Core 用于发布二进制文件的可重复构建过程），因此阻止了 HWI 与 Bitcoin Core 一起发布。这种分离也使得 HWI 原则上是可替代的：另一个程序可以实现 Bitcoin Core 的外部签名者合约。 CryptoSlate 对比特币核心 22.0 的报道描述了 2021 年外部签名者支持的到来。

然而，兼容的命令界面只是迁移的一部分。应用程序仍然需要打包替代品，测试它们公开的设备和操作，并在固件或操作系统行为发生变化时决定谁拥有修复程序。

BHWI 使用 Rust 核心而不是 Python 应用程序解决了打包约束。它的设计可以使多个编程环境的可重复分发和使用变得更容易，但每个下游项目仍然必须验证替代品是否涵盖了自己的命令集、设备矩阵和发布过程。 Bitcoin Core 可以在其外部签名者边界后面测试另一个一致的命令；使用 HWI 命令行的其他软件必须执行自己的兼容性工作。

这种区别将维护公告变成了继承问题，而不是简单的存储库状态更改。 HWI 的界面可能是共享的，但其消费者并不都以相同的方式使用或分发它。

下游图显示了三种类型的暴露：直接的 Python 依赖项、HWI 命令行的包装器以及已经维护单独后代实现的项目。

每日简报 噪音之前的信号。以由 CryptoSlate 编辑解码的推动市场的加密货币故事开始新的一天。一封电子邮件。一切重要的事情。电子邮件地址 免费加入 免费加入。随时取消订阅。哎呀，看来有问题了。请再试一次。你在名单上。您的下一份每日简报即将发送。

项目或路径 硬件钱包桥如何工作 过渡负担 Bitcoin Core 外部签名者 HWI 是单独签名者命令的记录示例 根据 Core 的命令合约和钱包流验证替换 Spectre Desktop 其依赖文件引脚 HWI 3.1.0 重新打包替换并重新测试发现、地址显示和签名 Wasabi 钱包 其兼容性文档将硬件钱包支持与 HWI 联系起来 在支持的平台上替换或维护可执行文件 BTCPay Server Vault BTCPayServer.Hwi 包装 HWI命令行 调整包装器并确认本地设备桥保留行为 Sparrow Wallet 当前的 Hwi.java 路径调用 Lark，而不是 Python HWI 继续维护单独的设备堆栈，而不是直接执行 Python-HWI 交换

Spectre Desktop 是比特币核心钱包的协调器，是最明显的直接依赖项。其项目描述解释了其比特币核心和硬件钱包的重点，而其源代码则固定了特定的 HWI 版本。 BTCPay Server Vault 采用了不同的路线：其本地服务通过 HWI 命令行请求的包装器公开连接的签名设备。即使替代者接受熟悉的命令，两者都需要集成测试。

Wasabi 是一款注重隐私的钱包，它提供了一个包装示例。 7 月份的项目报告称，Apple Silicon 版本包含 x86_64 HWI 可执行文件，由于对 Rosetta 的依赖变得越来越站不住脚，因此增加了 HWI 支持的设备检测、枚举、地址显示和签名受影响版本的风险。该问题涉及打包的可执行文件，而不是签名设备的故障。

Sparrow 是一款桌面钱包，它展示了为什么过渡可能会支离破碎，而不是集中在一个单一的继任者身上。 Lark 最初是 Python HWI 的 Java 端口，现在提供 Sparrow 的硬件钱包路径。因此，Sparrow 不是直接的 Python-HWI 迁移案例，但它仍然负责从同一接口派生的单独实现。

新的硬件模型是 HWI 冻结的明显体现。其支持矩阵涵盖 Ledger、Trezor、BitBox、KeepKey、Coldcard 和 Blockstream Jade 模型。功能因设备和固件而异，包括事务类型、地址显示和设备管理操作。替换必须匹配所需的设备操作对，而不仅仅是复制命令名称。

上游代码和下游可用性之间的差距已经出现在支持记录中。 HWI 在二月份发布了 3.2.0 版本，支持 BitBox02 Nova。 4 月份的 Spectre 用户报告涉及使用 HWI 2.4.0 的设置，无法检测到 Nova。 Spectre 问题并未确定是否是固定版本、包装、固件或本地环境导致了故障，但时间顺序显示上游支持和下游可用性可能存在差异。

根据 HWI 的新政策，面临下一个不受支持的模型的供应商或钱包团队可以维护分叉、构建单独的集成、采用另一个接口或不支持该组合。消失的是共享上游项目中变更落地的正常路径。

BHWI 有测试领导权，但没有生产交接权

BHWI 通过 Rust、无 I/O 核心解决了 HWI 的架构限制，将传输和运行时选择留给调用者。其工作区包括异步、命令行和 WebAssembly 层，其命令行包构建了一个 hwi 二进制文件，旨在保留 Python-HWI 兼容的输出。存储库仍然标记正在进行的项目工作。

当前的项目快照列出了 BitBox02、Coldcard、Jade 和 Ledger 模型。其公布的最强有力的兼容性证据范围较窄。 BHWI 的奇偶校验文档描述了针对 BitBox02、Coldcard、Ledger 和 Jade 的 BHWI 运行未经修改的 HWI 3.2.0 设备套件的差异测试和最终门。

这些测试降低了替换命令为所涵盖的设备返回不同结果的风险。它们没有展示 HWI 更广泛的矩阵、每个主机平台、每种包装格式或完整的下游钱包流程的生产行为。 BHWI 的自述文件和奇偶校验文件也没有提到已经作为 HWI 生产替代品发货的钱包。

剩下的差距是组织和技术方面的。 HWI 的维护人员以合适的替代品为条件进行存档，而 BHWI 则定义了架构和不断增长的测试面。钱包团队仍必须决定其覆盖的设备路径是否足够、如何分发以及由谁来维护他们提供的集成。

可能的最终 HWI 版本将建立固定的上游边界。新设备、固件行为或主机平台可能需要下游补丁，而无需正常路径返回 HWI。捆绑Python HWI的项目需要打包和发布计划。命令行使用者需要对其自己的调用进行兼容性测试。 Sparrow 和 Lark 等项目面临着关于继续其独立堆栈的单独决定。

HWI 的存储库可能会保持开放，直到合适的继任者为止，但其贡献冻结已经生效。当下一个兼容性更改到达并且共享桥不再接受它时，继承风险就开始了。