Una bifurcación suave es una transición coordinada desde el conjunto de validez V (antiguo) a su subconjunto V (nuevo). La activación determina el bloque a partir del cual los nodos completos actualizados aplican la restricción. La señalización del minero puede coordinar la preparación, pero la validez la decide una regla ejecutada en los nodos; diseño, implementación, despliegue, activación y adopción no son lo mismo.
Marquemos con V (antiguo) todos los bloques aceptados por las reglas antes de la actualización. El cambio es una bifurcación suave sólo si V(nuevo) se encuentra dentro de V(antiguo): el nuevo nodo rechazará la siguiente clase de bloques, pero un bloque que cumpla con las nuevas reglas también pasará las comprobaciones anteriores. El nombre habla de la compatibilidad de las reglas de validez, no del tamaño, la seguridad o la compatibilidad social del cambio. Aumentar el límite visible para un nodo antiguo o permitir un gasto previamente no válido expande el grupo y generalmente requiere una bifurcación dura. [Guía para desarrolladores de Bitcoin: cambios en las reglas de consenso] [Bitcoin Optech: activación de bifurcación suave]
Un nodo completo antiguo puede continuar siguiendo la cadena porque los mineros actualizados crean rutinariamente bloques que reconoce. Pero no verifica la condición agregada. Si una rama con más trabajo viola la nueva regla, el nodo antiguo puede aceptarla, mientras que el actualizado la rechaza. Quienes necesiten una nueva garantía deberán actualizar su propio software de validación; la capacidad de una billetera para aceptar pagos, la compatibilidad de formatos y la validación por consenso total son cosas diferentes. [Guía para desarrolladores de Bitcoin: cambios en las reglas de consenso] [BIP 341: implementación de Taproot]
Bitcoin creó subconjuntos utilizando varias técnicas. BIP66 prohibió las firmas DER no estrictas que aceptaban las antiguas reglas. BIP65 y BIP112 agregaron condiciones a los códigos de operación NOP que el antiguo intérprete consideraba una inacción exitosa. SegWit y Taproot dieron significado a las versiones reservadas del programa testigo, que el antiguo nodo considera que cualquiera puede gastar. Al mismo tiempo, el diseño debe impedir la elusión del nuevo control; Por lo tanto, SegWit comprometió datos de testigos a través de coinbase y conservó las antiguas reglas básicas de bloqueo. [BIP 66: firmas DER estrictas] [BIP 65: CHECKLOCKTIMEVERIFY] [BIP 112: CHECKSEQUENCEVERIFY] [BIP 141: testigo segregado] [BIP 341: implementación de raíz principal]
El código puede contener una regla inactiva mucho antes de que entre en vigor en la red principal. BIP y la implementación verificada no son implementaciones, los parámetros de implementación no están bloqueados, el bloqueo solo planea la aplicación futura y solo el estado ACTIVO significa verificar el bloque dado. Cada nodo calcula el estado a partir de los ancestros de su propia rama. La reorganización en el límite puede recalcularlo y el software con diferentes parámetros puede comenzar a imponer reglas incompatibles. [BIP 9 - Bits de versión con tiempo de espera y retraso] [Bitcoin Core - versionbits.cpp]
BIP9 asigna un nombre, versión de bit, hora de inicio y tiempo de espera a la implementación. La variante original de la red principal evalúa períodos después de 2016 bloques: después de al menos 1916 bloques de señalización, es decir, el 95%, pasa de STARTED a LOCKED_IN, espera un período y luego está ACTIVA; de lo contrario, puede terminar FALLADO. La secuencia completa es DEFINED, STARTED, LOCKED_IN, ACTIVE y FAILED. El estado de un bloque depende de sus ancestros, no de su propia nVersion, y la señalización después del bloqueo ya no cambia el resultado. [BIP 9 — Bits de versión con tiempo de espera y retraso]
Los versionbits indican la preparación del minero y coordinan la transición; no otorgan a los mineros la propiedad permanente del consenso. BIP8 usa alturas y con lockinontimeout puede forzar la señalización en la última ventana. BIP148, por otro lado, ordenó a los nodos participantes que rechazaran los bloques de señalización que no fueran SegWit; BIP91 redujo el umbral de minería para coordinarse con esta presión. La activación obligatoria puede dividir la cadena si los nodos, la tasa de hash y la adopción económica divergen, por lo que incluso el método de activación es un compromiso de seguridad. [BIP 8 — Versión bits con bloqueo por altura] [BIP 148 — Activación obligatoria de SegWit] [BIP 91 — Umbral reducido SegWit MASF] [Bitcoin Optech — Activación de bifurcación suave]
P2SH bajo BIP16 se activó en 2012 mediante señalización de coinbase y límite de tiempo. BIP34 utilizó la versión de bloque y el umbral de altura obligatoria en coinbase. El mismo procedimiento de enteros ejecutó DER estricto en BIP66 y CHECKLOCKTIMEVERIFY en BIP65, pero consumió valores de versión y no pudo realizar implementaciones simultáneas. Por lo tanto, BIP9 introdujo bits independientes. BIP68, BIP112 y BIP113 luego se activaron juntos como tiempo de bloqueo relativo y CSV a una altura de 419,328 en 2016. [BIP 16 - Pay to Script Hash] [BIP 34 - Block v2, altura en coinbase] [BIP 65 - CHECKLOCKTIMEVERIFY] [BIP 66 - Firmas DER estrictas] [BIP 112 - VERIFICAR SECUENCIA VERIFICAR]
SegWit se activó en 481,824 en agosto de 2017. Un nodo antiguo ve una transacción sin datos de testigo y considera el testigo v0 como que cualquiera puede gastar; Testigo de verificación actualizado, nuevo resumen de firmas y reglas anti-maleabilidad. El compromiso de Merkle de presenciar los datos en la salida de Coinbase evita que un minero cambie u omita datos sin ser detectado. La facturación por peso aumentó la capacidad efectiva sin que el bloque subyacente visible para el nodo antiguo excediera el límite anterior de un megabyte. [BIP 141 — Testigo Segregado]
BIP341 y BIP342 programa testigo versión 1 gasto de ruta de clave y ruta de script con firmas Schnorr y Tapscript. El nodo antiguo vuelve a tratar el programa reservado como si cualquiera pudiera gastarlo: el subconjunto se conserva, pero la validación completa no. La red principal utilizó una prueba rápida BIP9 modificada con un umbral de 1.815 de 2.016 bloques, o 90%, y una altura mínima de activación de 709.632. Taproot se activó en él el 14 de noviembre de 2021; Las reglas de Taproot y cómo activarlas son dos preguntas de auditoría independientes. [BIP 341 - Implementación de Taproot] [BIP 342 - Tapscript] [Notas de la versión de Bitcoin Core 0.21.1 - Implementación de Taproot]
Cuando se activó BIP66 en julio de 2015, algunos mineros señalaron la nueva versión pero no validaron suficientemente el bloque principal en el que estaban minando. Ampliaron el bloque inválido y crearon una rama inválida de seis bloques el 4 de julio; Al día siguiente siguió otro incidente más breve. Los nodos de validación actualizados rechazaron ambas ramas. El número de versión o bit es un reclamo del minero, no una prueba de que él mismo haya verificado la plantilla, los padres y las transacciones. [BIP 66 - Firmas DER estrictas] [Bitcoin.org - Alerta de bifurcación de cadena BIP66 de julio de 2015]
En el estado ACTIVO, los nodos actualizados rechazan el bloque infractor independientemente de la tasa de hash compartida; Que surja una división permanente depende del trabajo de las ramas y de su uso económico. Simplemente eliminar la restricción volvería a habilitar los bloques no válidos actuales y, por lo tanto, es una bifurcación dura; Los parámetros o el código se pueden reemplazar con una liberación coordinada antes de la activación. El operador verifica su propia versión, getdeploymentinfo o getblockchaininfo, los parámetros exactos, la altura de activación y los registros. Ni el gráfico de señalización ni la etiqueta del explorador pueden reemplazar la validación local. [Guía para desarrolladores de Bitcoin: cambios en las reglas de consenso] [Bitcoin Core: versionbits.cpp] [Notas de la versión de Bitcoin Core 0.21.1: implementación de Taproot]
Para obtener la imagen más completa, lee esta entrada junto con Reglas de consenso, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. También enlazan con esta entrada Hard Fork, BIP (Bitcoin Improvement Proposal), Reglas de consenso, Guerra del tamaño de bloque.