¿Cuáles son los formatos estándar de los resultados de las transacciones?

Una salida de transacción puede tener el tipo

  • Pague al hash de clave pública, P2PKH, donde el campo ScriptPubKey tiene el formato:

    76 a9 14 <hash de 20 bytes de clave pública> 88 ac

  • Pagar al hash de secuencia de comandos, P2SH, utilizado, por ejemplo, para multisig:

    a9 14 <hash de script de 20 bytes> 87

También hay algo llamado P2WPKH y P2WSH. ¿Puede mostrarme cómo se formatean estas salidas y hay más formatos de salida posibles que estos cuatro?

los formatos de SegWit: en.bitcoin.it/wiki/Segregated_Witness , o aquí: bitcoincore.org/en/segwit_wallet_dev . Y luego hubo en los primeros tiempos "pago a clave pública", y los antiguos tipos "multisig" (no P2SH). No estoy seguro de si todavía son válidos hoy.
No conocía el formato de pago a clave pública. ¡Interesante! Había oído hablar del tipo "multisig", pero nunca lo encontré ni una descripción del mismo.
Creo que se llamaba bare multisig. Y fue BIP0011. Una búsqueda rápida en el foro: bitcoin.stackexchange.com/questions/29708/…

Respuestas (1)

AFAIK hay 5 tipos diferentes de transacciones estándar que no son de SegWit y 4 de SegWit.

Sin SegWit:

Pagar a clave pública (P2PK)

PUSH (1 byte) + <compressed/uncompressed_pk> (33/65 bytes) + OP_CHECKSIG (1 byte)

Pagar al hash de clave pública (P2PKH)

OP_DUP (1 byte) + OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(PK)> (20 bytes) + OP_EQUALVERIFY (1 byte) + OP_CHECKSIG (1 byte)

Multigrado (P2MS)

<number_of_PKs> (1 byte) PUSH (1 byte) <PK_0> (33/65 bytes) PUSH (1 byte) <PK_1> (33/65 bytes)  ... PUSH (1 byte) <PK_n-1> (33/65 bytes) OP_CHECKMULTISIG (1 byte)

P2MS permite hasta 15-15 scripts, sin embargo, solo hasta 3-3 son estándar.

Pagar al hash de secuencia de comandos (P2SH)

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash160(redeem_script)> (20 bytes) + OP_EQUAL (1 byte)

OP_Retorno

OP_RETURN (1 byte) PUSH (1 byte) <0 to 83 bytes of data>

SegWit:

En cuanto a los tipos de segwit, hay dos no nativos y dos nativos.

Pago nativo para presenciar hash de clave pública (P2WPKH)

OP_0 (1 byte) PUSH (1 byte) <hash 160(PK*)> (20 bytes)

Pago nativo para presenciar hash de script (P2WSH)

OP_0 (1 byte) PUSH (1 byte) <script_hash> (32 bytes)

Hash de clave pública de pago para presenciar encapsulado en un hash de script de pago (P2SH-P2WPKH)

El script de canje sigue la misma estructura que el P2WPKH nativo:

redeem_script = OP_0 (1 byte) PUSH (1 byte) <hash_160(PK*)> (20 bytes)

Mientras que la estructura externa del script ( scriptPubKey) es como cualquier otro P2SH:

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(redeeem_script)> (20 bytes) + OP_EQUAL (1 byte)

Hash de secuencia de comandos de pago para presenciar encapsulado en un hash de secuencia de comandos de pago (P2SH-P2WSH)

El script de canje sigue la misma estructura que el P2WSH nativo:

redeem_script = OP_0 (1 byte) PUSH (1 byte) <script_hash> (32 bytes)

Mientras que la estructura externa del script ( scriptPubKey) es como cualquier otro P2SH:

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(redeeem_script)> (20 bytes) + OP_EQUAL (1 byte)

*En los scripts P2WPKH, el hash 160 debe corresponder a una clave pública comprimida, de lo contrario, se perderán los fondos.

Gracias. Pero no entiendo su última oración: "El hash de script de pago para presenciar no nativo encapsulado en un hash de script de pago (P2SH-P2WPKH) tiene la misma estructura". Puedes profundizar sobre eso? Por lo que entendí, las salidas de segwit no nativas son indistinguibles de las salidas de P2SH.
Lo que menciono es que en P2SH-P2WPKH el script de canje sigue la estructura del P2WPKH nativo y en el P2SH-P2WSH el script de canje sigue la estructura del P2WSH nativo. Lo editaré para aclararlo.
Al revisar la respuesta me di cuenta de que el script OP_Return no estaba actualizado. La cantidad máxima de datos que se pueden enviar es de 83 bytes desde Bitcoin Core 0.12. He actualizado la respuesta para corregirla.
¿Podría esta respuesta actualizarse con salidas P2TR?