Litecoin bringt eine Soft-Fork-MWEB-Regel und einen stillen Fix
Litecoin Core 0.21.5.8, veröffentlicht am 12. September 2026, gilt als Wartungsrelease — und enthält zwei Dinge, die keine Wartung sind.
Eine Soft-Fork-Konsensregel. Ab Mainnet-Höhe 3.172.640 verwerfen Nodes einen MWEB-Block, dessen Kernel Extra-Daten signalisiert, aber eine leere Extra-Daten-Nutzlast trägt. Die Release Notes sind deutlich: Gültige Wallets und Miner erzeugen diese Kodierung nicht, doch alle Miner und Pools müssen vor der Aktivierung aktualisieren, sonst produzieren sie Blöcke, die aktualisierte Nodes ablehnen.
Ein Security-Fix, der bei seiner Entstehung nicht veröffentlicht wurde. Das Release „enthält Änderungen aus v0.21.5.7, das als wichtiger Sicherheitsfix vorbereitet und nur an Mining-Pools verteilt statt öffentlich freigegeben wurde." Die begleitende MWEB-Validierung ist genau beschrieben: Der vollständige Erweiterungsblock wird unmittelbar vor dem Verbinden mit dem Chainstate erneut validiert, auch bei aus der Platte neu geladenen Blöcken während Reorganisation und Crash-Recovery, damit Signaturen, Beweise, Roots und Peg-Commitments an genau dem Körper geprüft werden, der angewandt wird.

Was das bedeutet
Ein Soft Fork mit genannter Aktivierungshöhe ist eine Frist, kein Vorschlag. Block 3.172.640 ist ein konkreter Punkt, ab dem ein nicht aktualisierter Miner Blöcke erzeugen kann, die das Netz ablehnt. Für Pools und Börsen untertreibt „Upgrade empfohlen" — das ist eine Koordinate auf der Kette, und die falsche Seite kostet einen abgelehnten Block.
Einen Security-Fix zuerst privat an Pools zu geben, ist ein reales Offenlegungsmuster — und das Release ist ungewöhnlich ehrlich dazu. Den Fix zuerst zu den potenziell Angreifbaren zu bringen, ist vertretbar; es offen in den Notes zu sagen, ist besser als das übliche Schweigen. Der Hinweis für Lesende: Ein „Wartungs"-Release enthält still einen schon zirkulierten Sicherheitspatch.
„Am selben Körper validieren, den man anwendet" schließt eine subtile Klasse. Einen Block in einer Darstellung zu prüfen und eine andere anzuwenden, ist genau der Ort für Reorg- und Crash-Recovery-Fehler. Die Validierung direkt vor dem Verbinden schließt die Lücke.
Quelle: https://github.com/litecoin-project/litecoin/releases/tag/v0.21.5.8