El mismo fallo, dos desenlaces: Telestai, Ravencoin y lo que hereda un fork

Ayer escribimos sobre el fallo de consenso de Ravencoin: un campo nHeight sin validar en la cabecera del bloque que permitía falsificar la prueba de trabajo, y la reorganización de cadena de tres días que hizo falta para deshacerlo.

Esa historia tiene una segunda mitad, y es la más útil. Otra cadena tenía exactamente el mismo fallo exactamente en el mismo sitio. Nunca fue explotado.

La diferencia entre ambos desenlaces merece entenderse, porque no es una diferencia de código.

Telestai heredó el defecto, porque eso es lo que hacen los forks

Telestai es un fork de Ravencoin. Su base de código desciende de la de Ravencoin, pasando por Meowcoin: las notas de la versión Telestai Core 3.0.1 todavía enumeran una «purga de fuentes de Meowcoin» entre las limpiezas, lo que da idea de hasta qué punto ese linaje seguía visible en el árbol de fuentes hace nada.

La validación de cabeceras de Ravencoin no comprobaba el nHeight declarado contra la posición real del bloque en la cadena. La de Meowcoin tampoco. La de Telestai tampoco. Nadie introdujo el fallo en Telestai; llegó con todo lo demás, del mismo modo en que un fork hereda tanto las partes del código que alguien mira como las que nadie mira.

Esta es la mecánica poco lucida por la que un solo defecto se convierte en el problema de varias cadenas. Los forks no son copias que se van independizando a la deriva. Son copias que arrastran todo el historial de supuestos del padre, incluido, en este caso, el supuesto de que alguien ya validaba ese campo.

Lo que hizo Telestai con dos días de aviso

El exploit de Ravencoin se divulgó públicamente el 11 de agosto de 2026. Telestai Core 2.1.8 salió el 13 de agosto, titulado, sin rodeos, «Security: KAWPOW nHeight bind».

Sus notas de versión no se andan con matices:

Esta versión corrige un problema de consenso/DoS en KAWPOW en el que el campo nHeight de la cabecera (que selecciona la época de ethash) no estaba vinculado a la cadena. La misma clase de fallo fue explotada en la mainnet de Ravencoin. Los nodos de Telestai con versiones anteriores siguen expuestos hasta que actualicen.

La corrección en sí está por capas, y las capas son lo interesante:

• Se impone un límite absoluto de época de inmediato, antes de que se calcule ningún hash de prueba de trabajo.
• La vinculación estricta height == prev + 1 se activa en el bloque 1.100.000, al estilo de un soft fork, sin reescribir historia.
• La prueba de trabajo solo se calcula después de encontrar el bloque padre y verificar la altura, lo que cierra una vía de agotamiento de memoria en la que se podía obligar a un nodo a hacer trabajo caro sobre una cabecera que debería haber rechazado de plano.
• Las mismas comprobaciones se aplican en ConnectBlock y VerifyDB, de modo que un nodo que reindexa su base de datos no puede volver a aceptar en silencio lo que las nuevas reglas prohíben.

La mainnet estaba alrededor de la altura 1.057.000 cuando aterrizó la 2.1.8. La imposición se fijó en 1.100.000. Ese margen —unos 43.000 bloques— era deliberado: pista suficiente para que exchanges, pools, exploradores y operadores de nodos actualizaran antes de que la regla entrara en vigor, y no tanta como para dejar la ventana abierta indefinidamente.

Telestai también acreditó su fuente. Las notas apuntan a 2miners/Ravencoin, rama rvn-nheight-fix —el mismo parche salido del incidente de Ravencoin— y agradecen a los investigadores que documentaron la corrección más completa de aceptación de cabeceras. El arreglo viajó por el mismo camino que había recorrido el fallo.

Los dos desenlaces, uno al lado del otro

Dos cadenas. Una herencia de código. Un mismo defecto latente.

El de Ravencoin lo encontró antes un atacante. El resultado fueron cuatro días de bloques falsificados antes de la divulgación pública, exchanges deteniendo depósitos y retiradas, una caída de precio de en torno al 20% y una reorganización de tres días para eliminar la rama envenenada.

El de Telestai se encontró leyendo el informe de incidente de otro. El resultado fue un parche dos días después, una altura de activación fijada con holgura y —al no haber historia inválida que eliminar— ninguna reorganización. No se revirtió nada porque no hacía falta revertir nada.

Esa es toda la diferencia. No mejor código. No un fallo distinto. Solo quién se dio cuenta primero, y con qué rapidez actuó la gente que mantiene la cadena a partir de la mala semana de otro.

Después Telestai cambió el algoritmo entero

Seis días después del parche de seguridad, Telestai publicó Core 3.0.0, con un fork en el bloque 1.150.000 —alrededor del 16 de octubre de 2026— hacia Meraki, su propio algoritmo de prueba de trabajo. Meraki sigue siendo pariente de KAWPOW (un derivado de Ethash con sabor a ProgPoW, y el minero nació como un fork de kawpowminer), planteado como de menor consumo y alcanzable con GPU modestas.

Conviene ser cuidadoso con la causalidad aquí, porque tienta trazar una línea recta y la línea no es recta. Meraki ya estaba en marcha antes de agosto: las compilaciones de prueba de la 3.0.0 para testnet se publicaron los días 13 y 14 de agosto, los mismos días que la versión de seguridad, y eso no es un calendario que nadie monte en cuarenta y ocho horas. El cambio de algoritmo era trabajo planificado que casualmente aterrizó junto a un incidente, no una reacción a él.

También hay una pequeña lección en la lista de versiones sobre las partes menos lucidas de mantener una cadena. Entre la corrección de seguridad y el fork, Telestai publicó la 2.1.9 por un motivo que nada tiene que ver con el consenso: la 2.1.8 se había compilado contra una Berkeley DB más nueva, y abrir un wallet.dat antiguo con ella podía reescribir los registros del monedero de forma que los clientes anteriores ya no pudieran leer el archivo. Así que recompilaron contra Berkeley DB 4.8 y volvieron a publicarla. Una versión de seguridad no sirve de mucho si actualizarse a ella pone en riesgo los archivos de monedero de tus usuarios.

Por qué esto importa más allá de dos cadenas pequeñas

Casi nadie que lea esto tiene ni RVN ni TLS. Lo que se generaliza es el patrón.

Las cadenas forkeadas comparten superficie de fallo, y casi nadie la vigila. Litecoin, Dogecoin, Bitcoin Cash, Ravencoin, Zcash y decenas más descienden de Bitcoin Core, y cada una carga con un punto de divergencia a partir del cual las correcciones de aguas arriba dejan de llegar solas. Una vulnerabilidad divulgada en una cadena es una pregunta abierta para todas las cadenas situadas aguas abajo del mismo código, y cuanto más se ha alejado un fork, más trabajo cuesta saber siquiera si el parche aplica. Telestai respondió a esa pregunta en dos días. No todos los forks tienen a alguien cuyo trabajo sea ese.

«Nadie lo explotó» no es lo mismo que «no estaba ahí». El software de nodo de Telestai fue vulnerable durante toda su existencia. El fallo fue real todo el tiempo; lo nuevo era solo la atención. Las cadenas que nunca reciben el informe de incidente de un hermano no se enteran por esta vía.

Un arreglo que llega antes del exploit no cuesta casi nada. El mismo arreglo después cuesta una reorganización. El trabajo técnico de Telestai 2.1.8 y el del hard fork de Ravencoin son a grandes rasgos el mismo parche. Lo que cambió fue todo lo demás: si había historia inválida que descartar, si los exchanges tenían que parar, si las confirmaciones de los usuarios significaban algo durante tres días.

Es el mismo razonamiento que hay detrás de las compilaciones reproducibles y el escrutinio de dependencias: casi todo lo que te protege está aguas arriba de lo que puedes ver desde dentro de un monedero, y lo mantiene gente que presta atención en tu nombre.

Qué significa esto en SSP

En la práctica: para ti no cambia nada.

SSP admite Ravencoin, y nuestro nodo corre la 4.8.0 en la cadena recuperada; verificamos los hashes de bloque a ambos lados de la reorganización contra la cadena de referencia en el artículo de ayer. SSP no admite Telestai, así que no hay ningún saldo de Telestai en tu monedero por el que preocuparse.

Escribimos sobre una cadena que no admitimos porque la historia ilustra con limpieza algo que sí nos tomamos en serio. Operar infraestructura de nodos significa seguir el trabajo de seguridad aguas arriba de cada cadena que llevamos, incluidas aquellas cuyas bases de código comparten antepasados. El valor de eso es completamente invisible cuando funciona: un nodo parcheado se ve exactamente igual que uno sin parchear, justo hasta el día en que deja de verse igual.

El agosto de Telestai es cómo se ve eso desde dentro: alguien que mantiene el proyecto lee sobre el exploit de otro, reconoce esa forma en su propio árbol de código y publica. Sin incidente, sin reorganización, sin ningún anuncio que nadie de fuera vaya a recordar. Solo un número de versión que sube.