Ein Covenant ist eine Bedingung, die nicht nur bestimmen kann, wer Bitcoin ausgeben darf, sondern auch, wie die nächste Übertragung aussehen muss. Beispielsweise könnten die Mittel zuerst einen Output mit einer Wartefrist durchlaufen müssen. Die Einschränkung gehört zu den Ausgaberegeln dieses Outputs und ist nicht bloß eine Einstellung in einer App. Covenants bezeichnet eine Familie von Konstruktionen und Vorschlägen, keine einzelne Funktion jeder Wallet.
Anna spart in Bitcoin. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Das Guthaben ihrer Wallet besteht aus noch nicht ausgegebenen Outputs früherer Transaktionen, den UTXOs. Jeder Output enthält einen Betrag und die Bedingungen für dessen Ausgabe. Diese stehen in einem kurzen Programm namens Bitcoin Script. Eine digitale Signatur weist die Berechtigung zur Zahlung nach. Sie wird mit einem privaten Schlüssel erzeugt, also einem geheimen Zahlenwert, der dabei nicht offengelegt wird. Multisig kann mehrere Signaturen verlangen; ein Timelock fügt eine Wartebedingung hinzu. Ein Covenant kann außerdem die nächste Transaktion einschränken, etwa die Outputs, in die das Geld fließen muss. Auch ein Dieb mit dem richtigen Schlüssel müsste diese Regel erfüllen. Entscheidend sind allerdings sämtliche möglichen Ausgabepfade: Lässt ein anderer Zweig die Umgehung zu, kann man sich auf die Einschränkung nicht verlassen. [1] [5] [9] [11]
Stellen wir uns vor, Anna legt ihre Ersparnisse in einen Tresor mit Wartefrist. Tresor meint hier kein besonderes Gerät, sondern eine Anordnung von Ausgaberegeln. Ihr Alltagsschlüssel könnte eine Auszahlung starten, doch das Geld würde zunächst in einen wartenden Output gelangen. Erst nach Ablauf der Frist dürfte es zum vorgesehenen Empfänger weiterfließen. Startet ein Dieb die Auszahlung, könnte Anna während der Wartezeit einen vorbereiteten Rettungspfad nutzen und die Mittel unter sicherere Bedingungen verschieben. Sie muss den Vorgang jedoch bemerken und die Rettungstransaktion rechtzeitig in einem Block bestätigen lassen. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Eine abgeschlossene Zahlung wird damit nicht rückgängig gemacht; ohne Eingreifen werden die Mittel auch nicht automatisch gerettet. Die genauen Möglichkeiten hängen vom Tresorentwurf ab. [6] [10]
Verspricht eine App, mit der Auszahlung zu warten, kann das lediglich eine Zusage ihres Betreibers sein. Eine Regel im Bitcoin-Skript prüfen dagegen die Nodes: Programme, die Transaktionen anhand der gemeinsamen Netzwerkregeln verifizieren. Bei einer entsprechenden Covenant-Konstruktion müssen sie eine Übertragung ablehnen, die gegen die Einschränkung verstößt. Ein vorgeschlagenes Werkzeug ist OP_CHECKTEMPLATEVERIFY, kurz CTV, beschrieben in BIP119. Ein BIP ist ein Dokument mit einem Vorschlag für Bitcoin. CTV würde den Hash ausgewählter Daten der geprüften Transaktion mit einem vorab hinterlegten Fingerabdruck vergleichen. Ein Hash ist hier ein kurzer, überprüfbarer Datenfingerabdruck. Ein anderer vorgeschriebener Empfänger oder Betrag würde ihn verändern; die abweichende Transaktion bestünde die Prüfung nicht. Die Bezeichnung „Tresor“ in einer App allein bietet diese Durchsetzung nicht. [2]
CTV bindet eine Transaktion an eine vorbereitete Vorlage einschließlich ihrer Outputs. Daneben werden andere Ansätze untersucht. BIP443 schlägt OP_CHECKCONTRACTVERIFY für Outputs vor, die eine überprüfbare Bindung an bestimmte Daten tragen. Diese Bindung, ein Commitment, verhindert, dass später unbemerkt ein anderer Wert eingesetzt wird. Die Daten können den Zustand eines Vertrags beschreiben, etwa die aktuelle Aufteilung gemeinsamer Mittel. Der nächste Output könnte dann einen aktualisierten Zustand tragen, sofern die vorgeschriebenen Regeln erfüllt sind. CTV und dieser Vorschlag sind deshalb keine zwei Namen derselben Sache. Bei jedem Entwurf ist zu klären, was vorher feststehen muss, was später geändert werden darf und welche weiteren Werkzeuge die vollständige Konstruktion benötigt. [2] [7]
Eine rekursive Konstruktion kann verlangen, dass der nächste Output erneut eine bestimmte Einschränkung trägt. Die Regel setzt sich dadurch über mehrere Transaktionen fort, etwa während sich ein Vertragszustand schrittweise ändert. Gemeint ist keine Endlosschleife bei der Prüfung eines einzelnen Skripts. Russell O’Connor und Marta Piekarska beschrieben solche Konstruktionen in ihrer Arbeit von 2017. Ob Wiederholung möglich ist, hängt vom konkreten Vorschlag ab. [3]
Manche Einschränkungen lassen sich mit vorab signierten Transaktionen, Zeitsperren und Schlüsselverwaltung vorbereiten. Dabei können zuverlässiges Löschen eines Schlüssels, Aufbewahrung aller Transaktionen oder weitere Zusammenarbeit nötig sein. Ein Multisig, bei dem ein weiterer Unterzeichner unerwünschte Zahlungen ablehnen soll, hat wiederum eine andere Vertrauensannahme. Ein ähnliches Nutzungserlebnis bedeutet keine identische Durchsetzung oder Wiederherstellung. [5] [6]
Neben Tresoren werden gemeinsam genutzte UTXOs und Zahlungen untersucht, deren Abwicklung sich zeitlich verteilt. Ziele können weniger laufende Zusammenarbeit oder eine bessere Nutzung des Blockplatzes sein. Daraus folgen weder unbegrenzte Transaktionen noch garantiert niedrige Gebühren. Ein Entwurf muss auch den alleinigen Ausstieg eines Teilnehmers, unerreichbare Partner und die Gebührenzahlung bei Netzüberlastung erklären. [2] [7]
Am 17. Oktober 2026 stehen BIP119 und BIP443 auf Draft, also noch in der Entwurfsphase. Der ältere BIP345, OP_VAULT, ist Closed und nennt BIP443 als vorgeschlagenen Nachfolger. Dass dieses Dokument geschlossen wurde, bedeutet nicht das Ende der Tresorforschung. Ebenso wenig bedeutet eine BIP-Nummer, dass das Netzwerk eine Änderung angenommen hat. Ein Testnetz oder eine Demonstrations-Wallet kann eine Funktion zeigen, während die Regeln des Bitcoin-Hauptnetzes, des Mainnets, unverändert bleiben. Prüfen Sie bei einem angebotenen Covenant-Tresor deshalb, auf welchem Netzwerk und nach welchen Regeln er tatsächlich funktioniert. [6] [8]
Eine zu enge Vorlage oder ein Fehler bei Beträgen, Skripten oder der Gebührenabwicklung kann die beabsichtigte Ausgabe verhindern. Weitere Operationen erweitern außerdem den Umfang sicherer Validierung. Konsensänderungen müssen deshalb anhand ihrer genauen Spezifikation und ihres Fehlerverhaltens bewertet werden. Ein Covenant gibt einem Fremden nicht von sich aus das Recht, Bedingungen Ihrer bestehenden UTXOs nachträglich zu ändern. [4] [8]
Fragen Sie bei einer konkreten Lösung, wer Auszahlung und Rettung auslösen darf, wie lange das Reaktionsfenster ist und ob jemand die Blockchain laufend überwachen muss. Prüfen Sie auch Sicherungen, Gebühren, Ausstiegsmöglichkeiten und das tatsächlich verwendete Netzwerk. Covenants können die eigene Kontrolle über Geld erweitern. Das Wort in einer Produktbeschreibung allein belegt diese Kontrolle nicht. [3] [6]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, Konsensregeln, UTXO, Multisig. Auf diesen Eintrag verweisen außerdem OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.