Estructura de bloques

Estructura de bloques, Árboles de Merkle y formato de transacciones

---

“Los mineros construyen bloques, pero los nodos deciden qué bloques seguir.” — Principio fundamental de Bitcoin

---

1. Introducción

Bitcoin es una red distribuida cuyo funcionamiento depende de dos estructuras centrales:

1. bloques

2. transacciones

Ambas están encadenadas criptográficamente mediante árboles de Merkle y protegidas por Prueba de Trabajo (PoW). Comprender su diseño es esencial para entender:

• cómo se organiza la información

• cómo funcionan los incentivos

• cómo se garantiza la inmutabilidad

• cómo se alcanza consenso sin autoridad central

---

2. La cadena de bloques: estructura general

Un bloque de Bitcoin se compone de dos partes principales:

┌────────────────────┐ │ Encabezado (80B) │ ← Hash del bloque └────────────────────┘ ┌────────────────────┐ │ Cuerpo: transacciones │ └────────────────────┘

---

2.1. Campos del encabezado

El encabezado del bloque tiene exactamente 80 bytes, estructurados así:

Campo	Tamaño	Descripción
version	4 bytes	Señala reglas de validación
prev_block_hash	32 bytes	Hash del bloque anterior
merkle_root	32 bytes	Raíz del árbol de Merkle
timestamp	4 bytes	Hora aproximada
bits	4 bytes	Objetivo de dificultad
nonce	4 bytes	Contador para PoW

Hash final del bloque:

---

3. Cuerpo del bloque: transacciones

Un bloque contiene:

• 1 transacción coinbase (la primera)

• N transacciones normales

Representación conceptual:

Block ├─ Coinbase TX ├─ TX1 ├─ TX2 ├─ ... └─ TXn

El límite actual es un peso máximo de:

$\text{4,000,000 unidades de weight}$

tras la activación del SegWit (BIP141).

---

4. Árboles de Merkle en Bitcoin

Los árboles de Merkle permiten:

• demostrar inclusión de transacciones

• reducir la cantidad de información necesaria para clientes SPV

• proteger contra modificaciones

4.1. Construcción paso a paso

1. Tomar el hash de cada transacción: $h_i = SHA256d(tx_i)$

2. Agrupar pares y hashearlos nuevamente:

$H_{i,j} = SHA256d(h_i || h_j)$

1. Repetir hasta llegar a la raíz.

---

4.2. Representación

             Merkle Root
             /        \
    Hash 0-3            Hash 4-7
    /      \            /      \
   Hash 0-1   Hash 2-3  Hash 4-5  Hash 6-7
   /    \     /    \    /    \    /    \
 TX0  TX1  TX2  TX3 TX4 TX5 TX6 TX7

---

4.3. Pruebas de inclusión (Merkle Proof)

Un cliente SPV puede demostrar que:

$tx_j \in \text{bloque}$

con una prueba de tamaño $O(\log n)$.

---

5. Transacciones Bitcoin: estructura técnica

Una transacción consta de:

• inputs (entradas)

• outputs (salidas)

Los inputs consumen UTXOs previos. Los outputs generan nuevos UTXOs.

---

5.1. Formato general

Transaction ├─ Version (4 bytes) ├─ TX_IN_COUNT ├─ [Inputs] ├─ TX_OUT_COUNT ├─ [Outputs] └─ locktime

---

5.2. UTXO: el modelo contable de Bitcoin

Bitcoin no usa cuentas. Usa un conjunto global de outputs no gastados (Unspent Transaction Outputs).

Ventajas:

• paralelización

• verificabilidad fácil

• protección contra doble gasto

• simplicidad en validación

Formalización:

$UTXO_{new} = UTXO_{old} - inputs + outputs$

---

6. Inputs: consumiendo transacciones previas

Un input contiene:

Campo	Descripción
prev_txid	hash de la transacción previa
prev_index	índice del output consumido
scriptSig	firma + datos de desbloqueo
sequence	usado en locktime

El input prueba que el usuario posee la clave privada asociada al UTXO.

---

6.1. scriptSig (clásico)

Ejemplo:

<firma ECDSA> <clave pública>

Con SegWit, la firma va en un campo diferente (witness).

---

7. Outputs: creando nuevos UTXOs

Un output contiene:

Campo	Descripción
value	cantidad en satoshis
scriptPubKey	condiciones de gasto

---

7.1. scriptPubKey más común (P2PKH)

OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

---

7.2. P2SH

Tipo introducido por BIP16:

OP_HASH160 <hash_del_script> OP_EQUAL

---

7.3. P2WPKH (SegWit)

Formato witness:

0 <20-byte-key-hash>

Beneficios:

• menor peso de firma

• elimina maleabilidad

• reduce fees

---

8. Firmas en transacciones

Bitcoin usa ECDSA sobre la curva secp256k1.

Para firmar una transacción se construye un mensaje:

$m = \text{serialización modificada}(\text{TX})$

Luego:

$firma = ECDSA_sign(privkey, m)$

---

8.1. Sighash types

Bitcoin permite distintos modos de firmar:

Código	Efecto
SIGHASH_ALL	Firma inputs y outputs
SIGHASH_NONE	Firma inputs, outputs libres
SIGHASH_SINGLE	Firma input correspondiente
ANYONECANPAY	Modifica inputs permitidos

---

9. La transacción coinbase

Es la primera transacción en cada bloque.

9.1. Características:

• no tiene inputs válidos

• crea nuevos bitcoins

• incluye recompensa (subsidio + fees)

• contiene un script arbitrario con mensajes opcionales

Ejemplo clásico: el mensaje del bloque génesis.

---

9.2. Subsidio

$\text{Subsidio actual} = 50 \cdot 2^{-n}$

donde

• $n$ = número de halvings transcurridos

---

10. Cómo se verifican las transacciones

Un nodo verifica:

1. Formato correcto

2. Firmas válidas

3. UTXOs existan

4. No haya doble gasto

5. Outputs no excedan inputs

6. Sighash válido

7. Script ejecutado sin error

---

10.1. Evaluación de scripts

Bitcoin Script es un lenguaje simple, no Turing completo.

Ejemplo evaluación P2PKH:

scriptSig: <firma> <pubKey> scriptPub: OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG

---

11. Validación de bloques

Para aceptar un bloque:

1. Hash del bloque < Target

2. Todas las transacciones válidas

3. Tamaño correcto

4. Recompensa correcta

5. Prev_block_hash coincide

6. El Merkle Root coincide

7. Timestamp razonable

---

12. Representación matemática del encadenamiento

Si:

• $B_i$ = Bloque i

• $H(B_i)$ = Hash del encabezado del bloque i

entonces:

que produce:

$B_0 \rightarrow B_1 \rightarrow B_2 \rightarrow \dots$

La seguridad depende de:

$\text{Costo de reorganización} \approx \text{PoW acumulado}$

---

13. Conclusión del capítulo

En este capítulo hemos visto:

• cómo está estructurado un bloque

• cómo se organizan y verifican las transacciones

• qué rol juega el árbol de Merkle

• cómo se asegura la integridad de la cadena

• por qué el sistema UTXO es superior a un modelo basado en cuentas

Todos estos elementos son la base de la capa fundamental de Bitcoin.

---

Si entiendes un bloque, entiendes Bitcoin. Si entiendes el árbol de Merkle, entiendes por qué es inmutable.

---