> For the complete documentation index, see [llms.txt](https://www.notbank.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.notbank.com/learn/academy/bitcoin/estructura-de-bloques.md). # Estructura de bloques *** > “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: $$\text{hash\_bloque} = SHA256(SHA256(\text{header}))$$ *** ## 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)$$ 3. 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: ` ` 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 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: ` `\ scriptPub: `OP_DUP OP_HASH160 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: $$\text{prev\_hash}(B\_i) = H(B\_{i-1})$$ 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. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.notbank.com/learn/academy/bitcoin/estructura-de-bloques.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.