Ich habe heute OP_CHECKSIG überprüft und festgestellt, dass die Signatur einer Transaktion aus der Transaktion berechnet wird, aber der ScriptPubKey aus der Transaktion, auf die verwiesen wird, als Eingabe in den SigKey der neuen Transaktion kopiert wird.
Ich denke, das hat etwas mit der TX-Formbarkeit zu tun, aber ich kann nicht erkennen, in welchem Fall dies wirklich helfen würde? Die TX-Eingänge verweisen bereits auf IDs, die geändert werden können, was eine Formbarkeit impliziert.
Es wäre nur sinnvoll, die Eingaben ScriptPubKeys einzuschließen, wenn es möglich wäre, eine ID beizubehalten, während der ScriptPubKey geändert wird (was nicht möglich ist), oder übersehe ich etwas?
Ich beziehe mich auf diese Grafik Schritt 7 + 8: https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png
AFAIK, dies war ursprünglich eine Designentscheidung von Satoshi, die aus den im OP genannten Gründen unnötig ist. Es gibt einen Kommentar dazu in bitcoinj
// Set the input to the script of its output. Bitcoin Core does this but the step has no obvious purpose as
// the signature covers the hash of the prevout transaction which obviously includes the output script
// already. Perhaps it felt safer to him in some way, or is another leftover from how the code was written.
Es sollte jedoch beachtet werden, dass es sinnvoll ist, bestimmte Teile der vorherigen Transaktion zu unterzeichnen. Segwit hat gerade einen neuen Transaktionssignaturalgorithmus implementiert, um die Menge an Satoshis abzudecken, die eine Eingabe von einer bestimmten Ausgabe ausgibt.
Die Signatur sollte so viele Daten wie möglich umfassen.
Und es ist keine gute Idee, dieselben Daten für alle Eingabeskripte zu signieren, wenn die Transaktion mehrere Ausgaben einer Transaktion einlöst