MSTR Cat

Blockchain/Niveau IV · Tiefer ins Protokoll/4.2 Upgrades/Lektion 5

Covenants und Vaults: CTV, OP_CAT und die Debatte 2026

Die Regel, die die nächste Ausgabe beschränkt – und der Zeitpuffer, den sie schafft

MaterialienEine Kopie von BIP119 (OP_CHECKTEMPLATEVERIFY)Eine Kopie von BIP347 (Wiederaktivierung von OP_CAT in Taproot)Quellcode von Bitcoin Core für die Skript-ValidierungslogikEin Block-Explorer mit Funktionen zur Überprüfung von Transaktionen

Neugier

  1. Warum kann ein Standard-Bitcoin-Skript überprüfen, wer die Schlüssel besitzt, aber nicht, wohin die Coins anschließend gehen?
  2. Welche konkreten Einschränkungen erlegt OP_CHECKTEMPLATEVERIFY künftigen Transaktionen auf?
  3. Warum würde die Wiederaktivierung eines einzigen Konkatenations-Opcodes per Soft Fork den Weg zu Covenants öffnen?

Erkunden

    Teil ICovenant-Vorschläge: CTV und OP_CAT

  1. Standardmäßiges Bitcoin-Scripting prüft den Besitz eines Schlüssels oder Hashes, kann aber nicht einschränken, wohin die Coins nach dem Entsperren fließen. Ein Covenant ändert das, indem er Bedingungen an den `scriptPubKey` nachfolgender Outputs knüpft. Dieser Mechanismus wird oft mit Essensgutscheinen verglichen: Anders als Bargeld, das überall ausgegeben werden kann, sind diese Mittel auf bestimmte Partnerrestaurants beschränkt. Zu den vorgeschlagenen Anwendungen gehören Vaults mit verzögerten Auszahlungspfaden, Congestion Control (Entlastung bei Netzwerküberlastung) und einfachere Lightning-Designs.
  2. Jeremy Rubin schlug 2019 OP_CHECKTEMPLATEVERIFY (CTV) vor. Dieser Opcode fügt einen Hash eines zukünftigen Transaktionstemplates in die aktuelle UTXO ein. Um sie auszugeben, muss die Ausgabetransaktion genau diesem Template entsprechen; bei der Überprüfung ist keine Signatur erforderlich. Dadurch wird der nächste Schritt bereits vor der Ausführung des aktuellen festgelegt. Jede Abweichung in Bezug auf Beträge, Empfänger oder Scriptstruktur führt sofort zu einem Fehlschlag der Validierung und gewährleistet somit die strikte Einhaltung des im Voraus definierten Ablaufs.
  3. Die Schwäche von CTV ist seine Starrheit: Die Outputs der nächsten Transaktion stehen fest, sobald die Coins gesperrt werden, weshalb Gebühren auf andere Weise geregelt werden müssen, etwa mit einem Anchor-Output und Child Pays for Parent (CPFP). Im Gegenzug ist CTV einfach zu analysieren und günstig zu validieren.
  4. OP_CAT, ein Opcode, der zwei Stack-Elemente aneinanderhängt, wurde 2010 von Satoshi Nakamoto vorsorglich gegen Angriffe durch Speichererschöpfung deaktiviert. BIP347 schlägt vor, ihn gezielt innerhalb von Tapscript wieder zu aktivieren. In Kombination mit Tricks rund um Schnorr-Signaturen ermöglicht OP_CAT Covenants und andere komplexe Logik, ohne dass für jeden einzelnen Anwendungsfall neue Konsensregeln nötig wären. Er bietet einen elementaren Baustein, den Entwickler kombinieren können, um maßgeschneiderte Einschränkungen für künftige Transaktionen zu schaffen.
  5. Zu den verwandten Vorschlägen gehört OP_CHECKSIGFROMSTACK (BIP348), das eine Signatur über eine beliebige, auf dem Stack bereitgestellte Nachricht prüft statt über die ausgebende Transaktion. Diese Flexibilität würde in Kombination mit CTV (oder, unabhängig davon, mit dem vorgeschlagenen ANYPREVOUT) symmetrische Lightning-Kanäle ermöglichen, bei denen keine der Parteien Strafdaten für jeden alten Kanalzustand speichern muss.
  6. Stand 2026 wurde keiner dieser Covenant-Vorschläge aktiviert, auch wenn die Bemühungen um eine Aktivierung und die Auseinandersetzung darüber weitergehen. Die Debatte über ihren Nutzen, das Risiko, das sie den Konsensregeln hinzufügen, und den für eine Aktivierung erforderlichen Governance-Prozess dauert an. Die Erweiterung der Konsensregeln wirft Fragen zur Komplexität des Netzwerks und zur langfristigen Wartbarkeit auf, die in der Community weiterhin ungeklärt sind.

    7. Teil IICovenants und Vaults: die Debatte im Jahr 2026

  7. Bitcoin-Skripte prüfen derzeit Bedingungen der aktuellen Transaktion, etwa Signaturen oder Timelocks. Die Outputs der ausgebenden Transaktion können sie nicht einsehen. Covenants erweitern diesen Rahmen: Ein scriptPubKey kann Vorgaben für den scriptPubKey der Outputs machen, die von der ihn ausgebenden Transaktion erzeugt werden. Das schränkt ein, wohin Coins als Nächstes gehen können, und ermöglicht Funktionen wie Adress-Whitelisting und nicht-interaktive Zahlungskanäle.
  8. BIP-119 schlägt OP_CHECKTEMPLATEVERIFY (CTV) vor. Damit kann ein Skript einen Template-Hash einbetten; die ausgebende Transaktion muss diesem Template bei Outputs, Anzahl der Inputs, Sequenzen, Locktime und Version entsprechen, nicht jedoch dabei, welche Inputs ausgegeben werden. CTV ist nicht rekursiv, beschränkt also nur den unmittelbar nächsten Schritt. Es ersetzt OP_NOP4 und erfordert einen Soft Fork. CTV kann als Grundlage für „Vaults“ dienen, die der Wiederherstellung nach einem Diebstahl eine Zeitverzögerung hinzufügen.
  9. In einem Vault müssen Abhebungen eine Wartezeit durchlaufen (zum Beispiel 12 Stunden), in der ein separater Wiederherstellungsschlüssel die Mittel in Sicherheit bringen kann. Stiehlt ein Angreifer den Alltagsschlüssel und startet eine Abhebung, sieht der Eigentümer dies on-chain und holt die Mittel zurück, bevor die Verzögerung abläuft. So wird Schlüsseldiebstahl von einem unumkehrbaren Verlust zu einem behebbaren Ereignis – vorausgesetzt, das Opfer überwacht die Blockchain.
  10. Trotz Diskussionen seit 2013 wurde bisher kein Covenant-Soft-Fork aktiviert. Taproot (November 2021) ist nach wie vor das letzte große Upgrade. Im Februar 2026 wurde ohne Beteiligung von Bitcoin Core ein Aktivierungsclient für BIP-119 veröffentlicht. Er erfordert, dass zwischen März 2026 und März 2027 90 % der Miner Zustimmung signalisieren. Stand Mai 2026 lag das Signaling nahe null, was auf keinen Konsens über die Einführung hindeutet.
  11. OP_CAT (BIP-347) erreichte im März 2026 eine vollständige Spezifikation, hat aber keine Aktivierungsparameter. Es ermöglicht die Verkettung von Skriptelementen und damit komplexere Logik als CTV allein. CTV wird oft mit CheckSigFromStack (CSFS) kombiniert, das eine Signatur über beliebige Daten vom Stack prüft, nicht nur über die ausgebende Transaktion. Zusammen bieten sie einen deutlichen Gewinn an Ausdrucksstärke für Smart Contracts und Protokolldesign.
  12. Die Debatte dreht sich um Zielkonflikte: Covenants erhöhen die Sicherheit und ermöglichen neue Protokolle wie Vaults, bringen aber Komplexität und Governance-Risiken mit sich. Ein Soft Fork ändert die Konsensregeln und erfordert eine breite Zustimmung von Minern und Node-Betreibern. Der derzeitige Stillstand spiegelt Vorsicht gegenüber Implementierungsfehlern und der Unumkehrbarkeit von Änderungen am Zustand der Chain wider. Nutzer müssen diese Vorteile gegen das Risiko einer gescheiterten oder umstrittenen Aktivierung abwägen.

Kernfakten

  • Ein Covenant beschränkt den `scriptPubKey` künftiger Transaktionen, nicht nur die aktuellen Bedingungen zum Entsperren.
  • OP_CHECKTEMPLATEVERIFY (BIP119) legt einen Output auf die exakte Form der Transaktion fest, die ihn ausgibt.
  • CTV erfordert die Vorberechnung der Details zukünftiger Transaktionen sowie die Festlegung von Beträgen und Gebühren zum Zeitpunkt der Erstellung.
  • OP_CAT wurde 2010 deaktiviert, aber über BIP347 (2023–2024) zur Wiederaktivierung in Tapscript vorgeschlagen.
  • BIP348 schlägt OP_CHECKSIGFROMSTACK vor, das eine Signatur über eine vom Stack entnommene Nachricht prüft.
  • Stand 2026 war kein Covenant-Vorschlag aktiviert worden; die Debatte über Nutzen, Risiken und Aktivierung ging weiter.
  • Covenants beschränken die Outputs der Transaktion, die einen UTXO ausgibt.
  • BIP-119 (CTV) erfordert für die Aktivierung, dass zwischen März 2026 und März 2027 90 % der Miner Zustimmung signalisieren.
  • Das Signaling für BIP-119 lag Stand Mai 2026 nahe 0 %.
  • Taproot (November 2021) ist der zuletzt aktivierte Soft Fork; es sind keine Covenants live.
  • OP_CAT erreichte im März 2026 die vollständige Spezifikation ohne Aktivierungsparameter.
  • Vaults nutzen Covenants, um gegen Schlüsseldiebstahl eine Verzögerung und einen Rückholpfad einzubauen.

Übung neun, sechs, drei, eins

9SammelnListen Sie 9 vorgeschlagene Bitcoin-Opcodes oder Mechanismen im Zusammenhang mit Covenants oder der Erweiterung von Script auf (z. B. CTV, APO, OP_CAT).
6GruppierenGruppieren Sie die 9 nach ihrer primären Art der Einschränkung in 6 Kategorien: Transaktionsform, Schlüsselableitung, Konkatenationslogik usw.
3VerdichtenReduzieren Sie die 6 Gruppen auf 3 wesentliche technische Kompromisse zwischen Flexibilität und Validierungskosten.
1KristallisierenSchreiben Sie 1 Satz, der erklärt, warum ein starrer Covenant wie CTV günstiger zu validieren ist als flexible, auf OP_CAT basierende Scripts.

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

In der interaktiven Akademie öffnen →

EN PT ES ZH JA KO RU FR MS