In dem von Christian Decker et al. die update transactionsmüssen bestellt werden. In Kapitel 4.1.2 des Vorschlags wird aus Gründen der Rückwärtskompatibilität beschrieben, dass das nLocktimeFeld innerhalb der Aktualisierungstransaktionen umfunktioniert werden kann.
Gibt es noch andere Fallstricke dieser Lösung außer der Tatsache, dass sie ein bisschen hacky erscheint?
Ich hatte gehofft, jemand anderes würde darauf antworten, da ich der Autor von eltoo bin, hätte ich eine unabhängige Antwort vorgezogen.
Um es noch einmal zusammenzufassen: Die Sperrzeit wird in eltoo verwendet, um einen numerischen Vergleich zwischen einem Element auf dem Stack (Statusnummer) und einem Wert zu ermöglichen, auf den sich die Signatur festlegt. Der Grund, warum wir nicht einfach selbst eine Zahl auf den Stack schieben können, ist, dass dieser Push in der erfolgen würde redeemScript, was nicht in der Signatur festgeschrieben werden kann, da es die Signatur enthält. OP_CLTVkombiniert Push, Vergleich und Verifizierung in einem Opcode:
Markiert die Transaktion als ungültig, wenn das oberste Stack-Element größer als das nLockTime-Feld der Transaktion ist, andernfalls wird die Skriptauswertung fortgesetzt, als ob ein OP_NOP ausgeführt wurde.
Zu Ihrer Frage, ob es sicher ist: OP_CLTVist der einzige Opcode, der jemals berührt nLocktime(zur Verwendung in verwendet werden soll scriptPubkey), und die einzige andere Verwendung besteht darin, eine Transaktion bis zu einer bestimmten Höhe als ungültig zu markieren. Beide Anwendungsfälle spezifizieren nur, was mit zukünftigen Blockhöhen und Zeitstempeln passiert, und haben keine Auswirkungen, wenn sie nLocktimein der Vergangenheit liegen.
Daher ist die Nutzung des nLocktimeFeldes und durch eltoo OP_CLTVtechnisch gesehen keine Umnutzung, sondern nutzt die vorhandene Semantik.
Natürlich kann ich nicht vorhersehen, ob es einen zukünftigen Vorschlag gibt, der frühere Blockhöhen und Zeitstempel wiederverwenden möchte, aber mir sind keine bekannt, und die Suche nach den BIPs liefert keine widersprüchlichen Ergebnisse. Es wäre auch sehr unsicher, seine Semantik für Zeitstempel neu zu definieren, die in der Blockchain plausibel waren, und uns ein paar Millionen einzigartige Zeitstempel zu lassen, selbst wenn wir nur den 03.01.2009 betrachten – heute.