Warum werden SIGHASH-Flags mit 4 Bytes signiert, wenn nur 1 Byte in der Transaktion enthalten ist?

Dieser Artikel machte mich darauf aufmerksam, dass SIGHASH-Flags 4 Byte lang sind, wenn sie signiert sind, aber nur das letzte Byte tatsächlich in der Transaktion enthalten ist. Dann fügt OP_CHECKSIG 3 Bytes 0x000000wieder hinzu, bevor die Signatur überprüft wird. Der Artikel beschreibt einen cleveren Weg, einen Fork mit diesen drei abgeschnittenen Bytes einzuführen – warum also sind die SIGHASH-Flags überhaupt 4 Bytes lang? Ist das ein Konstruktionsfehler oder Feature?

Antworten (1)

Ich nehme an, es ist einfach das Ergebnis von Faulheit.

Im ursprünglichen Client-Quellcode (und noch heute) wird der Sighash-Typ als int dargestellt. Das Serialisierungsframework serialisiert ints standardmäßig als 4 Little-Endian-Bytes.

Ich nehme an, der Schöpfer von Bitcoin hat sich nicht die Mühe gemacht, es vor der Serialisierung in ein einzelnes Byte zu konvertieren.

Wenn es einen anderen Grund gibt, fürchte ich, müssen Sie ihn fragen.

Danke Pieter, das macht Sinn ... aber wann (im Code) wird das int auf 1 Byte abgeschnitten? Soll das nur die Transaktionsgröße reduzieren?
Ist es diese Zeile hier, die nHashTypeals unsigned char(1 Byte) gecastet wird: github.com/bitcoin/bitcoin/blob/…
Ja, ich gehe davon aus, dass sich der Schöpfer von Bitcoin um die Signaturgröße gekümmert hat (obwohl er nicht wusste, dass die Verwendung der DER-Codierung grundlos 6 Bytes hinzufügte) und dort 1 Byte für den Sighash-Typ verwendete, sich aber nicht genug darum kümmerte dasselbe gilt für die Seufzerberechnung.
Warum werden SIGHASH-Flags mit 4 Bytes signiert, wenn nur 1 Byte in der Transaktion enthalten ist?
AntwortenHierDatenschutz-Bestimmungen1y, 0v