La respuesta corta
Un fork es un cambio en las reglas que deciden si un bloque es válido, y adopta exactamente dos formas.
Un soft fork vuelve las reglas más estrictas. Un programa que nunca se actualizó sigue aceptando todos los bloques producidos bajo las reglas nuevas, porque esos bloques ya eran válidos bajo las viejas.
Un hard fork vuelve las reglas más laxas. Un programa que nunca se actualizó rechaza el primer bloque que usa esa libertad nueva, porque según sus reglas ese bloque está sencillamente mal.
La BIP 123, que clasifica las propuestas por la capa que tocan, lo resume en dos frases: en un soft fork, "algunas estructuras que eran válidas bajo las reglas viejas dejan de serlo bajo las nuevas", mientras que en un hard fork "estructuras que eran inválidas bajo las reglas viejas pasan a ser válidas bajo las nuevas". Todo lo que sigue se desprende de ahí.
Una regla de consenso es una regla sobre validez
No toda regla que sigue un nodo es una regla de consenso. La documentación de política de Bitcoin Core traza la línea: la política de retransmisión es "local al nodo y configurable", se aplica solo a transacciones sin confirmar y "no se aplica a las transacciones que están en bloques" (doc/policy/README.md). Un nodo que no retransmite una transacción está expresando una preferencia. Un nodo que no acepta un bloque está haciendo otra cosa.
Las reglas de consenso responden si un bloque forma parte de la cadena. Un bloque cuyo peso supera las 4.000.000 de unidades es inválido (BIP 141); una transacción coinbase que no se compromete con la altura de su propio bloque es inválida (BIP 34). Cada nodo comprueba esto por su cuenta y descarta lo que falla, sin importar cuánto trabajo se invirtió ni quién lo produjo. Un desacuerdo sobre política significa retransmitir de forma algo distinta. Un desacuerdo sobre consenso significa no estar mirando la misma cadena.
Quién está obligado a actualizar
Tomemos el límite de peso en ambas direcciones. Si los bloques se limitan a 2.000.000 de unidades en lugar de 4.000.000, todo bloque que cumple la regla nueva cumple también la vieja, así que un nodo con el programa del año pasado acepta la cadena sin notar nada. Si el límite sube a 8.000.000, el primer bloque que use el espacio extra es inválido para todo nodo que siga con el programa viejo.
La BIP 99, que establece las vías de despliegue para los cambios de consenso, enuncia la consecuencia sin rodeos: un soft fork significa que "una mayoría de hashrate de los mineros puede imponer las reglas nuevas", y los hard forks "exigen que todos los usuarios actualicen".
Así que, bajo un soft fork, un nodo sin actualizar sigue la cadena sin que nadie se lo pida, y nunca tiene que enterarse. Por eso un soft fork puede desplegarse mientras buena parte de la red corre programas viejos, y ahí está también la parte incómoda: a ese nodo lo mantiene en consenso la aplicación de reglas ajena, no la propia. Un hard fork no ofrece esa cortesía, y uno que la mayoría no adopta no fracasa en silencio. Produce una segunda cadena.
El chain split, y cuándo deja de ser temporal
Las divisiones breves ocurren todo el tiempo y no tienen nada que ver con cambios de reglas: dos mineros encuentran un bloque casi en el mismo instante y el empate se resuelve cuando el bloque siguiente extiende uno de ellos. Todos los nodos aplicaron las mismas reglas en todo momento. Un desacuerdo sobre reglas es otra cosa. La BIP 99 llama a la versión deliberada hard fork de cisma, y la define como el caso en que "los usuarios van a validar conscientemente 2 conjuntos distintos de reglas de consenso", con el resultado de que "terminarán siguiendo 2 cadenas distintas durante al menos un tiempo, quizá para siempre". Que sea para siempre depende de la dirección del cambio.
Tras un hard fork, la permanencia es estructural: los bloques de la cadena nueva son inválidos para los nodos viejos y nunca podrán reorganizarse dentro de su cadena, por mucho trabajo que se acumule detrás. Las cadenas que se van suelen dejarlo explícito. La especificación del fork de Bitcoin Cash de agosto de 2017 exigía que su primer bloque superara 1.000.000 de bytes, y daba la razón: eso "impone el hard fork respecto de la cadena original de 1MB e impide una reorganización de la cadena bifurcada hacia la cadena original" (especificación técnica UAHF, REQ-3, versión 1.6, 24 de julio de 2017).
Tras una división por soft fork no lo es, porque los bloques de la cadena estricta siguen siendo válidos para todos. La división existe solo para los nodos que aplican la regla extra, y dura solo mientras esos nodos elijan una cadena que los demás abandonarían por otra con más trabajo. La ventana de señalización obligatoria de la BIP-110 mostró ambas mitades en agosto de 2026: los nodos que aplicaban la propuesta dejaron la cadena principal en cuanto llegó un bloque sin el bit de versión exigido, y la minería en la cadena nueva se detuvo. Ese estancamiento fue aritmética. La dificultad solo se reajusta cada 2.016 bloques, de modo que una cadena que se separa hereda la dificultad de toda la red con apenas el hashrate que se fue con ella, y tiene que minar 2.016 bloques con ese ajuste antes de poder corregirlo.
Replay, y por qué una cadena escindida suele añadir protección
Ambas cadenas comparten todos los bloques anteriores a la división, así que cada moneda que existía antes existe en las dos, gastable con la misma clave y bajo el mismo script. Eso es cómodo hasta el momento exacto en que deja de serlo. Una transacción firmada para mover monedas en una cadena es, byte por byte, una transacción válida en la otra, y cualquiera puede difundirla allí. Esto es un replay, y no requiere ningún acceso especial: la transacción ya es pública y ya es válida.
La solución consiste en hacer que las dos cadenas discrepen sobre qué cubre una firma. Bitcoin Cash exigió, a nivel de consenso, que toda transacción marcara una bandera nueva en su tipo de hash y se firmara con un algoritmo de digest modificado, de modo que una firma hecha para una cadena no verifique en la otra. La especificación da el propósito en una línea: "brindar una protección fuerte contra el replay de transacciones existentes" (especificación técnica UAHF, REQ-6-2).
Alguien tiene que construir eso, y no es automático. Una propuesta de noviembre de 2017 en la lista bitcoin-dev para un mecanismo general abría describiendo el estado de la práctica: "Actualmente, cuando ocurre un hard fork, en el mejor de los casos se improvisa una protección de replay en cuestión de días y con poca revisión, o directamente no hay protección de replay" (Mats Jerratsch, 5 de noviembre de 2017).
Cómo se enciende una regla en la práctica
Un cambio tiene que empezar a aplicarse en un momento sobre el que todos los nodos estén de acuerdo, y hay más de una manera de elegirlo.
La BIP 9 señaliza a través de la cabecera del bloque. Cada despliegue recibe un bit en el campo de versión, una hora de inicio y un vencimiento. Una vez iniciado, si al menos 1.916 bloques de un período de reajuste de 2.016 bloques marcan el bit, es decir el 95 por ciento, el despliegue pasa a LOCKED_IN durante un período más y luego a ACTIVE; si el vencimiento llega sin lock-in, queda en FAILED (BIP 9). El bit es la manera en que los mineros dicen que están listos para aplicar la regla, no un voto sobre si la regla es buena idea, y la BIP 9 trata un resultado insuficiente como fracaso y no como rechazo.
La BIP 8 conserva la idea y cambia las partes que resultaron problemáticas. El inicio y
el vencimiento son alturas de bloque en lugar de marcas de tiempo, porque "el tiempo de
bloque es algo poco fiable"; el umbral sugerido es de 1.815 bloques, o el 90 por ciento; y
un minimum_activation_height permite separar el lock-in de la activación tanto como
necesiten quienes operan nodos. Su motivación nombra el problema de la BIP 9 de forma
directa: una activación "dependiente de una señalización de hashrate casi unánime, que puede
resultar poco práctica y derivar en un veto por parte de una pequeña minoría de hashrate que
no señaliza"
(BIP 8).
Su parte distintiva es la bandera lockinontimeout. Al activarla, el despliegue entra en un
período MUST_SIGNAL antes del vencimiento en el que los bloques que no señalizan se rechazan
como inválidos, de modo que el fork queda bloqueado antes de la fecha límite hagan lo que
hagan los mineros. La BIP 8 dice cuándo usarla: para cualquier soft fork "del que se espere,
o del que se compruebe, que tiene oposición política por parte de un porcentaje no
despreciable de mineros".
Un user activated soft fork prescinde de la negociación. Los nodos empiezan a aplicar la regla en una fecha fija y rechazan los bloques que no la cumplen, y la señalización de los mineros deja de ser el disparador. La BIP 148 es el ejemplo trabajado: desde el 1 de agosto de 2017, todo bloque tenía que señalizar el despliegue existente de SegWit, y "los bloques que no señalicen como se requiere serán rechazados". El precedente que citaba era mucho más viejo que la discusión a la que pertenecía, porque pay-to-script-hash se activó en una fecha fija, con reglas aplicables a todo bloque fechado el 1 de abril de 2012 o después (BIP 16).
El mecanismo no decide si una regla obligatoria es segura o temeraria. Un nodo que aplica una regla que el resto de la red ignora obtiene una cadena propia: eso es lo valioso cuando funciona y el costo cuando no. La mayoría de las activaciones son más aburridas, y la de Taproot no produjo ninguna división.
Lo que un fork no hace
No cambia las monedas de nadie. Ambas cadenas heredan la misma historia, así que una salida que existía antes de la división sigue existiendo después, conserva el mismo monto y se puede gastar con la misma clave. Un fork puede crear un segundo lugar donde existe una copia de un saldo. No puede meter la mano en el primero.
Correr un programa viejo no coloca a nadie en una cadena nueva. Tras un soft fork, el programa viejo sigue la misma cadena que todos sin que nadie se lo pida, que es justamente la definición de la cosa. Tras un hard fork, el programa viejo se queda en la cadena que ya consideraba válida y rechaza la nueva. Terminar en una cadena nueva exige un acto deliberado: instalar un programa que aplique reglas que el anterior rechazaba.
Señalizar no es votar. Los mineros eligen qué transacciones válidas ponen en los bloques. Los nodos deciden qué significa válido. Una mayoría de hashrate puede imponer un endurecimiento, y no puede volver aceptable un relajamiento para quien no lo instaló.
Por dónde seguir
SegWit y cuánto pesa un bloque explica cómo un soft fork logró cambiar la capacidad efectiva de un bloque, que es el caso que más a menudo se confunde con un aumento de tamaño. Para la historia en la que todo esto se decidió en lugar de describirse, la guerra del tamaño de bloque produjo casi todo el vocabulario de esta página.