Le même bug, deux issues : Telestai, Ravencoin et ce dont hérite un fork

Hier, nous avons écrit sur le bug de consensus de Ravencoin : un champ nHeight non validé dans l'en-tête de bloc, qui permettait de forger la preuve de travail, et la réorganisation de chaîne de trois jours qu'il a fallu pour le défaire.

Cette histoire a une seconde moitié, et c'est la plus utile. Une autre chaîne portait exactement le même bug exactement au même endroit. Il n'a jamais été exploité.

La différence entre ces deux issues mérite d'être comprise, car ce n'est pas une différence de code.

Telestai a hérité du défaut, parce que c'est ce que font les forks

Telestai est un fork de Ravencoin. Sa base de code descend de celle de Ravencoin, en passant par Meowcoin : les notes de version de Telestai Core 3.0.1 mentionnent encore une « purge des sources Meowcoin » parmi les nettoyages, ce qui dit à quel point cette filiation restait visible récemment dans l'arbre des sources.

La validation d'en-tête de Ravencoin ne vérifiait pas le nHeight déclaré par rapport à la position réelle du bloc dans la chaîne. Celle de Meowcoin non plus. Celle de Telestai non plus. Personne n'a introduit le bug dans Telestai ; il est arrivé avec tout le reste, de la façon dont un fork hérite des parties d'une base de code que personne ne regarde en même temps que de celles qu'on regarde.

C'est la mécanique sans gloire par laquelle un seul défaut devient le problème de plusieurs chaînes. Les forks ne sont pas des copies qui dérivent vers l'indépendance. Ce sont des copies qui transportent tout l'historique d'hypothèses du parent — y compris, ici, l'hypothèse que quelqu'un validait déjà ce champ.

Ce que Telestai a fait avec deux jours de préavis

L'exploit de Ravencoin a été divulgué publiquement le 11 août 2026. Telestai Core 2.1.8 est sorti le 13 août, intitulé sobrement « Security: KAWPOW nHeight bind ».

Ses notes de version ne prennent pas de gants :

Cette version corrige un problème de consensus/DoS dans KAWPOW où le champ d'en-tête nHeight (qui sélectionne l'époque ethash) n'était pas lié à la chaîne. La même classe de bug a été exploitée sur le mainnet de Ravencoin. Les nœuds Telestai exécutant des versions antérieures restent exposés jusqu'à leur mise à jour.

Le correctif lui-même est en couches, et c'est le feuilletage qui est intéressant :

• Une borne d'époque absolue est appliquée immédiatement, avant tout calcul de hachage de preuve de travail.
• La liaison stricte height == prev + 1 s'active au bloc 1 100 000 — à la manière d'un soft fork, sans réécriture de l'histoire.
• La preuve de travail n'est calculée qu'après avoir trouvé le bloc parent et vérifié la hauteur, ce qui ferme une voie d'épuisement mémoire où un nœud pouvait être poussé à un travail coûteux sur un en-tête qu'il aurait dû rejeter d'emblée.
• Les mêmes vérifications s'appliquent dans ConnectBlock et VerifyDB, afin qu'un nœud réindexant sa base ne réaccepte pas discrètement ce que les nouvelles règles interdisent.

Le mainnet se situait autour de la hauteur 1 057 000 quand 2.1.8 est arrivé. L'application a été fixée à 1 100 000. Cet écart — environ 43 000 blocs — était délibéré : assez de marge pour que plateformes, pools, explorateurs et opérateurs de nœuds se mettent à jour avant l'entrée en vigueur, et pas assez pour laisser la fenêtre ouverte indéfiniment.

Telestai a aussi cité sa source. Les notes pointent vers 2miners/Ravencoin, branche rvn-nheight-fix — le correctif même issu de l'incident Ravencoin — et remercient les chercheurs qui ont documenté la correction plus complète de l'acceptation des en-têtes. Le remède a emprunté le chemin qu'avait pris le bug.

Les deux issues, côte à côte

Deux chaînes. Un héritage de code. Un même défaut latent.

Celui de Ravencoin a d'abord été trouvé par un attaquant. Résultat : quatre jours de blocs contrefaits avant la divulgation publique, des plateformes suspendant dépôts et retraits, une chute de prix d'environ 20 % et une réorganisation de trois jours pour retirer la branche empoisonnée.

Celui de Telestai a été trouvé en lisant le rapport d'incident d'autrui. Résultat : un correctif deux jours plus tard, une hauteur d'activation fixée avec de la marge et — puisqu'il n'y avait aucune histoire invalide à retirer — aucune réorganisation. Rien n'a été annulé parce que rien n'avait besoin de l'être.

C'est là toute la différence. Pas un meilleur code. Pas un bug différent. Juste qui a remarqué en premier, et à quelle vitesse les mainteneurs de la chaîne ont agi sur la mauvaise semaine de quelqu'un d'autre.

Puis Telestai a changé d'algorithme entièrement

Six jours après le correctif de sécurité, Telestai a publié Core 3.0.0, avec un fork au bloc 1 150 000 — autour du 16 octobre 2026 — vers Meraki, son propre algorithme de preuve de travail. Meraki reste un parent de KAWPOW (un dérivé d'Ethash teinté de ProgPoW, et le mineur est né comme un fork de kawpowminer), présenté comme moins gourmand en énergie et accessible à des GPU modestes.

Il faut être prudent sur la causalité ici, car il est tentant de tracer une ligne droite et la ligne n'est pas droite. Meraki était déjà en chantier avant août : les builds de rodage testnet pour 3.0.0 ont été publiés les 13 et 14 août, les jours mêmes de la version de sécurité, et ce n'est pas un calendrier qu'on assemble en quarante-huit heures. Le changement d'algorithme était un travail planifié qui a atterri par hasard à côté d'un incident, pas une réaction à celui-ci.

La liste des versions contient aussi une petite leçon sur les aspects ingrats de la maintenance d'une chaîne. Entre le correctif de sécurité et le fork, Telestai a publié 2.1.9 pour une raison sans rapport avec le consensus : 2.1.8 avait été compilée contre une Berkeley DB plus récente, et ouvrir un ancien wallet.dat avec elle pouvait réécrire les journaux du portefeuille au point que des clients plus anciens ne puissent plus lire le fichier. Ils ont donc recompilé contre Berkeley DB 4.8 et republié. Une version de sécurité ne sert pas à grand-chose si la mise à jour met en danger les fichiers de portefeuille de vos utilisateurs.

Pourquoi cela dépasse deux petites chaînes

La plupart des gens qui lisent ceci ne détiennent ni RVN ni TLS. Ce qui se généralise, c'est le motif.

Les chaînes forkées partagent une surface de bugs, et presque personne ne la suit. Litecoin, Dogecoin, Bitcoin Cash, Ravencoin, Zcash et des dizaines d'autres descendent de Bitcoin Core, et chacune porte un point de divergence après lequel les correctifs amont cessent d'arriver tout seuls. Une vulnérabilité divulguée dans une chaîne est une question ouverte pour toute chaîne située en aval du même code — et plus un fork a dérivé, plus il faut de travail pour seulement savoir si le correctif s'applique. Telestai a répondu à cette question en deux jours. Tous les forks n'ont pas quelqu'un dont c'est le métier.

« Personne ne l'a exploité » n'équivaut pas à « il n'était pas là ». Le logiciel de nœud de Telestai a été vulnérable pendant toute son existence. Le bug était réel depuis le début ; seule l'attention était neuve. Les chaînes qui ne reçoivent jamais le rapport d'incident d'une sœur ne l'apprennent pas de cette façon.

Un correctif qui arrive avant l'exploit ne coûte presque rien. Le même correctif après coûte une réorganisation. Le travail technique de Telestai 2.1.8 et celui du hard fork de Ravencoin sont grosso modo le même correctif. Ce qui a différé, c'est tout ce qui l'entourait : y avait-il une histoire invalide à écarter, les plateformes devaient-elles s'arrêter, les confirmations des utilisateurs signifiaient-elles quelque chose pendant trois jours.

C'est le même raisonnement que derrière les builds reproductibles et l'examen des dépendances : l'essentiel de ce qui vous protège se situe en amont de tout ce que vous pouvez voir depuis un portefeuille, et c'est maintenu par des gens qui font attention à votre place.

Ce que cela signifie dans SSP

Concrètement : rien ne change pour vous.

SSP prend en charge Ravencoin, et notre nœud tourne en 4.8.0 sur la chaîne rétablie — nous avons vérifié hier les empreintes de bloc de part et d'autre de la réorganisation par rapport à la chaîne de référence. SSP ne prend pas en charge Telestai, il n'y a donc aucun solde Telestai dans votre portefeuille dont vous devriez vous soucier.

Si nous écrivons sur une chaîne que nous ne prenons pas en charge, c'est que l'histoire illustre proprement quelque chose que nous prenons, lui, très au sérieux. Exploiter une infrastructure de nœuds signifie suivre le travail de sécurité en amont pour chaque chaîne que nous portons, y compris celles dont les bases de code partagent des ancêtres. Cette valeur est totalement invisible quand elle fonctionne : un nœud corrigé ressemble exactement à un nœud non corrigé, jusqu'au jour où ce n'est plus le cas.

Le mois d'août de Telestai, c'est à quoi cela ressemble de l'intérieur : un mainteneur lit l'exploit d'un autre, en reconnaît la forme dans son propre arbre de code, et publie. Pas d'incident, pas de réorganisation, aucune annonce dont quiconque à l'extérieur se souviendrait. Juste un numéro de version qui monte.