Estructura de una transacción

Cada campo, cada byte. Cómo se construye una transacción Bitcoin a nivel de protocolo.

Visión general

Una transacción Bitcoin es una estructura de datos que especifica:

• Qué UTXOs se gastan (inputs)
• Qué nuevos UTXOs se crean (outputs)
• Condiciones adicionales (locktime, witness data)

Todo se serializa en una secuencia de bytes que se transmite por la red y se almacena en la blockchain.

Anatomía completa

Una transacción SegWit tiene la siguiente estructura: [Version] 4 bytes [Marker] 1 byte (0x00) - solo SegWit [Flag] 1 byte (0x01) - solo SegWit [Input Count] varint [Inputs] variable [Output Count] varint [Outputs] variable [Witness] variable - solo SegWit [Locktime] 4 bytes

Vamos campo por campo.

Version (4 bytes)

Indica la versión del formato de transacción. Actualmente:

• 01000000 (little-endian) = versión 1
• 02000000 = versión 2 (necesaria para OP_CHECKSEQUENCEVERIFY)

Marker y Flag (SegWit)

En transacciones SegWit, después de la versión vienen:

• Marker: 00
• Flag: 01

Estos bytes indican que hay datos witness al final. Las transacciones legacy no tienen estos campos.

Input Count (varint)

Un entero de longitud variable que indica cuántos inputs tiene la transacción.

El formato varint:

• 0x00-0xFC: 1 byte, valor directo
• 0xFD: 3 bytes, los siguientes 2 bytes son el valor (little-endian)
• 0xFE: 5 bytes, los siguientes 4 bytes son el valor
• 0xFF: 9 bytes, los siguientes 8 bytes son el valor

Inputs

Cada input tiene: [Previous txid] 32 bytes (hash de la transacción que creó el UTXO) [Previous vout] 4 bytes (índice del output en esa transacción) [ScriptSig size] varint [ScriptSig] variable (vacío en SegWit nativo) [Sequence] 4 bytes

El txid anterior está en orden de bytes invertido (little-endian) comparado con cómo se muestra normalmente.

Output Count (varint)

Número de outputs.

Outputs

Cada output tiene: [Value] 8 bytes (satoshis, little-endian) [ScriptPubKey size] varint [ScriptPubKey] variable (el script que bloquea este output)

El valor en satoshis usa 8 bytes little-endian. Por ejemplo, 100.000 sats = A086010000000000.

Witness (SegWit)

Para cada input, el witness contiene los datos de firma y otros elementos necesarios para satisfacer el script. La estructura es: [Item count] varint (número de elementos para este input) [Item 1 size] varint [Item 1 data] variable [Item 2 size] varint [Item 2 data] variable ...

En un P2WPKH típico, el witness tiene 2 elementos: la firma y la clave pública.

Locktime (4 bytes)

Especifica cuándo la transacción puede incluirse en un bloque:

• Si < 500.000.000: altura de bloque mínima
• Si ≥ 500.000.000: timestamp Unix mínimo
• 00000000: sin restricción (lo más común)

Ejemplo real

Una transacción SegWit simple (1 input P2WPKH, 2 outputs): 01000000 Version: 1 00 Marker 01 Flag 01 1 input [32 bytes txid] Previous transaction 01000000 vout: 1 00 Empty scriptSig ffffffff Sequence: max 02 2 outputs e803000000000000 1000 sats 160014[20 bytes] P2WPKH scriptPubKey 1027000000000000 10000 sats 160014[20 bytes] P2WPKH scriptPubKey 02 2 witness items 47[71 bytes sig] Signature 21[33 bytes pub] Public key 00000000 Locktime: 0

txid y wtxid

txid: El identificador tradicional de la transacción. Se calcula como SHA256(SHA256(serialización legacy)), excluyendo marker, flag y witness.

wtxid: Incluye todos los datos (con witness). Se usa internamente para commitment en el bloque.

En transacciones legacy, txid = wtxid (no hay witness). En SegWit, son diferentes.

La separación del witness del cálculo del txid es precisamente lo que resolvió el problema de maleabilidad que impedía Lightning Network.