Ist mein Verständnis von Locktime richtig?

Ich habe versucht, Sperrzeiten und Sequenznummern zu verstehen. Ich baue nach und nach ein Bild in meinem Kopf auf, basierend auf Code, Code-Kommentaren und Informationen im Web. Anstatt viele Fragen zu stellen, werde ich mein Verständnis davon beschreiben, wie Locktime und Sequenznummern funktionieren. Könnte mir bitte jemand sagen, ob es richtig ist, und wenn nicht, dann spezifizieren Sie bitte genau, welche Bits falsch sind, indem Sie Beispiele verwenden oder mich auf den Quellcode verweisen.

Mining-Kriterien

Alle Transaktionseingaben haben ihre eigene Sequenznummer, und es gibt eine Sperrzeit für die gesamte Transaktion. Eine Transaktion kann "endgültig" gemacht werden durch :

  • Sperrzeit auf 0 setzen, oder
  • Festlegen der Sperrzeit auf weniger als die aktuelle Blockhöhe, oder
  • Einstellen der Sperrzeit auf weniger als die aktuelle Zeit (aber immer noch über einem Schwellenwert, damit sie nicht mit einer Blockhöhe verwechselt wird), oder
  • ALLE TXIN-Sequenznummern auf setzen 0xffffffff.

Jede dieser Bedingungen reicht aus, damit eine Transaktion als "endgültig" betrachtet wird. Wenn alle Bedingungen fehlschlagen, ist die Transaktion nicht "endgültig". Nur "endgültige" Transaktionen werden in Blöcke abgebaut - nicht endgültige Transaktionen schaffen es nie in die Blockchain. Beachten Sie, dass eine Transaktion in der Blockchain nur dann eine Sperrzeit mit einem zukünftigen Zeitstempel oder einer zukünftigen Blocknummer enthalten kann, wenn alle Sequenznummern auf gesetzt sind 0xffffffff.

Geld sperren

Angenommen, die Blockhöhe beträgt derzeit 377199. Wenn ich jemandem Geld schicken möchte, aber erst irgendwann in der Zukunft empfangen möchte, könnte ich eine Transaktion an seine Adresse durchführen, die Sperrzeit auf 400000setzen und alle Sequenznummern in der Transaktion auf setzen 0xffffffff. Diese Transaktion wird in Block 377200oder vielleicht abgebaut 377201. Es wird wahrscheinlich auch eine Mining-Gebühr verlangen. Diese Gebühr ist Teil der Coinbase-Gelder und wird sofort von der vorherigen Transaktion abgezogen (dh der Miner muss nicht bis zur Sperrzeit warten, um die Gelder in die Coinbase zu legen).

Alle txin-Skripte in meiner locktime=400000- Transaktion müssen erfolgreich mit ihren entsprechenden txout-Skripten in der/den ausgegebenen Transaktion(en) validiert werden. Sobald die Transaktion locktime=400000 in einen Block abgebaut wurde (z. B. block=377200 ), kann jeder Block, der auf block=377200 aufgebaut ist, die Txouts, die meine Transaktion locktime=400000 bereits ausgegeben hat , nicht doppelt ausgeben . Sobald die Transaktion locktime=400000 in einen Block geschürft wird, führt dies dazu, dass die UTXOs, auf die sie verweist, sofort aus dem Pool entfernt werden, obwohl die Gelder für einen Zeitraum bis zum Erreichen der Sperrzeit gesperrt sind.

Gesperrte Gelder ausgeben

Nicht alle Transaktionsausgaben, die in einen Block geschürft wurden, können sofort oder überhaupt ausgegeben werden. Zum einen werden, wenn Transaktion A von Transaktion B ausgegeben wird, die txout-Skripte in Transaktion B von den Minern nicht auf Syntax überprüft (obwohl die txout-Skripte in A überprüft werden). Wenn die Txout-Skripte in B Unsinn sind, werden die Gelder, die sie lenken, für immer unausgebbar.

Aber in einem Fall, in dem Scriptsig und Scriptpubkey validieren, werden Miner eine Transaktion in die Blockchain nur zulassen, wenn sie die Locktime-Kriterien erfüllt. Angenommen , jemand möchte die Transaktionsgelder von locktime=400000 ausgeben (bereits in Blocks abgebaut) – er würde eine eigene Transaktion erstellen, die die txouts aus der locktime=400000- Transaktion verwendet, und sie an das Netzwerk senden. Bergleute würden alle Standardprüfungen für diese neue Transaktion durchführen, und die spezifischen Prüfungen in Bezug auf die Sperrzeit wären:

  • dass die Transaktion "endgültig" ist, wie zuvor besprochen
  • dass dieser zuletzt erstellte Block 400000 oder größer ist

Wenn dieser letzte Block nicht 400000 ist, kann die Transaktion nicht in den Block geschürft werden. Und tatsächlich, wenn ein bösartiger Miner die Ausgabetransaktion in einen Block vor Block 400000 legt, wird dieser Block von anderen Minern im Netzwerk abgelehnt, weil er eine Transaktion enthält, die nicht validiert werden kann.

Sagen Sie die Person, die die Sperrzeit = 400000 verbringtTransaction Funds möchte, dass dies geschieht, sobald Block 400000 erreicht ist. Wenn sie ihre Ausgabentransaktion zu früh senden (z. B. 377199), wird sie möglicherweise abgelehnt, da Miner die Transaktion wegen Nichtvalidierung verwerfen. Wenn die Bergleute schlau sind (wahrscheinlich sind sie es, aber ich habe mir den Code dafür nicht angesehen), dann werden sie sehen, dass die Transaktion zu einem späteren Zeitpunkt ausgegeben werden kann, und werden sie behalten, damit sie sie abbauen können in Block 400000 und erhalten die Gebühren vor allen anderen. Wenn die Transaktion jedoch zu weit in der Zukunft liegt, kann den Minern der Speicher ausgehen, um diese Transaktion zu speichern und zu verwerfen. Die Person, die die Transaktion ausgibt, kann ihre Ausbreitung auf blockchain.info überprüfen und sie vor Block 400000 erneut senden, wenn die Ausbreitung zu gering ist.

OP_CHECKLOCKTIMEVERIFY

Dieser Opcode kann entweder in scriptpubkey oder scriptsig (oder in beiden gleichzeitig) verwendet werden. Es vergleicht grundsätzlich ein Stapelelement ( nur die 5 Bytes ganz rechts im minimierten Format ) mit der Sperrzeit der Transaktion. Wenn die Transaktionssperrzeit ( Zeitstempel, wenn über dem Schwellenwert oder Blocknummer, wenn unter dem Schwellenwert ) größer als das Stack-Element ist, wird dieser Opcode erfolgreich validiert. Aber wenn die Transaktionssperrzeit den Stack-Item-Wert noch nicht erreicht hat, wird der Opcode nicht validiert und Miner werden diese Transaktion nicht in einen Block aufnehmen.

In dem Fall, in dem ein Skript OP_CHECKLOCKTIMEVERIFYnur die Sequenznummer für die TXIN 0xffffffdieses Skripts enthält, bedeutet dies, dass die Sperrzeit ignoriert wird. Daher schlägt dies OP_CHECKLOCKTIMEVERIFYfehl und die Transaktion wird nicht in einen Block abgebaut.

OP_CHECKLOCKTIMEVERIFYkann auch verwendet werden, um sicherzustellen, dass auf Gelder erst zu einem späteren Zeitpunkt oder zu einem späteren Zeitpunkt zugegriffen werden kann. Um beispielsweise Gelder an die Adresse xyz zu senden, sie aber ab Block 400000 zugänglich zu machen, könnte das folgende TXOUT-Skript verwendet werden:

OP_DUP OP_HASH160 OP_PUSHDATA xyz OP_EQUALVERIFY OP_CHECKSIG OP_PUSHDATA 400000 OP_CHECKLOCKTIMEVERIFY

Um diese Transaktion auszugeben, muss dann jemand eine Transaktion mit einer Sperrzeit von 400000 oder mehr einreichen (aber immer noch unter dem Schwellenwert).

Antworten (1)

Angenommen, die Blockhöhe ist derzeit 377199. Wenn ich jemandem Geld schicken wollte, aber erst irgendwann in der Zukunft, dann könnte ich eine Transaktion an seine Adresse durchführen, die Sperrzeit auf 400000 setzen und alle festlegen Sequenznummern in der Transaktion auf 0xffffffff. Diese Transaktion wird in Block 377200 oder vielleicht 377201 abgebaut.

nLockTimemacht eine Transaktion ungültig , nicht unauszahlbar . Wenn Sie versuchen, eine Transaktion zu übertragen, bevor sie gültig ist, wird sie nicht weitergeleitet und kann nicht in einen Block aufgenommen werden. Sie können die Transaktion beibehalten, bis sie gültig wird (durch Blockhöhe oder Zeit), aber Sie können die ursprünglichen Ausgaben in der Zwischenzeit auch mit einer völlig anderen Transaktion verbringen. In Ihrem Beispiel wird es erst bei einer Höhe von mindestens 400.000 in einen Block gelangen, und nur, wenn Sie es nach dieser Zeit senden. nLockTimewirkt sich nicht auf die Ausgabenfähigkeit der Ausgabe in den Blöcken aus, sondern nur auf die Gültigkeit der Transaktion, die sie erstellt.

aber wenn alle Sequenznummern vorhanden sind, 0xffffffffist die Transaktion "endgültig" und wird in einen Block abgebaut.
In diesem Fall nLockTimehat das Testament keinerlei Wirkung.
Ah richtig. Weißt du, wo ich das im Quellcode überprüfen kann?
die Regeln könnten in ConnectBlock gefunden werden ?