Un nodo de Bitcoin es un programa que verifica bloques y transacciones. Un Reorg es el cambio de un nodo de Bitcoin a otra rama válida con más Proof of Work acumulado, es decir, trabajo acreditado por la minería. El nodo vuelve a evaluar los últimos bloques y sus pagos. No cambia las reglas de Bitcoin ni da a nadie un botón para cancelar pagos ajenos.
Anna recibe 20.000 satoshi, las pequeñas unidades del bitcoin. Su monedero muestra una confirmación: el pago está en un bloque que su nodo ha aceptado. Entonces el nodo descubre una rama competidora válida que todavía no incluye ese pago. Cuando esa rama acredita más trabajo de minería acumulado, el nodo pasa a seguirla. Esa sustitución de parte del historial se llama Reorg. El pago de Anna puede volver a esperar confirmación sin que nadie haya robado sus claves ni cambiado su firma. No decide una votación ni simplemente el número de bloques, sino el chainwork: la suma del trabajo que cada bloque acredita según su dificultad. El nodo rechaza una rama inválida aunque tenga más trabajo. [1] [4]
Lo que Anna vea después depende de la nueva rama. Si también incluye su pago, este sigue confirmado, aunque puede cambiar el número de confirmaciones. Si no, Bitcoin Core puede intentar devolverlo al Mempool, su lista temporal de transacciones sin confirmar que esperan un bloque. El regreso no está garantizado. Una salida de una transacción anterior registra una cantidad y las condiciones para gastarla. La nueva rama puede haber gastado esos mismos fondos en otra transacción; también puede faltar una salida anterior que se pretende gastar o incumplirse condiciones temporales u otros requisitos de admisión. Por eso un pago que vuelve a esperar es distinto de otro que el nuevo historial ya no permite. [1]
Una confirmación corresponde al bloque que contiene el pago. Cada bloque posterior añade una confirmación y más trabajo que una rama competidora tendría que superar. Un pago en el último bloque tiene, por tanto, una confirmación; cuanto más profundo quede en el historial aceptado, más difícil suele ser reemplazar esa parte. Pero ningún número finito de confirmaciones garantiza matemáticamente que ese reemplazo sea imposible. Comercios y plataformas de intercambio ajustan la espera al valor del pago y al riesgo que aceptan. [3] [5]
Un Reorg por sí solo no demuestra un ataque. Dos mineros pueden encontrar casi a la vez bloques con el mismo predecesor. La información sobre los bloques no recorre la red de forma instantánea, de modo que los nodos pueden seguir brevemente extremos distintos de la cadena. Cuando una rama válida acumula más trabajo, pasan a ella; el bloque abandonado es un Stale Block. Ese mismo mecanismo puede explotarse en un ataque Double Spend: el atacante intenta imponer un historial en el que los mismos fondos se pagaron a otro destino. Para evaluar lo ocurrido importa saber por qué cambió la rama y qué pagos resultaron afectados. [4] [5]
Durante un Reorg, el nodo conserva las mismas reglas y elige entre historiales que las cumplen. Un Hard Fork cambia las reglas de validez, de modo que el software antiguo y el nuevo pueden juzgar de forma diferente un mismo bloque. Una reorganización no crea por sí sola otra moneda ni reescribe las reglas de Bitcoin. Los capítulos siguientes explican cómo realiza el nodo ese cambio de historial. [4]
El tip es el último bloque de la rama aceptada en ese momento. El punto de bifurcación es el último bloque compartido por la cadena activa actual y la rama alternativa. La profundidad suele expresarse como el número de bloques del extremo activo que hay que desconectar para llegar a ese antecesor común. Un Reorg de un bloque sustituye el extremo; uno más profundo revierte varios bloques confirmados. La profundidad depende de la perspectiva de cada nodo. [1]
Un Full Node verifica las reglas por sí mismo. Los nombres de funciones siguientes describen su implementación en Bitcoin Core. Bitcoin Core no elige simplemente la rama más alta o popular. La cadena candidata debe cumplir las reglas de consenso del nodo durante la activación; un mayor chainwork no convierte un bloque inválido en válido. FindMostWorkChain elige al candidato con más trabajo cuya invalidez no se conoce. Esto aún no implica una validación completa: se realizan comprobaciones adicionales al conectar los bloques en ActivateBestChain. Las ramas cuya invalidez ya se conoce se excluyen. [1]
Un UTXO es una salida de transacción aún sin gastar; el conjunto UTXO reúne esas salidas disponibles. Los datos undo guardan lo necesario para deshacer los efectos de un bloque. DisconnectTip y la lógica de validación asociada deshacen los efectos de los bloques desconectados en orden inverso. Se restauran los UTXO gastados y las salidas creadas por el bloque retirado dejan de estar confirmadas. Por eso Bitcoin Core conserva datos de deshacer: debe reconstruir el conjunto UTXO exactamente en el punto de bifurcación. [1]
Rollback significa aquí volver al estado anterior a los bloques desconectados; chainstate es el estado de trabajo del nodo correspondiente al historial aceptado. Tras la reversión, ConnectTip conecta en orden ascendente los bloques de la rama con mayor chainwork. Cada transacción se valida de nuevo contra el conjunto UTXO reconstruido y las reglas vigentes a esa altura. El resultado es un chainstate correspondiente a una historia concreta, no una mezcla de transacciones de ambas ramas. [1]
La Coinbase Transaction es la primera transacción del bloque y asigna la recompensa al minero. La altura h indica la posición del bloque en la cadena. La transacción coinbase es una excepción: no vuelve al mempool después de la desconexión. Según el consenso, una salida coinbase creada a la altura h puede gastarse por primera vez en el bloque h + 100. Con el extremo en h + 99, el bloque de origen tiene 100 confirmaciones y la condición de madurez permite incluir el gasto en el bloque siguiente. Si un Reorg retira el bloque con la coinbase, su recompensa desaparece del chainstate activo. También pueden resultar inválidas las transacciones descendientes que dependían de la historia retirada. [1] [2] [3]
Lo que sigue son nombres de funciones de una versión concreta del programa, no pasos adicionales para quien utiliza un monedero. En Bitcoin Core v29.0 los pasos son explícitos: FindMostWorkChain encuentra al candidato con más chainwork cuya invalidez no se conoce, ActivateBestChainStep puede desconectar el extremo actual, ConnectTip valida y conecta los bloques alternativos y MaybeUpdateMempoolForReorg reexamina las transacciones de los bloques desconectados. La activación puede detectar que un candidato es inválido y continuar buscando otra rama. Un Reorg grande exige procesar más bloques desconectados y conectados, por lo que puede prolongar el procesamiento de ActivateBestChain. [1]
Para obtener la imagen más completa, lee esta entrada junto con Confirmación, Proof of Work, Stale Block, Doble gasto, Full Node, UTXO. También enlazan con esta entrada Confirmación, Doble gasto, Transacción coinbase, Soft Fork.