Der Preis des Schweigens war Fachwissen
- Sechs Begriffe, die dieser Text voraussetzt
- Ein Embargo ist eine Wette auf die Kosten des Nachsehens
- Zwei Teams, ein Motor
- Die Prüfung, die eine Abspaltung kippte
- Die eine Größe, die kein Modell wegdiskontieren kann
- Miss die Joule, nicht den Betreiber
- Was einem Betreiber bleibt
- Das Gegenargument – und die Zahl, die niemand hat
- Der Rückstand
- Quellen
Am Donnerstag, dem 22. Oktober, ging um 18:07 UTC auf der Mailingliste der Bitcoin-Entwickler eine Nachricht von etwa dreihundert Wörtern ein. Betreff: „Bitcoin Core security policy update“. Sie enthielt keine CVE-Nummer, keinen Patch, keine Offenlegung einer bestimmten Schwachstelle. Sie veränderte den Preis eines Geheimnisses.
Antoine Poinsot schrieb, das Projekt habe „in jüngster Zeit eine Zunahme von Meldungen über Sicherheitslücken erlebt, die sich leicht wiederentdecken lassen“, und nannte den Grund ohne Umschweife: „Das liegt weitgehend daran, dass LLMs die Hürde drastisch senken, bestimmte Klassen von Problemen zu finden oder verdeckte Korrekturen zu erkennen.“
Dann benannte er den Zielkonflikt, den jede Sicherheitsrichtlinie hinter ihrem Verfahren versteckt. „Jede Sicherheitsrichtlinie muss zwischen zwei Zielen abwägen, die in Spannung zueinander stehen: Transparenz und den Nutzern genug Zeit für ein Update zu geben.“ Bitcoin Core habe sich für das zweite Ziel entschieden, wegen „der Natur unseres Projekts und einer langsamen Kultur des Aktualisierens“. Der Preis dieser Wahl war strukturell: Sicherheitskorrekturen „lassen sich nicht zurückportieren und werden erst mit der nächsten großen Version verfügbar“. Für die Klasse von Fehlern, die ein Sprachmodell auf Zuruf findet, sei das, so sein Fazit, „der falsche Kompromiss“.
Die neue Regel ist in ihrer Mechanik fast banal. Während der Sichtung darf ein Fehler als leicht auffindbar eingestuft werden. Für diese Klasse wird die Korrektur in jede noch gepflegte Version zurückgetragen, so schnell wie möglich eine Veröffentlichung geschnitten, und zum selben Zeitpunkt gehen erste Einzelheiten in einem Sicherheitshinweis hinaus. Alles andere behält seine alte Uhr. Fehler mit geringer Schwere werden zwei Wochen nach der großen Version offengelegt, die die Korrektur enthält. Mittlere und schwere zwei Wochen nach dem Ende der Lebenszeit der letzten betroffenen Version, typischerweise ein Jahr später. Kritische Fehler stehen gar nicht erst in der geschriebenen Richtlinie; sie werden von Fall zu Fall behandelt, so wie Marty Bent es am 23. Oktober zusammengefasst hat. Bents Datum liegt um einen Tag daneben – die Nachricht auf der Liste trägt den 22. Oktober, 18:07 UTC –, und diese Abweichung ist erwähnenswert, weil der ganze Streit um Zeitpunkte geht.
Bewegt hat sich nicht die Software. Bewegt hat sich eine Eingangsgröße einer Entscheidung, die immer wirtschaftlich war und die nie als solche aufgeschrieben wurde.

Sechs Begriffe, die dieser Text voraussetzt
Wer nicht täglich mit Versionsverwaltung und Sicherheitsverfahren arbeitet, stolpert über ein halbes Dutzend Wörter. Sie sind der halbe Text, deshalb vorab in Kürze.
Freigabesperre (Embargo) heißt: Ein Fehler ist bekannt, die Korrektur ist geschrieben, und das Wissen darum wird zurückgehalten, bis die Betreiber Zeit hatten, sie einzuspielen. Es ist kein Geheimnis gegenüber der Allgemeinheit, sondern eine Frist.
Zurückportieren heißt, eine Korrektur aus der aktuellen Entwicklung in eine ältere, weiterhin gepflegte Version zu übertragen. Nicht jede Korrektur lässt sich so übertragen; manche hängen an Umbauten, die es in der alten Version nicht gibt.
Commit und Diff. Ein Commit ist ein festgeschriebener Änderungssatz im Quelltextarchiv, ein Diff die Zeile-für-Zeile-Anzeige dieses Unterschieds. Wer den Diff liest, sieht, welche Zeile entfernt und welche eingefügt wurde. Ein veröffentlichter Diff ist deshalb eine Wegbeschreibung – kurz, präzise und dauerhaft abrufbar.
Ende der Lebenszeit (End of Life) markiert den Punkt, ab dem eine Version keine Korrekturen mehr bekommt. Danach ist sie kein Ziel mehr für den Wartungsaufwand, aber weiterhin im Netz.
Fork und Testnetz. Ein Fork ist hier keine Spaltung der Kette in zwei konkurrierende Netze, sondern die Aktivierung einer Regeländerung. Sie wird zuerst auf einem Testnetz eingeschaltet, also auf einer Kopie der Kette mit wertlosen Münzen, damit Fehler dort auffallen und nicht mit echtem Geld.
Gas ist die Gebühr, die Ethereum für jede Rechenoperation berechnet. Sie hängt an Regeln, die sich mit einem Fork ändern können – und damit auch an der Frage, ob ein Vertrag, der gestern scheiterte, morgen durchläuft.
Ein Embargo ist eine Wette auf die Kosten des Nachsehens
Zieht man das Verfahren ab, bleibt ein Embargo eine Wette zwischen zwei Preisen. Auf der einen Seite steht der Preis, den ein Angreifer zahlen muss, um die Lücke selbst wiederzuentdecken. Auf der anderen steht der Preis des Wartens, den jeder Betreiber zahlt, der den Fehler noch mit sich herumträgt. Solange das Wiederentdecken teuer ist, kauft Schweigen den Verteidigern Zeit, die sie sich selbst nicht kaufen können. Sobald das Wiederentdecken billig ist, stellt dieselbe Stille dieselbe Zeit denen in Rechnung, die sie schützen sollte.
Die alte Richtlinie von Bitcoin Core war eine bewusste Wette darauf, dass der erste Preis hoch liegt. Der Gedanke war richtig, als er notiert wurde: Um aus einer bekannten, aber geheim gehaltenen Korrektur einen Angriff zu bauen, musste ein Angreifer den Commit finden, verstehen, was er behebt, und den Angriff aus kryptografischem und systemtechnischem Wissen rekonstruieren. Diese Hürde ist keine Mauer, sie ist ein Lohn. Sie legt fest, wie viele Stunden ein Gegner bezahlen muss, und damit, wie viele Gegner sich die Arbeit überhaupt leisten können.
Der zweite Preis ist messbar, und das Projekt musste ihn nie nennen. Aus den Veröffentlichungsmarken selbst – eine schlichte Abfrage gegen das öffentliche Quelltextarchiv, am Morgen des 23. Oktober ausgeführt – liegen zwischen zwei großen Versionen 192 Tage von 28.0 auf 29.0, 181 Tage von 29.0 auf 30.0, 189 Tage von 30.0 auf 31.0 und 184 Tage von 31.0 bis zur Marke 32.0, die am 21. Oktober gesetzt wurde. Der Mittelwert sind 186,5 Tage. Das ist der Maßstab, der die Verzögerung früher definierte: Je nachdem, wann im Zyklus eine Korrektur fertig wurde, wartete ein Betreiber im Schnitt etwa die Hälfte dieser Spanne, im schlechtesten Fall den ganzen Zyklus.
Danach begann die Offenlegungsuhr, und sie lief noch langsamer. Zwei Wochen nach der großen Version bei einem Fehler geringer Schwere – damit kann man leben. Zwei Wochen nach dem Ende der Lebenszeit bei mittleren und schweren Fehlern sind keine Woche und kein Monat, sondern etwa ein Jahr, nachdem die Korrektur bereits existierte, folgt man der Stufenordnung, die Bent beschreibt. In diesem Jahr stand die Korrektur im Quelltext. Das heißt: Der Diff war öffentlich. Das heißt: Zwischen dem Diff und einem funktionierenden Angriff stand wieder nur der Lohn.
Zwei Preise, eine Richtlinie. Die Richtlinie unterstellte, der Lohn sei hoch. Das vergangene Jahr war ein Versuch über den Lohn.
Zwei Teams, ein Motor
Der deutlichste Beleg dieses Jahres kam nicht aus einem Richtlinienpapier. Er kam aus PHP.
Forscher legten zwei Speicherfehler in der PHP-Engine offen, geführt als CVE-2026-109618 und CVE-2026-109619, in PHPs interner Behandlung von Speicherknappheit und schweren Laufzeitfehlern – nicht in einem Erweiterungsmodul eines Redaktionssystems, nicht in der Anmeldung einer Anwendung. Die veröffentlichten Vorführungen beschrieben Fernzugriff mit Codeausführung ohne vorherige Anmeldung gegen WordPress, Drupal und Joomla sowie das Auslesen von Speicherinhalten gegen PHP-Anwendungen allgemein. Die abgestimmte Reaktion lief etwa zwei Monate durch das Ökosystem, und eines der beiden Entdeckerteams war ein Forscher mit einem Modell im Ablauf: Ryan Austin von der Sicherheitsfirma Calif nutzte im August 2026 GPT-5.6 Sol, im Rahmen von OpenAIs Programm „Patch the Planet“. Wiz, kürzlich in Google Cloud eingegliedert, fand dieselben Schwachstellen unabhängig mit Gemini 4 Argon, GPT-5.6 Sol und eigenen Werkzeugen, wie die KI-Nachrichtenzusammenfassung von Latent Space am 22. Oktober festhielt.
Die sorgfältige Lesart ist hier wichtig, und dieselbe Zusammenfassung liefert sie mit: Es handelt sich um von Forschern gemeldete Ausnutzungsergebnisse, und daraus folgt nicht, dass jede PHP-Installation einen identischen, sofort ausnutzbaren Pfad trug. „Siebzig Prozent des Netzes“ ist eine Schlagzeile über die Verbreitung eines Interpreters, keine Messung ausnutzbarer Rechner.
Interessant ist aber das Koordinationsproblem. Zwei voneinander unabhängige Teams, beide mit kommerziellen Modellen ausgerüstet, trafen innerhalb weniger Wochen auf denselben Fehler auf der Ebene des Interpreters. Wenn unabhängiges Wiederentdecken zur Routine wird, verfällt der Wert eines Geheimnisses nicht allmählich. Er bricht in dem Moment, in dem das zweite Team auftaucht – und niemand, der das Geheimnis hält, sieht das zweite Team kommen. Ein Embargo ist nur so stark wie sein am wenigsten beobachtbares Leck, und ein Sprachmodell mit einem guten Prompt ist ein Leck, das keine Spur im Quelltextarchiv hinterlässt.
Es gibt ein Gegengewicht, und es ist der Teil, den die meiste Berichterstattung überspringt. Das Entdecken wurde auch für Verteidiger billig. Ein am selben Tag veröffentlichtes Preprint, Self-Evolving Static Analysis via LLM Pseudo-Labeling, beschreibt einen Agenten, der ohne jede Erkennungsregel für eine Programmiersprache beginnt und sich einen Satz lesbarer Abfragen erarbeitet. Rückmeldung erhält er ausschließlich von einem zweiten Modell, das als Kritiker auftritt – Zugriff auf die Wahrheit, also auf die Etiketten echter Fundstellen, hat er zu keinem Zeitpunkt. Über acht unabhängige Läufe auf dem OWASP-Benchmark für Python erreichte er einen mittleren F1-Wert von 0,742 und lag damit über den Voreinstellungen von fünf verbreiteten Werkzeugen sowie auf Augenhöhe mit dem stärksten dieser Werkzeuge, sobald man dieses mit genau den Wahrheitsdaten nachjustierte, die der Agent nie gesehen hatte. In einem Pilotversuch an echten Python-Projekten fanden Regeln, die aus Code vor Entstehung einer Schwachstelle abgeleitet waren, 10 von 19 späteren CVEs – neun davon mit Regeln, die für dasselbe Archiv geschrieben worden waren.
Das ist also keine Geschichte davon, dass Angreifer einen dauerhaften Vorsprung gewinnen. Es ist die Geschichte davon, dass eine bestimmte Asymmetrie sich auflöst: die zwischen dem, der weiß, wo er nachsehen muss, und dem, der nachsehen könnte, wenn es billig wäre. Sobald beide Seiten nachsehen können, ist Geheimhaltung keine Subvention für Verteidiger mehr, sondern eine Verzögerung, die ihnen auferlegt wird. Genau das schrieb Poinsot, in weniger Worten, an einem Donnerstag um 18:07 auf eine Mailingliste.
Die Prüfung, die eine Abspaltung kippte
Fünf Tage vor dieser Nachricht lief dieselbe Umbewertung in die andere Richtung, und die Rechnung landete auf einem Veröffentlichungskalender.
Ethereum-Entwickler sagten die Aktivierung des Upgrades Glamsterdam auf dem Testnetz Hoodi vier Tage vor dem geplanten Start ab, wie Unchained am 22. Oktober berichtete. Auslöser war eine am 13. Oktober veröffentlichte Analyse der Sicherheitsfirma ChainSecurity zu EIP-8037 und EIP-8038, zwei Vorschlägen, die ändern, wie das Netzwerk Gas für das Anlegen und den Zugriff auf Zustand berechnet. Die Warnung betraf keinen Fehler in irgendeinem Vertrag. Sie betraf Verträge, die niemand mehr anfassen würde: „Selbst bei unverändertem Vertragscode kann ein Fehlerpfad, der bisher zurückgesprungen ist, nun durchlaufen“, und wer diesen Pfad weitergehe, „kann aus einer wiederholbaren Operation einen dauerhaften Fehlschlag machen“.
Diesen Satz sollte man zweimal lesen, denn er ist der allgemeine Fall. Der Code hat sich nicht geändert. Der Grund unter ihm hat sich geändert. Ein fehlgeschlagener Aufruf, der früher abbrach, läuft jetzt durch – und damit erbt jeder Vertrag, der einen Abbruch voraussetzte, jede Wiederholungsschleife, jeder Ersatzpfad, jede Buchungslogik, die gegen die alte Gas-Semantik geschrieben wurde, ein Verhalten, dem er nie zugestimmt hat. Besu-Entwickler haben am 22. Oktober einen Änderungssatz mit dem Titel „Unschedule Amsterdam on Hoodi“ übernommen, und wie der Bericht anmerkt: Code zu übernehmen aktualisiert keine Knoten, die bereits mit der alten Fassung laufen.
In dieser Abfolge stecken zwei Lehren, und sie ziehen in entgegengesetzte Richtungen. Die gute: Eine Sicherheitsprüfung, die vor zwei Jahren zu teuer gewesen wäre, um sie überhaupt zu fahren, läuft heute früh genug, um eine Abspaltung vier Tage vor dem Start zu stoppen. Die schlechte: Die Prüfung hat etwas gefunden, und die Kosten des Findens landeten bei allen, die davon abhängen – im schlechtesten Moment, ohne Reserve. Billiges Entdecken entwertet nicht nur Geheimnisse. Es entwertet auch Termine. In einer Welt, in der das Nachsehen gratis ist, ist jede Frist vorläufig, und Teams, die Veröffentlichungen als feste Daten planen, werden weiter spät merken, dass diese Daten nie ihre eigenen waren.
Das ist auch der ehrliche Preis der Änderung bei Bitcoin Core, und Poinsot benennt ihn in derselben Nachricht: Korrekturen werden jetzt zurückportiert und „so schnell wie möglich“ veröffentlicht, was ein Versprechen über jemandes Wochenende ist.
Die eine Größe, die kein Modell wegdiskontieren kann
Wenn die Kosten des Nachsehens überall zusammenbrechen, wird die interessante Frage, was teuer bleibt. Die Antwort dieses Monats lautete: Joule.
Der gleitende Sieben-Tage-Durchschnitt der Bitcoin-Rechenleistung überschritt am 22. Oktober wieder eine Zettahash pro Sekunde – ein Siebenmonatshoch, zuletzt am 3. März gesehen –, laut Miner Weekly von BlocksBridge Consulting, wiedergegeben bei Bent. Die Schwierigkeit stieg am 16. Oktober um 5,92 Prozent, und BlocksBridge erwartet bei der nächsten Anpassung weitere 5,16 Prozent, zusammen rund 11,4 Prozent über zwei Anpassungen hinweg. Beide Zahlen stiegen, während die börsennotierten Miner gingen.
Das ist der Punkt, an dem man kurz stehen bleiben sollte. Öffentlich gehandelte Miner senkten ihre tatsächlich betriebene Rechenleistung um etwa 23 Prozent und steigerten zugleich ihre Erlöse aus KI und Hochleistungsrechnen im zweiten Quartal 2026 um 52 Prozent gegenüber dem Vorquartal. BlocksBridge schätzt die abgezogene Kapazität auf etwa 1,5 Milliarden Dollar Mining-Hardware, gerechnet mit einem eigenen angenommenen Einkaufspreis von 20 Dollar je Terahash – eine Annahme, die die Firma selbst als Größenordnung und nicht als Marktpreis kennzeichnet, weil sich die Preise für spezialisierte Rechenchips bewegt haben. Die Reaktion des Netzwerks darauf, dass ein Fünftel seiner öffentlichen Kapazität weggeht, bestand darin, 45 Prozent schwerer zu werden als der Tiefpunkt im Juli bei etwa 726 Exahash pro Sekunde, nach Daten von CryptoQuant, die Ki Young Ju anführt.
Daraus folgen drei Rechnungen, und sie sind meine, nicht die der Quellen.
Erstens: Schwierigkeit mal 2^32 geteilt durch 600 ergibt Hashes pro Sekunde. Eine Zettahash pro Sekunde bei Zehn-Minuten-Blöcken entspricht also einer Schwierigkeit von knapp 139,7 Billionen. Das ist die Größenordnung, auf der die beiden veröffentlichten Zahlen zueinander passen.
Zweitens: Der Ertrag je Einheit Rechenleistung fällt mit steigender Schwierigkeit, solange der Preis sich nicht bewegt. Nach einer Anpassung um 5,92 Prozent und einer weiteren um 5,16 Prozent verdient dieselbe Maschine bei derselben Stromrechnung noch 89,8 Prozent dessen, was sie vorher verdiente – eine Kürzung um 10,2 Prozent, angewandt auf jeden Betreiber im Netz, in derselben vierzehn Tagen, in denen ein Viertel der öffentlichen Flotte entschied, dass das Geschäft sich nicht mehr lohnt.
Drittens, und das verlangt eine ausdrücklich genannte Annahme statt einer Messung: Eine Zettahash pro Sekunde bedeutet bei 15 Joule je Terahash fünfzehn Gigawatt Dauerleistung, bei 20 Joule zwanzig, bei 25 Joule fünfundzwanzig. Ich kenne den tatsächlichen Durchschnittswirkungsgrad der Flotte nicht, und niemand, der eine Schlagzeilenzahl veröffentlicht, kennt ihn ebenfalls. Behandle die Spanne deshalb als Empfindlichkeitsprüfung einer Größenordnung, nicht als Messwert. Dutzende Gigawatt im Dauerbetrieb, um ein Register zu erhalten, das ein Laptop nachprüfen kann. Ich veröffentliche lieber die Annahme als eine Schlagzeilenzahl zu verteidigen, und die Annahme ist die einzige weiche Zahl in diesem Satz.

Warum das für eine sicherheitspolitische Frage zählt, liegt in der Form der Nachfrage auf der anderen Seite des Zauns. Erik Bernhardsson, dessen Firma Modal eine Milliarde Dollar annualisierter Umsatz überschritten und 750 Millionen Dollar zu einer Bewertung von 16 Milliarden eingesammelt hat, beschreibt die Nachfrage nach Rechenbeschleunigern als alles andere denn rechteckig: Ein Kapazitätsvertrag gibt einem Kunden eine feste Zahl von Chips für einen festen Zeitraum, und echte Arbeitslast wächst, spitzt sich zu und fällt im Tagesverlauf. Sein Geschäft ist eine Umwandlung von Dauer – tausende Kunden bündeln, damit die Summe glatter ist als jeder einzelne, und das Risiko tragen, dass die heute eingekaufte Kapazität teuer wird, wenn die Preise fallen. Sandboxes, das Produkt, das beinahe eingestellt wurde, steht heute für etwa ein Drittel des Umsatzes.
Stellt man beide Branchen nebeneinander, ergibt die Wanderung als Tausch Sinn und nicht als Mode. Mining bietet eine feste, nachprüfbare Auszahlung je Hash und eine Schwierigkeit, die genau dann steigt, wenn jemand anders bereit ist, mehr Geld zu verlieren als man selbst. Inferenz bietet einen sprunghaften, vertragsförmigen Erlösstrom mit Restrisiko auf den Hardwarepreis. Kapital ging dorthin, wo die Nachfragekurve weniger rechteckig war, und die Schwierigkeitskurve hat das nicht gekümmert – denn wenn diese Lesart stimmt, sind die Maschinen, die blieben, billiger zu betreiben als die, die gingen. Die gebrauchten Antminer S21 XP, die über Hosting-Anlagen in Paraguay und Texas angeboten werden, sind der sichtbare Rand davon.
Miss die Joule, nicht den Betreiber
Damit schließt sich der Kreis, denn die neueste Idee in der Regulierung von KI ist die älteste Idee in Bitcoin.
Ein am 23. Oktober eingestelltes Preprint, Detecting AI Training in Datacentre Power, fragt, wie eine Aufsicht erkennen kann, ob ein überwachter Rechnerverbund ein großes Modell trainiert, ohne dem Betreiber zu glauben. Das Verfahren ist keine Softwarebescheinigung und keine Prüfung der Unterlagen. Es liest die Leistungsaufnahme der Anlage und verfolgt den wandernden Takt der Trainingsschritte mit einem Viterbi-Verfolger. Auf simulierten Rechenzentrumsdaten, bei einem Betreiber, der nichts zu verbergen versucht, erkennt es mindestens 96 Prozent der Trainingsläufe gegenüber einer angegebenen reinen Inferenzlast bei einer Falschalarmrate von 1 Prozent und bleibt damit 0,04 vom Optimum nach Neyman-Pearson entfernt – vorausgesetzt, der Zähler tastet mit mindestens 2 Hertz ab.
Die gegnerische Hälfte ist der Teil, der daraus ein Argument statt einer Vorführung macht. Von acht Strategien, mit denen ein Betreiber sich verstecken könnte, entgeht nur eine einzige extreme Schwankung des Aufwands je Iteration dem Verfolger. Ihre stärkste Form verbirgt Training in bis zu 73 Prozent der Fünf-Minuten-Beobachtungen, aber über einen Tag werden mindestens 87 Prozent solcher Läufe weiterhin erkannt, bei 0,1 Prozent Falschalarm je Lauf. Diese Verschleierung kostet keinen Durchsatz, aber im Training kleiner Modelle braucht der Betreiber 93 bis 267 Prozent mehr Rechenaufwand, um dasselbe Verlustniveau zu erreichen. Die Schlussfolgerung der Autoren ist bewusst zurückhaltend: Ein passiver Zähler genügt, um verborgenes Training sowohl erkennbar als auch teuer zu machen.
Ersetzt man ein Wort, hat man die Konstruktion des Proof of Work. Ersetze Leistung durch Hashes, den Iterationstakt durch die Nonce, den Zähler durch jeden Knoten im Netzwerk. Bitcoins Antwort auf „Woher weiß ich, dass das ehrlich erzeugt wurde“ war nie „Frag den Erzeuger“. Sie lautet: „Die Erzeugung hat eine physische Spur hinterlassen, die teuer zu fälschen und billig zu prüfen ist.“ Das Papier ist dieses Prinzip angewandt auf das, was alle für nicht messbar hielten – und es erscheint in derselben Woche, in der die konservativste Sicherheitsrichtlinie der Branche einräumte, dass die Kosten des Nachsehens durch den Boden gefallen sind.
Was einem Betreiber bleibt
Die praktische Folge von Poinsots Änderung ist kleiner als das Argument und schärfer als die Berichterstattung. Kleine Versionsnummern sind kein Hausputz mehr. Unter der alten Richtlinie bedeutete eine Punktversion meist Korrekturen, die man nach eigenem Zeitplan einspielen konnte. Unter der neuen kann eine Punktversion einen Sicherheitshinweis tragen, der gleichzeitig erscheint. Für eine Klasse von Fehlern liegt der Abstand zwischen „die Korrektur existiert“ und „alle wissen, worin sie bestand“ damit ungefähr bei null.
Das verwandelt Versionsdisziplin in eine Sicherheitsmaßnahme mit Frist, und die Frist ist für den Betreiber nicht verhandelbar. Es macht außerdem den Veröffentlichungsstrom zu einem Sicherheitsstrom. Zur Größenordnung: Der öffentliche Veröffentlichungsstrom des Projekts führt 68 Veröffentlichungen seit November 2016, davon acht im Jahr 2026 bis zum 10. Juli; die Marke 32.0 – signiert und datiert auf den 21. Oktober, 13:27 UTC – erscheint dort noch nicht als Veröffentlichungseintrag. Die Marke ist da, die Ankündigung nicht. Wer als Knotenbetreiber Ankündigungen liest statt Marken, ist immer ein wenig hinterher, und in diesem Jahr hat „ein wenig hinterher“ einen Preis bekommen.

Ich habe beim Schreiben den Knoten nachgesehen, den ich selbst betreibe. Er meldet sich als /Satoshi:31.1.0/ mit zehn ausgehenden Verbindungen, während die Marke 32.0 vorgelagert bereits existiert. Genau das ist die Lage, auf die die neue Richtlinie zielt: gepflegt, funktionsfähig und eine große Version hinter den Korrekturen zurück, die künftig mit ihrem eigenen Sicherheitshinweis erscheinen.
Die Kurse des Morgens, aus meinem eigenen Kursabruf um 09:31 MESZ am 23. Oktober: Bitcoin bei 81.693,51 Dollar, plus 377,31 im Handelsverlauf; Brent bei 114,47; Gold bei 4.027,40; der Dollarindex bei 101,803; der S&P 500 bei 7.663,43, minus 93,74 Punkte. The Block meldete, derselbe Ausverkauf habe über Nacht Asien erreicht, mit dem Kospi minus 2,3 Prozent und dem Nikkei minus 1,6 Prozent, während Bitcoin unter 81.500 Dollar rutschte. Nichts davon ändert das sicherheitspolitische Argument. Es ändert das Publikum, denn ein fallender Preis ist die Zeit, in der Betreiber Upgrades verschieben.
Das Gegenargument – und die Zahl, die niemand hat
Der Einwand gegen die neue Stufe lautet nicht, dass sie falsch sei. Er lautet, dass sie nicht gemessen ist, und Poinsots eigene Nachricht enthält den Grund dafür.
Wenn die Einstufung bei der Sichtung fällt, durch den Entwickler, der den Fehler kennt, dann hängt die Sicherheit der Richtlinie an einem Urteil der Partei, die das geringste Interesse hat, zu viel mitzuteilen, und die das meiste Wissen darüber hat, wie auffindbar der Fehler wirklich ist. Das ist ein vernünftiger Ort für diese Entscheidung, und zugleich ein nicht prüfbarer. Das Etikett „leicht auffindbar“ ist eine Vorhersage über die Kosten eines Gegners, getroffen von jemandem, der den Gegner nicht sehen kann.
Schlimmer: Der Sicherheitshinweis veröffentlicht eine Wegbeschreibung gegenüber einer Nutzergruppe, die langsam aktualisiert – die Formulierung ist Poinsots, und sie ist das tragende Zugeständnis. Unter der alten Richtlinie war die Gruppe langsam, aber ahnungslos. Unter der neuen ist sie langsam und informiert, und zu den Informierten gehören alle, die einen Sicherheitshinweis beruflich lesen. Die Richtlinie ist also richtig, wenn der zusätzliche Angreifer, der den Hinweis liest, langsamer ist als der mittlere Betreiber, der aktualisiert. Gilt das Umgekehrte, dann hat die schnellere Uhr die Gefährdung von den Geduldigen zu den Nachlässigen verschoben, ohne sie zu verkürzen.
Niemand misst eine der beiden Zahlen. Bitcoin Core veröffentlicht keine Schätzung der Versionsverteilung, und eine Stichprobe von zehn Gegenstellen an einem Knoten ist eine Anekdote. Diese Lücke ist der ehrliche Stand der Technik: Die Richtlinie wurde aufgrund eines Preises korrigiert – der Kosten des Wiederentdeckens –, während der andere Preis, die Zeit, die Betreiber tatsächlich brauchen, eine Vermutung bleibt, und zwar in demselben Dokument, das den ersten korrigiert.
Der Test ist überprüfbar und nah. Wird eine Schwachstelle aus der Stufe „leicht auffindbar“ zwischen ihrem Sicherheitshinweis und der breiten Installation der Version im Feld ausgenutzt, wird die Richtlinie überarbeitet, denn die Kultur des Projekts behandelt veröffentlichtes Verfahren als Zusage. Man beobachte die nächsten Patch-Zyklen. Kommen die Veröffentlichungen schnell und verbrennt niemand in der Lücke, war die Wette richtig. Verbrennt jemand, dann haben wir erfahren, wie hoch der zweite Preis war – auf die teure Art.
Der Rückstand
Der rote Faden dieser Woche ist nicht, dass Maschinen besser darin geworden sind, Fehler zu finden. Er ist, dass ein Jahrzehnt Sicherheitspraxis auf einem Preis stand, den niemand aufgeschrieben hatte, und dass dieser Preis sich schneller bewegte als die Richtlinie. Bitcoin Core hat geantwortet, indem es das Embargo genau für die Klasse von Fehlern verkürzte, in der der Lohn zusammengebrochen war. Ethereum hat geantwortet, indem es eine Abspaltung vier Tage vor dem Start absagte, weil eine Prüfung, die bezahlbar geworden war, unausweichlich geworden war und dann etwas Echtes fand. Die Miner haben geantwortet, indem sie Maschinen an jeden mit billigerem Strom verkauften, und die Schwierigkeit stieg trotzdem, weil Joule die eine Eingangsgröße ist, die kein Modell zu fälschen gelernt hat.
Alles andere in diesem Geschäft ist heute billig herzustellen: ein Absatz, ein Diagramm, eine plausible Forschungsnotiz, ein Diff, der wie eine Korrektur aussieht, ein Schwachstellenbericht, der wie ein Gefallen aussieht. Teuer bleibt der Teil, der eine physische Spur hinterlässt – ein Hash, ein Watt, eine signierte Veröffentlichung, ein Diff, den tatsächlich jemand gelesen hat. Die nützliche Frage für das nächste Jahr ist nicht, welches Modell klüger ist. Sie ist, welche der eigenen Eingangsgrößen ein Fremder mit einem Messgerät noch nachprüfen kann. Bitcoin Core hat gerade schriftlich mitgeteilt, welche seiner eigenen Geheimnisse diesen Test nicht mehr bestehen.
Quellen
- Bitcoin-Entwickler-Mailingliste — Antoine Poinsot, „Bitcoin Core security policy update“, 22. Oktober 2026
- bitcoincore.org — Sicherheitshinweise und Richtlinie von Bitcoin Core
- bitcoincore.org — Lebenszyklus der Bitcoin-Core-Versionen
- bitcoin-core/bitcoincore.org — Änderungssatz 1281 (Richtlinientext)
- GitHub — bitcoin/bitcoin, veröffentlichte Versionen (abgefragt am 23. Oktober 2026)
- TFTC — Bitcoin Core adds „easily discoverable“ tier as LLMs break embargo model, 23. Oktober 2026
- TFTC — Bitcoin hashrate hits 1 ZH/s, seven-month high, 22. Oktober 2026
- arXiv 2610.30182 — Detecting AI Training in Datacentre Power
- arXiv 2610.30184 — Self-Evolving Static Analysis via LLM Pseudo-Labeling
- Latent Space — AINews, PHP2Shell und die Offenlegung im Programm Patch the Planet, 22. Oktober 2026
- Unchained — Ethereum verwirft Glamsterdams Hoodi-Fork nach Gas-Warnung von ChainSecurity, 22. Oktober 2026
- Latent Space — Why AI compute comes in rectangles, Erik Bernhardsson, 22. Oktober 2026
- The Block — Bitcoin slides below $81,500 as tech sell-off spreads to Asian equities, 23. Oktober 2026
Eigene Auswertung — Abstände zwischen den großen Bitcoin-Core-Versionen aus den Veröffentlichungsmarken, Mittelwert 186,5 Tage, Stand 23. Oktober 2026
Eigene Beobachtung — eigener Knoten meldet /Satoshi:31.1.0/ mit zehn ausgehenden Verbindungen, Stand 23. Oktober 2026
Write a comment