Multisig 2-von-3 einrichten Das hersteller-agnostische Quorum
Drei Hardware-Wallets. Drei Hersteller. Drei Jurisdiktionen. Ein Ziel: Die Eliminierung des Single Point of Failure. Diese Anleitung orchestriert ein Multisig-Setup mit BitBox02, Trezor Safe 5 und einem Ledger-Gerät der Nano-S-Plus- oder Nano-X-Reihe via Sparrow Wallet. P2WSH als 2026-Standard. Descriptor-Backup nach BIP-129. Verifikations-Protokoll gegen Software-Manipulationen.
Die Redundanz-Theorie: Warum drei Hersteller?
Ein Single-Signature-Setup ist ein architektonischer Fehler. Nicht weil die BitBox02 unsicher wäre. Nicht weil dem Trezor Safe 5 die Integrität fehlt. Sondern weil du eine einzelne Entität zur kritischen Abhängigkeit deiner gesamten Bitcoin-Position machst.
Shift Crypto kann morgen von einer feindlichen Übernahme betroffen sein. Ledger kann unter regulatorischen Druck geraten. SatoshiLabs kann einen katastrophalen Firmware-Bug ausliefern. Diese Szenarien sind nicht paranoid. Sie sind die operative Realität einer Industrie, die noch keine 20 Jahre alt ist.
Das Prinzip der architektonischen Neutralisierung
Ein 2-of-3 Multisig mit drei verschiedenen Herstellern macht dich immun gegen den Ausfall einer einzelnen Firma. Wenn morgen Ledger seine Pforten schließt, signierst du mit BitBox02 und Trezor. Wenn ein kritischer Bug in der Trezor-Firmware entdeckt wird, hast du noch zwei intakte Signierer. Du benötigst nur zwei von drei Schlüsseln, um deine Bitcoin zu bewegen.
$$P(\text{Totalverlust}) = 3p^{2}(1-p) + p^{3}$$
Wobei $p$ = Ausfallwahrscheinlichkeit je Hersteller, als unabhängig angenommen
Effekt: Bei 1 Prozent individuellem Risiko → 0,0298 Prozent Gesamtrisiko
Eigene Rechnung: Bei einem 2-von-3-Setup ist das Vermögen verloren, sobald beliebige zwei der drei Schlüssel fehlen — dafür gibt es drei Paare. Mit p als Ausfallwahrscheinlichkeit je Hersteller und unter der Annahme, dass die drei unabhängig ausfallen, sind das 3p²(1−p) + p³; bei p von 1 Prozent ergibt das 0,0298 Prozent.
BitBox02
Signer #1
Schweizer Jurisdiktion. Open-Source Firmware. Minimalistisches Secure Element. Bitcoin-only Edition verfügbar.
Trezor Safe 5
Signer #2
Tschechische Jurisdiktion. Quelloffene Firmware — das Secure Element ist es nicht. Zertifizierung EAL6+. Touch-Display für sicheren Input.
Ledger
Signer #3
Französische Jurisdiktion. Certified Secure Element (CC EAL6+ beim Nano S Plus, EAL5+ beim Nano X). Proprietäre Firmware. Breiteste Altcoin-Unterstützung.
Quellen: die Produktseiten der drei Hersteller — Trezor Safe 5, Produktseite (abgerufen 11.09.2026) | Ledger, Produktseiten Nano S Plus und Nano X (abgerufen 01.10.2026) | Shift Crypto, Best of both worlds: using a secure chip with open source firmware, abgerufen am 27.09.2026 — die Produktseiten des Hauses antworten unserem Server mit 403, die Hilfe nicht. Da sie keinen Chiptyp nennt, ist „minimalistisches Secure Element“ unsere Einordnung, ebenso die Reihung als Signer #1 bis #3.| Stand: 11.09.2026
Im September 2026 verschickte ein Angreifer über die übernommenen Newsletter-Konten von Trezor und BitBox beim Dienst Brevo Phishing-Mails an die Abonnenten, mit einem Link zu einer App bzw. Seite, die die Wiederherstellungswörter abfragte (Trezor und BitBox sind Partner von BitAtlas; für vermittelte Kunden erhalten wir eine Vergütung). Um ihr Guthaben gefährdet ist laut beiden Herstellern nur, wer dort seine Wiederherstellungswörter eingegeben hat, Geräte waren nicht betroffen; mehr dazu, zum von Trezor im August 2026 gemeldeten Datenleck mit Lieferanschriften beim Versanddienstleister ShipMonk und zu den mit BitBox-Firmware 9.26.5 geschlossenen Lücken in den Testberichten zu Trezor und BitBox.
Im Dezember 2025 wurden beim Bestelldienstleister Global-e Name, Anschrift, E-Mail, Telefonnummer und Bestelldetails von Kunden offengelegt, die auf ledger.com über Global-e bestellt hatten (Ledger ist Partner von BitAtlas; für vermittelte Kunden erhalten wir eine Vergütung). Zahlungsdaten waren nicht betroffen, und Wiederherstellungswörter liegen laut Ledger gar nicht bei Global-e; weitere Vorfälle (2020 und das Sicherheitsbulletin LSB 023 vom August 2026) und was dabei zu tun ist, stehen im Testbericht.
Warum nicht drei identische Geräte?
Die Versuchung liegt nahe: Drei BitBox02, weil du dem Produkt vertraust. Aber damit erreichst du keine echte Redundanz. Ein Firmware-Bug, der in Version X eingeführt wird, betrifft alle drei Geräte gleichzeitig. Ein Supply-Chain-Angriff, der Shift Crypto kompromittiert, kompromittiert alle deine Signierer.
Herstellerdiversität ist keine Paranoia. Es ist Architektur. Die drei Hersteller nutzen unterschiedliche Sicherheitsmodelle (Secure Element vs. Open-Source-Only), unterschiedliche Firmware-Stacks, unterschiedliche Supply-Chains und operieren unter verschiedenen Rechtssystemen. Ein Angriff, der einen Hersteller kompromittiert, hat keine Korrelation mit den anderen.
Du musst keinem einzelnen Hersteller vollständig vertrauen. Dein Setup ist so konstruiert, dass selbst ein kompromittierter Signer (durch Bug, Backdoor oder physischen Diebstahl) nicht ausreicht, um deine Bitcoin zu bewegen. Das verschiebt das Vertrauen, statt es abzuschaffen: weg von einem einzelnen Hersteller, hin zu deiner eigenen Sorgfalt beim Descriptor und bei der Verteilung. Wie viel daran hängt, zeigt der nächste Abschnitt.
Die BitBox02 ist unser empfohlener Primär-Signer im Multisig-Setup. Unser BitBox02 Select Report analysiert die Firmware-Architektur und Sicherheitseigenschaften im Detail.
Orchestrierung via Sparrow Wallet
Sparrow Wallet ist der Koordinator. Es verbindet die drei Hardware-Wallets, konstruiert die Multisig-Policy und generiert die Empfangsadressen. Die Signierer selbst halten nur ihren privaten Schlüssel. Sparrow sieht nur die Extended Public Keys (xpubs) und kann niemals eigenständig signieren.
Vor dem Setup: Kritische Vorbereitungen
Initialisiere alle drei Hardware-Wallets separat. Jedes Gerät erzeugt sein eigenes Backup: der Trezor Safe 5 ab Werk 20 Wörter nach SLIP-39, die beiden anderen 24 Wörter nach BIP-39. Sichere jeden Seed auf Stahl. Die Seeds dürfen sich niemals am selben Ort befinden. Erst wenn alle drei Wallets unabhängig funktionieren, beginnt die Multisig-Orchestrierung.
Sparrow starten und neue Wallet erstellen
In Sparrow Wallet: File → New Wallet. Vergib einen aussagekräftigen Namen (z.B. „Quorum-2of3-2026“). Wähle Multi Signature als Wallet-Typ.
Policy definieren: 2-of-3 P2WSH
Setze M = 2 (benötigte Signaturen) und N = 3 (Gesamtzahl Signierer). Script Type: Native Segwit (P2WSH). Taproot (P2TR) ist 2026 noch nicht vollständig interoperabel über alle drei Hersteller.
P2WSH (Native SegWit) → Stabiler Standard für herstellerübergreifende Multisigs
P2TR (Taproot) → Bessere Privacy, kleinere Fees, aber Interoperabilität noch im Aufbau
Derivation Path (Multisig): m/48h/0h/0h/2h
Quellen: BIP-48 — Multi-Script Hierarchy for Multi-Sig Wallets für den Pfad m/48h/0h/0h/2h | Sparrow Wallet Documentation | Dass Taproot über alle drei Hersteller hinweg noch nicht durchgängig zusammenspielt, ist unsere Einschätzung aus der Lektüre — wir haben es nicht nachgestellt
Keystore #1: BitBox02 via xPub-Copy
Die BitBox02 wird als Watch-Only Keystore importiert. Öffne die BitBoxApp, verbinde deine BitBox02 via USB und navigiere zu deinem Bitcoin-Account. Im Account-Menü findest du die Option „xpub anzeigen“ oder „Export xpub“. Kopiere den vollständigen Extended Public Key (beginnt mit xpub, ypub oder zpub je nach Adresstyp).
BitBox02 xpub in Sparrow einfügen
In Sparrow unter „Keystores“ → Klicke auf Keystore 1 → Wähle xPub / Watch Only Wallet. Füge den kopierten xpub aus der BitBoxApp ein. Verifiziere Fingerprint und Derivation Path. Speichere den Keystore. Stelle den Keystore anschließend auf „Connected Hardware Wallet“ um, sobald die BitBox02 angeschlossen ist: Ein reiner xPub-Eintrag kann Adressen ableiten, aber nicht signieren — und du brauchst ihn zum Signieren, wie das Recovery-Audit in Abschnitt 05 zeigt.
Keystore #2: Trezor Safe 5 via Device-Scan
Der Trezor Safe 5 wird direkt via USB verbunden. Schließe Trezor Suite vollständig. Sparrow kommuniziert direkt mit dem Gerät und liest xpub, Master-Fingerprint und Derivation Path automatisch aus.
Trezor Safe 5 scannen
Verbinde den Trezor Safe 5 via USB. In Sparrow → Keystore 2 → Connected Hardware Wallet → Scan for Connected Devices. Sparrow erkennt den Trezor. Klicke Import Keystore.
Keystore #3: Ledger via Device-Scan
Der Ledger folgt dem gleichen Prozess. Schließe Ledger Wallet (früher Ledger Live). Öffne die Bitcoin-App auf dem Ledger-Gerät. Verbinde via USB.
Ledger scannen
Bitcoin-App auf dem Ledger öffnen. In Sparrow → Keystore 3 → Connected Hardware Wallet → Scan for Connected Devices. Ledger wird erkannt. Import Keystore klicken.
Wallet finalisieren
Alle drei Keystores sind eingefügt. Überprüfe die Zusammenfassung: 2-of-3, P2WSH, drei verschiedene Fingerprints. Klicke Apply und setze ein starkes Passwort für die Sparrow-Wallet-Datei.
Die Reihenfolge der Keystores in Sparrow ist relevant für die Descriptor-Rekonstruktion. Dokumentiere exakt, welcher Keystore zu welchem Gerät gehört. Sparrow verwendet sortedmulti, aber der Master-Fingerprint muss korrekt zugeordnet werden können.
Das Descriptor-Dilemma (BIP-129)
Hier liegt die Falle, in die selbst erfahrene Bitcoiner tappen: Du hast drei Seeds auf Stahl gesichert. Du denkst, du bist auf der sicheren Seite. Du bist es nicht.
Bei einer Single-Signature-Wallet reicht der Seed, um alle Adressen zu rekonstruieren. Der Derivation Path ist standardisiert (BIP-44/49/84), die Wallet-Software kann die Adressen ableiten. Bei Multisig funktioniert das nicht.
Warum Seeds allein zum Totalverlust führen können
Eine Multisig-Adresse ist ein Hash aus mehreren Informationen: Welche xpubs gehören zusammen? In welcher Reihenfolge? Welcher Script-Typ wird verwendet? Welcher Derivation Path für Multisig? Wenn du nur die drei Seeds hast, aber nicht weißt, wie sie kombiniert wurden, kannst du die Adressen nicht rekonstruieren.
$$wsh(sortedmulti(2,[fp_1/path_1]xpub_1,[fp_2/path_2]xpub_2,[fp_3/path_3]xpub_3))$$
wsh = Witness Script Hash (P2WSH)
sortedmulti(2,…) = 2-of-3 mit lexikografisch sortierten Keys
[fp/path]xpub = Fingerprint + Derivation Path + Extended Public Key
Quellen: BIP-129 — Bitcoin Secure Multisig Setup (BSMS) | BIP-380 — Output Script Descriptors — dort ist wsh() als P2WSH-Ausgang definiert
Anleitung: Descriptor aus Sparrow exportieren
Sparrow macht den Export einfach. Der Descriptor enthält alle Informationen, die zur vollständigen Rekonstruktion der Wallet benötigt werden: alle drei xpubs, ihre Fingerprints, die Derivation Paths und die Policy.
Wallet-Settings öffnen
In Sparrow: Öffne deine Multisig-Wallet → Navigiere zu Settings (Zahnrad-Symbol).
Output Descriptor anzeigen
Unter „Script Policy“ siehst du den vollständigen Output Descriptor. Er beginnt mit wsh(sortedmulti(2,... für P2WSH 2-of-3.
Export: Wallet File
File → Export Wallet → Wähle Sparrow oder Wallet Descriptor. Speichere die Datei. Sie enthält den Descriptor und alle Konfigurationsinformationen.
Papier-Backup erstellen
Drucke den Descriptor zusätzlich aus. Handschriftliche Kopie als Redundanz. Lagere das Papier-Backup separat von den Seeds.
Beispiel-Struktur | Fingerprints und xpubs gekürzt | Tatsächliche xpubs sind ~111 Zeichen
Stell dir vor, du verlierst den Descriptor und hast nur die drei Seeds. Du müßtest alle Kombinationen aus Ableitungspfad, Skript-Typ und Quorum durchprobieren. Die Reihenfolge der Schlüssel fällt dabei weg, solange du weißt, daß Sparrow sortedmulti benutzt und lexikografisch sortiert — weißt du das nicht mehr, kommen sechs Reihenfolgen dazu. Jede Kombination erzeugt andere Adressen, und ob du richtig geraten hast, siehst du erst, wenn ein Saldo erscheint. Ohne Descriptor ist die Wiederherstellung ein Glücksspiel.
BIP-129 (BSMS): Der interoperable Standard
BIP-129 (Bitcoin Secure Multisig Setup) definiert ein standardisiertes Format für Multisig-Konfigurationen mit Manipulationsschutz beim Setup. Coldcard hat BSMS-Support implementiert. Für ein herstellerübergreifendes Setup mit BitBox, Trezor und Ledger fanden wir BSMS in der Dokumentation der drei Häuser nicht beschrieben — das ist unsere Lektüre, keine Erprobung, und es heißt nicht, daß es nirgends geht. Der Descriptor-Export aus Sparrow bleibt der Weg, den diese Anleitung zeigt.
Die Goldene Regel: Verifikations-Zwang
Du hast die Wallet erstellt. Sparrow zeigt dir Empfangsadressen. Vertraue ihnen nicht. Nicht weil Sparrow kompromittiert wäre. Sondern weil du es nicht wissen kannst.
Ein Angreifer, der deinen Computer kontrolliert, könnte eine modifizierte Sparrow-Version ausführen. Diese könnte Adressen anzeigen, die zu seinem Wallet gehören, nicht zu deinem Multisig. Du sendest Bitcoin an diese Adresse. Der Angreifer hat sie. Dein Multisig hat nichts.
Warum jede Adresse auf dem Gerät verifiziert werden muss
Die Hardware-Wallet ist dein Trust Anchor. Sie hat Zugriff auf den privaten Schlüssel und kann die korrekte Adresse berechnen. Wenn die Adresse auf dem Display des Hardware-Wallets mit der Adresse in Sparrow übereinstimmt, weißt du: Diese Adresse gehört zu deinem Multisig.
Receive-Tab in Sparrow öffnen
Navigiere zu Receive. Sparrow generiert eine neue Empfangsadresse aus deinem 2-of-3 Multisig.
„Display Address“ auf Hardware-Wallet
Klicke „Show Address on Device“ oder „Verify on Hardware Wallet“. Verbinde eines deiner Geräte (BitBox02, Trezor oder Ledger).
Exakter Zeichenvergleich
Vergleiche die Adresse auf dem Geräte-Display mit der Adresse in Sparrow. Jedes Zeichen. Groß/Kleinschreibung (bei Bech32 nur Kleinbuchstaben). Keine Abweichung akzeptabel.
Erst dann: Adresse verwenden
Nur wenn die Adresse auf dem vertrauenswürdigen Geräte-Display verifiziert wurde, darfst du sie für Einzahlungen verwenden.
Wenn ein Angreifer Sparrow kompromittiert und eine falsche Adresse einfügt (z.B. einen seiner eigenen xpubs statt deines Ledger-xpubs), kann das Gerät die korrekte Adresse nicht berechnen. Die Adresse auf dem Geräte-Display weicht ab. Du erkennst den Angriff, bevor Bitcoin verloren gehen.
Verifikation schützt dein Setup vor Manipulation, aber Adress-Wiederverwendung kompromittiert deine Privatsphäre. Unser Privacy Basics Dossier zeigt die vollständige OpSec-Architektur.
Recovery-Audit: Der Ledger-Ausfall
Theorie ist schön. Aber hast du dein Setup jemals unter Stress getestet? Simuliere jetzt den Ausfall eines Geräts. Das ist keine Übung. Das ist eine Pflicht.
Szenario: Ledger defekt, nur BitBox + Trezor + Descriptor
Dein Ledger ist vom Tisch gefallen und zeigt nur noch ein weißes Display. Du hast den Ledger-Seed auf Stahl gesichert. Du hast den Descriptor. Du hast BitBox02 und Trezor Safe 5 intakt. Die Aufgabe: Bewege die Bitcoin in ein neues Setup.
Neues Sparrow-Setup erstellen
Auf einem sauberen Rechner: Sparrow installieren. File → Import Wallet → Wähle deine gesicherte Sparrow-Konfigurationsdatei oder importiere den Descriptor manuell.
Wallet-Rekonstruktion via Descriptor
Sparrow liest den Descriptor und rekonstruiert die Wallet mit allen drei Keystores. Die Adressen sind wieder sichtbar. Der Saldo wird angezeigt (nach Sync mit einem Electrum-Server oder Bitcoin Core).
BitBox02 und Trezor verbinden
Verbinde BitBox02 und Trezor Safe 5 via USB. Sparrow erkennt beide als Keystores. Die Fingerprints müssen übereinstimmen.
Ledger: Watch-Only bleibt
Der Ledger-Keystore ist im Descriptor enthalten. Er bleibt als Watch-Only-Key. Du brauchst den Ledger nicht zum Signieren – du hast BitBox02 und Trezor. Das sind 2 von 3.
Transaktion erstellen und signieren
Erstelle eine Transaktion an eine neue Adresse (z.B. ein frisches 2-of-3 mit einem Ersatz-Gerät). Signiere mit BitBox02 → Bestätigung auf dem Gerät. Signiere mit Trezor Safe 5 → Bestätigung auf dem Gerät. Broadcast.
Du hast bewiesen, dass dein Backup funktioniert. Der Ledger war komplett unbrauchbar. Sein Seed wurde nicht einmal benötigt, um die Bitcoin zu bewegen. Das ist die Macht von 2-of-3. Jetzt weißt du: Wenn ein Gerät ausfällt, bist du nicht hilflos.
Die Multisig-Backup-Formel
Redundanz existiert nicht auf dem Papier. Sie existiert in der physischen Welt. Ein 2-of-3 Setup, bei dem alle drei Seeds im Tresor neben dem Router liegen, ist kein 2-of-3. Es ist ein Desaster, das auf seinen Moment wartet.
Das Gesetz der physischen Trennung
Niemals alle drei Seeds am selben Ort. Niemals alle drei Geräte am selben Ort. Ein Einbruch, ein Brand, eine Beschlagnahmung darf maximal einen Seed und ein Gerät kompromittieren. Das ist die Minimalbedingung für operative Sicherheit.
| Item | Primärer Ort | Redundanz |
|---|---|---|
| Seed #1 (BitBox02) | Heimtresor | keine Zweitkopie |
| Seed #2 (Trezor) | Bankschließfach | keine Zweitkopie |
| Seed #3 (Ledger) | Vertrauensperson (andere Stadt) | keine Zweitkopie |
| Descriptor (Papier) | Heimtresor | Bankschließfach, verschlüsselte Ablage |
| Descriptor (Digital) | Encrypted USB | Encrypted Cloud (Proton Drive / Tresorit) |
Eigene Empfehlung: Die Verteilung ist unsere Zusammenstellung und an die eigene Lage anzupassen. Die Seeds bekommen bewusst keine Zweitkopie — bei 2-von-3 ist das Quorum selbst die Redundanz, wie das Recovery-Audit weiter oben zeigt: Dort fällt ein Gerät vollständig aus, und sein Seed wird nicht einmal gebraucht. Nur der Descriptor darf mehrfach liegen: Er ist kein Schlüssel und bewegt für sich genommen nichts
Der Descriptor ist kein Schlüssel und bewegt nichts, aber er verrät alle Adressen der Wallet und damit Saldo und jede Bewegung. In die Cloud gehört er deshalb nur verschlüsselt.
Niemals alle drei Seeds am selben physischen Ort aufbewahren. Niemals alle drei Geräte am selben Ort lagern. Die physische Trennung ist das, was Multisig von einer Illusion zu einer Festung macht.
Heimtresor
Schneller Zugriff. Einbruchrisiko. Feuerrisiko. 1 Seed + 1 Gerät + Descriptor.
Bankschließfach
Physisch sicher. Zugriff nur zu Banköffnungszeiten. 1 Seed + 1 Gerät + Descriptor-Kopie.
Ausland / Jurisdiktion
Schutz vor lokaler Beschlagnahmung. Erschwerter Zugriff. 1 Seed oder 1 Gerät.
Gegenüberstellung, keine Messgröße: Vor- und Nachteile der drei Lagerorte sind unsere Einordnung
Architektur: Unangreifbar.
Ein Multisig funktioniert nur mit Hardware, der du vertrauen kannst. Jeder Signer in deinem Quorum muss den BitAtlas Select Standard erfüllen. Keine Kompromisse.
BitAtlas Select Archiv →