Multisig und Mnemonic Split

Viele haben sicherlich schon einmal von einer sogenannten „Multisig-Wallet" gehört. Doch wie funktioniert das eigentlich und was muss man beachten? Und was ist eigentlich ein sogenannter Mnemonic Split? Dieser Beitrag liefert die Antworten.

Findet bei besagter 2/3 Aufteilung ein Angreifer eines der Backups kennt er 16 von 24 Wörtern. Das ist natürlich immer noch besser als alle auf einmal zu finden, allerdings geht man dennoch einen Kompromiss ein. Acht Wörter zu erraten ist schließlich einfacher als die vollen 24, wie es bei einer Multisig-Wallet der Fall wäre.

Bei 8 fehlenden Wörtern beträgt die Entropie nur noch ungefähr 80 Bit, also muss ungefähr 2⁸⁰ mal geraten. Das ist eine Zahl, die um ein Vielfaches kleiner ist als bei den vollen 24 Wörtern mit 256 Bit Entropie und damit auch weniger Sicherheit bedeutet. 

Für den Anwendungszweck einen Einbrecher davon abzuhalten innerhalb von Sekunden mit dem Smartphone die eigene Wallet leerzuräumen ist es aber dennoch vollkommen ausreichend.

Aus unserer Mnemonic (den 12 oder 24 Wörtern) können wir den Seed und damit auch alle „darunter“ liegenden Schlüssel ableiten. Aus jedem Private Key kann ein Public Key abgeleitet, und aus diesem wiederum eine Adresse berechnet werden. Man benötigt, um eine einzelne Adresse zu generieren, also nur den entsprechenden Public Key, keinen Private Key.

Um also alle Adressen einer Wallet zu kennen bzw. um neue Adressen generieren zu können müssen wir auch alle Public Keys, also alle öffentlichen Schlüssel kennen. Die einzelnen Public Keys der Adressen stehen im Ableitungspfad (Derivation Path) ganz am Ende. Darüber liegen “mächtigere” Schlüssel, aus denen die Public Keys der Adressen abgeleitet wurden.

Einer dieser Schlüssel ist der xpub, der Extended Public Key oder auch erweiterte öffentliche Schlüssel. Mit ihm ist es möglich alle öffentlichen Schlüssel und damit auch alle Adressen eines Accounts abzuleiten, wie ein Generalschlüssel in einem Wohngebäude.

Allerdings kann man mit diesem Schlüssel natürlich nur öffentliche Adressen ableiten, es besteht also kein Risiko etwas zu verlieren, da man mit dem xpub keinen Zugriff auf private Schlüssel erhält. Am xpub hängt deshalb auch nur die Privatsphäre des gesamten Accounts, da man mit allen Adressen auch alle Transaktionen und Bestände nachvollziehen kann. Deswegen sollte man trotzdem nicht leichtsinnig mit ihm umgehen.

Man kann den xpub auch auf dem Smartphone in Software (z.B. BlueWallet) als sogenannte watch-only Wallet importieren, um immer Zugriff auf Adressen und den Kontostand zu haben. Wenn man seine Hardware-Wallet mit der BitBoxApp, Ledger Live oder Electrum verwendet, gibt die Hardware auch ganz automatisch den xpub an die Software auf dem Rechner weiter, damit diese eure Transaktionen und Adressen überhaupt anzeigen kann.

Die Funktion einer Multisig ist zunächst gar nicht so kompliziert: Um eine gültige Transaktion zu erstellen brauchen wir nicht, wie bisher, nur eine Signatur mit dem privaten Schlüssel der Adresse, sondern mehrere Signaturen mit mehreren privaten Schlüsseln.

Wir führen also eine Mehrfaktorauthentifizierung über die Signaturen ein. Die Idee ist, dass jede Signatur von einem anderen Seed abhängig ist, also von anderen Wiederherstellungswörtern und wir damit mehrere Backups benötigen, um an unsere Bitcoin zu kommen – oder besser ausgedrückt: um an alle benötigten Private Keys für die gültigen Signaturen zu kommen.

Dabei ist es völlig egal, wie die unterschiedlichen Seeds generiert wurden, also ob mit einer Hardware Wallet, in einfacher Software oder mit dem Würfel. Die Schlüssel sind untereinander nicht miteinander verknüpft oder voneinander abhängig, sondern nur die Adressen. Das ist ein super Sicherheitsvorteil, den wir ausnutzen können, z.B. durch die Verwendung unterschiedlicher Hardware-Wallets.

Die Besonderheit ist, dass wir die Anzahl der Schlüssel um Adressen zu generieren (n) und die Anzahl benötigter Schlüssel für eine Signatur (m) frei wählen können. Wir brauchen also m von n (m/n) Schlüssel bzw. Backups, um Zugang zu unseren Bitcoin zu erlangen. Typischerweise wählt man ein Setup mit zwei von drei Schlüsseln (2/3), also werden von insgesamt drei Schlüsseln nur zwei benötigt, um eine Transaktion zu unterschreiben, allerdings alle drei, um die entsprechenden Adressen zu generieren.

• Jemand besitzt alle n Schlüssel, generiert diese aber auf unterschiedlicher Hardware, um einen „single point of failure“ auszuschließen.
• Jemand besitzt alle n Schlüssel, lagert diese aber an unterschiedlichen Orten, die nicht voneinander abhängig sind, um das Diebstahlrisiko stark zu reduzieren. Ein Angreifer muss m Schlüssel finden und eure Adressen kennen, um den Diebstahl durchzuführen.
• Alle Schlüssel sind auf n Personen verteilt, beispielsweise um bei einem Familienaccount sicherzustellen, dass ausreichend viele Mitglieder der Familie (m) mit einer Transaktion einverstanden sind.

Der größte Vorteil einer m/n Aufteilung gegenüber einer einfachen n/n Aufteilung ist trivial: Verlieren wir bei einer 2/3 Aufteilung ein Backup (z.B. durch Diebstahl, Naturgewalten oder sogar Beschlagnahmung), haben wir immer noch zwei Backups, mit denen wir ohne Probleme Zugang zu unserer Wallet haben. Wir schlagen also einen Kompromiss zwischen dem Vorteil der Aufteilung der Backups und dem Nachteil des damit verbundenen Verlustrisikos.

• 2/2: Sparaccount zwischen Ehepartnern, beide müssen sich über eine Transaktion einig sein, da beide Schlüssel benötigt werden.
• 2/2: Lightning Netzwerk: Zwei Personen eröffnen einen Channel und sichern durch die Multisig Transaktion ihre Bitcoin on-chain ab.
• 2/2: Sicherere Lösung für Anbieter von Hot-Wallets. Beispiel hierfür ist die Green Wallet von Blockstream, bei der einer von zwei Schlüsseln bei Blockstream verwahrt wird und der Nutzer über 2FA (Zweifaktorauthentifizierung) eine Transaktion unterschreiben lassen kann.
• 2/3: Sparaccount von Eltern für das Kind, beide Eltern müssen sich über eine Transaktion einig sein, das Kind muss sich, sobald es dazu in der Lage ist, aber nur mit einem Elternteil über eine Transaktion einig sein.
• 2/3: Sichere cold-storage für einen einzelnen Nutzer mit Backups an verschiedenen Orten (Unser oben erklärter Anwendungsfall)

Was die Komplexität betrifft, gibt es kaum Grenzen und man kann der eigenen Fantasie freien lauf lassen, wie die eigenen Bitcoin gesichert werden sollen und an welche Ausgabebedingungen man sie knüpfen möchte.

Zurück zu unserem Anwendungsfall. Grundsätzlich gilt: Sicherheit kostet!

Auch wenn uns Mehrfaktorauthentifizierung zunächst mehr Sicherheit bietet, kombinieren wir gleichzeitig die Kosten und Nachteile aller Faktoren. Das gilt neben Multisig genauso für den oben erklärten Mnemonic Split, aber auch für sonstige Sicherheitsfunktionen wie der optionalen Passphrase.

Konkret im Fall einer m/n Aufteilung der Backups (egal ob Multsig oder Split) bedeutet dies:

• Erhöhtes Verlustrisiko durch die Aufteilung auf verschiedene Backups und damit einhergehend verschiedene Orte. Fallen mehr als n - m Backups bzw. Orte aus, führt dies zum Totalverlust.
• Erhöhtes Verlustrisiko durch die Komplexität und Fehleranfälligkeit. Im Fall der Multisig ist auch die Benutzung selbst deutlich komplexer und schränkt die Praktikabilität zusätzlich ein.
• Je mehr Backups n, desto höher die Komplexität und Fehleranfälligkeit (und damit das Verlustrisiko).
• Verlust eines einzigen Backups führt zum Verlust der Adressen, da wir alle n xpubs bzw. alle n Master Public Keys brauchen, um Adressen zu generieren. Hat man keinen Zugang mehr zu seinen Adressen bzw. seinen UTXO kann man trotz ausreichender Schlüsselanzahl keine Transaktion erstellen. Im nächsten Abschnitt schauen wir uns dieses Risiko genauer an und minimieren es.

Einer der größten Stolpersteine beim Einrichten einer Multisig ist das Verwalten der Backups. Wir schauen uns das mal am Beispiel der klassischen 2/3 Multisig an:

Während man für eine gültige Signatur nur zwei der drei Schlüssel benötigt werden die Adressen trotzdem aus allen drei Schlüsseln abgeleitet. Das bedeutet: Wenn man ausschließlich zwei Backups hat kann man seine Bitcoin nicht wiederherstellen, auch wenn man theoretisch eine Transaktion unterschreiben kann. Letzteres bringt einem nämlich nichts, wenn man die eigenen Adressen bzw. Public Keys nicht kennt.

Deswegen: Auf jedem Backup müssen stets alle drei Extended Public Keys stehen! Natürlich hat man im Normalfall Zugang zur Software, in der sowieso alle drei xpubs hinterlegt sind, aber bei Backups geht es ja nunmal nicht um „den Normalfall“, sondern um den Notfall.

Jetzt könnte man den Einwand bringen, dass man durch das Aufschreiben aller drei xpubs auf einem Backup Privatsphäre verliert. Das ist richtig, findet jemand ein einzelnes Backup, kann er den Besitz und alle Transaktionen nachvollziehen (auch wenn er keinen Zugriff hat). Gerade für Backups die bei einem Verwandten oder einem Freund liegen könnte dieses Argument relevant sein.

Deshalb: Man kann die xpubs, genau wie die mnemonischen Phrasen, ebenfalls 2/3 auf die Backups aufteilen, sodass man mit 2/3 Backups immer 3/3 xpubs hat, aber mit 1/3 Backups nur 2/3 xpubs. Außerdem sollte man auf jedem Backup den verwendeten Derivation Path sorgfältig notieren, dieser könnte zum Beispiel so aussehen: m/48'/0'/0'/2'

Konkret würden die drei Backups in diesem Beispiel dann so aussehen:

So muss immer nur ein xpub pro Backup notiert werden, da aus der Mnemonic automatisch auch der entsprechende xpub folgt. Natürlich nur, wenn das Thema Privatsphäre ein relevantes Risiko darstellt, denn ansonsten schreibt man einfach immer alle drei auf.

Überprüft die xpubs vor dem Sichern zuerst auf dem Display eurer Hardware-Wallet. Wenn ihr von Hand notiert, überprüft anschließend die xpubs nochmal auf Richtigkeit, indem ihr versucht eine watch-only Wallet mit den drei notierten xpubs zu erstellen. Ansonsten ist es kein Problem, die xpubs (auch mit QR-Code) einfach auszudrucken.