Was ist der Zeuge und welche Daten enthält er?

Ich habe von dem Segregated Witness erfahren, konnte aber keine Informationen darüber finden, wie man ihn aufschlüsselt.

Ich weiß, dass normalerweise, wenn Legacy-Adressen verwendet werden, die öffentlichen Schlüssel zum Beispiel unter Scriptig. Mit P2SH kann ich sehen, dass der ScriptSigden Hash von enthält redeemScript, der mit dem Hash der Adresse in der Ausgabe übereinstimmen muss (glaube ich). Aber bei den witnessDaten bin ich mir nicht sicher.

Nehmen wir diesen TX: 80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369

Welche Informationen sind in der witness, kann jemand sie bitte aufschlüsseln?

Antworten (3)

Diese Struktur enthält Daten, die zum Überprüfen der Transaktionsgültigkeit, aber nicht zum Bestimmen von Transaktionseffekten erforderlich sind. Insbesondere Skripte und Unterschriften werden in diese neue Struktur verschoben.

Der Zeuge ist eine Serialisierung aller Zeugendaten der Transaktion. Jedem TXIN ist ein Witness-Feld zugeordnet. Ein Witness-Feld beginnt mit einem var_int, um die Anzahl der Stack-Elemente für das TXIN anzugeben. Es folgen Stapelelemente, wobei jedes Element mit einem var_int beginnt, um die Länge anzugeben. Zeugendaten sind KEIN Skript. Siehe BIP 141 .

Zeugendaten hängen von der Art der Transaktion ab.

Eingang 3

Blick auf die Transaktionseingabe Nr. 3 im rohen json :
script =a914771962306e72e479245d48e879dd2a1862225b4c87

Diese hat die Struktur einer Pay-to-Script-Hash (P2SH)-Transaktion. Aufgrund der Zeugendaten ist dies wahrscheinlich ein Multisig- P2WSH, das in BIP16 P2SH verschachtelt ist :

witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig:    <0 <32-byte-hash>>
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
              (0xA914{20-byte-hash}87)

Zeuge:
04(4 Stapelelemente)

00(1. Stapelelement, 0 Bytes)

47(2. Stapelelement, erste Signatur, hex: 0x47 dezimal: 71 Bytes)304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901

47(3. Stapelelement, zweite Signatur, hex: 0x47 dezimal: 71 Bytes)30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01

69(4. Stapelelement, 2-von-3-Multisig-Skript, Hex: 0x69 dezimal: 105 Bytes)
<52 OP_2>
21(33 Bytes)
<021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe pubkey1>
21(33 Bytes)
<03bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38 pubkey2>
21(33 Bytes)
<0280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c65 pubkey3> <53 OP_3><ae OP_CHECKMULTISIG>

Beachten Sie, dass OP_2und OP_3angeben, dass dies ein 2-von-3-Multisig-Transaktionsskript ist. Siehe Pay-to-Script-Hash | Transaktion

Danke! Ich verstehe Zeugendaten jetzt viel besser. Eine letzte Klarstellung bitte. Der Befehl OP_1sagt also , nimm diese beiden Signaturen und füge sie dem Stack hinzu . OP_2weist an, die folgenden drei pubKeys hinzuzufügen , und OP_3sagt , um diesen TX zu validieren, werden 2 von 3 Signaturen OP_1benötigt, die entsprechen ? Oder werden 2 von 3 Unterschriften benötigt, um die TX im nächsten INPUT abzuschließen? Die Dekodierung scriptSigfür Eingang 3 führt nicht zu MultiSig. 002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87gibt type: scripthash. Danke noch einmal.
Jemand muss mich korrigieren, wenn ich falsch liege, aber ich glaube, die 0x04 sagt Ihnen, dass es 4 Stack-Elemente gibt, es kein OP_1 gibt (es gibt ein leeres Stack-Element, nicht sicher warum), das Format für ein Multisig-P2SH ist : m-of-n multi-signature transaction: scriptSig: 0 <sig1> ... <script> script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIGSiehe en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash
Ich weiß, dass es ein altes Thema ist, aber ich hätte gerne ein wenig mehr Informationen über das 4. Stack-Element, da ich gesehen habe, dass es sich um das Einlöseskript handelt, aber sobald ich die Pubkeys verwende, um einen Multisig-Schlüssel zu generieren, ist es anders. Irgendwelche Gedanken?

Für die Segwit-Varianten einer Ausgabe (P2PKH wird zu P2WPKH und P2SH wird zu P2WSH) enthält der Zeuge dieselben Daten, die in der scriptSig zu finden wären. Für P2PKH hätten Sie im scriptSig eine Signatur und einen Pubkey. Das gleiche ist im Zeugen für ein P2WPKH.

Für P2SH hätten Sie ein Einlöseskript, Signaturen und andere Dinge in der scriptSig. Für P2WSH befinden sich diese im Zeugen und das RedeemScript im Zeugen wird als WitnessScript bezeichnet.

Es ist wichtig zu beachten, dass der Zeuge anders aussieht als die scriptSig. Dies liegt daran, dass es sich nicht wirklich um ein Skript handelt, sondern um einen Stapel von Elementen. Ein Standard-ScriptSig ist eines, das nur Elemente auf den Stack schiebt. Der Zeuge geht noch einen Schritt weiter, indem er einen zu verwendenden Stapel bereitstellt, anstatt ein Skript ausführen zu müssen, das denselben Stapel erzeugt.

Zusätzlich zu JBaczuk und Andrew Chow gibt es hier eine detaillierte TX-Decodierung. Dies ist eine gemischte Transaktion mit drei "normalen" Eingaben und einer Eingabe vom Typ 4. Segwit (TX_IN[3]). Daher sehen wir nach dem Versionsfeld des TX die Bytes "0001", wobei 0x01 anzeigt, dass eine Segwit-Datenstruktur im TX enthalten ist. Im Eingabebereich gibt es drei folgende "Standard"-Elemente, ebenfalls mit Multisig-Signaturen. Das vierte Eingabeelement (TX_IN[3]) ist der Segwit-Teil. Das Skript enthält keine Signaturen, sondern nur die 0x0020{32-Byte-Skripthash}-Struktur.

Am Ende folgt 0x00000004, jedes Byte ist die Anzahl der Segwit-Elemente pro Eingang. Die ersten drei Bytes sind also „0“, was bedeutet, dass für diese Eingaben keine Segwit-Struktur folgt, und dann ist das vierte Byte 0x04, was vier Witness-Datenelemente anzeigt: ein „0x00“, um das Entfernen des Stack-Elements während der Skriptauswertung zu kompensieren, eine Signatur, eine weitere Signatur und das Einlöseskript.

VERSION 01000000
SEGWIT (BIP141):       this is a segwit tx, marker=00
       (BIP141):       flag=01
TX_IN COUNT [var_int]: hex=04, decimal=4
 TX_IN[0]
  TX_IN[0] OutPoint hash  08A1266CED5EF064741BD4BC51C1202456F22509AE030231860D6E9BEF4ACD5E
  TX_IN[0] OutPoint index hex=62000000, reversed=00000062, decimal=98
  TX_IN[0] Script Length  hex=FC, decimal=252
  TX_IN[0] Script Sig     0047304402207E38831ECA394E472E...555C0E2D7A9D9915D6986BFC200453AE 
  TX_IN[0] Sequence       FFFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash  AD4C8508B8D5EECE6FD100B58D667DEA9C7A8C178C1B06602C1E3358D8105C0B
  TX_IN[1] OutPoint index hex=7D000000, reversed=0000007D, decimal=125
  TX_IN[1] Script Length  hex=FC, decimal=252
  TX_IN[1] Script Sig     0047304402203299B925B1F2C87282...ABDC12E55B0F545FFF14667A515F53AE 
  TX_IN[1] Sequence       FFFFFFFF
 TX_IN[2]
  TX_IN[2] OutPoint hash  C8066B798384B502F225BD89F7EB405265357CB0BDC0C169FE96B013310629B2
  TX_IN[2] OutPoint index hex=A3000000, reversed=000000A3, decimal=163
  TX_IN[2] Script Length  hex=00FD, decimal=253
  TX_IN[2] Script Sig     0047304402204D4DA5303BE178D649...B5A43BC43D60C844F65DB8FB78AD53AE 
  TX_IN[2] Sequence       FFFFFFFF
 TX_IN[3]
  TX_IN[3] OutPoint hash  D80FF02D0D9EB2DA8C8A1C47AB099901F447DD197E34220EA13ECA72D7D6D21D
  TX_IN[3] OutPoint index hex=9A000000, reversed=0000009A, decimal=154
  TX_IN[3] Script Length  hex=23, decimal=35
  TX_IN[3] Script Sig     22002044C55C1DA36A576217259C3BC21B0C3943F7EB3FF4E3C381D9FD3502434B9E87 
  TX_IN[3] Sequence       FFFFFFFF
TX_OUT COUNT, hex=05, decimal=5
 TX_OUT[0]
  TX_OUT[0] Value         hex=C0D4010000000000, reversed_hex=000000000001D4C0, dec=120000
  TX_OUT[0] PK_Script Len hex=17, dec=23
  TX_OUT[0] pk_script     A914A1932CFD432D928311B4ADA550BBC468D1E909B787
 TX_OUT[1]
  TX_OUT[1] Value         hex=A086010000000000, reversed_hex=00000000000186A0, dec=100000
  TX_OUT[1] PK_Script Len hex=17, dec=23
  TX_OUT[1] pk_script     A9146B0E7A66416F1D8598B5956576ADB22DAF79853E87
 TX_OUT[2]
  TX_OUT[2] Value         hex=3A4A000000000000, reversed_hex=0000000000004A3A, dec=19002
  TX_OUT[2] PK_Script Len hex=17, dec=23
  TX_OUT[2] pk_script     A914EC4C73145428ABBE0B1C40FBF58C59F0EF3C29F487
 TX_OUT[3]
  TX_OUT[3] Value         hex=382C050000000000, reversed_hex=0000000000052C38, dec=339000
  TX_OUT[3] PK_Script Len hex=17, dec=23
  TX_OUT[3] pk_script     A914ABB18A298E5B629BF5652F341D2CD8207CCC214A87
 TX_OUT[4]
  TX_OUT[4] Value         hex=8010020000000000, reversed_hex=0000000000021080, dec=135296
  TX_OUT[4] PK_Script Len hex=19, dec=25
  TX_OUT[4] pk_script     76A91438D769CF2899983022B5611AB4D35BF7907DAE2088AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=00, decimal=0
WITNESS TXIN[2] stack elements: hex=00, decimal=0
WITNESS TXIN[3] stack elements: hex=04, decimal=4
 WITNESS data[0]: 00
 WITNESS data[1]: 4730440220...D207D14D45945A6901
 WITNESS data[2]: 4730440220...36B45FAFAEB96E0F01
 WITNESS data[3]: 695221021E...3234312D684C6553AE

LOCK_TIME 00000000

Eine gute Zusammenfassung aller Segwit-Details finden Sie hier .

Vielen Dank für Ihre Antwort. Darf ich fragen, was Sie verwenden, um einen TX mit solchen Details zu decodieren? Ich verwende chainquery.com
Ich habe durch das Buch von Andreas und das Forum hier gelernt, also habe ich einige unixoide Shell-Skripte geschrieben. Und wenn Eigenmarketing erlaubt ist (schamlos), dann ist der Code hier zu finden: github.com/pebwindkraft/trx_cl_suite . Die Transaktionssuite hat das Tool (Shellscript) „tcls_tx2txt.sh“, um es wie oben gezeigt zu dekodieren (und dann habe ich es etwas verschönert, damit passt es hier besser ins Forum).
Exzellent. Ich werde bald mit dem Skript auf Bash spielen, danke! Dies ist nützlich für alle, die sich für die Community interessieren, daher denke ich nicht, dass es wie Werbung ist :)