Habe ich das vielleicht falsch verstanden? Ich dachte immer Taproot/Schnorr stellen eine Erweiterung dar aber bringen nicht mehr Flexibilisierung ins Bitcoin Script.
Taproot/Schnorr nicht, sondern Simplicity selbst. Man soll nicht für jeden neuen Opcode einen neuen Softfork brauchen, sondern mit dem Simplicity-Softfork wäre es möglich Taproot/Schnorr usw. ohne weitere Softforks zu realisieren.Allerdings scheint auch bei Taproot eine Skriptsprache namens "Tapscript" mit ähnlichen Zielen wie Simplicity eingebaut zu sein. So ganz blicke ich da auch noch nicht durch.
Gibt es mittlerweile eigentlich einen Zeitpunkt, an dem es für Taproot/Schnorr nun ernst werden soll? Ich meine mich erinnern zu können, dass es dieses Jahr kommen sollte.
Das neueste was ich gefunden habe ist dieser Artikel auf Coindesk von Ende April, aber es scheint noch getestet zu werden, ohne ETA:Wenn es hier keinen Loop gibt, dann wir der Smart Contract quasi nur einmalig ausgeführt? Hättest du vielleicht hierfür ein anschauliches Beispiel wie so ein Smart Contract aussehen könnte? Also was der Endverbraucher damit anstellen könnte.
Hab da jetzt auf die Schnelle kein Beispiel parat, müsste mal stöbern. Aber grundsätzlich werden wohl HTLCs wie bei Lightning und bei Atomic Swaps flexibler gestaltet werden können. Also generell Contracts bei denen eine Transaktion ausgelöst wird (genauer: das auf gewisse Coins von einem bestimmten Private Key aus zugegriffen werden kann), wenn eine bestimmte Bedingung erfüllt ist. Wie gesagt werden auch Taproot und Schnorr als Beispiele für mögliche Contracts genannt.Edit: Ein Beispiel, was vielleicht möglich sein könnte und was mich selbst interessieren würde (wegen diesem Thema hier (Absicherung gegen Crashs)): Put- und Call-Optionen mit reiner Bitcoin-Technologie.
Call-Optionen können als Atomic Swaps mit langer Laufzeit beschrieben werden (Atomic Swaps = Austausch zweier Coins, ohne dass jemand den anderen übers Ohr hauen kann). Bei Atomic Swaps gibt es immer eine Seite, die während der Laufzeit des Contracts entscheiden kann, ob der Austausch ausgeführt wird. Das wird als "ungerecht" angesehen. Nun könnte die Gegenseite eine zusätzliche Zahlung eines Betrags ("premium") fordern, dann wäre das ganze äquivalent zu einer Call-Option (die man auch in eine Put-Option umbauen kann, wenn man die Coins austauscht). Man zahlt also, um die Option zu haben, während der Laufzeit (z.B. 30 Tage) Coin A für eine festgelegte Summe von Coin B zu kaufen.
Das Problem ist derzeit, dass diese "Premium"-Zahlung (also die Bezahlung des Kaufpreises der Option) etwas "tricky" ist - wahrscheinlich muss mit aktuellem Bitcoin Script das Premium immer in dem Coin bezahlt werden, den der Optionskäufer kaufen möchte (siehe hier). Er muss also schon vorher über einige dieser Coins verfügen. Eventuell könnte das mit Simplicity so organisiert werden, dass auch der Ausgangs-Coin für die Zahlung verwendet werden könnte.
