Ausgabe über den Skriptpfad

Ausgaben über den Skriptpfad sind der Ausweichweg aus einer Taproot-Ausgabe (Output) und werden genutzt, wenn die kooperative Signatur, auf die alle gehofft hatten, nie zustande kam. Der Nachweis reist in einem Kontrollblock von 33 Bytes plus 32 weiteren für jede Ebene des Baums, und BIP-341 begrenzt diesen Baum auf 128 Ebenen. Wer diesen Weg nimmt, veröffentlicht den verwendeten Zweig, sodass die eine Bedingung, auf die Sie sich tatsächlich verlassen haben, nicht mehr privat ist.

Wie es funktioniert

Ein Node, der eine Ausgabe über den Skriptpfad validiert, liest den Witness-Stack von hinten, weil das letzte Element die meiste Arbeit leistet.

Dieses letzte Element ist der Kontrollblock, und seine Länge wird vor allem anderen geprüft. Sie muss genau 33 + 32m Bytes betragen, für eine ganze Zahl m zwischen 0 und 128, und jede andere Länge scheitert sofort. BIP-341 setzt die Obergrenze bei 128 an, weil ein optimal gepackter Baum nur bei einem Blatt tiefer geht, dessen Nutzungswahrscheinlichkeit unter 1 zu 2^128 liegt.

Das erste Byte trägt zwei Dinge, die nichts miteinander zu tun haben. Maskieren Sie es mit 0xfe, erhalten Sie die Blattversion, 0xc0 für die Tapscript-Regeln; das wegmaskierte Bit ist die Parität der Y-Koordinate des Ausgabeschlüssels, vorhanden, damit die Ausgabe im Stapel verifiziert werden kann. Die nächsten 32 Bytes sind der interne öffentliche Schlüssel, derjenige, der eine kooperative Ausgabe signiert hätte; alles danach ist der Merkle-Pfad, 32 Bytes pro Ebene.

Dann baut der Node die Festschreibung neu auf. Er hasht die Blattversion zusammen mit dem offengelegten Skript zu einem Tapleaf-Hash und faltet nacheinander jedes Pfadelement ein. Die Richtung wird nie übertragen: die beiden 32-Byte-Werte jedes Schritts werden vor dem Hashen lexikografisch sortiert, sodass der Vergleich die Reihenfolge entscheidet und kein Richtungsbit gesendet wird. Die Wurzel und der interne Schlüssel ergeben einen Tweak, und der getweakte Schlüssel muss den 32 Bytes in der Adresse entsprechen, einschließlich Paritätsbit, bevor das Skript ausgeführt werden darf.

Ein Byte kann alles davor verändern. Enthält der Witness mindestens zwei Elemente und beginnt das letzte mit 0x50, wird dieses Element vor Beginn der Validierung als Annex entfernt. BIP-341 definiert dafür keine Bedeutung und warnt, dass die Aufnahme eines Annex zu "PERMANENT FUND LOSS" führen kann.

Wo sie auftritt

Eine Ausgabe über den Skriptpfad ist in einem Block-Explorer als Taproot-Eingabe erkennbar, deren Witness, abgesehen vom Annex, mehr als ein Element enthält.

Das eigene Rechenbeispiel von BIP-341 ist ein Baum aus fünf Skripten, A bis E. Wer mit Skript D ausgibt, veröffentlicht D, plus einen Kontrollblock mit dem internen Schlüssel und drei Hashes: C, E und dem kombinierten Hash von A und B. Dieser Kontrollblock umfasst 129 Bytes für einen Vertrag mit fünf Bedingungen, und die anderen vier Skripte werden nie veröffentlicht.

Der Nachweis verrät zugleich etwas. Der Abschnitt zur Sicherheit in BIP-341 merkt an, dass die Tiefe des offengelegten Blattes die Mindesttiefe des Baums preisgibt, was "suggests specific wallet software that created the output and helps clustering" (auf bestimmte Wallet-Software schließen lässt, die die Ausgabe erstellt hat, und die Clusterbildung erleichtert). Die von BIP-341 vorgeschlagene Gegenmaßnahme ist, vom Baum abzuweichen, den die Blattwahrscheinlichkeiten sonst optimal machen würden.

Derselbe Abschnitt äußert sich unmissverständlich zur Schlüsselwiederverwendung. Schlüssel müssen für jedes Blatt neu sein, nicht nur für das verwendete, weil ein wiederholter Zweig in einem späteren Nachweis als wiederholter Hash wieder auftaucht, und Blätter mit gemeinsamen Schlüsseln machen ein nicht offengelegtes Skript billig per Brute Force angreifbar.

Ausgabe über den Skriptpfad vs. Tapscript

Eine Ausgabe über den Skriptpfad ist der Weg; Tapscript ist die Sprache, die an dessen Ende gesprochen wird. BIP-341 definiert alles bis zu dem Moment, in dem die Ausführung beginnt: den Kontrollblock, das sortierte Merkle-Falten, die Tweak-Prüfung, das Paritätsbit. Was danach läuft, entscheidet die Blattversion.

Derzeit bedeutet nur 0xc0 Tapscript. Ein Blatt mit einer anderen Version ist kein Fehler, weil BIP-341 verlangt, dass die Ausführung bei unbekannten Blattversionen erfolgreich ist. Das ist der Ansatzpunkt, der eine spätere Soft Fork eine andere Skriptsprache im selben bc1p-Adressformat definieren lässt, was die Ausgabe über den Skriptpfad zur dauerhaften Hälfte des Paares macht.