REFERENCIA TÉCNICA

Anatomía de una transacción Bitcoin: campos, scripts y fees explicados

Recorrido campo a campo de una transacción Bitcoin: inputs, outputs, witness, scripts (P2WPKH, P2TR), txid, fees, vbytes, signing y propagación. Con diagramas.

Resumen rápido

Una transacción Bitcoin es una estructura binaria con seis bloques: versión, lista de inputs (qué UTXOs gastas), lista de outputs (a quién y cuánto), witness opcional (firmas SegWit/Taproot), locktime y serialización. El txid identifica la transacción de forma única. Las fees son la diferencia entre inputs y outputs, expresadas en sat/vbyte. Esta página recorre cada campo.

Diagrama conceptual

┌─────────────────────────────────────────────────────────┐
│                  TRANSACCIÓN BITCOIN                    │
├─────────────────────────────────────────────────────────┤
│ Versión (4 bytes)                                       │
├─────────────────────────────────────────────────────────┤
│ Marker + Flag (SegWit, 2 bytes)                         │
├─────────────────────────────────────────────────────────┤
│ N° inputs (varInt)                                      │
│ ┌─── INPUT 0 ───────────────────────────────────────┐   │
│ │ outpoint (txid del UTXO + vout, 36 bytes)         │   │
│ │ scriptSig length + scriptSig                      │   │
│ │ sequence (4 bytes)                                │   │
│ └───────────────────────────────────────────────────┘   │
│ ...                                                     │
├─────────────────────────────────────────────────────────┤
│ N° outputs (varInt)                                     │
│ ┌─── OUTPUT 0 ──────────────────────────────────────┐   │
│ │ value en satoshis (8 bytes)                       │   │
│ │ scriptPubKey length + scriptPubKey                │   │
│ └───────────────────────────────────────────────────┘   │
│ ...                                                     │
├─────────────────────────────────────────────────────────┤
│ Witness data (SegWit/Taproot, 1 por input)              │
├─────────────────────────────────────────────────────────┤
│ Locktime (4 bytes)                                      │
└─────────────────────────────────────────────────────────┘

Campo a campo

1. Versión (4 bytes, little-endian)

Indica la versión del formato de transacción. Versiones válidas: 1 y 2. La 2 habilita el uso de nSequence para BIP-68 (relative locktime), necesario para canales Lightning.

2. Marker + Flag (SegWit/Taproot)

Si la transacción usa witness data (SegWit, Taproot), incluye dos bytes: 0x00 (marker) y 0x01 (flag). Transacciones legacy las omiten.

3. Inputs (entradas)

Cada input gasta un UTXO anterior. Contiene:

Outpoint (36 bytes) — Identifica el UTXO: txid del bloque que lo creó + vout (índice del output dentro de esa tx).
scriptSig — En transacciones legacy contiene la firma. En SegWit/Taproot suele estar vacío (la firma vive en el witness).
Sequence (4 bytes) — Habilita RBF (Replace-By-Fee), relative locktime y otras políticas de gasto.

4. Outputs (salidas)

Cada output crea un UTXO nuevo. Contiene:

Value (8 bytes) — Cantidad en satoshis. 1 BTC = 100.000.000 sats.
scriptPubKey — El "candado" que indica las condiciones para gastar este output más adelante.

5. Witness data (SegWit/Taproot)

Las firmas digitales y otros datos de gasto viven aquí desde 2017 (SegWit) y 2021 (Taproot). Separar el witness del cuerpo reduce el peso efectivo y habilita Lightning, Taproot, MuSig2 y BitVM.

6. Locktime (4 bytes)

Bloque mínimo o timestamp Unix mínimo a partir del cual la transacción es válida. Si es 0, la tx puede incluirse inmediatamente. Locktime + sequence habilitan transacciones programadas y canales Lightning.

Tipos de scriptPubKey en 2026

Tipo	Prefijo dirección	Año	Witness	Uso típico
P2PKH (legacy)	`1…`	2009	No	Histórico
P2SH	`3…`	2012	No	Multisig pre-SegWit
P2WPKH (SegWit nativo)	`bc1q…`	2017	Sí	Estándar mayoritario
P2WSH	`bc1q…`	2017	Sí	Multisig SegWit, Lightning
P2TR (Taproot)	`bc1p…`	2021	Sí (Schnorr)	Moderno, MuSig2, BitVM

Cómo se calculan las fees

fee = Σ inputs − Σ outputs. La diferencia se la queda el minero que incluye la tx. Las wallets estiman fees en sat/vbyte:

Vbytes = peso de la tx / 4. Un input P2WPKH pesa ~68 vbytes; un output P2WPKH ~31 vbytes.
Estimación — Las wallets consultan la mempool (mempool.space ↗) para conocer el sat/vbyte mínimo que está entrando en bloques.
RBF (Replace-By-Fee) — Si una tx queda atascada con fee baja, se puede reenviar con fee más alta sustituyendo la original.
CPFP (Child-Pays-For-Parent) — Una tx hija que gasta un output de la pendiente puede pagar fee extra para que el minero incluya ambas.

Ejemplo: tx P2WPKH simple

Alice gasta un UTXO de 50.000 sats y envía 30.000 a Bob con fee de ~1.500 sats:

1 input P2WPKH (~68 vbytes).
2 outputs P2WPKH (Bob + change) (~62 vbytes).
Overhead (~11 vbytes).
Total: ~141 vbytes.
Si el sat/vbyte actual es 10, fee ≈ 1.410 sats.
Change a Alice: 50.000 − 30.000 − 1.410 = 18.590 sats.

Estados de una transacción

Creada — Construida y firmada pero no propagada.
Difundida (broadcast) — Enviada a la red P2P.
En mempool — Aceptada por uno o más nodos pero sin confirmar.
1 confirmación — Incluida en un bloque.
6 confirmaciones — Considerada prácticamente irreversible (~60 min).
Reorg (raro) — Si un fork temporal supera la cadena que la incluía, vuelve a la mempool.

Por qué importa entender la anatomía

Conocer los campos permite leer transacciones directamente en exploradores como mempool.space ↗, evaluar fees por uno mismo en lugar de aceptar la estimación de una wallet, detectar patrones de privacidad (consolidaciones, change heuristics) y entender por qué Lightning, Taproot Assets y BitVM son posibles encima de este formato relativamente simple.

Recursos relacionados

Fuentes

Preguntas frecuentes

+¿Qué campos tiene una transacción Bitcoin?

Versión (4 bytes), número de inputs (varInt), inputs (cada uno con outpoint, scriptSig, secuencia), número de outputs (varInt), outputs (cada uno con valor en satoshis y scriptPubKey), opcionalmente witnesses para SegWit/Taproot, y locktime (4 bytes).

+¿Qué es el txid?

El txid es el doble SHA-256 de la serialización legacy de la transacción (sin witness). Sirve como identificador único e inmutable de la transacción.

+¿Qué diferencia hay entre weight, vbytes y bytes?

Bytes es el tamaño bruto. Weight = (base × 4) + witness. Vbytes = weight / 4. Las fees se calculan típicamente en sat/vbyte. Un bloque tiene un peso máximo de 4 millones de unidades (~1 MB legacy + ~3 MB de witness).

+¿Cómo se calculan las fees?

fee = sum(inputs) - sum(outputs). El minero se queda con la fee. Las wallets estiman fees consultando la mempool actual (sat/vbyte) y multiplican por el tamaño en vbytes de la tx.

+¿Qué es el locktime?

Locktime es el bloque o timestamp mínimo a partir del cual la transacción puede incluirse en un bloque. Bitcoin Core la rechaza si llega antes. Habilita transacciones programadas y es base de Lightning.

+¿Una transacción confirmada se puede revertir?

En teoría sí mediante reorg, en la práctica no después de 6 confirmaciones (1 hora). Cuanto más profunda está en la cadena, más caro es revertirla — exige rehacer todo el PoW posterior.