Soft Fork

Imagina que Anna y Pavel verifican Bitcoin, cada uno en su propio ordenador. Anna ha actualizado el software; Pavel todavía no. Llega un cambio parecido a BIP66: las firmas digitales, que demuestran la autorización para gastar determinados bitcoins, deben ajustarse a un formato más preciso. Algunas codificaciones antes aceptadas dejan de estar permitidas. Un pago con una firma válida en el formato ahora exigido supera esta comprobación en ambos equipos. Si la firma utiliza una codificación antes permitida y ahora prohibida, Anna la rechaza, mientras que Pavel aún podría aceptarla. Suponemos que el pago cumple todas las demás reglas. Esa diferencia explica un Soft Fork: las reglas nuevas prohíben más casos sin permitir nada que las antiguas prohibieran. Mientras los mineros produzcan bloques que cumplan las reglas más estrictas, ambos podrán seguir la cadena. Sin embargo, Pavel no comprueba por sí mismo la condición añadida. Así, un Soft Fork permite modificar Bitcoin sin actualizar todos los nodos a la vez. Eso no hace que el software antiguo compruebe lo mismo que el nuevo, ni crea por sí solo una segunda moneda. [1] [6]

Un Full Node es un ordenador que comprueba las reglas de Bitcoin de forma independiente. Para elegir entre ramas válidas, compara el trabajo acumulado demostrado mediante la minería, no los votos de sus partidarios. El nodo completo antiguo puede seguir la cadena porque los mineros actualizados suelen producir bloques que reconoce. Pero no comprueba la condición añadida: puede aceptar una rama con más trabajo que la viola mientras los nodos nuevos la rechazan. Quien necesite la nueva garantía debe actualizar su software de verificación. Recibir pagos, entender una dirección y validar todas las reglas no son equivalentes. [1] [12]

Un BIP es una propuesta técnica numerada. Publicarla no cambia la red: hay que desarrollar y comprobar el software, y sus usuarios deciden si lo ejecutan. Mainnet es la red principal de Bitcoin, donde se transfieren bitcoins reales. La activación determina desde cuándo los nodos actualizados empiezan a exigir la nueva regla. Por eso, tener el código en el programa no equivale a utilizarlo para comprobar bloques. En los procedimientos descritos aquí, lock-in significa que se ha cumplido la condición para una activación posterior; la regla todavía puede no aplicarse. El nodo la comprueba cuando llega al estado ACTIVE. Calcula el estado a partir de los bloques anteriores de su propia rama. Si una reorganización cambia ese historial cerca del límite de activación, el resultado también puede cambiar. Dos programas con parámetros de activación distintos pueden, por tanto, aceptar bloques diferentes en un mismo momento. [2] [15]

El minero construye su bloque sobre uno anterior, llamado bloque padre. Si no lo comprueba, puede desperdiciar trabajo en una rama que otros nodos rechazarán. En julio de 2015 algunos mineros señalaron BIP66 pero minaron sin validar bien el bloque padre. Extendieron un bloque inválido y crearon una rama inválida de seis bloques el 4 de julio; hubo otra menor al día siguiente. Los nodos actualizados las rechazaron. Una señal de versión es una afirmación del minero, no la prueba de que verificó el bloque preparado, su predecesor y las transacciones incluidas. [6] [14]

Para saber qué reglas aplica realmente tu nodo, empieza por su versión y por la información que devuelve él mismo. Según la versión, getdeploymentinfo y getblockchaininfo ofrecen datos sobre los cambios desplegados y la cadena. Junto con la documentación de esa versión, la altura de activación y los registros, ayudan a distinguir una regla preparada de otra ya activa. Un explorador de bloques en la web muestra la visión de otro servicio; no demuestra qué comprueba tu ordenador. El hashrate mide la potencia de cálculo de la minería. No da a los mineros permiso para eludir las reglas de tu nodo: en ACTIVE, un nodo actualizado rechaza un bloque que incumple la nueva condición, aunque lo respalde la mayoría de la potencia. Que una división persista también depende del trabajo acumulado por cada rama y de su uso económico. Eliminar sin más una restricción activa volvería a permitir bloques que hoy son inválidos y sería, por tanto, un Hard Fork. Antes de la activación, una versión coordinada del software puede cambiar los parámetros; tampoco ese cambio se instala por sí solo en los nodos ajenos. [1] [15] [16]

V(antiguo) reúne los bloques aceptados antes de la actualización. Solo hay Soft Fork si V(nuevo) es su subconjunto: el nodo nuevo rechaza más casos y todo bloque que cumple la regla nueva todavía supera las comprobaciones antiguas. El término describe compatibilidad de validez, no tamaño, seguridad ni consenso social. Elevar un límite visible para nodos antiguos o autorizar un gasto antes inválido ensancha el conjunto y normalmente exige Hard Fork. [1] [17]

Endurecer las reglas también puede introducir una función. BIP66 precisó DER, el formato de codificación de las firmas. BIP65 y BIP112 añadieron condiciones temporales de gasto a determinadas instrucciones NOP, que antes no imponían ninguna condición. SegWit introdujo programas witness y datos de validación llamados witness, como las firmas. Taproot utilizó después su versión reservada 1. Los nodos antiguos no comprueban las nuevas condiciones correspondientes. Anyone-can-spend describe esa visión limitada, no una forma de eludir los nodos actualizados y gastar monedas ajenas. Además, SegWit vincula criptográficamente los datos witness al bloque mediante un witness commitment. Este vínculo se guarda en la transacción coinbase, la primera transacción con la recompensa del minero, y mantiene la compatibilidad con las antiguas reglas del bloque base. [6] [5] [7] [8] [12]

Un bit vale 0 o 1. En nVersion, el campo de versión de la cabecera del bloque, determinados bits pueden señalar que un minero está preparado. BIP9 asigna a cada despliegue un nombre, un bit concreto, un momento de inicio y un plazo límite. El procedimiento original de mainnet evalúa periodos de 2016 bloques. Si durante STARTED señalan apoyo al menos 1916 bloques, el 95 %, el siguiente periodo pasa a LOCKED_IN. Tras otro periodo de espera llega ACTIVE. Si no se cumple la condición antes del plazo, el procedimiento puede acabar en FAILED. El estado inicial, anterior al comienzo, se llama DEFINED. Cada nodo calcula esta secuencia a partir de los bloques anteriores. Por eso, el nVersion de un bloque no decide si la nueva regla se le aplica. Las señales coordinan la transición; no son una votación sobre la validez de cada bloque. Una vez alcanzado el lock-in, las señales posteriores ya no cambian el resultado de este procedimiento. [2]

Versionbits permite a los mineros señalar que están preparados, pero no reescribir las reglas de otros nodos. BIP8 utiliza alturas de bloque en lugar de límites temporales. Si lockinontimeout está en true y aún no se ha alcanzado el lock-in, el último período puede entrar en MUST_SIGNAL, con señalización obligatoria. BIP148 exigía que los nodos participantes rechazaran los bloques que no señalaban SegWit; BIP91 utilizó un umbral de señalización minera menor para coordinar esa transición. Si divergen la aplicación de reglas, el hashrate y la aceptación económica, la cadena puede dividirse. Elegir un mecanismo de activación implica, por tanto, compromisos de seguridad. [11] [9] [10] [17]

P2SH (BIP16) permite enviar fondos al hash de un script, un programa con las condiciones para gastarlos después. Cuando se introdujo en 2012, las señales en las transacciones coinbase ayudaron a conocer la preparación de los mineros. Sin embargo, las nuevas comprobaciones empezaron a aplicarse desde un límite fijado para la marca temporal de los bloques; señalar apoyo no sustituía la verificación. Coinbase es la primera transacción del bloque y contiene la remuneración del minero. Los cambios posteriores utilizaron la versión del bloque y umbrales de señalización. BIP34 obligó a registrar en la coinbase la altura del bloque, su posición en la cadena. BIP66 hizo más estricto el formato DER de las firmas y BIP65 introdujo CHECKLOCKTIMEVERIFY para exigir un momento o una altura mínimos antes del gasto. Elevar sucesivamente el número de versión dificultaba desplegar cambios independientes en paralelo. BIP9 introdujo por ello bits separados. En 2016 se activaron juntos BIP68, BIP112 y BIP113, a la altura 419328, pero cada uno aborda una condición temporal distinta. BIP68 introduce una espera relativa desde la confirmación de la salida que se gasta. BIP112 permite exigir esa espera dentro del script con CHECKSEQUENCEVERIFY, o CSV. BIP113 cambia, en cambio, la referencia de un bloqueo temporal absoluto: utiliza Median Time Past, la mediana de las marcas temporales de los 11 bloques anteriores, en lugar de la del bloque evaluado. Una activación conjunta no significa que las tres propuestas introduzcan el mismo bloqueo relativo. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit se activó a la altura 481824 en agosto de 2017. Separó los datos de verificación witness, como las firmas, de la parte de la transacción utilizada para calcular su identificador txid. ¿Por qué importa? Con la codificación anterior, alguien podía modificar la representación de una firma y, con ello, el identificador de la transacción, sin cambiar a quién ni cuánto se pagaba. Esa posibilidad se llama maleabilidad. Cambiar solo los datos witness no modifica el txid; esta solución no corrige, sin embargo, las entradas que siguen utilizando el formato antiguo. Un nodo antiguo ve la transacción sin witness y trata un programa witness v0 como anyone-can-spend. Un nodo actualizado comprueba además el witness y el digest de firma, la huella de los datos firmados. El witness commitment guardado en una salida coinbase vincula criptográficamente los datos witness al bloque, de modo que una verificación completa puede detectar cambios u omisiones. Weight, la ponderación de los datos al contabilizar la capacidad del bloque, permitió aumentar la capacidad efectiva. El bloque base visible para un nodo antiguo siguió dentro del límite original de un megabyte. [8]

Key-path permite gastar con una firma correspondiente a la clave de salida; script-path exige cumplir las condiciones de un script revelado. Schnorr es un esquema de firma y Tapscript el lenguaje de esos scripts. BIP341 y BIP342 definen gastos por key-path y script-path con firmas Schnorr y Tapscript para salidas SegWit nativas con un programa witness de versión 1 y 32 bytes. El nodo antiguo lo ve como anyone-can-spend: conserva compatibilidad, no validación completa. Speedy Trial utilizó una versión modificada de BIP9, con un umbral de 1815/2016 (90 %) y una altura mínima de 709632; Taproot se activó allí el 14 de noviembre de 2021. Las reglas y su mecanismo de activación requieren evaluaciones separadas. [12] [13] [16]