Beliebte Bitcoin-Wallets riskieren den Verlust der Unterstützung für neue Hardware-Geräte, da kritische Sicherheitsbrücke keine neuen Geräte mehr akzeptiert

Bitcoin HWI, eine weit verbreitete Schnittstelle zur Verbindung von Wallet-Software mit Hardware-Signaturgeräten, steuert auf die Einstellung zu, während das Rust-Projekt, das von seinem Betreiber als vielversprechender Nachfolger genannt wurde, noch keinen Produktionsübergang demonstriert hat.

Der Betreiber der Hardware Wallet Interface von Bitcoin Core, oder HWI, sagte am 18. August, dass das Projekt effektiv seit Jahren im Wartungsmodus sei und größtenteils eine Einzelanstrengung gewesen sei. HWI wird keine neuen Geräte oder Funktionen über die für MuSig2 erforderliche Arbeit hinaus akzeptieren. Sobald diese Arbeit abgeschlossen ist, erwartet der Betreiber eine Veröffentlichung, die wahrscheinlich die letzte des Projekts sein wird, und dann HWI in minimaler Wartung zu halten, bis ein geeigneter Ersatz bereit ist.

HWI ist die Brücke, die Wallet-Software verwenden kann, um ein Hardware-Gerät zu entdecken, öffentliche Schlüssel abzurufen, eine Empfangsadresse anzuzeigen und eine teilweise signierte Bitcoin-Transaktion an Geräte wie Ledger, Trezor, Coldcard, BitBox oder Jade zur Genehmigung und Signatur zu senden. Der im Hinweis genannte Nachfolgekandidat, BHWI, zielt darauf ab, die HWI-ähnliche Befehlsausgabe mit einer Rust-Implementierung zu bewahren.

Kein Übergang ist abgeschlossen. HWI ist nicht archiviert, kein Ruhestandsdatum wurde festgelegt, und die Mitteilung besagt nicht, dass unterstützte Hardware-Wallets nicht mehr funktionieren oder dass das Bitcoin der Benutzer gefährdet ist. Der unmittelbare Druck liegt auf den Teams, die HWI paketieren, seine Befehlszeile aufrufen oder sich darauf verlassen, um Änderungen an Geräten, Betriebssystemen und Anbieterprotokollen zu absorbieren.

Warum die separate Grenze von HWI wichtig ist

HWI ist sowohl eine Python-Bibliothek als auch ein Befehlszeilenwerkzeug. Es bietet Software eine Schnittstelle für gängige Hardware-Wallet-Operationen, anstatt eine separate Implementierung für jeden Anbieter zu verlangen.

Das ursprüngliche Ziel war es, die Unterstützung von Hardware-Wallets in Bitcoin Core zu bringen. Die Integration erreichte die Benutzer über eine externe Signaturgrenze, anstatt HWI innerhalb von Bitcoin Core zu platzieren. Die Dokumentation des externen Signierers von Bitcoin Core beschreibt einen konfigurierbaren Befehl und verwendet HWI als Beispiel, während HWI's Bitcoin Core-Leitfaden zeigt, dass HWI für den Schlüsselabruf und die Transaktionssignierung zusammen mit einer Core-Wallet verwendet wird.

Der HWI-Betreiber sagte, Python verhindere deterministische Builds, den reproduzierbaren Build-Prozess, den Bitcoin Core für Release-Binaries verwendet, und halte daher HWI davon ab, mit Bitcoin Core ausgeliefert zu werden. Diese Trennung macht HWI auch prinzipiell ersetzbar: Ein anderes Programm kann den externen Signaturvertrag von Bitcoin Core implementieren. Die Berichterstattung von CryptoSlate über Bitcoin Core 22.0 beschrieb das Eintreffen der Unterstützung für externe Signaturen im Jahr 2021.

Eine kompatible Befehlsoberfläche ist jedoch nur ein Teil einer Migration. Anwendungen müssen weiterhin einen Ersatz paketieren, die Geräte und Operationen testen, die sie bereitstellen, und entscheiden, wer die Fehler behebt, wenn sich das Verhalten von Firmware oder Betriebssystem ändert.

BHWI adressiert die Verpackungsbeschränkung mit einem Rust-Kern anstelle einer Python-Anwendung. Sein Design könnte die reproduzierbare Verteilung und Nutzung aus mehreren Programmierumgebungen erleichtern, aber jedes nachgelagerte Projekt muss dennoch überprüfen, ob der Ersatz sein eigenes Befehlsset, die Gerätematrix und den Veröffentlichungsprozess abdeckt. Bitcoin Core kann einen anderen konformen Befehl hinter seiner externen Signaturgrenze testen; andere Software, die die Befehlszeile von HWI konsumiert, muss ihre eigene Kompatibilitätsarbeit leisten.

Diese Unterscheidung verwandelt die Wartungsankündigung in ein Nachfolgeproblem, anstatt in eine einfache Änderung des Repository-Status. Die Schnittstelle von HWI kann geteilt werden, aber ihre Verbraucher verwenden oder verteilen sie nicht alle auf die gleiche Weise.

Die nachgelagerte Karte zeigt drei Arten von Abhängigkeiten: direkte Python-Abhängigkeiten, Wrapper um die Befehlszeile von HWI und Projekte, die bereits eine separate Nachkommenimplementierung pflegen.

Specter Desktop, ein Koordinator für Bitcoin Core-Wallets, ist die klarste direkte Abhängigkeit. Die Projektbeschreibung erklärt den Fokus auf Bitcoin Core und Hardware-Wallets, während die Quelle eine spezifische HWI-Version fixiert. BTCPay Server Vault verfolgt einen anderen Ansatz: Der lokale Dienst gibt verbundene Unterzeichnungsgeräte über einen Wrapper um die Befehlszeilenanforderungen von HWI preis. Beide müssten Integrationstests durchführen, selbst wenn ein Ersatz vertraute Befehle akzeptierte.

Wasabi, eine datenschutzorientierte Wallet, bietet ein Verpackungsbeispiel. Ein Projektproblem im Juli berichtete, dass Apple Silicon-Bauten eine x86_64 HWI-executable enthielten, was ein Risiko für die Erkennung, Aufzählung, Adressanzeige und Unterzeichnung von HWI-unterstützten Geräten in betroffenen Bauten darstellt, da die Abhängigkeit von Rosetta weniger tragfähig wurde. Das Problem betraf die verpackte ausführbare Datei, nicht einen Ausfall der Unterzeichnungsgeräte.

Sparrow, eine Desktop-Wallet, zeigt, warum der Übergang fragmentiert werden kann, anstatt sich auf einen einzigen Nachfolger zu konzentrieren. Lark begann als Java-Port von Python HWI und liefert jetzt den Hardware-Wallet-Pfad von Sparrow. Sparrow ist daher kein direkter Fall eines Python-HWI-Migrationsfalls, bleibt jedoch für eine separate Implementierung verantwortlich, die von derselben Schnittstelle abstammt.

Neue Hardwaremodelle sind der Bereich, in dem die Freeze von HWI sichtbar werden kann. Matrix der Unterstützung umfasst Ledger, Trezor, BitBox, KeepKey, Coldcard und Blockstream Jade-Modelle. Die Fähigkeiten unterscheiden sich je nach Gerät und Firmware, einschließlich Transaktionstypen, Adressanzeige und Geräteverwaltungsoperationen. Ein Ersatz muss die erforderlichen Gerätebetriebs-Paare übereinstimmen, nicht nur die Befehlsnamen reproduzieren.

Die Lücke zwischen dem Upstream-Code und der Verfügbarkeit im Downstream zeigt sich bereits in den Support-Aufzeichnungen. HWI veröffentlichte im Februar die Version 3.2.0 mit Unterstützung für BitBox02 Nova. Ein Benutzerbericht von Specter im April betraf eine Konfiguration, die HWI 2.4.0 verwendete und die Nova nicht erkennen konnte. Das Specter-Problem identifizierte nicht, ob die festgelegte Version, das Packaging, die Firmware oder die lokale Umgebung die Ursache für das Versagen war, aber die Chronologie zeigt, dass die Unterstützung im Upstream und die Verfügbarkeit im Downstream auseinanderdriften können.

Unter HWIs neuer Richtlinie kann ein Anbieter oder ein Wallet-Team, das mit dem nächsten nicht unterstützten Modell konfrontiert ist, einen Fork beibehalten, eine separate Integration erstellen, eine andere Schnittstelle übernehmen oder diese Kombination nicht unterstützen. Was verschwindet, ist der normale Weg, um die Änderung im gemeinsamen Upstream-Projekt zu verankern.

BHWI hat eine Testleitung, keinen Produktionsübergang

BHWI geht HWIs architektonische Einschränkung mit einem Rust-Kern ohne I/O an, der die Transport- und Laufzeitentscheidungen dem Aufrufer überlässt. Sein Arbeitsbereich umfasst asynchrone, Kommandozeilen- und WebAssembly-Schichten, und sein Kommandozeilenpaket erstellt eine hwi-Binärdatei, die dazu gedacht ist, die mit Python-HWI kompatible Ausgabe zu bewahren. Das Repository kennzeichnet das Projekt weiterhin als in Arbeit.

Der aktuelle Projekt-Snapshot listet BitBox02, Coldcard, Jade und Ledger-Modelle. Die stärksten veröffentlichten Kompatibilitätsnachweise sind enger gefasst. Die Paritätsdokumentation von BHWI beschreibt differenzielle Tests und finale Gates, die die unveränderte HWI 3.2.0-Gerätesuite gegen BHWI für BitBox02, Coldcard, Ledger und Jade ausführen.

Diese Tests verringern das Risiko, dass ein Ersatzbefehl unterschiedliche Ergebnisse für die abgedeckten Geräte zurückgibt. Sie zeigen jedoch nicht das Produktionsverhalten über HWIs breiteres Matrix, jede Host-Plattform, jedes Packaging-Format oder vollständige Wallet-Flows im Downstream. BHWIs README und Paritätsdokument benennen auch kein Wallet, das bereits als Produktionsersatz für HWI ausgeliefert wird.

Die verbleibende Lücke ist sowohl organisatorisch als auch technisch. Der Wartungsbeauftragte von HWI machte die Archivierung von einer geeigneten Ersatzlösung abhängig, während BHWI eine Architektur und eine wachsende Testoberfläche definiert hat. Wallet-Teams müssen weiterhin entscheiden, ob die abgedeckten Gerätepfade ausreichend sind, wie sie es verteilen und wer die Integration, die sie ausliefern, warten wird.

Die wahrscheinlich letzte HWI-Version würde eine feste Upstream-Grenze festlegen. Ein neues Gerät, das Verhalten der Firmware oder die Host-Plattform könnte dann einen Patch im Downstream erfordern, ohne einen normalen Weg zurück in HWI. Projekte, die Python HWI bündeln, benötigen Packaging- und Release-Pläne. Kommandozeilenbenutzer benötigen Kompatibilitätstests für ihre eigenen Aufrufe. Projekte wie Sparrow und Lark stehen vor einer separaten Entscheidung über die Fortsetzung ihres unabhängigen Stacks.

HWIs Repository kann offen bleiben, bis ein Nachfolger geeignet ist, aber der Beitragseinbruch ist bereits in Kraft. Das Nachfolgerisiko beginnt, wenn die nächste Kompatibilitätsänderung eintrifft und die gemeinsame Brücke sie nicht mehr akzeptiert.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.