explicar los campos de salida e interpretación de decoderrawtransaction

Su publicación es un poco larga, en el intercambio de pila preferimos shotrt, preguntas fáciles de responder: consulte aquí: https://bitcoin.stackexchange.com/help/how-to-ask

Probablemente tenga un ejemplo de una interpretación JSON como referencia. ¿De dónde lo tienes? Como todos pueden interpretar una transacción sin procesar, creo que es mejor hacer referencia a la transacción sin procesar original de bitcoin.org . Esto es anambigo. Se vería así (sin segwit, para que sea sencillo. Segwit solo a pedido :-)

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)

El montaje de un tx antes de ser enviado fue bastante bien explicado por la respuesta de @amaclin aquí .

¿Cómo se puede determinar la cantidad de cada entrada dentro del subconjunto vin?

El software de la billetera necesitaría buscar los valores cuando desee gastar un nuevo tx. Por lo tanto, se requiere una referencia a un tx anterior, donde se encuentra v_in. Si no es suficiente para la corriente gastada, se utilizará otro v_in o incluso otro tx con su v_in (se incrementaría el recuento de TX_IN).

¿Cómo se puede validar el scriptSig, como: está bloqueada la entrada CLTV o CSV?

No entiendo lo que quieres decir con esto. Scriptsig y CLTV/CSV no están directamente vinculados a scriptsig. CLTV y CSV entraron en el juego por BIP-68 y BIP-112. CLTV (como también locktime) son bloqueos de tiempo absolutos, con CSV hablamos de bloqueos de tiempo relativos. Por lo tanto, definen cuándo se puede gastar la producción de una transacción. Tal vez valga la pena buscar en los BIP. También hay mucho en el foro aquí y en bitcointalk.

Scriptsig (en general) se valida con el hash y la clave pública. El blog de Ken Shirrif (enlace en la parte inferior) lo explica muy bien. Pruebas de Scriptsig, que tenía la clave privada ("usted es el propietario legítimo") para gastar esta transacción. El privkey firma un hash del tx, que es seguido por el pubkey. Puede haber más, pero quiero quedarme en general. Aquí hay un ejemplo de cómo puede verificar una firma en el shell de los sistemas unixoide con openssl (bitcoin siempre usa datos codificados en hexadecimal para hacer hashes, y openssl necesita una clave con formato PEM):

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

¿Se valida el script de redimir (si es p2sh) como verdadero (por ejemplo, el número requerido de firmas disponibles, otras reglas IF/ELSE cumplidas)?

El script redimido es básicamente un hash de "algo". Tiene la ventaja de "ocultar", lo que se pretende, cuando la transacción de financiación se extrae en la cadena de bloques. Cuando crea su transacción de gastos, se revelan los datos de su script p2sh. El uso común es un script multisig. Pero puede poner todo tipo de código en él, lo que definiría la condición bajo la cual se pueden gastar los fondos (junto a multisig, cualquier tipo de contrato inteligente, ...). Hay limitaciones para ello. Los OPCODES que se pueden utilizar se explican aquí . En bitcoin.org también hay explicaciones sobre p2sh.

Aprendí todo esto de 2 referencias adicionales: el libro increíblemente bien escrito "Mastering Bitcoin" de Andreas, y una muy buena explicación sobre transacciones de Ken Shirrif .

txid - hash de la transacción en sí

En efecto. Es el hash de la transacción sin datos de testigos incluidos (si los hay).

hash - hash de la transacción en sí. Si la transacción no es segwit, txid == hash; de lo contrario, en las transacciones segwit, el hash de la transacción es diferente.

En efecto. Es el hash de la transacción con datos de testigos incluidos (si los hay). La serialización sobre la que se calcula se define en BIP144 .

versión : esto es obvio, pero ¿cómo debe interpretarse?

Reporta el contenido del nVersioncampo de la transacción.

Actualmente hay dos números de versión de transacción definidos:

• 1: el número de versión original
• 2: definido en BIP68 . Las transacciones con este número de versión (o superior) tienen sus nSequencecampos interpretados de acuerdo con las nuevas reglas especificadas en BIP68.
• Cualquier otro número de versión no es estándar (no será transmitido por el software de nodo común en la red), pero está permitido por las reglas de validez de bloqueo. 0 tiene el mismo significado que 1; 3 y superiores tienen el mismo significado que 2.

tamaño - tamaño de la transacción en bytes

En efecto. Es el tamaño de la serialización de la transacción.

vsize - tamaño ponderado para transacciones segwit

En efecto. Es el tamaño de la serialización, donde los datos testigo se descuentan por un factor de 4, como se especifica en BIP141 .

locktime - tiempo de bloqueo de esta transacción ya sea en altura de bloque o en tiempo de Unix. OP_CLTV solo se puede determinar desde el script de redención, no desde este campo.

En efecto. Reporta el valor del nLocktimecampo de la transacción. Es el tiempo o altura hasta el cual la transacción no puede ser incluida en un bloque. Entonces, por ejemplo, una transacción con locktime700000 solo se puede incluir en bloques con una altura de 700001 o superior.

El OP_CHECKLOCKTIMEVERIFYcódigo de operación (también conocido como OP_CLTVdefinido en BIP65 ) proporciona una forma de hacer cumplir las restricciones en el nLocktimecampo de la transacción de gasto desde los scripts internos y, por lo tanto, indirectamente en el tiempo en que se puede gastar la salida. Está disponible en todas las construcciones de secuencias de comandos (bare, P2SH, P2WSH, ...), pero no sería estándar en las simples.

vin : este subconjunto incluye todas las entradas que se gastan.

Esta es una matriz que contiene información sobre todas las entradas de las transacciones, que se almacenan en su vincampo.

• txid - txid de la entrada que se está gastando.

Más específicamente, es el hashvalor del prevoutcampo de entrada de la transacción, que contiene el txid de la transacción que creó el UTXO gastado por esta entrada.

• vout - ¿qué es esto?

Es el nvalor del campo de entrada de la transacción prevout. Informa qué índice en la voutmatriz de la transacción de creación se está gastando.

• scriptSig - asm / hex - esto incluye las firmas y el script redimido de esta entrada en particular. ¿Hay alguna diferencia entre asm y hexadecimal?

En efecto. El valor hexadecimal es exactamente lo que se almacena en la transacción. El valor asm es una decodificación más legible por humanos de esos datos.

• secuencia : ¿cómo se puede interpretar esto? ¿Cómo se puede determinar si la entrada está bloqueada en CSV o reemplazable por tarifa (RBF)?

Es el valor del nSequencecampo de la transacción.

Su significado moderno es doble:

• Cada vez que una transacción tiene nVersion2 o más, y el nSequencevalor es menor que 2 ² , se aplican las reglas BIP68 , lo que impone restricciones sobre cuánto tiempo hace que debe gastarse la salida antes de que esta transacción sea válida (en altura o tiempo). El código de operación BIP112OP_CHECKSEQUENCEVERIFY (también conocido como OP_CSV) proporciona un medio en el script para poner restricciones en el nSequencevalor (y, por lo tanto, indirectamente en el tiempo relativo que se puede gastar la salida).
• BIP125 especifica una política potencial (no una regla de consenso) para los nodos sobre el reemplazo de transacciones mientras están en el mempool. Específicamente, permite el reemplazo de cualquier transacción cuyo nSequencevalor no sea 0xFFFFFFF o 0xFFFFFFFE. Este es el caso de cualquier entrada de transacción que utilice un tiempo de bloqueo relativo, como se explica en el punto anterior. Tenga en cuenta que los nodos modernos al momento de escribir no implementan exactamente las reglas de la política BIP125 , aunque no de una manera que invalide esta descripción.

vout : este subconjunto incluye todas las salidas de la transacción:

Esta es una matriz que contiene información sobre todas las salidas de las transacciones, que se almacenan en su voutcampo.

• valor - cantidad de esta salida.

En efecto.

• n : ¿esto se parece al número/orden de las salidas?

Es el análogo del campo vout en las entradas. Cuando una entrada gasta un UTXO particular creado por esta salida, debe hacer referencia al txid y al ncampo de esta transacción.

• scriptPubKey - script o pubkeyhash de la salida

Contiene el script de bloqueo de la UTXO que se está creando, que define las condiciones bajo las cuales se puede gastar. Para salidas P2PKH, este es un script que requiere una firma por una clave pública cuyo hash es un valor específico, pero sigue siendo un script.

• reqSigs : ¿cómo puede saber esto de antemano el remitente, solo teniendo la dirección?

Puede, pero solo para secuencias de comandos multisig simples (donde la secuencia de comandos completa se almacena directamente en la salida, y no a través de un script de rescate), que están en desuso y no son estándar como escritura. El campo reqSigs también está obsoleto ahora por ese motivo. Es confuso.

• tipo : ¿cómo se puede saber esto de antemano también?

Es el tipo de salida . por ejemplo, puede notar la diferencia entre una salida P2PKH o P2SH. No puede saber cuál es el script de salida de P2SH hasta que se gasta.

• ¿Cómo se puede determinar la cantidad de cada entrada dentro del subconjunto vin?

Se busca en la base de datos de conjuntos de UTXO al pasar el tiempo, utilizando los campos txidy informados en la salida de RPC. voutEsos dos identifican de forma única la salida de una transacción (número voutde transacción cuyo txid es txid), y el conjunto UTXO recuerda sus campos amounty .scriptPubKey

• ¿Cómo se puede validar el scriptSig, como: está bloqueada la entrada CLTV o CSV? ¿Se valida el script de redimir (si es p2sh) como verdadero (por ejemplo, el número requerido de firmas disponibles, otras reglas IF/ELSE cumplidas)?

La ejecución procede de la siguiente manera, aproximadamente:

• Primero scriptSigse ejecuta. Se recuerda el estado final de la pila. Si falla, la transacción no es válida.
• Luego scriptPubKeyse ejecuta el de la salida que se está gastando, con el estado final anterior de la pila como estado inicial. Esto scriptPubKeyse busca en la base de datos de UTXO como se indica arriba. Entonces, lo que esto hace efectivamente es ejecutar el script de bloqueo, con scriptSigcomo entrada; si eso falla, la transacción no es válida.
• Luego, como un paso especial, si scriptPubKeycoincide exactamente con la plantilla BIP16 (P2SH), se activa una regla adicional: el elemento scriptSig final se trata como otro script y se ejecuta con todos menos el elemento scriptSig final como entrada.

Se aplican reglas similares a los gastos P2WSH (BIP141) y P2TR (BIP341).

Con bitcoin-core usaríasdecoderawtransaction

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

Ejemplo con mi nodo

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"
        ]
      }
    }
  ]
}