Ausgabefelder und Interpretation von decoderawtransaktionen erklären

Ihr Beitrag ist etwas lang, beim Stack-Tausch bevorzugen wir Shotrt, einfach zu beantwortende Fragen - siehe hier: https://bitcoin.stackexchange.com/help/how-to-ask

Sie haben wahrscheinlich ein Beispiel für eine JSON-Interpretation als Referenz. Von wo hast du es? Da jeder eine Rohtransaktion interpretieren kann, denke ich, dass es am besten ist, auf die ursprüngliche Rohtransaktion von bitcoin.org zu verweisen . Dies ist eindeutig. Es würde so aussehen (Nicht-Segwit, um es einfach zu halten. Segwit nur auf Anfrage :-)

VERSION
TX_IN COUNT         (how many input this tx has)
 TX_IN[0...n]
  OutPoint hash     (the previous tx where funds come from)
  OutPoint index    (the n'th TX_IN)
  Script Length     (the length of the following Script Sig)
  Script Sig        (signature)
  Sequence          (a sequence field, originally intended to disable lock-time) 
TX_OUT COUNT        (how many outputs this tx has)
 TX_OUT[0...n]
  Value             (the value in Satoshis)
  PK_Script Length  (length of the following script)
  pk_script         (the script, which defines the condition, under which the funds can be spent)
LOCKTIME            (earliest time or earliest block when that transaction may be added to the block chain)

Der Zusammenbau eines zu sendenden TX wurde durch die Antwort von @amaclin hier ziemlich gut erklärt .

Wie kann die Menge jeder Eingabe innerhalb der vin-Teilmenge bestimmt werden?

Die Wallet-Software müsste die Werte nachschlagen, wenn sie eine neue TX ausgeben möchte. Dazu ist ein Verweis auf einen vorherigen tx erforderlich, in dem v_in zu finden ist. Wenn dies für den aktuellen Verbrauch nicht ausreicht, wird ein anderes v_in oder sogar ein anderes tx mit seinem v_in verwendet (der TX_IN-Zähler würde erhöht).

Wie kann die scriptSig validiert werden, z. B.: Ist die Eingabe CLTV oder CSV gesperrt?

Ich verstehe nicht, was Sie damit meinen. Scriptsig und CLTV/CSV sind nicht direkt mit scriptsig verknüpft. CLTV und CSV kamen beide durch BIP-68 und BIP-112 ins Spiel. CLTV (wie auch locktime) sind beides absolute Timelocks, bei CSV sprechen wir von relativen Timelocks. Sie definieren also, wann die Ausgabe einer Transaktion ausgegeben werden kann. Vielleicht lohnt es sich, in den BIPs nachzuschlagen. Es gibt auch viel im Forum hier und in Bitcointalk.

Scriptsig (im Allgemeinen) wird mit dem Hash und dem Pubkey validiert. Ken Shirrifs Blog (Link unten) erklärt sehr gut. Scriptsig beweist, dass Sie den privaten Schlüssel ("Sie sind der rechtmäßige Eigentümer") hatten, um diese Transaktion auszugeben. Der Privkey signiert einen Hash des tx, dem der Pubkey folgt. Da kann noch mehr sein, aber ich will allgemein bleiben. Hier ist ein Beispiel, wie Sie eine Signatur in der Unixoide-System-Shell mit openssl verifizieren können (Bitcoin verwendet immer hex-codierte Daten, um Hashes zu erstellen, und openssl benötigt einen PEM-formatierten Schlüssel):

sig=30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
pk=03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
hash=4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
printf $( echo $hash | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx_dsha256.hex
echo "MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=" > cat pubkey.pem
printf $( echo $sig | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sig.hex
openssl pkeyutl <tmp_utx_dsha256.hex -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex

Wird das RedeemScript (falls p2sh) als wahr validiert (z. B. erforderliche Anzahl verfügbarer Zeichen, andere IF/ELSE-Regeln erfüllt)?

Das Einlöseskript ist im Grunde ein Hash von "etwas". Es hat den Vorteil, dass „versteckt“ wird, was beabsichtigt ist, wenn die Finanzierungstransaktion in die Blockchain geschürft wird. Wenn Sie Ihre Ausgabentransaktion erstellen, werden die Daten Ihres p2sh-Skripts angezeigt. Die übliche Verwendung ist ein Multisig-Skript. Aber Sie können jede Art von Code hineinstecken, der die Bedingung definiert, unter der Gelder ausgegeben werden können (neben Multisig, jede Art von Smart Contracts, ...). Es gibt Einschränkungen. Die verwendbaren OPCODES werden hier erklärt . In bitcoin.org gibt es auch Erklärungen zu p2sh.

All das habe ich aus 2 weiteren Referenzen gelernt: dem unglaublich gut geschriebenen Buch „Mastering Bitcoin“ von Andreas, und einer sehr guten Erklärung zu Transaktionen von Ken Shirrif .

txid - Hash der Transaktion selbst

In der Tat. Es ist der Hash der Transaktion ohne enthaltene Zeugendaten (falls vorhanden).

Hash - Hash der Transaktion selbst. Wenn die Transaktion kein Segwit ist, ist txid == Hash, andernfalls ist der Transaktions-Hash in Segwit-Transaktionen anders.

In der Tat. Es ist der Hash der Transaktion mit eingeschlossenen Zeugendaten (falls vorhanden). Die Serialisierung, über die dies berechnet wird, ist in BIP144 definiert .

Version - das ist offensichtlich, was es ist, aber wie sollte interpretiert werden?

Es meldet den Inhalt des Transaktionsfeldes nVersion.

Derzeit sind zwei Transaktionsversionsnummern definiert:

• 1: die ursprüngliche Versionsnummer
• 2: definiert in BIP68 . Bei Transaktionen mit dieser Versionsnummer (oder höher) werden die nSequenceFelder gemäß den neuen Regeln interpretiert, die in BIP68 festgelegt sind.
• Alle anderen Versionsnummern sind nicht standardmäßig (werden nicht von gängiger Knotensoftware im Netzwerk weitergeleitet), sind jedoch zulässig, um Gültigkeitsregeln zu blockieren. 0 hat dieselbe Bedeutung wie 1; 3 und höher haben die gleiche Bedeutung wie 2.

size - Größe der Transaktion in Byte

In der Tat. Es ist die Größe der Serialisierung der Transaktion.

vsize - gewichtete Größe für Segwit-Transaktionen

In der Tat. Es ist die Größe der Serialisierung, bei der Witness-Daten um den Faktor 4 abgezinst werden, wie in BIP141 angegeben .

locktime - Sperrzeit dieser Transaktion entweder in Blockhöhe oder in Unix-Zeit. OP_CLTV ist nur aus dem Redescript ermittelbar, nicht aus diesem Feld.

In der Tat. Es meldet den Wert des Transaktionsfelds nLocktime. Es ist die Zeit oder Höhe, bis zu der die Transaktion nicht in einen Block aufgenommen werden kann. So kann beispielsweise eine Transaktion mit locktime700000 nur in Blöcke mit einer Höhe von 700001 oder höher aufgenommen werden.

Der OP_CHECKLOCKTIMEVERIFYOpcode (auch bekannt als OP_CLTV; definiert in BIP65nLocktime ) bietet eine Möglichkeit, Einschränkungen im Feld der Ausgabentransaktion von innerhalb von Skripten und damit indirekt für die Zeit, in der die Ausgabe ausgegeben werden kann, durchzusetzen . Es ist in allen Skriptkonstruktionen (bare, P2SH, P2WSH, ...) verfügbar, wäre aber in nackten nicht standardisiert.

vin - diese Teilmenge enthält alle ausgegebenen Eingaben.

Dies ist ein Array, das Informationen über alle Eingaben der Transaktionen enthält, die in seinem vinFeld gespeichert sind.

• txid - txid der ausgegebenen Eingabe.

Genauer gesagt ist es der hashWert des Felds der Transaktionseingabe prevout, das die txid der Transaktion enthält, die das von dieser Eingabe ausgegebene UTXO erzeugt hat.

• vout - was ist das?

Es ist der nWert des Felds der Transaktionseingabe prevout. voutEs meldet, welcher Index im Array der erstellenden Transaktion ausgegeben wird.

• scriptSig - asm / hex - dies beinhaltet die Signatur(en) und das Einlöseskript dieser bestimmten Eingabe. Gibt es einen Unterschied zwischen asm und hex?

In der Tat. Der Hex-Wert ist genau das, was in der Transaktion gespeichert wird. Der asm-Wert ist eine besser lesbare Dekodierung dieser Daten.

• Reihenfolge - wie ist das zu interpretieren? Wie kann man feststellen, ob die Eingabe entweder CSV-gesperrt oder durch Gebühr (RBF) ersetzbar ist?

Es ist der Wert des Transaktionsfelds nSequence.

Seine moderne Bedeutung ist zweifach:

• Immer wenn eine Transaktion nVersion2 oder höher hat und der nSequenceWert kleiner als 2 ² ist , gelten die BIP68- Regeln, die einschränken, wie lange die ausgegebene Ausgabe zurückliegen muss, bevor diese Transaktion gültig ist (in Höhe oder Zeit). Der BIP112- Opcode OP_CHECKSEQUENCEVERIFY(auch bekannt als OP_CSV) bietet im Skript eine Möglichkeit, den Wert einzuschränken nSequence(und damit indirekt die relative Zeit, die die Ausgabe verbringen kann).
• BIP125 spezifiziert eine potenzielle Richtlinie (keine Konsensregel) für Knoten zum Ersetzen von Transaktionen, während sie sich im Mempool befinden. Insbesondere ermöglicht es das Ersetzen jeder Transaktion, deren nSequenceWert nicht 0xFFFFFFF oder 0xFFFFFFFE ist. Dies ist der Fall für alle Transaktionseingaben, die eine relative Sperrzeit verwenden, wie im obigen Aufzählungspunkt beschrieben. Beachten Sie, dass moderne Knoten zum Zeitpunkt des Schreibens die BIP125-Richtlinienregeln nicht genau implementieren , wenn auch nicht in einer Weise, die diese Beschreibung ungültig macht.

vout - diese Teilmenge enthält alle Ausgaben der Transaktion:

Dies ist ein Array, das Informationen über alle Ausgaben der Transaktionen enthält, die in seinem voutFeld gespeichert sind.

• Wert - Betrag dieser Ausgabe.

In der Tat.

• n - das sieht aus wie die Anzahl / Reihenfolge der Ausgänge?

Es ist das Analogon des vout- Feldes in den Eingängen. Wenn eine Eingabe ein bestimmtes UTXO ausgibt, das von dieser Ausgabe erstellt wurde, muss sie auf die txid und das Feld dieser Transaktion verweisen n.

• scriptPubKey - Skript oder Pubkeyhash der Ausgabe

Es enthält das Sperrskript des zu erstellenden UTXO, das die Bedingungen definiert, unter denen es ausgegeben werden kann. Für P2PKH-Ausgaben ist dies ein Skript, das eine Signatur durch einen öffentlichen Schlüssel erfordert, dessen Hash ein bestimmter Wert ist, aber es ist immer noch ein Skript.

• reqSigs - wie kann dies dem Absender im Voraus bekannt sein, nur indem er die Adresse hat?

Dies ist möglich, jedoch nur für bloße Multisig-Skripte (bei denen das vollständige Skript direkt in der Ausgabe gespeichert wird und nicht über ein Einlöseskript), die als veraltet und nicht standardmäßig geschrieben werden. Das reqSigs-Feld wird aus diesem Grund jetzt auch als veraltet markiert. Es ist nur verwirrend.

• Typ - wie kann man das auch im Voraus wissen?

Es ist die Art der Ausgabe . zB kann es den Unterschied zwischen einer P2PKH- oder P2SH-Ausgabe erkennen. Es kann nicht wissen, was das Skript der P2SH-Ausgabe ist, bis es ausgegeben wird.

• Wie kann die Menge jeder Eingabe innerhalb der vin-Teilmenge bestimmt werden?

Es wird in der UTXO-Set-Datenbank zum Zeitpunkt des Verbringens nachgeschlagen, indem die Felder txidund verwendet werden vout, die in der RPC-Ausgabe gemeldet werden. Diese beiden eindeutigen identifizieren eine Transaktionsausgabe (Nummer voutder Transaktion, deren txid txid) ist, und der UTXO-Satz merkt sich seine amountund scriptPubKey-Felder.

• Wie kann die scriptSig validiert werden, z. B.: Ist die Eingabe CLTV oder CSV gesperrt? Wird das RedeemScript (falls p2sh) als wahr validiert (z. B. erforderliche Anzahl verfügbarer Zeichen, andere IF/ELSE-Regeln erfüllt)?

Die Ausführung läuft grob wie folgt ab:

• Zuerst scriptSigwird die ausgeführt. Der endgültige Stack-Zustand wird gespeichert. Wenn dies fehlschlägt, ist die Transaktion ungültig.
• Dann scriptPubKeywird die ausgegebene Ausgabe ausgeführt, mit dem vorherigen Endzustand des Stacks als Anfangszustand. Dies scriptPubKeywird in der oben aufgeführten UTXO-Datenbank nachgeschlagen. Was dies effektiv bewirkt, ist das Ausführen des Sperrskripts mit der scriptSigEingabe as; Wenn dies fehlschlägt, ist die Transaktion ungültig.
• Dann, als besonderer Schritt, wenn das genau mit scriptPubKeyder Vorlage BIP16 (P2SH) übereinstimmt , wird eine zusätzliche Regel ausgelöst: Das letzte scriptSig-Element wird als ein anderes Skript behandelt und mit allen außer dem letzten scriptSig-Element als Eingabe ausgeführt.

Ähnliche Regeln gelten für P2WSH (BIP141)- und P2TR (BIP341)-Ausgaben.

Mit Bitcoin-Core würden Sie verwendendecoderawtransaction

https://en.bitcoin.it/wiki/Raw_transactions#decoderawtransaction_.3Chex_string.3E

Beispiel mit meinem Knoten

decoderawtransaction 01000000000101502c5d0d5e7e869ff1b40cc1542695fb35830355861f61932645fa1b1a149a5d0e000000171600149a1c78a507689f6f54b847ad1cef1e614ee23f1effffffff01c8f703000000000017a914691ad0b9182c753a26bed191e470b85236b67a878702483045022100817d7d87af9568c025e5dac8bc2b27bdac7181779b81ed5dc8a468f970c33124022059e09b0b5f48516b01ed2262084c8ba1a58a250b3f2e39a69b890f68237e8cb5012103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd00000000



{
  "txid": "1c5cb1487867459952d78624577788723f7d11d8ba39d211e524a9527d683152",
  "hash": "a660d4e8f9f9fc18866a38bac30f25ceef5ecfc8eaf640fc93004b3ea8763d9f",
  "version": 1,
  "size": 216,
  "vsize": 134,
  "weight": 534,
  "locktime": 0,
  "vin": [
    {
      "txid": "5d9a141a1bfa452693611f8655038335fb952654c10cb4f19f867e5e0d5d2c50",
      "vout": 14,
      "scriptSig": {
        "asm": "00149a1c78a507689f6f54b847ad1cef1e614ee23f1e",
        "hex": "1600149a1c78a507689f6f54b847ad1cef1e614ee23f1e"
      },
      "txinwitness": [
        "3045022100817d7d87af9568c025e5dac8bc2b27bdac7181779b81ed5dc8a468f970c33124022059e09b0b5f48516b01ed2262084c8ba1a58a250b3f2e39a69b890f68237e8cb501",
        "03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00260040,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 691ad0b9182c753a26bed191e470b85236b67a87 OP_EQUAL",
        "hex": "a914691ad0b9182c753a26bed191e470b85236b67a8787",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3BGkzr6ioLszJjqX2msqXjqDAFdUVtBY2T"
        ]
      }
    }
  ]
}