↓ Zum Hauptinhalt springen
CypherpunkGuide.
DE

Bitcoin-Multisig-Backup: Was du außer zwei Seeds brauchst

Cora Aegis hält zwei schlüsselförmige Teile und einen Plan der Multisig-Wallet-Konfiguration

Finanzierung: CypherpunkGuide kann über verlinkte Kaufratgeber Vermittlungsprovisionen erhalten. Dieser Artikel enthält keine direkten Affiliate-Kauflinks. Kein Wallet-Anbieter hat diese Arbeit gesponsert.

Die Software, die die Wallet koordiniert hat, ist nicht mehr verfügbar. Ein Signiergerät ist ausgefallen. Zwei Seed-Backups sind noch da, also Sicherungen des Ausgangsmaterials für die privaten Schlüssel. Genau gegen einen solchen Ausfall soll eine 2-von-3-Konfiguration doch schützen.

Das kann sie. Die Zahlen sagen aber nur, wie viele Signaturen nötig sind. Sie beschreiben keinen vollständigen Ablauf zur Wiederherstellung. Entscheidend ist auch, ob sich die Wallet rekonstruieren lässt, für die diese Schlüssel verwendet wurden.

Dieser Artikel behandelt herkömmliche Bitcoin-P2WSH-Wallets mit sortedmulti. Dieses Skript legt fest, wie viele Signaturen aus einer bestimmten Gruppe öffentlicher Schlüssel erforderlich sind. Hardware-Geräte, Taproot-Signaturverfahren und die Wiederherstellung zwischen unterschiedlichen Wallet-Produkten wurden nicht untersucht. Wenn du deine Selbstverwahrung erst aufbaust, beginne mit den Prüfungen für Empfang, Signatur und Wiederherstellung.

Zwei Signaturen ersetzen keine vollständige Wallet-Konfiguration
#

Zwei Signierschlüssel können eine 2-von-3-Bedingung erfüllen. Für die Rekonstruktion der Adressen ist dagegen die vollständige Skriptkonfiguration nötig: alle drei öffentlichen Schlüssel an den jeweiligen Ableitungspunkten, die erforderliche Zahl der Signaturen und der Skripttyp. Drei Schlüssel müssen nicht drei verschiedenen Personen gehören.

Ein Deskriptor beschreibt strukturiert, welche Skripte eine Wallet erkennen soll. Er kann erweiterte öffentliche Schlüssel enthalten, aus denen sich ganze Gruppen öffentlicher Schlüssel ableiten lassen, sowie die dafür verwendeten Pfade. BIP380 erläutert, weshalb alleinige Backups privater Schlüssel Fragen zu Skripttyp und Ableitungspfaden offenlassen können. BIP383 definiert die Multisig-Ausdrücke in Deskriptoren, darunter die Sortierung der abgeleiteten öffentlichen Schlüssel in sortedmulti.

Prüfe drei Arten von Wiederherstellungsinformationen getrennt:

MaterialWas es beiträgtWas es allein nicht belegt
Backups zum SignierenBei korrekter Wiederherstellung die privaten Schlüssel zur AutorisierungWelche vollständige Multisig-Konfiguration die Mittel verwaltete
Wallet-KonfigurationErforderliche Signaturzahl, öffentliche Schlüssel aller Beteiligten, Skripttyp und AbleitungsinformationenDass genügend private Schlüssel zum Signieren vorhanden sind
Bedingungen für die SucheZu durchsuchende Zweige und Adressbereiche sowie relevante historische DatenEine vollständige, gültige Signatur

Eine Wallet-Datei kann mehrere dieser Angaben gemeinsam speichern. Ein Deskriptor kann einen großen Teil der Konfiguration erhalten. Entscheidend ist, was der Export tatsächlich enthält und ob die Wiederherstellungssoftware dieses Format versteht. Dateiname und Prüfsumme beantworten diese Frage nicht.

Die Implementierung von Sparrows Backup-Dialog nennt ausdrücklich die benötigten Seeds und sämtliche erweiterten öffentlichen Schlüssel. Als Konfigurationsbackup nennt sie eine Wallet-Datei oder einen Deskriptor. Das ist eine Beobachtung aus dem Quellcode, kein Praxistest der aktuellen Oberfläche oder der Importkompatibilität mit einem anderen Produkt.

Was der isolierte Wiederherstellungstest gezeigt hat
#

Unser Versuch vom 24. September 2026 nutzte den Regtest-Modus von Core 31.1, eine private Test-Blockchain. Getrennt geprüft wurden Adressrekonstruktion, Auffinden einer bestimmten Testausgabe, vollständige Signatur und Annahme durch den lokalen Knoten. Der gemessene Versuchsabschnitt dauerte 13,3 Sekunden. Die anfänglichen Versions- und Hash-Prüfungen sowie das abschließende Herunterfahren und Aufräumen sind darin nicht enthalten. Es kamen öffentlich bekannte Testdaten und keine echten Mittel zum Einsatz. Am Ende war die Verbindung zu anderen Knoten deaktiviert; die Zahl der Verbindungen betrug null.

Für jeden der ersten fünf Fälle wurde die Konfiguration in einer eigenen, neu angelegten Beobachtungs-Wallet rekonstruiert. Die gesuchte Transaktionsausgabe — ein einem Empfänger zugewiesener Betrag — betrug 0,01000000 Regtest-BTC. Die Schlüssel A, B und C wurden aus veröffentlichten Testeingaben abgeleitet. Seeds wurden dabei nicht auf einem Hardware-Gerät eingegeben.

Bereitgestelltes MaterialGleiche Empfangsadressen?Bestimmte Testausgabe gefunden?Signatur vollständig?Annahmeprüfung am lokalen Knoten
Vollständige Konfiguration + A/BJaJaJaAngenommen
Vollständige Konfiguration + A/CJaJaJaAngenommen
Vollständige Konfiguration + B/CJaJaJaAngenommen
Vollständige Konfiguration + nur AJaJaNeinAbgelehnt
Nur öffentliche KonfigurationJaJaNeinAbgelehnt
Ersatz durch 2-von-2 ohne CNeinKein Guthaben gefundenNicht geprüftNicht geprüft
Falscher äußerer SkripttypNeinKein Guthaben gefundenNicht geprüftNicht geprüft
Falscher AbleitungszweigNeinKein Guthaben gefundenNicht geprüftNicht geprüft

Bei den letzten drei Fällen verglichen wir die zuvor mit dem Testbetrag belegte Empfangsadresse am Index 1. Im importierten Bereich wurde kein Wallet-Guthaben gefunden. Über Adressen außerhalb dieses Bereichs sagt das nichts aus. Auch der Fall ohne dritten Schlüssel prüft nicht jede mögliche Wiederherstellung: Der Ersatz von 2-von-3 durch 2-von-2 zeigt eine falsche Rekonstruktion. Ob ein weiteres Backup oder ein historisches Skript helfen könnte, wurde damit nicht untersucht.

Anschließend reichten wir die A/B-Transaktion in der privaten Test-Blockchain ein. Die Wallet mit beiden Ableitungszweigen fand die Wechselgeldausgabe von 0,00599000 Regtest-BTC. Die Wallet, die nur Empfangsadressen überwachte, hatte die ursprüngliche Testzahlung erkannt, fand aber dieses Wechselgeld nicht. Der Vergleich betraf genau diese Ausgabe. Er bedeutet nicht, dass das gesamte Guthaben der reinen Empfangs-Wallet auf null fiel; im Versuch gab es zusätzlich Mining-Ausgaben. Ein Deskriptor mit absichtlich beschädigter Prüfsumme wurde ebenfalls abgelehnt. Prüfungen des unveränderten Deskriptors unmittelbar davor und danach waren erfolgreich.

Zum Artikel gehören das Versuchsskript, die Messwerte, die Sicherheits-Regressionsprüfungen und eine leere Checkliste zur Wiederherstellung. Der importierte Adressbereich reichte von 0 bis 2; für die erneute Suche in der Blockchain war der Startzeitpunkt auf 0 gesetzt. Die Signaturtests verwendeten abgeleitete private Testschlüssel sowie korrekte Angaben zum Skript und zur vorherigen Ausgabe aus der vollständigen Referenz-Wallet. Sie belegen weder eine vollständige Seed-Wiederherstellung noch die Wiederherstellung einer Hardware-Wallet oder die Kompatibilität zwischen Produkten. Die lokale Annahmeprüfung verbreitet keine Transaktion. Aus diesem kontrollierten Versuch lassen sich auch keine Erfolgsquoten für reale Wiederherstellungen ableiten.

Voraussetzungen und Befehl zum Nachstellen stehen in den Versuchsnotizen. Verwende diese öffentlich bekannten Testschlüssel niemals für echte Mittel.

Guthaben finden und Guthaben ausgeben sind getrennte Prüfungen
#

Eine wiederhergestellte Wallet kann eine Ausgabe erkennen, ohne sie ausgeben zu können. Umgekehrt kann ein erwartetes Guthaben unsichtbar bleiben, weil die Suchbedingungen unvollständig sind.

Empfangs- und Wechselgeldadressen verwenden häufig unterschiedliche Ableitungszweige. Fehlen die Wechselgeldskripte in der wiederhergestellten Beschreibung, kann eine Zahlung den verbleibenden Betrag an eine Adresse verschieben, die diese Wallet nicht erkennt. Das Klassifizierungsmerkmal internal ist für sich genommen nicht gleichbedeutend damit, einen Zweig ein- oder auszuschließen.

Die Implementierung und Hilfe zum Deskriptorimport in Core unterscheiden Importzeitpunkt, Adressbereich und interne Klassifizierung. Auch Synchronisierung und verfügbare historische Blöcke können eine Rolle spielen. Eine Null in der Anzeige ist ein Anlass zur Untersuchung. Sie beweist für sich allein keinen Verlust der Coins.

Deshalb genügt weder eine erfolgreiche Importmeldung noch ein Feld namens solvable. Maßgeblich für die Signatur ist eine vollständig signierte Transaktion, die die Skriptbedingungen erfüllt. Ein lokaler Regtest belegt Verhalten unter diesen Testbedingungen. Er ist keine Bestätigung im Bitcoin-Hauptnetz und kein Kompatibilitätstest für Geräte.

Auch öffentliche Wallet-Daten brauchen Schutz
#

Ein rein öffentlicher Deskriptor kann allein nicht signieren. Er kann jedoch die Adressen offenlegen, die sich aus seinen öffentlichen Schlüsseln und Pfaden ableiten lassen. Wer diese Angaben erhält, kann möglicherweise Guthaben und Transaktionen in diesem Adressbereich miteinander verknüpfen.

„Öffentlicher Schlüssel“ ist keine Aufforderung, die Wallet-Konfiguration zu veröffentlichen. Begrenze den Zugriff darauf und unterscheide sie von einem privaten Deskriptor, der private Schlüssel enthalten kann. Es gibt zudem einen Grund, die Offenlegung öffentlicher Schlüssel nicht pauschal als unschädlich für die Mittel zu bezeichnen: BIP32 beschreibt, wie ein erweiterter öffentlicher Elternschlüssel zusammen mit einem nicht gehärtet abgeleiteten privaten Kindschlüssel den privaten Elternschlüssel offenlegen kann.

Diese kombinierte Offenlegung ist etwas anderes als ein öffentlicher Deskriptor allein. Keine der beiden Aussagen macht es sinnvoll, Wallet-Daten zur Fehlerdiagnose in einem Wiederherstellungsforum zu posten. Unser Leitfaden zur Bitcoin-Privatsphäre auf der Blockchain erklärt das weiterreichende Problem verknüpfbarer Transaktionen.

Prüfe den Wiederherstellungsplan, ohne Geheimnisse zu sammeln
#

Eine hilfreiche Bestandsaufnahme hält fest, ob das benötigte Material vorhanden und geprüft ist. Sie sollte keine neue Sammlung von Geheimnissen werden, die leichtfertig weitergegeben wird.

Unsere Vorlage fragt nach der erforderlichen Signaturzahl, dem Konfigurationsbackup, Empfangs- und Wechselgeldzweigen, unterstützten Importformaten sowie getrennten Prüfungen für Auffinden und Signieren. Sie enthält keine Felder für Seed-Wörter, zusätzliche Passwörter (Passphrasen), öffentliche Schlüssel oder echte Deskriptoren. Notiere den Prüfstatus, nicht die Werte.

Nutze das dokumentierte Prüfverfahren deines Wallet- oder Signiergeräteanbieters. Gib echte Seeds weder auf Websites noch in Chats oder in dieses Versuchsskript ein. Die öffentlich reproduzierbaren Testschlüssel sind für echte Mittel ungeeignet. Ein allgemeiner Wiederherstellungstest für verschlüsselte Backups kann belegen, dass gespeicherte Dateien lesbar wiederhergestellt werden können. Er belegt nicht, dass deren Inhalt für eine Ausgabe aus einer bestimmten Bitcoin-Wallet ausreicht.

Mit Multisig musst du mehr Informationen bewahren, Beteiligte oder Geräte koordinieren und zusätzliche Prüfungen durchführen. Wenn du diese Aufgaben nicht verlässlich bewältigen kannst, verbessern weitere Signiergeräte deinen Wiederherstellungsplan nicht automatisch. Dieser Artikel hilft, diese Anforderungen zu prüfen. Er empfiehlt keinen Gerätekauf.

Das solltest du festhalten
#

Fragen zur Wiederherstellung
#

Ist eine Wiederherstellung ohne Deskriptor unmöglich?
#

Nicht unbedingt. Ein anderes kompatibles Wallet-Backup kann die Konfiguration enthalten. Auch ein bekanntes Skript kann einen Teil der Angaben bewahren: Wird eine P2WSH-Ausgabe ausgegeben, legt die Transaktion nach BIP141 das zugehörige Witness-Skript offen. Daraus ergeben sich aber nicht automatisch sämtliche erweiterten öffentlichen Schlüssel oder alle Adressen der Wallet. Welche Wiederherstellung möglich ist, hängt vom verbliebenen Material ab.

Beweist eine gültige Prüfsumme, dass die Konfiguration stimmt?
#

Nein. Die Prüfsumme hilft, Übertragungsfehler in einem Deskriptor zu erkennen. Auch ein anderer Deskriptor kann seine eigene gültige Prüfsumme haben. Gleiche die Konfiguration mit einem vertrauenswürdigen Backup und der Wallet ab, die du wiederherstellen möchtest. Korrekte Syntax ist kein Echtheitsnachweis.

Quellen und archivierte Fassungen
#

Die Aussagen oben stützen sich auf diese Primärquellen. Archivierte Fassungen machen das zitierte Material später nachvollziehbar.

QuelleOriginal-URLArchiv
BIP380Original-URLArchiv
BIP383Original-URLArchiv
Sparrow — MultisigBackupDialog.javaOriginal-URLArchiv
Bitcoin Core 31.1 — backup.cppOriginal-URLArchiv
BIP32Original-URLArchiv
BIP141Original-URLArchiv