Bloque de versión 2

Los números de versión de los bloques significaban antes algo sencillo: 1 era el formato original, 2 añadió una regla y cada número nuevo hacía que el formato anterior ya no se pudiera minar. La versión 2 llegó con el BIP34, y Bitcoin Core la hace cumplir a partir del bloque 227.931. Nada de lo que usted hace como comprador depende de ella, pero todos los exploradores de bloques la muestran, y explica por qué los scripts coinbase empiezan por un número.

Cómo funciona

Estado: el campo de versión dejó de ser un contador en 2016, cuando el BIP9 redefinió sus bits superiores como un campo de bits de señalización, así que un bloque moderno muestra un valor como 0x20000000 en lugar de 2, 3 o 4. La regla del BIP34, introducida con la versión 2, es permanente y se sigue comprobando en cada bloque.

Los bloques de versión 2 existen para resolver un problema de identidad duplicada. Una transacción coinbase no tiene entradas que la hagan única, así que dos mineros que por casualidad usaran el mismo script de bloqueo y los mismos bytes arbitrarios en el campo coinbase podían producir transacciones idénticas byte a byte, con el mismo ID de transacción. No es una hipótesis: los bloques 91.842 y 91.880 contenían cada uno una transacción coinbase idéntica a otra de un bloque anterior, y la copia posterior sobrescribió el elemento anterior del conjunto de UTXO, lo que destruyó monedas gastables. El BIP30 prohibió de plano los duplicados como medida provisional, y el BIP34 eliminó la posibilidad en su origen.

El mecanismo es pequeño. Un bloque de versión 2 debe empezar su script coinbase por la altura del propio bloque, escrita como un número de script con codificación mínima. Como no hay dos bloques con la misma altura, ya nunca pueden colisionar dos transacciones coinbase. El despliegue usó un umbral en lugar de una fecha fija (flag day): una vez que una supermayoría de los bloques recientes llevó la versión 2, los bloques de versión 1 pasaron a ser inválidos, y la red superó ese punto en marzo de 2013.

El mismo patrón se repitió dos veces más. Los bloques de versión 3 hicieron obligatoria la codificación DER estricta de las firmas en el bloque 363.725, y los bloques de versión 4 trajeron el opcode (código de operación) OP_CHECKLOCKTIMEVERIFY en el bloque 388.381. Después, la secuencia se detuvo, porque tratar un campo de 32 bits como un contador desperdiciaba 31 bits que el BIP9 convirtió en señales de actualización paralelas.

Dónde aparece

La versión aparece en la página de bloque de cualquier explorador y en la llamada RPC getblock, tanto en el campo version como en versionHex. Si se mira un bloque de 2011, se ve un 1; si se mira uno de mediados de 2013, se ve un 2; si se mira uno de hoy, se ve un campo de bits.

La altura del BIP34 es más fácil de detectar que la propia versión. Si se decodifica cualquier script coinbase reciente, los primeros bytes son la altura, normalmente seguida del texto de identificación de un pool de minería y del espacio de nonce extra que recorre el hardware de minería. Los exploradores a menudo muestran esa cola en ASCII, y así es como el campo coinbase de un bloque revela qué pool lo minó.

Bloque de versión 2 frente a transacción de versión 2

Un bloque de versión 2 y una transacción de versión 2 comparten un número y nada más. La versión 2 de las transacciones procede del BIP68 y activa los bloqueos temporales relativos (relative locktimes), que permiten a una entrada exigir que su salida padre tenga cierta antigüedad antes de poder gastarse. Lightning depende de esa versión para los timeouts (expiraciones de plazo) de los canales. La versión 2 de los bloques procede del BIP34 y tiene que ver con la unicidad de las transacciones coinbase. Distinto objeto, distinto BIP, distinto año, y ninguna relación más allá de la coincidencia de que ambos contadores llegaran a 2.