Was ist die Erklärung für "Zeugenversion" und ihre Verwendung?

Was ist die Witness-Version und wie wird sie verwendet?

Eine Segwit-Transaktion besteht aus: [nVersion][Marker][Flag][txins][txouts][witness][nLockTime]

Aus dem BIP: "Ein Zeugenfeld beginnt mit einem var_int, um die Anzahl der Stack-Elemente für das TXIN anzugeben."

Wo kommt die Witness-Version ins Spiel und in welchen Szenarien kann sie verwendet werden?

Zweitens, warum heißt es, dass das Zeugenfeld mit einem var_int beginnt, um die Anzahl der Stack-Elemente für das TXIN anzugeben – sind Zeugendaten nicht nur eine Signatur? Oder bezieht es sich einfach auf Transaktionen mit mehr Eingaben, und die führende var_init zählt nur die Anzahl der Eingaben, also die erwarteten Signaturen?

Antworten (2)

Teil 1 der Frage wurde von Tony beantwortet.

Zeugendaten sind mehr als eine Signatur, Sie können einen Pub-Schlüssel „hinter“ der Signatur oder ein Einlösungsskript oder andere Smart Contracts haben. Werfen Sie einen Blick auf V_IN-Skripte ab Nicht-Segwit-tx.

Zum zweiten Teil Ihrer Frage: Die Zahl am Anfang (das Flag) identifiziert die Anzahl der Eingänge, die Zeugendaten haben. Sie könnten einen Tx erstellen, der 5 Eingänge hat, z. B. 2 Nicht-Segwit und 3 Segwit. Dann hat dieses Flag den Wert "3".

Siehe dieses Beispiel mit zwei V_INs und dem Flag-Wert "1", da nur ein Teil des TX Segwit/Witness-Daten enthält. Siehe auch am Ende die Anzahl der Segwit-Elemente für referenzierte V_IN (TX_IN[1]). Die ersten beiden Elemente sind eine Signatur (mit OP_SIGHASHSINGLE - hex 03 am Ende!), das dritte Element ist ein Pub-Schlüssel.

01000000000102FE3DC9208094F3FFD12645477B3DC56F60EC4FA8E6F5D67C565D1C6B9216B36E000000004847304402200AF4E47C9B9629DBECC21F73AF989BDAA911F7E6F6C2E9394588A3AA68F81E9902204F3FCF6ADE7E5ABB1295B6774C8E0ABD94AE62217367096BC02EE5E435B67DA201FFFFFFFF0815CF020F013ED6CF91D29F4202E8A58726B1AC6C79DA47C23D1BEE0A6925F80000000000FFFFFFFF0100F2052A010000001976A914A30741F8145E5ACADF23F751864167F32E0963F788AC000347304402200DE66ACF4527789BFDA55FC5459E214FA6083F936B430A762C629656216805AC0220396F550692CD347171CBC1EF1F51E15282E837BB2B30860DC77C8F78BC8501E503473044022027DC95AD6B740FE5129E7E62A75DD00F291A2AEB1200B84B09D9E3789406B6C002201A9ECD315DD6A0E632AB20BBB98948BC0C6FB204F2C286963BB48517A7058E27034721026DCCC749ADC2A9D0D89497AC511F760F45C47DC5ED9CF352A58AC706453880AEADAB210255A9626AEBF5E29C0E6538428BA0D1DCF6CA98FFDF086AA8CED5E0D0215EA465AC00000000

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
  TX_IN[0]:       6EB316926B1C5D567CD6F5E6A84FEC606FC53D7B474526D1FFF3948020C93DFE
  TX_IN[0] hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length hex=48, decimal=72
  TX_IN[0] Script Sig (uchar[]) 47304402200AF4E47C9B9629DBECC21F73AF989BDAA911F7E6F6C2E9394588A3AA68F81E9902204F3FCF6ADE7E5ABB1295B6774C8E0ABD94AE62217367096BC02EE5E435B67DA201       
  TX_IN[0] Sequence (uint32_t)
  FFFFFFFF
  TX_IN[1] F825690AEE1B3DC247DA796CACB12687A5E802429FD291CFD63E010F02CF1508
  TX_IN[1] hex=00000000, reversed=00000000, decimal=0
  TX_IN[1] Script Length hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t) FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
  TX_OUT[0] Value: hex=00F2052A01000000, dec=5000000000
  TX_OUT[0] PK_Script Length hex=19, dec=25
  TX_OUT[0] pk_script 76A914A30741F8145E5ACADF23F751864167F32E0963F788AC
  This is a P2PKH script, and translates base58 encoded into this bitcoin address: mvNy8bVyGDyuCiS1zMzm61eDtCBbUVfHPD

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=03, decimal=3
 WITNESS[0] data length (var_int), hex=47, decimal=71, data(uchar[]):
  304402200DE66ACF4527789BFDA55FC5459E214FA6083F936B430A762C629656216805AC0220396F550692CD347171CBC1EF1F51E15282E837BB2B30860DC77C8F78BC8501E503
 WITNESS[1] data length (var_int), hex=47, decimal=71, data(uchar[]):
  3044022027DC95AD6B740FE5129E7E62A75DD00F291A2AEB1200B84B09D9E3789406B6C002201A9ECD315DD6A0E632AB20BBB98948BC0C6FB204F2C286963BB48517A7058E2703
 WITNESS[2] data length (var_int), hex=47, decimal=71, data(uchar[]):
  21026DCCC749ADC2A9D0D89497AC511F760F45C47DC5ED9CF352A58AC706453880AEADAB210255A9626AEBF5E29C0E6538428BA0D1DCF6CA98FFDF086AA8CED5E0D0215EA465AC

 LOCK_TIME
00000000

Wenn Sie mit Zeugenversion die Skriptversion meinen, die mit dem SegWit-Upgrade hinzugefügt wurde, erklärt dieser Blogbeitrag von Bitcoin Core die Auswirkungen dieser Versionsnummer:

Segwit löst dies, indem es eine Versionsnummer für Skripte einschließt, sodass zusätzliche Opcodes, die eine Hard-Fork für die Verwendung in Nicht-Segwit-Transaktionen erfordert hätten, stattdessen durch einfaches Erhöhen der Skriptversion unterstützt werden können.

Bei Ihrer zweiten Frage ist Ihre Intuition richtig. Die Zahl entspricht der Anzahl der Eingänge.

Vielen Dank für Ihre Antwort. Was ist mit txins, die n-von-m-Signaturen sind? Nehmen wir an, ich erstelle einen Segwit-Tx mit 4 Txins: 3 reguläre p2wpkh und 1 p2wsh mit 5-von-8-Signaturen. die führende var_int wird hier 4 oder 8 sein?
@skydanc3r Die Protokolldokumentation beschreibt die Zeugendaten als „Eine Zeugenliste, eine für jede Eingabe …“ unter der Tabelle für die tx-Datenstruktur. Ref: en.bitcoin.it/wiki/Protocol_documentation#tx
In diesem Fall bezüglich meiner Frage im zweiten Kommentar enthält der Zeuge ErlöseScript + Signaturen (5 von 8) und wird als 1 Zeugenelement gezählt?
@skydanc3r Ich bin mir da nicht ganz sicher, aber ich denke, diese Frage würde einen weiteren separaten Fragepost rechtfertigen. Die Antwort auf diese Frage würde mich auch sehr interessieren.