¿Qué es el Testigo y qué datos contiene?

Aprendí sobre el Testigo Segregado pero no pude encontrar información sobre cómo desglosarlo.

Sé que, por lo general, cuando se utilizan direcciones heredadas, las claves públicas, por ejemplo, estarán bajo Scriptig. Con P2SH, puedo ver que ScriptSigcontiene el hash del redeemScriptque debe coincidir con el hash de la dirección en la Salida (creo). Pero no estoy seguro de los witnessdatos.

Tomemos este TX: 80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369

¿Qué información hay en el witness, alguien puede desglosarla por favor?

Respuestas (3)

Esta estructura contiene datos necesarios para verificar la validez de la transacción, pero no necesarios para determinar los efectos de la transacción. En particular, los guiones y las firmas se trasladan a esta nueva estructura.

El testigo es una serialización de todos los datos testigo de la transacción. Cada txin está asociado con un campo testigo. Un campo testigo comienza con var_int para indicar el número de elementos de la pila para la txin. Le siguen los elementos de la pila, y cada elemento comienza con var_int para indicar la longitud. Los datos de testigos NO son secuencias de comandos. Ver BIP 141 .

Los datos de los testigos dependen del tipo de transacción.

Entrada 3

Mirando la entrada de transacción n. ° 3 en el json sin formato :
script =a914771962306e72e479245d48e879dd2a1862225b4c87

Tiene la estructura de una transacción Pay to Script Hash (P2SH). Debido a los datos del testigo, este es probablemente un P2WSH multisig anidado en BIP16 P2SH :

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)

testigo:
04(4 elementos de la pila)

00(primer elemento de la pila, 0 bytes)

47(segundo elemento de pila, primera firma, hexadecimal: 0x47 decimal: 71 bytes)304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901

47(3er elemento de pila, segunda firma, hexadecimal: 0x47 decimal: 71 bytes)30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01

69(Cuarto elemento de la pila, script multigrado 2 de 3, hexadecimal: 0x69 decimal: 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>

Tenga en cuenta que OP_2e OP_3indica que se trata de un script de transacción multisig de 2 de 3. Consulte Pay-to-Script-Hash | Transacción

¡Gracias! Ahora entiendo mucho mejor los datos de los testigos. Una última aclaración por favor. Entonces el comando OP_1dice tomar estas dos firmas y agregarlas a la pila . OP_2indica que se agreguen las siguientes tres pubKeys y OP_3dice que para validar este TX, OP_1se necesitan 2 de 3 firmas correspondientes a ? ¿O se necesitarán 2 de 3 firmas para completar la TX en la próxima ENTRADA? La decodificación de la scriptSigEntrada 3 no da como resultado multiSig. 002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87da type: scripthash_ Gracias de nuevo.
Alguien tendrá que corregirme si me equivoco, pero creo que el 0x04 le dice que hay 4 elementos de pila, no hay OP_1 (hay un elemento de pila vacío, no estoy seguro de por qué), el formato para un P2SH multisig es : m-of-n multi-signature transaction: scriptSig: 0 <sig1> ... <script> script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIGVer en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash
Sé que es un tema antiguo, pero me gustaría un poco más de información sobre el elemento de la pila 4, como vi que es el script de canje, pero una vez que uso las claves públicas para generar la clave multisig, es diferente. ¿Alguna idea?

Para las variantes segwit de una salida (P2PKH se convierte en P2WPKH y P2SH se convierte en P2WSH), el testigo contiene los mismos datos que se encontrarían en scriptSig. Para P2PKH, en scriptSig, tendría una firma y una clave pública. Lo mismo está en el testigo de un P2WPKH.

Para P2SH, tendría un script de canje, firmas y otras cosas en scriptSig. Para P2WSH, esos están en el testigo y el script redimido en el testigo se conoce como el script del testigo.

Es importante tener en cuenta que el testigo se verá diferente al scriptSig. Esto se debe a que en realidad no es un script sino una pila de elementos. Un scriptSig estándar es uno que solo empuja elementos a la pila. El testigo lleva esto un paso más allá al proporcionar una pila para usar en lugar de tener que ejecutar un script que produce la misma pila.

Además de JBaczuk y Andrew Chow, aquí hay una decodificación detallada de tx. Esta es una transacción mixta, con tres entradas "normales" y una cuarta entrada de tipo segwit (TX_IN[3]). Por lo tanto, después del campo de versión del tx, vemos los bytes "0001", con 0x01 que indica que se incluye una estructura de datos segwit en el tx. En la sección de entrada, hay tres elementos "estándar" siguientes, también con firmas multisig. El cuarto elemento de entrada (TX_IN[3]) es la parte segwit. Los scripts no contienen firmas, solo la estructura 0x0020{scripthash} de 32 bytes.

Al final sigue 0x00000004, cada byte es el número de elementos segwit por entrada. Entonces, los primeros tres bytes son "0", lo que significa que no se sigue ninguna estructura segwit para estas entradas, y luego el cuarto byte es 0x04, lo que indica cuatro elementos de datos testigo: un "0x00" para compensar la eliminación del elemento de pila durante la evaluación del script, una firma, otra firma y el script de redención.

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

Un buen resumen de todos los detalles del segwit está aquí .

Gracias por tu respuesta. ¿Puedo preguntar qué usas para decodificar un TX con tanto detalle? Estoy usando chainquery.com
Aprendí a través del libro de Andreas y el foro aquí, así que escribí algunos scripts de shell unixoide. Y si se permite la autocomercialización (descaradamente), el código se puede encontrar aquí: github.com/pebwindkraft/trx_cl_suite . El conjunto de transacciones tiene la herramienta (script de shell) „tcls_tx2txt.sh“, para decodificar de la manera que se muestra arriba (y luego lo embellecí un poco, así que encaja mejor en el foro aquí).
Excelente. Pronto jugaré con el guión en bash, ¡gracias! Esto es útil para cualquier persona interesada en la comunidad, así que no creo que sea como publicidad :)