Estructura de un bloque
80 bytes que enlazan toda la historia. El header del bloque y lo que contiene.
Visión general Un bloque Bitcoin tiene dos partes:
Header: 80 bytes fijos con metadatos del bloque Transacciones: Lista de transacciones, empezando por la coinbase
El header es lo que se hashea para la minería. Las transacciones son el contenido útil. El header del bloque (80 bytes) [Version] 4 bytes [Prev Block] 32 bytes [Merkle Root] 32 bytes [Timestamp] 4 bytes [Bits] 4 bytes [Nonce] 4 bytes Version (4 bytes) Indica la versión del bloque y se usa para señalización de soft forks. Los bits individuales pueden señalar soporte para actualizaciones propuestas. Valor típico actual: 0x20000000 (versión 2 con bits de señalización). Previous Block Hash (32 bytes) El hash SHA256(SHA256(header)) del bloque anterior. Este campo es lo que forma la "cadena" en blockchain. Para modificar un bloque antiguo, tendrías que recalcular todos los bloques posteriores porque cada uno referencia al anterior. Merkle Root (32 bytes) Un hash que resume todas las transacciones del bloque. Calculado construyendo un árbol de Merkle de los txids. Permite probar que una transacción está en el bloque sin descargar todas las transacciones (Merkle proof). Timestamp (4 bytes) Timestamp Unix del momento en que el minero creó el bloque. No tiene que ser preciso, pero debe cumplir ciertas reglas:
Mayor que la mediana de los 11 bloques anteriores Menor que el tiempo actual + 2 horas (según los nodos)
El timestamp se usa para calcular ajustes de dificultad. Bits (4 bytes) Codificación compacta del target de dificultad. El hash del bloque debe ser menor que el target derivado de este campo. Formato: el primer byte es el exponente, los siguientes 3 son el coeficiente. Ejemplo: 0x1d00ffff (dificultad del bloque génesis)
Exponente: 0x1d = 29 Coeficiente: 0x00ffff
Target = 0x00ffff × 2^(8×(0x1d-3)) Nonce (4 bytes) El número que el minero varía para buscar un hash válido. Cada incremento del nonce produce un hash completamente diferente. 4 bytes = 2³² posibilidades. Si no se encuentra un hash válido, el minero modifica otros campos (timestamp, transacciones, extraNonce). Ejemplo de header real Bloque #800000: Version: 00000020 Prev Block: 00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d72728a054 Merkle: f6b7a1e47c32ec8b17d7f0d8e9b8c2f4a3d5e6c7b8a9d0e1f2c3b4a5d6e7f8a9 Timestamp: 64c9ab2f (1691035439 = julio 2023) Bits: 17053894 Nonce: 2c8b7a1e (Valores ilustrativos simplificados) La coinbase transaction La primera transacción de cada bloque es especial:
No tiene inputs reales (el "input" referencia txid 0x00...00) Crea los nuevos bitcoin (subsidy) + recoge todas las fees El campo scriptSig puede contener datos arbitrarios (el "extraNonce" y mensajes)
Satoshi incluyó en el bloque génesis: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" Los mineros usan parte del coinbase scriptSig como "extraNonce" cuando los 4 bytes del nonce no son suficientes. Tamaño vs peso Límite histórico: 1 MB por bloque (pre-SegWit) Límite actual: 4.000.000 weight units (WU) Esto equivale a:
Exactamente 1 MB si no hay SegWit Hasta ~4 MB si todo fuera witness data (imposible en práctica) Típicamente 1.5-2 MB con mezcla de transacciones
El bloque génesis El bloque #0, creado por Satoshi el 3 de enero de 2009:
Hash: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f No tiene bloque anterior (prev block = 0x00...00) Contiene solo la coinbase con el mensaje del Times Curiosamente, los 50 BTC de recompensa son no gastables por un quirk del código
Propagación de bloques Cuando un minero encuentra un bloque válido:
Lo anuncia a sus peers (inv message) Los peers solicitan el bloque (getdata) El minero envía el bloque completo Cada receptor valida y retransmite
Con compact blocks (BIP 152), se envían solo los IDs cortos de las transacciones. El receptor reconstruye el bloque con transacciones que ya tiene en su mempool, reduciendo drásticamente el ancho de banda.