Neuland der Kryptografie: Witness Encryption und PIPEs

Neugier

1. Warum kann Bitcoin eine Signatur überprüfen, aber nicht einschränken, wohin der daraus hervorgehende Coin als Nächstes geht?
2. Wie viel kostet es, zu beweisen, dass man ein Geheimnis kennt, ohne das Geheimnis selbst preiszugeben?
3. Wie gewährleisten Protokolle die Sicherheit, wenn die zugrunde liegenden Regeln statisch und unveränderlich bleiben?

Erkunden

Teil IKryptografisches Neuland: Covenants und Witness Encryption

1. Bitcoin Script ist bewusst eingeschränkt. Es kann prüfen, ob eine Signatur zu einem öffentlichen Schlüssel passt, aber nicht, wohin Coins nach dem Ausgeben gehen. Diese Einschränkung hält Script einfach und vorhersehbar. Sie verhindert jedoch auch bestimmte Designs, bei denen Ausgabebedingungen von der Struktur künftiger Transaktionen abhängen.
2. Jeremy Rubins Vorschlag OP_CHECKTEMPLATEVERIFY (BIP-119) setzt an dieser Lücke an. Der Opcode würde es einem Script erlauben zu verlangen, dass die ausgebende Transaktion einem festgeschriebenen Template entspricht, das ihre Outputs und bestimmte weitere Felder festlegt. Das ermöglicht nicht-rekursive Covenants: Regeln darüber, wohin Coins als Nächstes gehen dürfen, etwa um Mittel in Vaults zu sperren oder Rücklösungspfade einzuschränken. Er ist bislang nicht aktiviert und in der Bitcoin-Community weiterhin Gegenstand von Debatten.
3. Ein separater Vorschlag, OP_CAT (BIP-347), konzentriert sich darauf, Daten auf dem Stack zu verketten, statt direkt Zielbeschränkungen durchzusetzen; in Kombination mit Schnorr-Signaturen kann er allerdings ebenfalls Covenants ermöglichen. Diese einfache Operation erlaubt komplexe kryptografische Konstruktionen, darunter Baumsignaturen, die sehr große Multisignatur-Richtlinien kompakt ausdrücken. Außerdem erleichtert sie Post-Quanten-resistente Lamport-Signaturen, indem sie es ermöglicht, Hashes und Werte direkt in der Script-Engine zu verarbeiten.
4. Über neue Opcodes hinaus untersucht die Forschung Witness Encryption als alternativen Weg zur Programmierbarkeit. Witness Encryption erlaubt es einem Absender, Daten so zu verschließen, dass nur jemand sie entsperren kann, der den Besitz eines bestimmten Geheimnisses (eines Witness) nachweisen kann. Theoretisch könnten so Bitcoin-Schlüssel erst offengelegt werden, wenn eine Aussage bewiesen ist, ohne dass das Netzwerk die Berechnung direkt verifizieren muss.
5. Erste Konstruktionen für Witness Encryption gibt es in der Fachliteratur, für den Einsatz auf Bitcoin sind sie aber weiterhin unpraktikabel. Für allgemeine Aussagen existiert noch keine praktikable Konstruktion: Bekannte Verfahren sind enorm groß und beruhen auf kryptografischen Annahmen, denen noch nicht breit vertraut wird. Die theoretischen Grundlagen sind zwar solide, doch die technische Lücke zwischen einem Proof of Concept und einem produktionsreifen Protokoll bleibt erheblich.
6. Der Kompromiss ist klar: Covenants erhöhen die Ausdrucksstärke, bringen aber neue Konsensregeln mit sich, die sorgfältig geprüft werden müssen; Witness Encryption bietet Privatsphäre und Flexibilität, verursacht aber hohe Speicher- und Rechenkosten. Beide Ansätze zielen darauf ab, die Fähigkeiten von Bitcoin zu erweitern, ohne sein zentrales Sicherheitsmodell aus fester, vorhersehbarer Ausgabe und begrenzter Skriptfähigkeit aufzugeben.

Teil IIBitcoin hinein und wieder heraus: PIPEs und Witness Encryption

7. Shielded Bitcoin, in der vorherigen Lektion ausführlich beschrieben, wickelt private Transfers innerhalb seines eigenen Note-Systems ab. Peg-in und Peg-out klammert es aus: also die Frage, wie Werte aus gewöhnlichem, transparentem Bitcoin in die abgeschirmte Schicht gelangen und wieder zurück. Der Entwurf für diese Brücken stützt sich auf einen Mechanismus namens Witness Encryption, konkret auf Bitcoin PIPEs v2 (IACR ePrint 2026/186, Februar 2026).
8. Witness Encryption schließt Daten hinter einer mathematischen Aussage ein. In diesem Zusammenhang wird ein privater Bitcoin-Schlüssel so verschlüsselt, dass er nur entschlüsselt werden kann, wenn jemand einen gültigen Witness vorlegt – einen Beweis dafür, dass die Aussage wahr ist. Der Ciphertext wird off-chain veröffentlicht, und der darin enthaltene Schlüssel bleibt für alle unzugänglich, die den entsprechenden Witness nicht liefern können.
9. Der Mechanismus verlagert die Programmierbarkeit vom Konsens in die Kryptografie. Statt neue Opcodes oder Soft Forks zu benötigen, um komplexe Ausgabebedingungen durchzusetzen, liegt die Logik vollständig im Verschlüsselungsverfahren. Wer einen gültigen Witness vorlegt, etwa einen SNARK-Proof, erhält den privaten Schlüssel und gibt die Coins mit einer gewöhnlichen Schnorr-Signatur aus. Für die Konsensregeln von Bitcoin ist das eine ganz normale Transaktion; die Komplexität bleibt unsichtbar.
10. Dieser Ansatz kann Covenant-artige Beschränkungen wie CheckTemplateVerify oder Vault-Mechanismen nachbilden, ohne das Protokoll zu ändern. Die Bedingungen werden dadurch durchgesetzt, dass sich der Schlüssel nicht entschlüsseln lässt, solange der Witness bestimmte Kriterien nicht erfüllt. Damit eröffnet sich ein Weg zu fortgeschrittenen Ausgabebedingungen, die mit den bestehenden Validierungsregeln von Bitcoin kompatibel bleiben – vorausgesetzt, die zugrunde liegende Kryptografie hält.
11. Das Haupthindernis ist die Größe. Das Paper vom Februar 2026 schätzte jeden Ciphertext auf etwa 338 Terabyte; spätere Arbeiten der Autoren nennen etwa 10 Terabyte, was zum Speichern und Verteilen immer noch unpraktikabel ist. Es gibt keine Implementierung, daher handelt es sich um Schätzungen, und ob PIPEs überhaupt eingesetzt werden können, bleibt eine offene Forschungsfrage.
12. Es handelt sich weiterhin um eine Forschungsphase, nicht um eine implementierte Funktion. Es gibt keine Termine für eine Einführung, und die widersprüchlichen Größenangaben unterstreichen die Unsicherheit in diesem Feld. Solange die Ciphertexte nicht ausreichend schrumpfen, dient Witness Encryption eher als theoretische Brücke zwischen Bitcoins transparentem Hauptbuch und komplexen kryptografischen Commitments als als funktionsfähiges Werkzeug für Nutzer.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

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

• J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• S. Garg, C. Gentry, A. Sahai & B. Waters, 'Witness Encryption and its Applications' (STOC 2013)
• bitcoin-dev mailing list archives
• Abdalla, Carmer, El Gebali, Kilinc Alper, Komarov et al., 'Bitcoin PIPEs v2' (IACR ePrint 2026/186, February 2026)
• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 2026)
• S. Garg et al., 'Witness Encryption and its Applications' (2013)