Decent Newsroom
Sign In

Zwei Tage für die Korrektur, 182 Tage für die Erklärung

By Roger October 24, 2026
Bitcoin Core versteckt keine Fehler mehr, die ein Sprachmodell auf Zuruf findet. Die Offenlegungswirtschaft, die es ersetzt hat, stand auf einer Knappheit, die nicht mehr existiert.
Zwei Tage für die Korrektur, 182 Tage für die Erklärung

Am 23. April 2026 meldete ein Forscher den Core-Lightning-Entwicklern einen Fehler. Ein Gegenüber im Netz konnte jeden Knoten zum Absturz bringen, indem es eine einzige Kanalankündigung schickte, die denselben Knoten als beide Endpunkte nannte. Der Routing-Code prüfte nie, ob die beiden Knoten-Kennungen überhaupt verschieden sind. Also wurde derselbe Knoten zweimal in die Tabelle eingetragen, eine Zusicherung im Code, die Doppelungen ausschließt, schlug an, und der Daemon brach ab — der ganze Knoten mit ihm.

Der unangenehme Teil kommt nach dem Absturz. Die Ankündigung wird auf die Platte geschrieben, bevor sie in den Routing-Graphen geladen wird. Jeder Neustart liest sie also wieder ein und bricht wieder ab. Ein Update räumt das nicht auf. Der Knoten bleibt offline, bis ein Betreiber den Datensatz von Hand löscht, und der Angreifer kann dieselbe Nachricht so lange erneut schicken, wie der Finanzierungs-Output dahinter nicht ausgegeben ist.

Die Korrektur wurde einen Tag nach der Meldung zusammengeführt: eine Prüfung, dass node_id_1 lexikografisch kleiner sein muss als node_id_2. Ein Vergleich. Core Lightning v26.04.1 hat sie am 25. April 2026 in die Welt getragen.

An die Öffentlichkeit kam die Sache am 24. Oktober 2026. Zwischen Korrektur und Erzählung lagen 182 Tage.

Zeitachse der Offenlegung bei Core Lightning: 415 Tage verwundbar, 182 Tage zurückgehaltene Einzelheiten

Diese Lücke ist keine Nachlässigkeit. Sie ist das Lehrbuchverfahren der abgestimmten Offenlegung, jene Übereinkunft, die die Softwaresicherheit zwei Jahrzehnte lang getragen hat. Und sie wird gerade von innen abgebaut, von den Leuten, die sie geschrieben haben.

Die Regeländerung, über die ein Jahrzehnt niemand stritt

Am 22. Oktober 2026 hat Bitcoin Core eine Änderung seiner Richtlinie für Sicherheitslücken zusammengeführt. Geschrieben wurde sie am 16. Oktober von Antoine Poinsot, Entwickler bei Chaincode Labs, angekündigt in derselben Woche auf der Mailingliste der Bitcoin-Entwickler und einen Tag später ins Japanische übersetzt. Auf der öffentlichen Richtlinienseite steht seither ein Satz, den es eine Woche vorher nicht gab:

„Der Zeitplan für die öffentliche Offenlegung hängt davon ab, ob wir eine gemeldete Schwachstelle als leicht auffindbar einstufen. Diese Einstufung gilt für Schwachstellen, die mit minimalem Aufwand gefunden werden können, etwa durch einen einfachen Prompt an ein Sprachmodell.“

Was aus dieser Einstufung folgt, ist die eigentliche Änderung. Bei als leicht auffindbar eingestuften Lücken trägt das Projekt die Korrektur in jede noch gepflegte Hauptversion zurück, schneidet so schnell wie möglich eine neue Veröffentlichung und publiziert einen Sicherheitshinweis in dem Moment, in dem die korrigierte Software erscheint. Keine Frist, kein Zurückhalten. Für alles andere gilt der alte Kalender: Fehler geringer Schwere werden zwei Wochen nach der Hauptversion öffentlich, die sie behebt. Mittlere und schwere warten bis zwei Wochen nach dem Ende der Lebenszeit der letzten betroffenen Version — also rund ein Jahr, nachdem die Korrektur zum ersten Mal in einer Hauptversion ausgeliefert wurde.

Legt man beide Zeitpläne nebeneinander, sieht man, was tatsächlich aufgegeben wurde. Ein schwerer Fehler in der Speicherverwaltung konnte zwölf Monate unter Verschluss bleiben, während die Betreiber in ihrem eigenen Tempo umstiegen. Jetzt schrumpft, wenn ein Modell denselben Fehler wiederfinden kann, das Fenster zwischen „Korrektur existiert“ und „alle wissen es“ auf null — und mit ihm die Testzeit, bevor eine Veröffentlichung die Nutzer erreicht. Poinsot hat diesen Tausch in seinem Vorschlag benannt. Für leicht wiederentdeckbare Fehler, schrieb er, „erreicht die Freigabesperre wenig, sie verzögert nur die Verfügbarkeit einer korrigierten Veröffentlichung“.

Sein angegebener Grund ist der, auf den es ankommt: „Wir haben in jüngster Zeit eine Zunahme von Meldungen über Sicherheitslücken erlebt, die sich leicht (wieder-)entdecken lassen. Das liegt weitgehend daran, dass Sprachmodelle die Hürde drastisch senken, bestimmte Klassen von Problemen zu finden oder verdeckte Korrekturen zu erkennen.“

Man beachte die zweite Hälfte dieses Satzes. Nicht nur den Fehler finden: verdeckte Korrekturen erkennen.

Sechs Wörter, die dieser Text voraussetzt

Wer nicht beruflich mit Versionsverwaltung und Sicherheitsverfahren zu tun hat, stolpert über ein halbes Dutzend Begriffe. Sie sind der halbe Text, deshalb vorab.

Freigabesperre, auch Embargo. Der Fehler ist bekannt, die Korrektur ist geschrieben, und das Wissen darum wird zurückgehalten, bis die Betreiber Zeit hatten, sie einzuspielen. Das ist kein Geheimnis gegenüber der Allgemeinheit, sondern eine Frist — gegenüber jedermann, auch gegenüber dem Angreifer.

Zurückportieren, englisch Backport. Eine Korrektur aus der aktuellen Entwicklung in eine ältere, weiterhin gepflegte Version übertragen. Nicht jede Korrektur lässt sich übertragen; manche hängen an Umbauten, die es in der alten Version nicht gibt. Deshalb ist Zurückportieren Arbeit und nicht bloß ein Kopiervorgang.

Punktveröffentlichung. Eine neue Versionsnummer, die nur Fehler behebt, meist die dritte Stelle wie in 26.04.1. Sie wird schnell geschnitten und entsprechend kurz getestet. Genau darin liegt der Zielkonflikt, den die neue Richtlinie verschärft.

CVE. Eine öffentliche Kennnummer für eine Schwachstelle, vergeben von einer autorisierten Stelle. Ein CVE ist eine Fundstelle im Register, kein Beweis, dass jemand den Fehler ausnutzt. Die Datenbank dieser Einträge ist die Grundlage der Messung weiter unten.

Sprachmodell, Large Language Model. Ein Modell, das Text fortsetzt und dabei auch Quelltext lesen kann. „Ein einfacher Prompt“ heißt in der Richtlinie: Ein Satz genügt, um ein solches Modell auf eine Codebasis anzusetzen. Das ist die neue Hürde, und sie ist niedriger als jede zuvor.

Virtuelle Bytes und 2-von-2-P2WSH. Die Gebühr einer Bitcoin-Transaktion hängt an ihrer Größe in virtuellen Bytes, abgekürzt vB, nicht an ihrem Wert. Ein 2-von-2-P2WSH-Output ist ein Geldschein, der zwei Unterschriften zum Ausgeben verlangt, typisch für einen Lightning-Kanal. Wer beide Schlüssel besitzt, kann ihn allein ausgeben — und genau das braucht der Angriff weiter unten.

Ein Embargo ist eine Wette auf den Preis des Wiederentdeckens

Zieht man das Zeremoniell ab, ist abgestimmte Offenlegung ein wirtschaftlicher Tausch, keine moralische Frage. Ein Entwickler, der von einem Fehler erfährt, hält zwei Güter: das Wissen und die Korrektur. Die Korrektur schützt jeden, der sie einspielt. Das Wissen hält den Fehler selten, solange es zurückgehalten wird. Die Freigabesperre ist der Zeitraum, in dem das Projekt möglichst viele Betreiber von „verwundbar und ahnungslos“ auf „korrigiert“ bewegen will, bevor das Wissen allgemein wird.

Dieser Tausch geht nur auf, solange Wissen teuer bleibt. Die ganze Begründung für das Warten ist die Annahme, dass ein Angreifer, dem man nichts sagt, es innerhalb der Frist nicht selbst herausfindet. Zwölf Monate Schweigen waren eine vernünftige Wette, als das Finden eines subtilen Zusicherungsfehlers einen Spezialisten mit einem Monat Zeit verlangte.

Die Zahlen, die Bitcoin Core selbst anführt, machen den Zusammenbruch sichtbar. Ende Juli hat eine freiwillige Gruppe von sechzehn Entwicklern, das Bitcoin Red Team, binnen etwa eines Tages KI-Modelle über 390 Repositories laufen lassen und dabei 4.962 Funde protokolliert, 85 davon als kritisch eingestuft — so berichtet es das Bitcoin Magazine. Das sind 310 Funde pro Entwickler und Tag und eine Kritisch-Quote von 1,7 Prozent. Fünfundachtzig kritische Funde sind keine Warteschlange, die ein Entwicklerteam an einem Tag abarbeitet. Das ist ein Rückstau, der von Hand gesichtet werden muss, Meldung für Meldung, und er kam an einem einzigen Nachmittag.

Die Folge ist Arithmetik. Wenn Wiederentdecken billig ist, verweigert eine Freigabesperre dem Angreifer nichts mehr, was er sich nicht selbst beschaffen kann. Sie verweigert nur dem Verteidiger die Korrektur. Geheimhaltung hört auf, ein Schutzschild zu sein, und wird zu einer Verzögerung mit Preisschild. Bitcoin Core hat die Richtlinie nicht geändert, weil das Projekt nicht mehr an abgestimmte Offenlegung glaubt. Es hat sie geändert, weil für eine bestimmte Klasse von Fehlern die Abstimmung ihren Gegenpart verloren hat.

Die Messung: 15.074

Die Behauptung, dass Finden billig geworden ist, lässt sich prüfen — und nicht nur innerhalb von Bitcoin.

Über die öffentliche Schnittstelle der nationalen Schwachstellendatenbank der USA habe ich sechzehn aufeinanderfolgende Monate veröffentlichter CVE-Zahlen abgerufen (eigene Abfragen, ausgeführt am 24. Oktober 2026). Von Juni 2025 bis April 2026 pendelt die Reihe zwischen 3.116 und 6.304 im Monat, ohne einen Trend, den man benennen müsste: 3.799 im Juni 2025, 4.537 im September 2025, 5.643 im Dezember 2025, 5.885 im April 2026. Dann hört das Pendeln auf. Mai 2026: 6.985. Juni: 8.001. Juli: 9.919. August: 12.719. September: 15.074. Sechs Monatsrekorde in Folge, das 2,56-fache des April-Werts in fünf Monaten, das 3,3-fache desselben Monats ein Jahr zuvor.

Der Zeitpunkt verdient einen zweiten Blick, weil er nicht zur aufgeräumten Geschichte passt. Der Knick beginnt im Mai 2026, zwei Monate bevor das Red Team Ende Juli seinen Ein-Tages-Durchlauf startete. Das Red Team war nicht die Ursache der Welle. Es war ein sichtbarer Kamm einer Verschiebung, die längst weiter oben im Fluss lief — in Werkzeugen, die jeder stundenweise mieten kann.

Veröffentlichte CVE-Zahlen pro Monat, Juni 2025 bis September 2026

Ein veröffentlichter CVE ist nicht dasselbe wie eine gefundene Schwachstelle, und ich will über die Grenzen dieser Zahl genau sein. Veröffentlichungszahlen enthalten Ausgaben von Scannern, Doppelmeldungen konkurrierender Vergabestellen und Einträge für Produkte, die niemand betreibt. Ein so steiler Sprung ist zum Teil ein Messartefakt der Meldepipeline selbst: Wenn Finden billig ist, ist Melden auch billig. Die Richtung aber ist eindeutig, und sie wird davon gestützt, was Praktiker in denselben achtundvierzig Stunden geschrieben haben.

Die Rundschau von Latent Space nannte die Strecke „Black October“, und die Liste, die sie zusammenstellte, liest man besser langsam. Eine nicht authentifizierte Remotecodeausführung in PHP, öffentlich PHP2Shell getauft. Ein Fehler mit CVSS 10,0 in GitLab, der Releases bis 2014 zurück betrifft und in 19.5.1 behoben wurde. Eine Remotecodeausführung im Brotli-Decoder von Node.js. Eine Zertifizierungsstelle namens eMudhra, deren Schlüssel so schwach gewesen sein sollen, dass einer von ihnen die Zahl vier war — geknackt durch einen einzigen Prompt, und das Unternehmen verlässt das Zertifizierungsgeschäft. Ein Passwortdieb, der in LiteLLM 1.107.0 mitgeliefert wurde. Ein Einbruch bei Zeabur, der 321.810 Konten offenlegte. Quest Diagnostics, das etwa die Hälfte der US-Krankenhäuser und Ärzte bedient, mit offengelegten Patientendaten. Und Microsoft, das eine Lieferkettenkompromittierung einer china-nahen Gruppe zuschreibt, die ein frei verfügbares agentisches Eindringwerkzeug gegen mehr als 2.250 Microsoft-365-Mandanten laufen ließ, mit rund 2.900 Anmeldeversuchen pro Minute.

Das ist keine Liste von KI-Funden. Das ist eine Liste davon, wie die Warteschlange eines Verteidigers aussieht, wenn die Kosten für das Erzeugen von Kandidaten durch den Boden fallen. Beides gilt gleichzeitig: Es tauchen mehr echte Fehler auf, und es taucht mehr Lärm mit ihnen auf. Die Antwort von Bitcoin Core ist gerade deshalb lehrreich, weil sie das nicht verhehlt. Die neue Kategorie ist eng, sie muss von Menschen angewendet werden, und kritische Fehler — die, die das Angebot aufblähen oder die Kette spalten könnten — bleiben ausdrücklich außerhalb der geschriebenen Richtlinie und werden von Fall zu Fall behandelt.

Was der Angriff tatsächlich kostet

Die Offenlegung bei Core Lightning ist ein guter Ort, um all dem einen Preis anzuhängen, weil der Angriff ungewöhnlich sauber ist.

Zum Auslösen braucht ein Angreifer einen nicht ausgegebenen 2-von-2-P2WSH-Output, den er selbst kontrolliert, sechs Bestätigungen tief, und eine gewöhnliche Verbindung als Gegenstelle. Die Ankündigung muss vier gültige Unterschriften tragen, und er kann sie erzeugen, weil er alle beteiligten Schlüssel hält. Nichts ist gefälscht. Die Nachricht ist wohlgeformt, sie ist nur selbstbezüglich. Der Knoten nimmt sie an, speichert sie und stirbt.

Meine eigene Rechnung zu den Kosten auf der Kette: Das Finanzieren eines 2-von-2-P2WSH-Outputs kostet ungefähr 110 bis 120 virtuelle Bytes, das spätere Ausgeben etwa 140 — zusammen rund 260 vB für den ganzen Weg hin und zurück. Bei 1 Satoshi pro vB, dem Satz, den der Mempool am Morgen des 24. Oktober 2026 anzeigte, sind das 260 Satoshi. Bei einem Bitcoin-Kurs von 80.689 Dollar (eigene Ablesung des Marktfeeds an diesem Morgen) sind das etwa 21 Cent. Bei 100 Satoshi pro vB, einem Niveau, das in den letzten zwei Jahren mehrfach erreicht wurde, kostet derselbe Angriff rund 21 Dollar. Das im Output gebundene Kapital kann an der Staubgrenze liegen, 330 Satoshi, derzeit 27 Cent.

Einundzwanzig Cent, einmal, und danach lässt sich die Nachricht beliebig oft wiederholen, solange der Output nicht ausgegeben ist. Dafür verliert ein Betreiber die Fähigkeit, die Kette zu beobachten — und damit das verpasste Bestätigen eines widerrufenen Kanalzustands oder eines HTLC, der vor Ablauf seiner Frist eingelöst werden muss. Die Kosten des Angriffs lauten in Cent. Die Kosten der Verteidigung lauten in Kanalsalden.

Kosten des Angriffs in Dollar bei unterschiedlichen Gebührensätzen im Mempool

Eine zweite, kältere Lehre steckt in der Zeitachse. Der Fehler kam mit v25.02 in die Codebasis, veröffentlicht am 6. März 2025, als die Knotentabelle so geändert wurde, dass sie Doppelungen zurückweist. Die Korrektur landete am 25. April 2026. Das sind 415 Tage, in denen jeder Knoten auf einer gepflegten Version eine Gossip-Nachricht von einem dauerhaften, neustartfesten Absturz entfernt war — und der öffentliche Bericht darüber öffnete sich erst 182 Tage, nachdem die Korrektur bereits herunterladbar war.

Schnell patchen ist keine Strategie, sondern eine Hoffnung

Hier ist der Teil, mit dem die neue Richtlinie leben muss, und er ist unbequem.

Der Sicherheitshinweis von Core Lightning endet mit einem Satz, der wie eine Warnung an die Autoren der Richtlinie klingt: „Prüfe nicht vertrauenswürdige Eingaben, bevor du sie speicherst. Eine Nachricht, die den Knoten nach dem Speichern zum Absturz bringt, wird neu geladen und bringt ihn bei jedem Neustart erneut zum Absturz.“ Dieselbe Logik gilt für die Lehre vom schnellen Patchen. Wenn ein Fehler gespeicherten Zustand beschädigen kann, dann schützt die Korrektur nur Knoten, die nie getroffen wurden. Ein Betreiber, der am Tag der Veröffentlichung aktualisiert — genau das Verhalten, das die neue Richtlinie belohnen will —, muss trotzdem wissen, dass Aktualisieren nicht reicht und eine Löschung von Hand nötig sein kann. Schnelligkeit beim Patchen ist notwendig, nicht hinreichend.

Die zweite unbequeme Folge ist die, die Antoine Riard vorbrachte und verlor. Riard wollte die Möglichkeit, eine Korrektur ganz ohne Sicherheitshinweis auszuliefern, nichts zu sagen und den Diff für die sprechen zu lassen, die Diffs lesen. Poinsot lehnte ab: Nutzer zu warnen, ohne ihnen Einzelheiten zu geben, „könnte unnötig mehr Risiko erzeugen“, weil es Leute in einen eiligen Umstieg treibt, die nie betroffen waren. Das ist ein echtes Dilemma ohne saubere Antwort. Nichts veröffentlichen, und der neugierige Angreifer liest den Diff der Punktveröffentlichung. Etwas veröffentlichen, und der besorgte Betreiber steigt in Eile um, womöglich auf eine Veröffentlichung mit drei Tagen Testzeit.

Der stärkste Gegeneinwand: langsame Betreiber sind kein Fehler

Die alte Freigabesperre gab es aus einem Grund, der nicht verschwunden ist: Knotenbetreiber sind langsam. Der Zeitplan von Bitcoin Core nahm ein Jahr Umstiegszeit für mittlere und schwere Fälle an, weil Betreiber tatsächlich so lange brauchen. Nimmt man das Jahr weg, hat man niemanden schneller gemacht; man hat nur den Puffer entfernt, der die Langsamkeit aufgefangen hat. Bringt eine eilige Punktveröffentlichung einen Rückschritt, dann hat das Projekt einen exotischen Fernabsturz gegen einen Konsensfehler getauscht, und dieser Tausch ist deutlich schlechter. Poinsots Antwort lautet: Das Modell hat den Fehler überhaupt erst gefunden, also lässt es sich auch auf die Korrektur richten. Das ist plausibel. Es ist nicht gezeigt, und niemand sollte so tun, als wäre es das.

Eine wirklich symmetrische Kraft zieht sich durch das ganze Bild, und sie ist leicht zu übersehen. Der Core-Lightning-Fehler wurde nicht von einem Menschen gefunden, der Code liest. Gefunden hat ihn ein Fuzz-Ziel für die Gossip-Zustandsmaschine, das dem Daemon gültige und fehlerhafte Nachrichten füttert und Kettenabfragen nachbildet — und dieses Ziel wurde danach upstream vorgeschlagen. Billiges Finden schneidet in beide Richtungen. Der Unterschied zwischen Angreifer und Verteidiger ist nicht, wer den Fehler finden kann. Es ist, wer die Korrektur schon hat.

Warum Bitcoin das härter trifft als die meiste Software

Ein Fehler in einer Webanwendung wird behoben, indem ein Anbieter ein Update auf Rechner schiebt, die niemand administriert. Ein Fehler in Bitcoin Core oder Core Lightning wird behoben, indem man Tausende unabhängige Betreiber davon überzeugt, neu zu kompilieren oder zu aktualisieren — in ihrem eigenen Tempo, mit ihrer eigenen Risikoabwägung. Es gibt keinen Schiebekanal. Das ist eine Eigenschaft, kein Defekt, und genau sie macht das alte Offenlegungsmodell für Bitcoin tragend, in einer Weise, die es für eine gewöhnliche Codebasis nie war.

Poinsots Änderung gesteht etwas zu, das der größte Teil der Branche weiterhin nicht laut sagt: Für eine Klasse von Fehlern hängt die Sicherheit des Netzwerks nicht mehr daran, Geheimnisse zu bewahren. Sie hängt an der Verteilung der Versionen. Die Angriffsfläche ist vom Code in die soziale Schicht gewandert, in die Frage, wer was laufen lässt und wie lange er zum Umsteigen braucht.

Der Oktober hat eine andere, unzusammenhängende Erinnerung daran geliefert, wie es aussieht, wenn eine Schätzung bricht. Morgan Stanley hat sein Modell für den Strombedarf von US-Rechenzentren in einem einzigen Zyklus um 43 Prozent nach oben korrigiert, von 68 auf 97 Gigawatt bis 2028, und es bleibt eine Netto-Lücke von rund 32 Gigawatt, selbst nach Anrechnung von Eigenerzeugung hinter dem Zähler und Brennstoffzellen — so berichtet es TFTC. Der Finanzchef von Nvidia bezifferte das Angebot auf rund 70 Prozent der Nachfrage. Zwei verschiedene Felder, ein Muster: Die Zahl, die letztes Quartal gut genug war, ist jetzt um einen Faktor falsch, und jeder Plan darauf muss neu gebaut werden. Eine Schätzung, die um 43 Prozent danebenliegt, ist kein Prognosefehler. Sie ist ein Regimewechsel.

Die Fähigkeit wird gerade gratis

Eine weitere Tatsache schließt den Kreis, und sie ist der Grund, warum ich nicht glaube, dass der Oktober 2026 wie ein Höhepunkt aussehen wird.

Am 23. Oktober hat Moonshot Kimi K3.1 Pro veröffentlicht: ein Modell mit gemischtem Expertengitter, 2,8 Billionen Parameter insgesamt und 104 Milliarden aktiv, ein Kontextfenster von einer Million Token und ein unabhängiger Wert von 55 bei Artificial Analysis. Zum Maßstab: Claude Opus 5.5 erreicht 58, Claude Fable 5.1, GPT-6 Astra und Gemini 4 Argon liegen bei 53. Die Schnittstelle kostet 2 Dollar je Million Eingabe-Token und 10 Dollar je Million Ausgabe-Token, laut dem Vergleich von Simon Willison die Hälfte des Preises von Opus 5.5. Und Moonshot hat die vollständigen Modellgewichte bis zum 4. November 2026 zugesagt.

Nimmt man beide Tatsachen zusammen: Im April bedeutete „ein Sprachmodell kann diese Klasse von Fehlern finden“ eine Spitzen-Schnittstelle zu Spitzenpreisen, hinter einem Anbieter, der drosseln, ablehnen oder protokollieren konnte. Im November ist die Fähigkeit, die Poinsot als Grund für seine Richtlinienänderung nannte, eine herunterladbare Gewichtsdatei, die jeder auf gemieteter Rechenleistung laufen lassen kann, ohne einen Torwächter, bei dem man Einspruch einlegt. Die Regulierer bewegen sich bereits in die Gegenrichtung: Die USA beschränken DeepSeek in der öffentlichen Beschaffung, und Chinas Handelsministerium lässt eine Vorabgenehmigung für international geteilte Spitzenmodelle prüfen. Keine der beiden Maßnahmen erreicht eine Datei, die schon auf zehntausend Platten liegt.

Die Richtung ist damit eindeutig. Die Grenzkosten des Wiederentdeckens laufen gegen null und bleiben dort. Jede Offenlegungsrichtlinie auf der Welt ist von nun an eine Richtlinie über eine Welt, in der die Antwort auf „könnte das jemand anderes finden?“ ja lautet, wahrscheinlich heute Nachmittag.

Was daraus folgt

Drei Dinge, geordnet danach, wie schnell sie wichtig werden.

Erstens wird der Rückstand beim Aktualisieren die beherrschende Sicherheitsgröße für jeden, der einen Knoten betreibt, und es ist keine Größe, die eine Freigabesperre zurückkaufen kann. Betreiber sollten für eine Welt planen, in der Korrektur und Sicherheitshinweis am selben Tag kommen. Das heißt: ein Weg zurück, ein Testknoten, und die Gewohnheit, Veröffentlichungshinweise zu lesen, in denen „Gossip“ oder „Validierung“ ohne Erklärung auftauchen.

Zweitens ist das Prüfen von Grenzen billig und seine Vernachlässigung teuer. Die Korrektur bei Core Lightning ist ein einziger Vergleich. Der Fehler war eine einzige Annahme: dass ein Absender eine Ordnungsregel schon angewendet hat, die der Empfänger nie nachprüft. In einem Netzwerk, in dem eine fehlerhafte Nachricht gespeichert und dann gegen jeden Neustart erneut abgespielt werden kann, ist die richtige Haltung, allem zu misstrauen, was gespeichert wird, bevor es als harmlos erwiesen ist. Die meisten ernsten Fehler dieses Jahrzehnts werden in dieser Lücke zwischen Auswertung und Speicherung liegen.

Drittens muss „schnell patchen“ aufhören, die ganze Antwort zu sein. Gegen zustandsbeschädigende Fehler hilft Patchen nur den Knoten, die nie getroffen wurden. Gegen Konsensfehler kann zu schnelles Patchen die Verletzung sein. Die reife Fassung ist nicht Geschwindigkeit, sondern ein abgestufter Plan: was sofort zurückportiert werden muss, was auf Tests warten kann, und was Menschen am Telefon klären müssen.

Die Entwickler von Bitcoin Core haben diese Woche eine Ermessensentscheidung getroffen, die entweder vorausschauend oder leichtsinnig wirken wird, und die Belege dafür liegen erst in einem Jahr vor. Sicher sagen lässt sich, dass sie ehrlich über den Grund waren. Die Freigabesperre war nie eine Mauer um das Wissen. Sie war eine Mautstelle davor, und die Maut ist gerade erlassen worden. Von hier an wird das Netzwerk dadurch verteidigt, wie schnell es sich bewegt, nicht dadurch, was es weiß und andere nicht.

Was ich nicht prüfen konnte

Vier Grenzen des Vorstehenden, klar benannt.

Die Zahlen des Red Teams — 390 Repositories und 4.962 Funde an etwa einem Tag — stammen aus einer einzigen veröffentlichten Darstellung. Ich habe die zugrunde liegende Fundliste nicht gesehen, deshalb ist die Kritisch-Quote von 1,7 Prozent als Größenordnung zu lesen, nicht als Koeffizient.

Niemand weiß, wie viele Core-Lightning-Knoten noch auf einer betroffenen Version laufen. Lightning hat keine verlässliche öffentliche Zählung der Softwareversionen, das Expositionsfenster, das ich aus Veröffentlichungsdaten gemessen habe, ist eine Eigenschaft des Codes und keine Zahl der Betroffenen.

Meine 260 vB sind eine Rechnung aus üblichen Skript- und Witness-Größen, keine Transaktion, die ich ausgesendet habe. Sie sind die richtige Größenordnung der Kosten, nicht die exakte Rechnung.

Und die Behauptung, modellgestützte Prüfung ersetze die Zeit einer Freigabesperre, ist derzeit eine Hoffnung mit einem plausiblen Mechanismus daneben. An einer Konsens-Codebasis unter Termindruck ist sie nicht gezeigt, und wenn sie zum ersten Mal scheitert, scheitert sie teuer.

Quellen

#bitcoin #sicherheit #ki #open-source #lightning
Write a comment