Derselbe Fehler, zwei Ausgänge: Telestai, Ravencoin und was ein Fork erbt

Gestern schrieben wir über Ravencoins Konsensfehler — ein ungeprüftes nHeight-Feld im Blockheader, mit dem sich Proof of Work fälschen ließ, und die drei Tage tiefe Chain-Reorganisation, die nötig war, um das rückgängig zu machen.

Diese Geschichte hat eine zweite Hälfte, und die ist die nützlichere. Eine andere Chain hatte genau denselben Fehler an genau derselben Stelle. Sie wurde nie ausgenutzt.

Der Unterschied zwischen diesen beiden Ausgängen lohnt das Verständnis, denn er ist kein Unterschied im Code.

Telestai erbte den Fehler, weil Forks genau das tun

Telestai ist ein Ravencoin-Fork. Seine Codebasis stammt von Ravencoins ab, über Meowcoin — die Release Notes von Telestai Core 3.0.1 führen unter den Aufräumarbeiten noch immer eine „Meowcoin source purge" auf, was zeigt, wie kürzlich diese Abstammung im Quellbaum noch sichtbar war.

Ravencoins Header-Validierung prüfte den angegebenen nHeight nicht gegen die tatsächliche Position des Blocks in der Chain. Meowcoins auch nicht. Telestais auch nicht. Niemand hat den Fehler in Telestai eingebaut; er kam mit allem anderen mit — so, wie ein Fork die Teile einer Codebasis erbt, die niemand anschaut, zusammen mit denen, die jemand anschaut.

Das ist die unglamouröse Mechanik, mit der ein einzelner Fehler zum Problem mehrerer Chains wird. Forks sind keine Kopien, die in die Unabhängigkeit driften. Sie sind Kopien, die die gesamte Annahmengeschichte des Elternteils mittragen — hier eingeschlossen die Annahme, jemand habe dieses Feld bereits validiert.

Was Telestai mit zwei Tagen Vorlauf tat

Ravencoins Exploit wurde am 11. August 2026 öffentlich gemacht. Telestai Core 2.1.8 erschien am 13. August, betitelt schlicht mit „Security: KAWPOW nHeight bind".

Die Release Notes drücken sich nicht:

Dieses Release behebt ein KAWPOW-Konsens-/DoS-Problem, bei dem das Header-Feld nHeight (das die Ethash-Epoche auswählt) nicht an die Chain gebunden war. Dieselbe Fehlerklasse wurde auf Ravencoins Mainnet ausgenutzt. Telestai-Nodes mit älteren Versionen bleiben exponiert, bis sie aktualisieren.

Der Fix selbst ist geschichtet, und die Schichtung ist der interessante Teil:

• Eine absolute Epochengrenze wird sofort durchgesetzt, bevor überhaupt Proof-of-Work-Hashing stattfindet.
• Die strikte Bindung height == prev + 1 aktiviert sich bei Block 1.100.000 — im Soft-Fork-Stil, ohne Umschreiben der Historie.
• Proof of Work wird erst berechnet, nachdem der Elternblock gefunden und die Höhe geprüft wurde. Das schließt einen Speichererschöpfungspfad, auf dem sich ein Node zu teurer Arbeit an einem Header verleiten ließ, den er sofort hätte ablehnen müssen.
• Dieselben Prüfungen gelten in ConnectBlock und VerifyDB, damit ein Node beim Reindizieren seiner Datenbank nicht stillschweigend wieder annimmt, was die neuen Regeln verbieten.

Das Mainnet stand bei etwa Höhe 1.057.000, als 2.1.8 landete. Die Durchsetzung wurde auf 1.100.000 gelegt. Dieser Abstand — rund 43.000 Blöcke — war Absicht: genug Anlauf für Börsen, Pools, Explorer und Node-Betreiber, um vor Inkrafttreten zu aktualisieren, und nicht so viel, dass das Fenster unbegrenzt offen blieb.

Telestai nannte auch die Quelle. Die Release Notes verweisen auf 2miners/Ravencoin, Branch rvn-nheight-fix — denselben Patch, der aus Ravencoins Vorfall hervorging — und danken den Forschern, die den umfassenderen Header-Annahme-Fix dokumentiert haben. Die Lösung reiste denselben Weg wie zuvor der Fehler.

Die zwei Ausgänge nebeneinander

Zwei Chains. Ein Code-Erbe. Ein identischer schlummernder Fehler.

Ravencoins fand zuerst ein Angreifer. Das Ergebnis: vier Tage gefälschter Blöcke vor der öffentlichen Bekanntgabe, Börsen, die Ein- und Auszahlungen stoppten, ein Kursverlust von rund 20 % und eine drei Tage tiefe Reorganisation, um den vergifteten Zweig zu entfernen.

Telestais fand jemand, indem er den Vorfallsbericht eines anderen las. Das Ergebnis: ein Patch zwei Tage später, eine Aktivierungshöhe mit Luft nach oben und — weil es keine ungültige Historie zu entfernen gab — überhaupt keine Reorganisation. Nichts wurde zurückgerollt, weil nichts zurückgerollt werden musste.

Das ist der ganze Unterschied. Kein besserer Code. Kein anderer Fehler. Nur wer es zuerst bemerkte und wie schnell die Leute, die die Chain pflegen, auf die schlechte Woche eines anderen reagierten.

Dann tauschte Telestai den Algorithmus komplett aus

Sechs Tage nach dem Sicherheitspatch erschien Telestai Core 3.0.0 mit einem Fork bei Block 1.150.000 — etwa am 16. Oktober 2026 — hin zu Meraki, dem eigenen Proof-of-Work-Algorithmus. Meraki ist weiterhin mit KAWPOW verwandt (ein ProgPoW-gefärbter Ethash-Abkömmling, und der Miner begann als Fork von kawpowminer) und wird als stromsparender und auf bescheidenen GPUs erreichbar beworben.

Bei der Kausalität lohnt sich Vorsicht, denn es ist verlockend, eine gerade Linie zu ziehen, und die Linie ist nicht gerade. Meraki war schon vor August unterwegs: Testnet-Soak-Builds für 3.0.0 wurden am 13. und 14. August veröffentlicht, denselben Tagen wie das Sicherheitsrelease — so einen Fahrplan stellt niemand in achtundvierzig Stunden auf. Der Algorithmuswechsel war geplante Arbeit, die zufällig neben einem Vorfall landete, keine Reaktion darauf.

In der Release-Liste steckt außerdem eine kleine Lehre über die unglamourösen Seiten der Chain-Pflege. Zwischen Sicherheitsfix und Fork brachte Telestai 2.1.9 heraus, aus einem Grund, der nichts mit Konsens zu tun hat: 2.1.8 war gegen eine neuere Berkeley DB gebaut, und das Öffnen einer alten wallet.dat damit konnte die Wallet-Logs so umschreiben, dass ältere Clients die Datei nicht mehr lesen konnten. Also baute man gegen Berkeley DB 4.8 neu und lieferte erneut aus. Ein Sicherheitsrelease nützt wenig, wenn das Aktualisieren die Wallet-Dateien der Nutzer gefährdet.

Warum das über zwei kleine Chains hinaus zählt

Die meisten, die das lesen, halten weder RVN noch TLS. Was sich verallgemeinert, ist das Muster.

Geforkte Chains teilen sich eine Fehlerfläche, und fast niemand verfolgt sie. Litecoin, Dogecoin, Bitcoin Cash, Ravencoin, Zcash und Dutzende weitere stammen von Bitcoin Core ab, und jede trägt einen Divergenzpunkt, ab dem Upstream-Fixes nicht mehr automatisch ankommen. Eine in einer Chain veröffentlichte Schwachstelle ist eine offene Frage für jede Chain stromabwärts desselben Codes — und je weiter ein Fork abgedriftet ist, desto mehr Arbeit kostet es, überhaupt zu wissen, ob der Fix zutrifft. Telestai beantwortete diese Frage in zwei Tagen. Nicht jeder Fork hat jemanden, dessen Aufgabe das ist.

„Niemand hat es ausgenutzt" ist nicht dasselbe wie „es war nicht da". Telestais Node-Software war während ihrer gesamten Existenz verwundbar. Der Fehler war die ganze Zeit real; neu war nur die Aufmerksamkeit. Chains, die nie einen Vorfallsbericht von einem Geschwister bekommen, erfahren es auf diesem Weg nicht.

Ein Fix vor dem Exploit kostet fast nichts. Derselbe Fix danach kostet eine Reorg. Die technische Arbeit in Telestai 2.1.8 und in Ravencoins Hard Fork ist im Groben derselbe Patch. Unterschiedlich war alles drumherum: ob es ungültige Historie zu verwerfen gab, ob Börsen anhalten mussten, ob die Bestätigungen der Nutzer drei Tage lang irgendetwas bedeuteten.

Es ist dieselbe Logik wie hinter reproduzierbaren Builds und der Prüfung von Abhängigkeiten: Das meiste, was dich schützt, liegt stromaufwärts von allem, was du aus einer Wallet heraus sehen kannst, und es wird von Leuten gepflegt, die stellvertretend für dich aufpassen.

Was das in SSP bedeutet

Praktisch: Für dich ändert sich nichts.

SSP unterstützt Ravencoin, und unser Node läuft mit 4.8.0 auf der wiederhergestellten Chain — im gestrigen Beitrag haben wir die Blockhashes beiderseits der Reorg gegen die Referenzchain geprüft. SSP unterstützt Telestai nicht, es gibt also kein Telestai-Guthaben in deiner Wallet, um das du dir Sorgen machen müsstest.

Wir schreiben über eine Chain, die wir nicht unterstützen, weil die Geschichte sauber illustriert, was wir sehr wohl ernst nehmen. Node-Infrastruktur zu betreiben heißt, die Sicherheitsarbeit stromaufwärts für jede Chain zu verfolgen, die wir führen — auch für jene, deren Codebasen gemeinsame Vorfahren haben. Der Wert davon ist völlig unsichtbar, solange es funktioniert: Ein gepatchter Node sieht genau aus wie ein ungepatchter, bis zu dem Tag, an dem er es nicht mehr tut.

Telestais August ist, wie das von innen aussieht: Jemand, der das Projekt pflegt, liest vom Exploit eines anderen, erkennt dessen Gestalt im eigenen Quellbaum und liefert aus. Kein Vorfall, keine Reorg, keine Ankündigung, an die sich draußen jemand erinnern würde. Nur eine Versionsnummer, die steigt.