---
# System prepended metadata

title: 18 - Versión del Bloque

---

  # 18 - <font color="#F7A004">Versión del Bloque</font>
  > Marcar: preparación para actualizaciones

![image](https://hackmd.io/_uploads/B1zaUOGagx.png)

Los mineros dan uso al campo de versión de 4 bytes en el encabezado del bloque para indicar su preparación para las bifurcaciones suaves propuestas.

Los números de versión se aplican en el software para indicar mejoras y/o la incorporación de nuevas funciones. No existe autoridad centran en Bitcoin que condicione a todos a implementar estas mejoras a nuevas versiones del software. Si es ideal que la mayor parte de la red acepte los cambios propuestos.

En versiones tempranas de Bitcoin (v1–v3), este valor solo representaba un número estático, pero a partir de BIP9 se introdujo el sistema de version bits, que permite a los mineros indicar qué mejoras (soft forks) están listos para aceptar.

> [!Important] 
> Entonces, el campo de versión se usa básicamente para votar por las mejoras propuestas al software.

> [!Note] 
En realidad, no son votos. Una mayor parte de mineros puede aplicar una nueva mejora; no necesitan indicarla en bloques ni informar a nadie. Lo que [el campo de versión] hace es indicar la preparación, para que se pueda encontrar un punto de transición coordinado.



## 1️⃣ Número de Versión

Hasta 2015, el número de versión se incrementaba para indicar la disponibilidad de nuevas mejoras. Esto fue hasta el número de versión fue 4:

0x00000001= El software original
-> Altura activada: 0
0x00000002= BIP 34 : Altura en Coinbase
-> Altura activada: 227,931
0x00000003= BIP 66 : Firmas DER estrictas
-> Altura activada: 363.725
0x00000004= BIP 65 : OP_CHECKLOCKTIMEVERIFY
-> Altura activada: 388,381

Estas mejoras se volvieron permanentes cuando 950 de 1000 bloques en un tiempoo determinado se minaron con la nueva versión. Ya activas, todos los bloques nuevos tienen que usar la nueva versión (y/o una superior).

Este sistema funciona, pero el inconveniente es que sólo se puede correr de a un cambio no varios al mismo tiempo. 

> [!Caution]
> Debido a estas mejoras, el número de versión mínimo requerido para un bloque ahora es 0x00000004. Cualquier número de versión inferior será descartad por los nodos de la red.

## 1️⃣ Versión Bits
> En 2015, el campo de versión se modificó para usarse como un campo de bits, lo que permite a los mineros señalar hasta 29 nuevas funciones propuestas al mismo tiempo.

-> Se pueden hacer de froma similtánea definir diferentes bits en el campo de versión de 32 bits (4 bytes) para indicar la disponibilidad para una bifurcación suave diferente. Por lo tanto, para indicar la disponibilidad para una mejora específica, basta con activar un bit específico (es decir, ponerlo a 1 ).

![image](https://hackmd.io/_uploads/Bya-K6VCeg.png)

Los siguientes bits se han utilizado para las actualizaciones:

**Bit 0: BIP 112 : VERIFICAR SECUENCIA**
Ejemplo:0b00100000000000000000000000000001
Altura activada: 419,328
**Bit 1: BIP 141 : Segwit**
Ejemplo:0b00100000000000000000000000000010
Altura activada: 481.824
**Bit 2: BIP 341 : Raíz principal**
Ejemplo:0b00100000000000000000000000000100
Altura activada: 709,632

Para usar bits de versión para indicar, debe configurar los primeros 3 bits en 0b001 (como se especifica en BIP 9). Esto es simplemente un requisito que indica que está usando el campo de versión como campo de bits para la marcar/indicar. Solo puede indicar un máximo de 29 cambios diferentes al mismo tiempo (32 - 3 = 29 bits).

Cada propuesta tiene su propio periodo dónde puede ser marcada/indicada, donde un número específico de bloques debe indicar la actualización durante un periodo específico para que se active. Por ejemplo, con la actualización de la raíz principal, el 90 % de los bloques durante un periodo de ajuste objetivo de 2016 bloques tuvieron que indicar la actualización (del 24 de abril al 11 de agosto de 2021), lo que finalmente se llevó a cabo, y la implementación se activó a la altura del bloque 709 632 .

> [!Tip] 
> Puedes ver las actualizaciones pasadas y actuales que se están votando a través de bitcoin-cli getblockchaininfo.

> [!Note] 
Se puede encontrar una lista de todas las asignaciones de bits para las actualizaciones propuestas en la página de asignaciones de BIP 9 , pero no creo que se actualice con frecuencia.


## 2️⃣ Ejemplos

Aquí hay algunos ejemplos de números de versión que encontrará en el historial de la cadena de bloques.

0x00000001- La mayoría de los bloques hasta la altura de bloque 200 000 utilizan este número de versión.
    Ejemplo: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f (Altura 0 )
0x00000002- La mayoría de los bloques entre 227,931 y 363,724 utilizan este número de versión.
    Ejemplo: 000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8 (Altura 227,931 )
0x00000003- La mayoría de los bloques entre 363,725 y 388,380 utilizan este número de versión.
    Ejemplo: 00000000000000000379eaa19dce8c9b722d46ae6a57c2f1a988119488b50931 (Altura 363,725 )
0x00000004- La mayoría de los bloques entre 388.381 y alrededor de 411.000 utilizan este número de versión.
    Ejemplo: 000000000000000004c2b624ed5d7756c508d90fd0da2c7c679febfa6c4735f0 (Altura 388,381 )
    
Después de la altura de bloque de aproximadamente 411 000, el campo de versión se usa con mayor frecuencia como campo de bits (en lugar de un simple número). Por eso, los números de versión parecen mucho mayores, ya que los primeros 3 bits se configuran como 0b001.

0x20000000- Se utilizan bits de versión, pero no indican ninguna actualización en particular.
**Bits de versión:0b00100000000000000000000000000000**
    Ejemplo: 000000000000000005025d88492c54a51ac3bccaaa15c12a05aee16a28d6b294 (Altura 410,370 )
0x20000001- Bits de versión que se utilizan para indicar la actualización de CSV.
**Bits de versión:0b00100000000000000000000000000001**
    Ejemplo: 000000000000000004983f04183f2a6ae7f1cdf6ddb8f4b3f79e39e14392db4c (Altura 416,498 )
0x20000002- Bits de versión que se utilizan para indicar la actualización de Segwit .
**Bits de versión:0b00100000000000000000000000000010**
    Ejemplo: 0000000000000000001094a0145695e4228c21cbbc6be40507f728c6b7d6f16a (Altura 471,329 )
0x20000004- Bits de versión que se utilizan para indicar la actualización de Taproot .
**Bits de versión:0b00100000000000000000000000000100**
    Ejemplo: 00000000000000000004f065fae967b93540f321076684fe926d4e7bfbcd77ab (Altura 703,353 )
A continuación se muestran ciertos números de versión no estándar que aparecen de cada determinado tempo:

0x30000000Creo que esto podría haber sido un fragmento no oficial usado para indicar la compatibilidad con bloques de 2 MB. Aparece 2058 veces entre los bloques 398 364 y ​​476 482 .
**Bits de versión:0b00110000000000000000000000000000**
    Ejemplo: 0000000000000000018c393bb66dac52e1a2131ab2332b4d6e2caed463209892 (Altura 414,996 )
0x08000004Esta es otra señal no oficial para tamaños de bloque adaptables . Aparece 39 veces entre los bloques 416.832 y 455.757 .
**Bits de versión:0b00001000000000000000000000000100**
    Ejemplo: 00000000000000000479bbbf51d485ddc7b161998b6f54049e576b09fd72e363 (Altura 416,832 )

## 3️⃣ Valor predeterminado actual
La versión predeterminada en el encabezado del bloque actualmente es:

:::info
0b00100000000000000000000000000000
:::

Su equivalente en hexadecimal es:
:::success
0x20000000
:::
Esto indica que estás usando **bits de versión** (es decir, los primeros 3 bits están configurados en 0b001), pero sin marca de ninguna característica nueva propuesta (todos los demás bits están configurados en cero).

Los bits altos (por ej., el bit 29) se reservan para mecanismos de activación.

> [!Important] 
En realidad, “0x20000000” no es un número decimal simple (como “536870912”), sino un conjunto de bits donde cada uno puede tener un significado independiente

> [!Warning]
> El primer bit del campo de versión nunca puede ser 1, ya que indica un número negativo y no sería válido. Esto se debe a que Bitcoin utiliza una codificación personalizada para valores uint256 .

### Version Bits (BIP9)
Desde la implementación del BIP9, la versión del bloque ya no representa solo un número, sino un campo donde cada bit puede utilizarse para señalar apoyo a una actualización específica.

Bit 0 -> Soft fork A
Bit 1 -> Soft fork B
Bit 2 -> Soft fork C

Cuando suficientes mineros señalan un mismo bit durante un período (2,016 bloques), el cambio se considera locked-in y se activa automáticamente en un bloque posterior

BIP9 fue usado para activar SegWit (bit 1, versión 0x20000000 | 0x02).
El sistema fue diseñado para evitar forks involuntarios, permitiendo activaciones coordinadas sin necesidad de aumentos manuales del número de versión.

### BIP320 (2018)
El BIP320 reservó los bits 0–28 para futuras propuestas y los bits 29–31 para el propio mecanismo de activación.
Esto significa que el campo “version” puede tener valores aparentemente arbitrarios, pero todos siguen la estructura:


## 4️⃣ Nonce adicional
> No hay restricciones sobre qué valores puedes poner en el campo de versión (excepto que debe ser un mínimo de 0x00000004y el primer bit no debe ser 1), por lo que los mineros a veces lo usan como un nonce extra cuando minan.

Por eso, desde la altura del bloque 600 000 (también antes, pero con mayor frecuencia desde entonces), es frecuente ver números de versión inusuales en el encabezado del bloque que no corresponden a ninguna actualización propuesta. Por ejemplo:

0x2844a000- Utiliza bits de versión con algunos bits configurados, pero ninguno de ellos corresponde a una actualización propuesta.
**Bits de versión:0b00101000010001001010000000000000**
    Ejemplo: 00000000000000000479bbbf51d485ddc7b161998b6f54049e576b09fd72e363 (Altura 791,617 )
Nuevamente, estos números de versión no indican nada en particular; simplemente se han ajustado para que el minero pueda continuar aplicando hashes a su bloque actual sin tener que reconstruirlo por completo.


## 5️⃣ Resumen
> El campo de versión del bloque es una herramienta de coordinación.

Pasó de ser un simple contador a un mapa binario de señalización para actualizar Bitcoin sin rupturas de consenso.

Esta evolución muestra cómo Bitcoin reemplaza la autoridad central (decidir cuándo actualizar) por coordinación descentralizada basada en bits de consenso.

:::info
:::
:::success
:::
:::warning
:::
:::danger
:::
:::spoiler
:::


> [!Important] 

> [!Note] 

> [!Tip] 

> [!Warning]

> [!Caution]

## 1️⃣ 




## 6️⃣
## 7️⃣
## 8️⃣
## 9️⃣
## 🔟
