153 / 736VAULT

Bitcoin Vault

Auszahlungen mit Zeit zum Eingreifen

Was wäre, wenn ein gestohlener Schlüssel nicht ausreichte, um Ersparnisse sofort zu stehlen? Bitcoin Vault schafft zwischen Beginn und Abschluss einer Auszahlung Zeit zum Eingreifen. Entscheidend ist, wer diesen Weg umgehen kann und wer rechtzeitig reagiert.

Bitcoin Vault ist ein Verwahrungsmodell, bei dem eine normale Auszahlung eine Wartephase durchläuft. Währenddessen können die Mittel über einen vorgegebenen Rettungsweg umgeleitet werden. Das soll dem Eigentümer Zeit geben, auf einen Schlüsseldiebstahl zu reagieren. Die Modelle unterscheiden sich; die Bezeichnung vault in einer App garantiert diesen Schutz nicht.

Anna hält einen Teil ihrer Ersparnisse in Bitcoin. 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. Bei einer gewöhnlichen Wallet mit einem einzigen Schlüssel kann ein Dieb mit diesem Schlüssel sofort eine Zahlung an seine eigene Adresse signieren. Bitcoin Vault soll das ändern: Der Schlüssel für alltägliche Auszahlungen startet zunächst einen Vorgang, und Anna erhält eine Gelegenheit zur Rettung. Das erinnert an einen Tresor mit Wartezeit und Notausgang. Der Vergleich gilt aber nur, wenn die Ausgabebedingungen im Netzwerk diese Beschränkungen tatsächlich erzwingen. Ein Timer in der App genügt nicht. Auch eine Hardware Wallet, die Signierschlüssel schützt, ist nicht automatisch ein Vault; sie sichert einen anderen Teil des Ablaufs ab. [1] [6]

Ein Transaktionsausgang hält einen Betrag und die Bedingungen fest, unter denen er später ausgegeben werden darf. Bitcoin erfasst ausgebbare Transaktionsausgänge, sogenannte UTXO. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. In einem einfachen Modell gibt die erste Transaktion den verwahrten Ausgang aus und erzeugt einen neuen mit einer Wartebedingung. Dieser erste Schritt heißt unvault. Die endgültige Zahlung kann erst später folgen, während ein Rettungspfad einen früheren Eingriff erlaubt. Wird der Zwischenausgang im Block H bestätigt und beträgt die Verzögerung 144 Blöcke, ist der normale Weg frühestens in H+144 nutzbar, sofern auch die übrigen Bedingungen erfüllt sind. Das sind nicht exakt 24 Stunden, denn Blöcke folgen keinem Fahrplan. Eine abgeschlossene Zahlung wird auch nicht zurückgebucht: Die Rettungstransaktion muss vor der endgültigen Ausgabe bestätigt sein. [1] [5] [7]

Anna bemerkt eine Auszahlung, die sie nicht veranlasst hat. Nun braucht sie funktionierende Netzwerküberwachung, eine gültige Rettungstransaktion und Mittel für deren Gebühr. Ein Mempool hält unbestätigte Transaktionen bereit; dort aufgenommen zu werden reicht nicht. Überlastung oder pinning, bei dem Angreifer das Ersetzen oder Bestätigen einer Transaktion erschweren, können die Reaktion verzögern. Revault sieht CPFP vor: Eine Folgetransaktion erhöht die Gebühr und schafft einen Anreiz, beide gemeinsam zu bestätigen. Bestimmte Rettungstransaktionen nutzen ALL | ANYONECANPAY, einen Signaturmodus für zusätzliche Eingänge, also Verweise auf weitere ungenutzte Beträge, aus denen die Gebühr bezahlt wird. Das sind Werkzeuge eines konkreten Modells, keine Zusage rechtzeitiger Bestätigung. Historische Gebührenangaben der Spezifikation sind keine heutige Empfehlung. [1] [4]

Eine Schutzüberweisung kann den Dieb stoppen und Anna trotzdem ein anderes Problem hinterlassen: Die Zielwallet muss später nutzbar sein. Ihre Adresse zu kennen genügt nicht. Anna benötigt die erforderlichen Schlüssel, die Beschreibung der Bedingungen und gegebenenfalls vorbereitete Transaktionen. Einen Schutztransfer auslösen zu dürfen ist außerdem etwas anderes, als vom Ziel ausgeben zu dürfen. Ein Überwachungsdienst kann die erste Befugnis erhalten, ohne die zweite zu bekommen. Ein zu leicht auslösbarer Rettungsweg kann allerdings wiederholt legitime Auszahlungen vereiteln. Ein gutes Modell berücksichtigt daher neben Diebstahl auch die Wiederherstellung des Zugangs und den Missbrauch des Schutzmechanismus. [1] [4]

Manche Vaults verwenden heutige Regeln und vorab signierte Transaktionen. Die nötigen Signaturen entstehen bei der Einrichtung; anschließend kann die Sicherheit vom Löschen einmaliger Schlüssel oder von unabhängigen Mitunterzeichnern abhängen, die andere Wege verweigern. Das Netzwerk kann nicht prüfen, ob wirklich jede Schlüsselkopie gelöscht wurde. Eine versteckte Kopie kann den Schutz umgehen. Auch zur Sicherung kann mehr als eine Seed Phrase gehören, also die Wörter zur Ableitung der Walletschlüssel. Daraus lässt sich eine fehlende Signatur eines bereits gelöschten einmaligen Schlüssels möglicherweise nicht neu erzeugen. Vorab signierte Transaktionen und ihre Daten können daher unverzichtbare Wiederherstellungsunterlagen sein. [1] [4]

Revault zeigt, dass die Frage nach dem Schlüsselbesitz nur der Anfang ist. Stakeholders haben die maßgeblichen Befugnisse; managers verwalten normale Auszahlungen und cosigning servers unterzeichnen diese mit. Die Einzahlung verlangt N-of-N, also alle vorgesehenen Stakeholder-Signaturen: Multisig bedeutet hier gemeinsame Freigabe mit mehreren Schlüsseln. Der Zwischenausgang lässt sich über den Stakeholder-Pfad oder nach X Blöcken über managers und Server ausgeben. Cancel führt ihn zu den ursprünglichen Einzahlungsbedingungen zurück; ein Nottransfer führt zum Emergency Deep Vault. Stakeholders verfügen auch über einen direkten bypass. Wer alle ihre Schlüssel erlangt, muss nicht warten. Diese Aufteilung gilt für diese Spezifikation, nicht für jeden Vault. [4]

Ein BIP dokumentiert einen Bitcoin-Vorschlag oder Standard; seine Nummer bedeutet keine Aktivierung. Bei der Prüfung am 17. Oktober 2026 steht BIP 345 auf Closed und nennt BIP 443 als Proposed-Replacement. Der ursprüngliche Vorschlag verband OP_VAULT und OP_VAULT_RECOVER mit OP_CHECKTEMPLATEVERIFY, Anweisungen zur Einschränkung von Auszahlungswegen. BIP 443 schlägt das allgemeinere OP_CHECKCONTRACTVERIFY, kurz OP_CCV, vor und bleibt Draft; der Aktivierungsmechanismus ist offen. Auch BIP 119 zu OP_CHECKTEMPLATEVERIFY ist Draft. Sie gehören zur Diskussion über Covenants, Beschränkungen der weiteren Verwendung eines Ausgangs. Veröffentlichter Code oder eine Vorführung belegen nicht, dass das mainnet, Bitcoins Hauptnetzwerk, den Schutz erzwingt. [1] [2] [3]

Bevor Anna einem Vault Ersparnisse anvertraut, muss sie normale Auszahlung, Rettung und jeden bypass verstehen. Praktische Versuche gehören in eine getrennte Testumgebung: normale Auszahlung, vorzeitiger Versuch, unerwartetes unvault, ausgefallene Überwachung und fehlende Gebührenmittel. Eine gültige Signatur, die Aufnahme in den Mempool und die Bestätigung in einem Block sind zu unterscheiden. Eine erfolgreiche Vorführung prüft nicht alle anderen Pfade. Für Einsteiger ist entscheidend: Ein Vault schafft Reaktionszeit, bringt aber auch Aufgaben mit sich, die jemand zuverlässig erfüllen muss. Dieser Text ist keine Anleitung, echtes Geld einem experimentellen Skript anzuvertrauen. [1] [4]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Selbstverwahrung. Auf diesen Eintrag verweisen außerdem Dead Man’s Switch.

DOC · 001BIP 345 — OP_VAULTSpezifikation DOC · 002BIP 443 — OP_CHECKCONTRACTVERIFYSpezifikation DOC · 003BIP 119 — CHECKTEMPLATEVERIFYSpezifikation DOC · 004Revault — Transaction specificationSpezifikation DOC · 005BIP 112 — CHECKSEQUENCEVERIFYSpezifikation DOC · 006Bitcoin Developer Guide — WalletsDokumentation DOC · 007Bitcoin Developer Guide — Block ChainDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung