155 / 736COLLAB

Collaborative Custody

Eigene Schlüssel mit Unterstützung beim Signieren

Sie möchten Ihr Geld selbst kontrollieren, bei einem verlorenen Schlüssel aber nicht allein dastehen. Collaborative Custody verteilt das Signieren auf mehrere Beteiligte. Entscheidend ist, welche Kombinationen eine Zahlung tatsächlich erlauben.

Collaborative Custody bezeichnet eine Verwahrung, bei der der Eigentümer und eine weitere Person oder ein Dienst gemeinsam Bitcoin absichern. In einem verbreiteten Modell besitzt der Eigentümer genug Schlüssel, um selbstständig zu zahlen; der Dienst hilft bei Problemen. Diese Unabhängigkeit muss sich aus den Wallet-Regeln ergeben, nicht bloß aus dem Produktnamen.

Multisig: Simulator für die SignaturschwellePrüfe, ob die verbleibenden Schlüssel in einem m-von-n-Modell die Signaturschwelle erreichen. Das Ergebnis beschreibt die Verfügbarkeit von Signaturen, nicht die Sicherheit oder vollständige Wiederherstellbarkeit der Wallet.

Peter verwaltet seine Bitcoins in einer eigenen Wallet. Sorgen macht ihm der Verlust eines Geräts oder einer Sicherung. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Unterschreiben bedeutet hier, mit einem privaten Schlüssel, einem geheimen Zahlenwert, einen überprüfbaren Nachweis für die Berechtigung zur Zahlung zu erzeugen. Andere können die Signatur prüfen, ohne diesen geheimen Wert zu kennen. Unchained beschreibt ein 2-of-3-Modell: Für eine Zahlung sind Signaturen von zwei der drei Schlüssel nötig. Peter hält A und B, der Dienst C. Möglich sind A+B, A+C und B+C; C allein reicht nicht. Mehrere Signaturen zu verlangen heißt Multisig. Peter kann ohne Dienst zahlen und bei Verlust eines Schlüssels Hilfe erhalten. Zwei Geräte mit derselben Seed Phrase, also derselben Sicherung in Wörtern, sind jedoch nicht unabhängig: Wird das gemeinsame Geheimnis bekannt, sind beide gefährdet. [1] [4] [8]

Solange Peter A+B nutzen kann und die vollständigen Wallet-Unterlagen hat, verhindert ein Dienstausfall allein keine Zahlung. Bleibt nur A, braucht er für A+C den Dienst. Dessen Ausfall oder Weigerung zu signieren kann die Wiederherstellung blockieren. Verliert er A und B, rettet ihn C allein nicht. Ein unabhängiger Ausstieg und eine unterstützte Wiederherstellung müssen deshalb getrennt erprobt werden. Auch Casas Anleitung zur Wiederherstellung ohne eigene Infrastruktur setzt ausdrücklich voraus, dass der Dienstschlüssel nicht verfügbar ist. Ablauf und Ausrüstung hängen vom Produkt ab; das Wort „collaborative“ verrät sie nicht. [1] [6]

Peter hat seine Sicherungen. Eine Ersatzanwendung muss aber wissen, welche Wallet sie rekonstruieren soll. Bei einem üblichen 2-of-3 braucht sie die öffentlichen Schlüssel aller drei Beteiligten einschließlich des Dienstes und deren Verwendungsregeln. Öffentliche Schlüssel prüfen Signaturen, private erzeugen sie. Ein Output Descriptor beschreibt diese Konfiguration maschinenlesbar, einschließlich der Adressableitung. Zwei eigene Seed Phrase-Sicherungen ersetzen den fehlenden öffentlichen Schlüssel des Anbieters nicht. Peter speichert und prüft den Export, solange der Dienst funktioniert. Vor einer Weitergabe kontrolliert er den Inhalt: Das allgemeine Descriptor-Format kann auch private Schlüssel enthalten. [4] [5]

Ein Koordinator stellt die Transaktionsdaten zusammen; ein Signierer besitzt den Schlüssel zur Freigabe. PSBT, das in BIP 174 beschriebene Format, transportiert eine unfertige Transaktion samt benötigten Angaben zwischen Programmen und Geräten. Eine Datei zu erstellen ersetzt keine fehlende Signatur. Ein Koordinator ohne Schlüssel kann trotzdem schaden, etwa indem er einen anderen Empfänger vorschlägt. Vor dem Signieren sind Adresse, Betrag, Gebühr und change zu prüfen: der Restbetrag, der in die eigene Wallet zurückfließt. Eine Hardware Wallet trennt den Schlüssel vom Computer. Entscheidend bleibt, was ihr Bildschirm überprüfen lässt und was Peter tatsächlich bestätigt. [2] [3]

Schon beim Einrichten der gemeinsamen Wallet kann ein Fehler entstehen. BIP 129 beschreibt den Austausch von Schlüsseln und Konfiguration, damit Beteiligte Signaturschwelle, enthaltene Schlüssel und erste Adresse vergleichen können. Dazu gehören der Skripttyp als Form der Ausgabebedingungen und die Ableitungspfade für weitere Schlüssel. Manipulierte Einstellungen können Einzahlungen umlenken. Das Dokument behandelt jedoch weder den Manipulationsschutz des Gerätespeichers noch spätere Prüfungen von Empfangs- und change-Adressen. Die Unterstützung des Standards bestätigt deshalb nicht die Sicherheit des gesamten Produkts. [2]

Ein XPUB ist ein erweiterter öffentlicher Schlüssel, aus dem öffentliche Schlüssel eines Wallet-Zweigs abgeleitet werden. Kennt ein Anbieter diese Daten und die Konfiguration, kann er unter Umständen Adressen und Zahlungen verfolgen, ohne genug Signaturen zum Ausgeben zu besitzen. Verbindet er sie mit einem Kundenkonto unter echtem Namen, entsteht eine weitere Zuordnung. Privatsphäre und Ausgabeberechtigung sind verschiedene Fragen. Auch die Aussage, der Dienst könne nicht allein zahlen, gilt unter Bedingungen: Er könnte einen weiteren Schlüssel Peters erlangen oder ihn zu einer schädlichen Signatur verleiten. Weniger Befugnisse verringern manche Risiken, beseitigen aber nicht alle. [2] [4]

Peter verliert einen Schlüssel und legt in der Anwendung einen neuen an. Für frühere Einzahlungen wird der alte dadurch nicht ungültig. Ein Transaktionsausgang hält einen Betrag und die Bedingungen fest, unter denen er später ausgegeben werden darf. Die früheren Einzahlungen liegen als UTXOs vor, noch nicht ausgegebene Transaktionsausgänge mit eigenen Ausgabebedingungen. Bei gewöhnlichem Multisig muss Peter neue Bedingungen erstellen und die betroffenen Mittel mit einer bestätigten Transaktion dorthin übertragen. Danach prüft er verbleibende Mittel auf alten Adressen. Ein neues Kontopasswort oder Schlüsseletikett ersetzt diese Übertragung nicht. Auch Konfiguration und Familienanweisungen müssen angepasst werden, damit Erben nicht mit einem überholten Plan arbeiten. [4] [9]

Eine sinnvolle Probe erfolgt mit einer getrennten Test-Wallet. Peter importiert die gespeicherte Konfiguration in kompatible Software, vergleicht Adressen und prüft, ob er ohne den ursprünglichen Dienst mit eigenen Schlüsseln signieren kann. Watch-only zeigt Adressen und Guthaben, beweist aber keine Signierfähigkeit. Caravan ist ein quelloffener Koordinator; die Unterstützung des konkreten Formats und der Geräte muss geprüft werden. Unterstützte Wiederherstellung, ein fehlender Schlüssel, Gebühren und change gehören ebenfalls zur Probe. Das Ergebnis sollten verständliche, dokumentierte Schritte samt Softwareversionen sein, nicht nur ein beruhigender Kontostand. [3] [6] [7]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Multisig, Selbstverwahrung, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. Auf diesen Eintrag verweisen außerdem Bitcoin Inheritance Plan, Institutional custody.

DOC · 001Unchained — Collaborative custody vaultsPrimärquelle DOC · 002BIP 129 — Bitcoin Secure Multisig SetupSpezifikation DOC · 003BIP 174 — Partially Signed Bitcoin Transaction FormatSpezifikation DOC · 004Bitcoin Core — Output DescriptorsDokumentation DOC · 005Unchained — Wallet configuration and recoveryPrimärquelle DOC · 006Casa — Recovery without CasaDokumentation DOC · 007Caravan — Open-source coordinatorPrimärquelle DOC · 008Bitcoin Developer Guide — WalletsDokumentation DOC · 009Bitcoin Developer Guide — Block ChainDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung