SIPA listet hier Quellen für TX-Formbarkeit auf: https://gist.github.com/sipa/8907691
Mir ist klar, wie eine Änderung der Signatur selbst oder der Signaturformatierung zu einem anderen tx-Hash führt (1. & 2.). Aber warum ist es erlaubt , den Rest (vielleicht "") der Skripte zu ändern ?
Soweit ich weiß, kann nur das Txin-Skript geändert werden, da die Txout-Skripte in den Signatur-Hashes enthalten sind. Offensichtlich kann die Signatur selbst nicht in den signierten Hash aufgenommen werden.
Für jede Signatur wird das entsprechende txin-Skript durch das entsprechende vorherige Ausgabeskript (?) ersetzt und alle anderen txin-Skripte im tx werden entfernt.
Warum ist das txin-Skript (ohne Signatur, also eine leere Zeichenfolge für ein Standard-tx ) nicht in den gehashten und signierten Daten enthalten?
(Bitte korrigieren Sie mich, wenn ich etwas falsch gemacht habe.)
edit: versuche mich klarer auszudrücken:
Natürlich müssen Umfang und Format der Signatur standardisiert werden. Aber es gibt andere Fälle von Formbarkeit, wie Sipa betont, wie das Hinzufügen von unsinnigen OPs zum tx_in-Skript oder die Verwendung alternativer OPs, die den gleichen oder einen ähnlichen Effekt haben. Ich spreche nur von diesen anderen Fällen.
Mein Punkt ist: Die Signatur selbst kann nicht signiert werden, aber warum sind OP-Codes, die möglicherweise im Txin-Skript vorhanden sind oder nicht, nicht signiert?
Beispiel:
Heute:
normales txinscript: "sig" --> Signaturformat: "" --> gültiges
Malled txinscript: "OP_NULL sig" --> Signaturformat: "" --> gültig
Warum nicht:
normales txinscript: "sig" --> Signaturformat: "" --> gültiges
Malled txinscript: "OP_NULL sig" --> Signaturformat: "OP_NULL " --> FAIL
Das Signaturformat ersetzt heute das gesamte Txinscript durch "". Mir scheint es sicherer zu sein, nur die Signatur selbst zu entfernen, aber die Opcodes beizubehalten, falls vorhanden, so dass es unmöglich ist, vorhandene Opcodes zu ändern oder unsinnige Opcodes hinzuzufügen.
Liegt es daran, dass nicht bekannt ist, welcher Teil des Skripts die Signatur ist? Ich denke, es könnte als solches gekennzeichnet werden, sollte dies das Problem sein.
Du liegst absolut richtig.
Der einzige Grund, warum dies getan wird, ist, dass die Konsensregeln derzeit nicht so funktionieren. Eine Änderung würde einen Hard Fork erfordern, der jeden Node und schließlich jede Wallet aktualisiert.
Das tx_in "Skript" ist die Signatur (und der Pubkey und einige Formatierungen). Es ist ein etwas verwirrender Name, der irgendwie andeutet, dass es ein tx_in-Skript gibt und dann woanders diese Signatur, aber das ist nicht der Fall.
Die Signatur kann nicht in die Eingabe aufgenommen werden, die die Signatur bildet.
Dieses Diagramm könnte helfen. https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png
Das Diagramm auf der linken Seite ist ein "Standard" tx_in.
Die tx_input-Struktur besteht aus
Previous txout-hash (tx_id)
Previous Txout-index
Txin-script length
Txin-script
sequence_no
Dies ist jedoch wirklich nur eine Abstraktion, das Txin_script ist nur die Signatur und der Pubkey, die bestehen aus:
L(sig)
0x30
L(rs)
0x02
L(r)
Sig r
0x02
L(s)
Sig s
0x01
L(key)
0x04
Key X
Key y (only for uncompressed keys)
Wenn Sie also sagen, dass das txin-Skript veränderbar ist, ist dies einfach eine andere Art, die Signatur (und die Formatierung) zu sagen. Es gibt nicht eine einzige Methode zur Wandlung. ECDSA selbst hat veränderbare Signaturen, das Auffüllen und Formatieren der Signatur kann geändert werden und ist immer noch gültig.
Um tx_id unveränderlich zu machen, muss entweder die tx_id (Hash) mit einer alternativen Methode berechnet werden, bei der die Nutzdaten des Hashs alle unveränderlichen Elemente sind, oder die ECDSA-Signatur auf eine bestimmte Teilmenge von Parametern, Formatierungen und Auffüllungen beschränkt werden, so dass für eine bestimmte Nutzlast dort ist nur eine mögliche "richtige" Bitcoin-Signatur. Alles andere, obwohl es sich um eine gültige ECDSA-Signatur handeln könnte, würde im Bitcoin-Netzwerk als ungültig angesehen.
Es ist eine nicht triviale Aufgabe. Nicht unmöglich, aber es wird nicht "schnell und einfach" gelöst werden und, soweit ich sehen kann, wird ein Hard Fork des Netzwerks erforderlich sein. Dies bedeutet zusätzliche Zeit beim Testen, Hinzufügen von Vorwärtskompatibilität und Konsensbildung, um unbeabsichtigte Folgen zu vermeiden, wie z. B. das Belassen eines erheblichen Teils des Netzwerks auf dem alten Fork.
My point is: The signature itself can not be signed but why are OP codes that may or may not be present in the txin script not signed?
Die aktualisierte Frage bietet einen spezifischeren Kontext, daher werde ich sie als neue Antwort beantworten.
Es gibt keinen Grund, warum Bitcoin nicht hart gegabelt werden könnte, um das zu erreichen, was Sie angeben. Wenn Sie sich fragen, warum ein so komplexes Signaturschema? Wie Pieter sagt: "Frag Satoshi".
Schon bevor wir auf diese Probleme stießen, fand ich den Signaturteil der Transaktion immer zu komplex und kontraintuitiv. Wenn Bitcoin tx wie in fast jedem anderen kryptografischen System signiert wäre, wäre die Signatur nicht Teil der Eingabe.
Es könnte etwa so aussehen
tx header
input(s)
output(s)
signature(s)
Der tx-Header, die Eingabe(n) und die Ausgabe(n) würden den "tx-Körper" umfassen. Der Hash des tx-Körpers ist die tx_id.
Um eine Transaktion zu erstellen, würde der Client den TX-Body erstellen und den TX-Hash berechnen. Der tx-Hash + privater Schlüssel für jede Eingabe würde verwendet, um eine Signatur zu generieren. Die Signaturen würden an den TX-Body angehängt und das Ganze als TX-Nachricht gesendet.
Entfernen Sie zur Validierung die Signaturen aus dem TX und Sie haben den TX-Body übrig. Hashen Sie den verbleibenden tx-"Body", überprüfen Sie die Signatur. Überprüfen Sie die Eingänge, überprüfen Sie die Ausgänge. Überprüfen Sie, ob jede der Signaturen korrekt ist.
Natürlich ist eine so radikale Änderung von Bitcoin immer noch „möglich“, aber es ist unwahrscheinlich, dass es jemals gegabelt wird, um dies zu ermöglichen. Satoshi hat vieles richtig gemacht, aber er war nicht perfekt und das ist ein Beispiel.
Kermit