txout-Skriptkriterien (scriptpubkey critieria)

Es werden absolut keine Konsensvaliditätsprüfungen für eine scriptPubKey. Nodes haben weiche Anforderungen namens IsStandard für das, was sie als Transaktion an ihre Peers weiterleiten (ein völlig Junk-Skript oder eine sehr große OP_RETURN-Ausgabe werden beispielsweise nicht bestanden), aber dies sind keine Konsensregeln. Einige Bergleute schürfen nicht standardmäßige Transaktionen in ihre Blöcke, aber im Allgemeinen muss ein anderer Transport als das P2P-Netzwerk verwendet werden, um eine Transaktion zu ihnen zu bringen.

OP_RETURNist ein Sonderfall, der als „nachweislich nicht ausgebbar“ bezeichnet wird. Dies ist eine Reaktion auf Leute, die Hashes und andere Daten in PubKeyHashAusgaben stauen, um sie rechtzeitig an die Blockkette zu koppeln. Da es keine Möglichkeit gibt zu wissen, ob die Ausgabe tatsächlich gültig ist oder nicht, müssen diese Ausgaben für immer im UTXO-Pool gespeichert werden. Eine OP_RETURNvorangestellte Ausgabe kann absolut niemals ausgegeben werden, sodass Knoten getrost vergessen können, dass sie jemals existiert haben.

Die Transaktion ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767aus der Live-Blockchain enthält viele syntaktisch falsche TXOUT-Skripte und ist als Demonstration nützlich:

mit pybitcointools:

#!/usr/bin/env python2.7                                                        

from bitcoin import *
tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767")
tx_dict = deserialize(tx_hex)
for (txout_num, txout) in enumerate(tx_dict["outs"]):
    script = txout["script"]
    print "raw txout %d script: %s" % (txout_num, script)

Ausgang:

raw txout 0 script: 01
raw txout 1 script: 0201
raw txout 2 script: 4c
raw txout 3 script: 4c0201
raw txout 4 script: 4d
raw txout 5 script: 4dffff01
raw txout 6 script: 4e
raw txout 7 script: 4effffffff01

Analyse jedes dieser Txout-Skripte:

01 = OP_PUSHDATA0(1)

dies schlägt fehl, weil es behauptet, es würde 1 Byte auf den Stack schieben, aber dann keine Bytes bereitstellen, die auf den Stack geschoben werden könnten

0201 = OP_PUSHDATA0(2) <01>

dies schlägt fehl, weil es behauptet, es würde 2 Bytes auf den Stack schieben, aber dann nur 1 Byte bereitstellen, um es auf den Stack zu schieben

4c = OP_PUSHDATA1(?)

dies schlägt fehl, da es sich um einen unvollständigen OP_PUSHDATA1-Opcode handelt. Auf das 4cByte sollte ein weiteres Byte folgen, das die Anzahl der Datenbytes angibt, die auf den Stapel verschoben werden sollen, dies ist jedoch nicht der Fall.

4c0201 = OP_PUSHDATA1(2) <01>

dies schlägt fehl, weil es behauptet, es würde 2 Bytes auf den Stack schieben, aber dann nur 1 Byte bereitstellen, um es auf den Stack zu schieben.

etc

Es ist lustig, dass die Ausgabeskripte in dieser speziellen Transaktion jeweils eine andere syntaktisch falsche Verwendung der OP_PUSHDATA-Befehle haben. Es ist fast so, als hätte jemand die gleiche Frage wie diese und wollte testen, ob eine Syntaxprüfung auf scriptpubkeys implementiert ist. Ich bin froh, dass sie dies getan haben, da dies eine sehr schlüssige Methode ist, um zu demonstrieren, dass absolut keine Syntaxprüfung (und daher auch keine anderen Prüfungen) an Skriptpubkeys durchgeführt wird, bevor sie ausgegeben werden.