Número de versión de la transacción

Solo tres valores han significado algo alguna vez. El campo no es una versión de software, ni una versión de protocolo, ni una pista sobre qué tipos de dirección contiene la transacción, que es la mayor parte de lo que la gente supone cuando lo ve por primera vez. El consenso es en gran medida indiferente a él, mientras que la política de retransmisión no lo es, y esa brecha es toda la historia del campo.

Cómo funciona

La versión ocupa los bytes 1 a 4 de la forma serializada, antes del recuento de entradas, y Bitcoin Core la lee como un entero de 32 bits con signo.

La versión 1 es la original, la que usaron todas las transacciones de los primeros años de la cadena. La versión 2 existe porque el BIP68 necesitaba una forma de reinterpretar los números de secuencia como bloqueos temporales relativos sin invalidar las transacciones más antiguas, así que asoció el nuevo significado a un incremento de versión. Desde el bloque 419.328, en julio de 2016, los números de secuencia de una transacción que declara la versión 2 se comprueban como períodos de espera, y los de una que declara la versión 1, no. Las billeteras modernas establecen la versión 2 por defecto tanto si usan bloqueos temporales como si no, y por eso casi todo lo que se consulta en un explorador de bloques indica 2.

La versión 3 llegó con Bitcoin Core 28.0 en octubre de 2024, con el nombre de topology restricted transactions, o TRUC. Declarar la versión 3 supone optar por un trato más estricto: la transacción siempre se trata como reemplazable, puede tener como máximo una transacción padre sin confirmar y una hija sin confirmar, y la hija se limita a 1.000 bytes virtuales y la propia transacción a 10.000. Esos límites parecen un retroceso hasta que se sufre el pinning (inmovilización de la transacción), que es cuando una contraparte acopla un descendiente enorme y barato a una transacción propia sin confirmar para que aumentar su comisión resulte inasequible. Las implementaciones Lightning adoptaron la versión 3 precisamente por ese motivo.

Nada en las reglas de consenso rechaza una transacción por tener la versión 7, o la versión 0. Las reglas de transacción estándar sí lo hacen: Bitcoin Core no retransmite ni mina versiones fuera del conjunto aceptado, así que una versión inusual es una transacción que tiene que llegar a un minero de alguna otra manera.

Dónde aparece

Todos los exploradores de bloques muestran la versión cerca del principio de la página de detalles de una transacción, y la llamada RPC decoderawtransaction de Bitcoin Core la devuelve como primer campo.

Para quien compra o conserva bitcoin, la versión sirve para diagnosticar, no para decidir. Usted nunca la elige: la elige su billetera. Su valor práctico está en interpretar software desconocido: una billetera que todavía produce transacciones de versión 1 en un mundo de bloqueos temporales relativos es antigua, y un pago que declara la versión 3 casi con seguridad salió de la maquinaria de canales de un nodo Lightning y no de una persona que pulsó enviar.

Número de versión de la transacción frente a número de versión del bloque

Tanto las transacciones como los bloques llevan un campo de versión de cuatro bytes, y no tienen nada que ver entre sí.

La versión del bloque sigue las actualizaciones de consenso. Los bloques de versión 2 pasaron a ser obligatorios en el bloque 227.931, en marzo de 2013, cuando el BIP34 exigió la altura del bloque dentro de la entrada coinbase, la versión 3 hizo cumplir la codificación DER estricta de las firmas con el BIP66, y la versión 4 llegó con el despliegue de CHECKLOCKTIMEVERIFY. A partir de 2015, el campo cambió de función otra vez y pasó a ser un conjunto de bits de señalización con el BIP9, para que los mineros pudieran aprobar con su voto una bifurcación blanda (soft fork) cambiando uno de sus bits. La versión de una transacción no hace nada de eso. Nunca señaliza, nunca aumenta con cada actualización y se aplica a una sola transacción, no al conjunto de reglas de toda la red.