Warum wird die Transaktion mit einem Sperrskript aus der Eingabetransaktion signiert?

Endlich habe ich erfolgreich eine Rohtransaktion mit Python durchgeführt, und das ist das Letzte, was mir völlig missfällt.

In meinem Fall ist hier die Eingabetransaktion und ihr Sperrskript lautet:

OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG

Warum muss das Entsperrskript vor dem Signieren für das Sperrskript der Eingabe eingerichtet werden ? Nach meinem Verständnis sollte das ganze Zeug auch mit leerem Sperrskript gut funktionieren, da wir tatsächlich nur andere Parameter signieren. Unlocking scriptund unlocking script lenghtwird sowieso geändert, also was ist der Grund?

Antworten (1)

Hier gibt es keine endgültige Antwort, und Sie müssen den Ersteller des Systems fragen, um sicherzugehen.

Ich vermute, dass dies auf die Interaktion mit einer Funktion zurückzuführen ist, die wir jetzt „Delegation“ nennen: die Möglichkeit für jemanden, eine Transaktion vorab zu signieren und ein neues Entsperrskript hinzuzufügen – wodurch das Recht zum Signieren unter bestimmten Umständen effektiv an jemand anderen delegiert wird .

Zu den Elementen der Skriptsprache, die in diese Richtung weisen, gehören die Existenz von OP_CODESEPARATOR und das ursprüngliche Ausführungsmodell, bei dem scriptSig + scriptPubKey in einem Durchgang ausgeführt werden, anstatt wie bisher separat ausgeführt zu werden.

Aber was ist mit der Sicherheit - habe ich Recht, dass der Miner das Entsperrskript + die Länge des Entsperrskripts bearbeiten kann, bevor die Transaktion in den Block aufgenommen wird, und die Transaktion weiterhin gültig ist?
Ja, das nennt man Formbarkeit, und es ist möglich. Dies lässt sich jedoch nicht vermeiden, da wir keine Signaturen haben können, die sich selbst signieren (wie im Entsperrskript). Ein Ausweg ist der Segregated Witness-Vorschlag, der die Formbarkeit nicht verhindert, aber dafür sorgt, dass das Entsperrskript nicht zur txid-Berechnung beiträgt.