Las populares billeteras de Bitcoin corren el riesgo de perder soporte para nuevos dispositivos de hardware a medida que un puente de seguridad crítico deja de aceptar nuevos dispositivos

Bitcoin HWI, una interfaz ampliamente utilizada para conectar el software de billetera a dispositivos de firma de hardware, se está moviendo hacia la jubilación, mientras que el proyecto Rust que su mantenedor citó como un sucesor prometedor aún no ha demostrado una transición a producción.

El mantenedor de la Interfaz de Billetera de Hardware de Bitcoin Core, o HWI, dijo el 18 de agosto que el proyecto había estado efectivamente en modo de mantenimiento durante años y había sido en gran medida un esfuerzo en solitario. HWI ya no aceptará nuevos dispositivos ni características más allá del trabajo necesario para MuSig2. Una vez que ese trabajo esté completo, el mantenedor espera hacer un lanzamiento que probablemente será el último del proyecto, y luego mantener HWI en un mantenimiento mínimo hasta que un reemplazo adecuado esté listo.

HWI es el puente que el software de billetera puede usar para descubrir un dispositivo de hardware, recuperar claves públicas, mostrar una dirección de recepción y enviar una transacción de Bitcoin parcialmente firmada a dispositivos como Ledger, Trezor, Coldcard, BitBox o Jade para su aprobación y firma. El candidato sucesor mencionado en el aviso, BHWI, tiene como objetivo preservar la salida de comandos al estilo HWI con una implementación en Rust.

Ninguna de las transiciones está completa. HWI no está archivada, no se ha establecido una fecha de jubilación, y el aviso no dice que las billeteras de hardware soportadas dejarán de funcionar o que el bitcoin de los usuarios está en riesgo. La presión inmediata recae sobre los equipos que empaquetan HWI, invocan su línea de comandos o dependen de ella para absorber cambios en dispositivos, sistemas operativos y protocolos de proveedores.

Por qué importa el límite separado de HWI

HWI es tanto una biblioteca de Python como una herramienta de línea de comandos. Proporciona a los software una interfaz para operaciones comunes de billeteras de hardware en lugar de requerir una implementación separada para cada proveedor.

Su objetivo original era llevar el soporte de billeteras de hardware a Bitcoin Core. La integración llegó a los usuarios a través de un límite de firmante externo en lugar de colocar HWI dentro de Bitcoin Core. La documentación del firmante externo de Bitcoin Core describe un comando configurable y utiliza HWI como su ejemplo, mientras que la guía de Bitcoin Core de HWI muestra a HWI siendo utilizado para la recuperación de claves y la firma de transacciones junto a una billetera Core.

El mantenedor de HWI dijo que Python impide construcciones deterministas, el proceso de construcción reproducible que Bitcoin Core utiliza para los binarios de lanzamiento, y por lo tanto mantiene a HWI de ser enviado con Bitcoin Core. Esa separación también hace que HWI sea reemplazable en principio: otro programa puede implementar el contrato de firmante externo de Bitcoin Core. La cobertura de CryptoSlate sobre Bitcoin Core 22.0 describió la llegada del soporte de firmante externo en 2021.

Sin embargo, una superficie de comando compatible es solo una parte de una migración. Las aplicaciones aún necesitan empaquetar un reemplazo, probar los dispositivos y operaciones que exponen, y decidir quién posee las correcciones cuando el firmware o el comportamiento del sistema operativo cambian.

BHWI aborda la restricción de empaquetado con un núcleo en Rust en lugar de una aplicación en Python. Su diseño podría facilitar la distribución y el uso reproducibles desde múltiples entornos de programación, pero cada proyecto descendente aún tiene que verificar que el reemplazo cubre su propio conjunto de comandos, matriz de dispositivos y proceso de lanzamiento. Bitcoin Core puede probar otro comando conforme detrás de su límite de firmante externo; otro software que consuma la línea de comandos de HWI debe realizar su propio trabajo de compatibilidad.

Esa distinción convierte el anuncio de mantenimiento en un problema de sucesión en lugar de un simple cambio de estado del repositorio. La interfaz de HWI puede ser compartida, pero sus consumidores no la utilizan ni la distribuyen de la misma manera.

El mapa descendente muestra tres tipos de exposición: dependencias directas de Python, envolturas alrededor de la línea de comandos de HWI y proyectos que ya mantienen una implementación descendiente separada.

Specter Desktop, un coordinador para billeteras de Bitcoin Core, es la dependencia directa más clara. Su descripción del proyecto explica su enfoque en Bitcoin Core y hardware-wallet, mientras que su fuente fija una versión específica de HWI. BTCPay Server Vault toma un camino diferente: su servicio local expone dispositivos de firma conectados a través de una envoltura alrededor de las solicitudes de línea de comandos de HWI. Ambos necesitarían pruebas de integración incluso si un reemplazo aceptara comandos familiares.

Wasabi, una billetera centrada en la privacidad, presenta un ejemplo de empaquetado. Un problema del proyecto de julio informó que las compilaciones de Apple Silicon incluían un ejecutable HWI x86_64, lo que aumentaba el riesgo de detección, enumeración, visualización de direcciones y firma de dispositivos respaldados por HWI en compilaciones afectadas a medida que la dependencia de Rosetta se volvía menos sostenible. El problema concernía al ejecutable empaquetado, no a un fallo de los dispositivos de firma.

Sparrow, una billetera de escritorio, muestra por qué la transición puede fragmentarse en lugar de converger en un único sucesor. Lark comenzó como un puerto de Java de Python HWI y ahora proporciona el camino de hardware-wallet de Sparrow. Por lo tanto, Sparrow no es un caso directo de migración de Python-HWI, pero sigue siendo responsable de una implementación separada descendida de la misma interfaz.

Los nuevos modelos de hardware son donde la congelación de HWI puede volverse visible. Su matriz de soporte abarca modelos de Ledger, Trezor, BitBox, KeepKey, Coldcard y Blockstream Jade. Las capacidades difieren según el dispositivo y el firmware, incluidos los tipos de transacciones, la visualización de direcciones y las operaciones de gestión de dispositivos. Un reemplazo debe coincidir con los pares de operación de dispositivo requeridos, no simplemente reproducir los nombres de los comandos.

La brecha entre el código de upstream y la disponibilidad de downstream ya aparece en los registros de soporte. HWI lanzó la versión 3.2.0 en febrero con soporte para BitBox02 Nova. Un informe de usuario de Specter en abril involucró una configuración que utilizaba HWI 2.4.0 que no pudo detectar el Nova. El problema de Specter no identificó si la versión fijada, el empaquetado, el firmware o el entorno local causaron la falla, pero la cronología muestra que el soporte de upstream y la disponibilidad de downstream pueden divergir.

Bajo la nueva política de HWI, un proveedor o equipo de billetera que enfrente el próximo modelo no compatible puede mantener un fork, construir una integración separada, adoptar otra interfaz o dejar esa combinación sin soporte. Lo que desaparece es la ruta normal para aterrizar el cambio en el proyecto compartido de upstream.

BHWI tiene un líder de pruebas, no una entrega de producción

BHWI aborda la limitación arquitectónica de HWI con un núcleo en Rust, sin I/O, que deja las elecciones de transporte y tiempo de ejecución al llamador. Su espacio de trabajo incluye capas asíncronas, de línea de comandos y WebAssembly, y su paquete de línea de comandos construye un binario hwi destinado a preservar la salida compatible con Python-HWI. El repositorio aún etiqueta el trabajo del proyecto como en progreso.

La instantánea actual del proyecto lista los modelos BitBox02, Coldcard, Jade y Ledger. Su evidencia de compatibilidad publicada más fuerte es más limitada. La documentación de paridad de BHWI describe pruebas diferenciales y puertas finales que ejecutan el conjunto de dispositivos HWI 3.2.0 sin modificar contra BHWI para BitBox02, Coldcard, Ledger y Jade.

Esas pruebas reducen el riesgo de que un comando de reemplazo devuelva resultados diferentes para los dispositivos cubiertos. No demuestran el comportamiento de producción a través de la matriz más amplia de HWI, cada plataforma host, cada formato de empaquetado o flujos completos de billetera de downstream. El README de BHWI y el documento de paridad tampoco nombran una billetera que ya lo esté enviando como un reemplazo de producción para HWI.

La brecha restante es organizativa así como técnica. El mantenedor de HWI hizo que el archivo fuera condicional a un reemplazo adecuado, mientras que BHWI ha definido una arquitectura y una superficie de prueba en crecimiento. Los equipos de billetera aún deben decidir si las rutas de dispositivos cubiertos son suficientes, cómo distribuirlo y quién mantendrá la integración que envían.

La probable última versión de HWI establecería un límite fijo de upstream. Un nuevo dispositivo, comportamiento de firmware o plataforma host podría requerir un parche de downstream sin una ruta normal de regreso a HWI. Los proyectos que agrupan Python HWI necesitan planes de empaquetado y lanzamiento. Los consumidores de línea de comandos necesitan pruebas de compatibilidad para sus propias llamadas. Proyectos como Sparrow y Lark enfrentan una decisión separada sobre continuar su pila independiente.

El repositorio de HWI puede permanecer abierto hasta que un sucesor sea adecuado, pero su congelación de contribuciones ya está en efecto. El riesgo de sucesión comienza cuando llega el próximo cambio de compatibilidad y el puente compartido ya no lo acepta.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.