Wenn ich eins in den letzten Jahren gelernt habe, ist es, dass man nicht paranoid genug sein kann.
Jedes Wallet, das ich per USB, Bluetooth (evtl NFC) mit dem Rechner verbinde, könnte durch einen betrügerischen Wallethersteller (oder Hack) kompromittiert werden und den Seed „rausgeben“. (siehe Ledger Recover)
Bei den airgapped Wallets bleibt meines Wissens nach nur „Dark Skippy“ als denkbarer Angriffsvektor. Aber ich denke, dass sowas bei publizierter firmware auffallen würde. (zumindest eher als der aktuelle Bug bei cc)
Transaktionen statt per Micro SD, per QR freizugeben halte ich persönlich für ein vertretbares Risiko, weil ich mehrfach mit einem selbstgebastelten Pythonskript die Rohdaten da rausgezogen habe und nichts anderes darin gefunden habe, als in einem psbt-file, das man per Micro SD überträgt, auch überträgt.
Für das Jade Plus steht der Test natürlich noch aus.
Das mit Trezor nehme ich zurück. Muss mir das Teil doch nochmal genauer anschauen. Hatte erst auch mit einem 2/3 Setup geplant, da bringt Trezor wohl Nachteile (fehlende On-Device-Registrierung), aber bei 3/3, 4/4 etc. scheint es egal zu sein. (bin, wie man merkt, noch neu beim Thema multisig)
Guter Punkt zu Dark Skippy, aber die häufigeren Verlustursachen sind eigentlich banaler: verlorenes Descriptor-Backup, ein verlorener Seed, ein Einrichtungsfehler. Da fängt Bitkeys dritter Schlüssel bei Block genau die Alltagsrisiken ab, die man sonst bei drei Airgap-Geräten selbst fehlerfrei managen müsste. Für mich langfristig zwar Ziel: eigene Multisig, aber bis Wissen und Sorgfalt reichen, ist Bitkey die pragmatischere Zwischenstufe.
Da teilen wir das gleiche Ziel! Mit den häufigen Verlurstursachen hast du völlig recht! Daher lasse ich mir da auch Zeit für Planung und Tests etc. Der Thread hier ist genial um sich schonmal im Vorfeld auszutauschen.
Verlorenes Descriptor-Backup wird ja, soweit ich das jetzt verstanden habe, nur zum Problem, wenn einer der 4 Seeds fehlt. → wenn man sowieso 4/4 plant also egal. (korrigiert mich bitte, wenn ich falsch liege!)
Der Bitkey, vor allen die neue Version mit Display, wirkt schon ziemlich genial für Einsteiger (und kleinere Stacks)!
Block ist natürlich keine kleine Hinterhofklitsche, aber trotzdem stört mich an dem Konzept, dass man dann wieder von einem Hersteller abhängig ist, dem man vertrauen muss.
wenn bei einem 4/4 einer der Seeds fehlt nützt dir auch kein Descriptorbackup mehr etwas. Dann bist du sozusagen am Arsch. Du benötigst ja ALLE 4 Keys zum Unterzeichnen einer Transaktion. Verwende lieber ein 2/3 oder ein 3/5, da bist du auf der sicheren Seite.
Bei Multisig stelle ich mir die getrennte Verwahrung der Seeds schwer vor. Und den Zugriff im Fall der Vererbung. Wobei da vermutlich Singlesig mit/ohne Passphrase schon eine hohe Hürde darstellt.
Beim Block-Vertrauen stimme ich zu, das ist der bewusste Kompromiss für die Bequemlichkeit, besonders für Anfänger.
Zum Descriptor: Das Backup selbst ist eigentlich kein Problem, wenn man die Descriptor-Datei einfach bei jedem Seed-Backup mit ablegt. Der eigentliche Vorteil der On-Device-Registrierung liegt woanders: bei der Adressverifizierung. Nur ein Gerät, das den Descriptor selbst gespeichert hat, kann eine Empfangsadresse wirklich eigenständig verifizieren, also bestätigen, dass diese Adresse tatsächlich zu genau dieser Multisig-Wallet gehört. Ohne das musst du dem Coordinator blind vertrauen, dass er dir die richtige Adresse anzeigt.
Genau deshalb ist das bei Geräten wie BitBox, Jade, Specter, Foundation oder Coldcard na ja relevant, die speichern den Descriptor und können so unabhängig verifizieren. Trezor kann das ohne diese Registrierung bei m-von-n-Setups nicht.
Ein Gerät mit registriertem Descriptor (Jade, BitBox) erkennt Wechselgeldadressen automatisch, weil es sie selbst aus dem bekannten Descriptor berechnet, und bestätigt sie ohne manuellen Prompt. Ohne Registrierung (z. B. Trezor) bekommst du stattdessen eine Abfrage, die du selbst gegenprüfen musst. Genau das ist der praktische Vorteil der On-Device-Registrierung: Sie schützt nicht nur Empfangsadressen, sondern vor allem das im Hintergrund mitlaufende Wechselgeld bei jeder Transaktion.
Bei Bitkey stellt sich diese ganze Frage gar nicht erst: Descriptor-Verwaltung, Registrierung, Wechselgeld-Verifizierung, das alles übernimmt die App im Hintergrund für dich. Du musst weder wissen, was ein Descriptor ist, noch ihn irgendwo registrieren oder bei einem Geräte-Wechsel neu einspielen. Genau das ist der Bequemlichkeits-Kompromiss, den man eingeht: Man verlässt sich darauf, dass Block das korrekt und sicher im Hintergrund erledigt, statt es selbst zu kontrollieren.
Kann man eine Multisig-Wallet eigentlich nicht mit der BitBoxApp erstellen?
Wie wirkt sich die Verwendung der 3rd-Party App „Sparrow“ eigentlich auf das Anti-Klepto-Feature der BitBox aus, hat das Sparrow implementiert oder ist diese Bitbox-Funktion durch Verwendung von Sparrow-Wallet dann derzeit außer Kraft gesetzt?
Der “Nonce Covert Channel”-Angriff wird vereitelt, indem die Möglichkeit der Hardware-Wallet eingeschränkt wird, die Nonce frei zu wählen. Dazu verlangt die BitBoxApp (oder jede andere Software, die mit der BitBox02 interagiert), dass die Hardware-Wallet wie bisher eine eigene Nonce wählt, zwingt sie aber auch dazu, eine von der BitBoxApp selbst gewählte Nonce hinzuzufügen.
Nein, das geht nicht. Aber der Hersteller empfiehlt ja explizit Sparrow Wallet und hat im Blog auf seiner Webseite sogar eine Anleitung dafür veröffentlicht.
ich hab schon viele multisig aufgesetzt, für meine Familie hab ich Frostsnap, weil es selbst für Kinder ab 10 Jahren bedienbar ist.
Wenn ihr also etwas sucht um euch nicht selbst auszusperren, Frostsnap ist da eine sehr gute wahl.
wenn ihr das machen wollt dann gehe in layern vor, schaltet software Wallet, HW (Bitbox) davor.
Erst Software Wallet, z.B. Lightning Wallet oder Liquid oder oder …, dann die Bitbox und von da dann in die Multisig.
Die grenzen ab welchem Betrag wohin, das macht ihr selber
relevant, die speichern den Descriptor und können so unabhängig verifizieren. Trezor kann das ohne diese Registrierung bei m-von-n-Setups nicht.