Decent Newsroom
Sign In

Der Patch ist nicht das Upgrade

By Roger October 29, 2026
Bitcoin Core hat drei Speicherfehler in fünf Tagen geschlossen und die Sperrfrist abgeschafft. Sechzehn Stunden nach der Offenlegung lief die Korrektur auf 3,5 Prozent der erreichbaren Knoten. Über drei Uhren, ein Tor und die Frage, was ein Patch wirklich ändert.
Der Patch ist nicht das Upgrade

Sechzehn Stunden, nachdem Bitcoin Core drei Speicherfehler öffentlich gemacht hat, meldeten 568 der 16.283 erreichbaren Knoten, die sich als Bitcoin Core ausgeben, eine Fassung mit der Korrektur. Das sind 3,5 Prozent. Eine einzige ältere Version, 31.1.0, stellte 8.080 Knoten und damit die Hälfte des Netzes. 4.965 Knoten liefen auf einer Fassung, die das Projekt einen Tag zuvor für tot erklärt hatte.

Die Geschichte von den fünf Tagen stimmt. Sie misst nur nicht den Teil, der entscheidet, ob jemand sicherer geworden ist. Code lässt sich an einem Tag reparieren, eine Flotte nicht. Das Zeitfenster der Verwundbarkeit bestimmen inzwischen drei Uhren, die verschieden schnell laufen — und die Regeländerung, die Bitcoin Core am 22. Oktober beschlossen hat, hat nur die erste davon angefasst.

Am 23. Oktober fand ein automatischer Prüfer einen Fehler, mit dem jeder verbundene Gegenüber einen Knoten unter Windows, macOS oder BSD zum Absturz bringt. Am 26. Oktober wurde die Korrektur geöffnet, zusammengeführt und in die älteren Versionszweige zurückgeschrieben. Am 27. Oktober erschienen die Versionen 31.2 und 32.1. Am 28. Oktober folgten 29.5 und 30.4, und in derselben Stunde wurden die Sicherheitshinweise veröffentlicht. Von der Entdeckung bis zur Offenlegung fünf Tage, ohne Sperrfrist dazwischen.

Diese Zeitachse ist ein Fortschritt, und sie ist zugleich eine Falle für die Interpretation. Wer sie liest, schließt auf Sicherheit. Wer nachzählt, sieht etwas anderes. Der folgende Text versucht beides zu trennen: was schneller geworden ist, was gleich geblieben ist, und warum die Zahl, die am häufigsten zitiert wird, die am wenigsten aussagekräftige ist.

Was ein Patch ist, ein Release und ein Rollout

Drei Wörter werden in dieser Debatte regelmäßig verwechselt, und die Verwechslung ist der Grund, warum gute Nachrichten nach Sicherheit klingen.

Ein Patch ist eine Änderung am Quellcode. Er entsteht an einem Tag, manchmal an einer Stunde, wenn der Fehler klar ist.

Ein Release ist eine gebaute, getestete, signierte und mit Versionsnummer versehene Ausgabe. Sie braucht mehr: Übersetzungen, Prüfsummen, Verhaltensprüfungen, und bei Bitcoin Core vier gepflegte Zweige gleichzeitig. Ein solcher Rückgriff in ältere Zweige heißt Backport: dieselbe Korrektur wird auf jede noch unterstützte Versionslinie einzeln übertragen, weil nicht jeder Betreiber auf die neueste Hauptversion springen kann oder will.

Ein Rollout ist die Installation. Er ist der einzige Schritt, der einen Angreifer tatsächlich trifft, und der einzige, der nicht in der Hand des Projekts liegt. Er passiert auf Servern, die jemand betreut, zu Zeiten, die jemand festlegt, mit Unterbrechungen, die jemand verantworten muss.

Zwischen Patch und Rollout liegt der ganze Abstand dieses Artikels. Und End-of-Life, ebenfalls ein Begriff, der erklärt werden muss: Versionen, für die ein Projekt keine Korrekturen mehr baut. Wer eine solche Fassung fährt, bekommt den Patch nicht angeboten. Er bekommt ihn nie.

Wer läuft schon die Korrektur: erreichbare Bitcoin-Core-Knoten nach Patch-Stand am 29. Oktober 2026

Drei Fehler, ein Scanner

Die Sicherheitshinweise sind weniger wegen ihres Inhalts bemerkenswert als wegen der Art, wie sie entstanden sind. Alle drei fallen in die neue Stufe „leicht auffindbar“, und zwei der drei fand Project Loupe, ein automatischer Prüfer auf Sprachmodellbasis, den Elias Rohrer bei Spiral gebaut hat. Gregory Sanders prüfte die Funde nach und gab sie an das Sicherheitsteam weiter.

Der erste Fehler ist ein Lehrstück darüber, wie aus einer stillen Annahme ein Absturz aus der Ferne wird. Bitcoin Core begrenzt, wie viele Daten es je Gegenüber in die Warteschlange legt, und zwar indem es das Lesen aussetzt, sobald die Schlange zu groß wird. Unter Linux nutzt die Socket-Schicht poll(), das nur die Bedingungen meldet, nach denen ausdrücklich gefragt wurde. Unter Windows, macOS und BSD steht dort select(), und select() meldet zusätzlich „außergewöhnliche Bedingungen“ — ein Rest aus Zeiten, in denen dringende Daten außerhalb des normalen Datenstroms signalisiert wurden. Genau diese Bedingung löst TCP bei dringenden Daten aus. Der zugehörige Handler las in beiden Fällen, ohne zu prüfen, ob das Lesen gerade ausgesetzt war. Ein pausierter Partner konnte die Bremse damit umgehen und beliebig viele Daten in die Schlange legen. Der Hinweis selbst formuliert es ungewöhnlich deutlich: ein bösartiger Partner „kann jeden Knoten unter Windows, macOS oder BSD, mit dem er verbunden ist, mühelos zum Absturz bringen“. Linux ist nicht betroffen.

Der zweite ist ebenfalls mittelschwer, langsamer und interessanter. Partner, die nicht mehr lesen, werden pausiert — aber Transaktionsankündigungen werden weiter an ihre Sendeschlange angehängt. Normalerweise läuft diese Schlange leer, oder der Partner wird getrennt, weil er ein Ping mit Zufallszahl nicht innerhalb von zwanzig Minuten beantwortet hat. Diese Trennung greift jedoch nicht bei Partnern, die keine Unterstützung für BIP 31 anmelden. BIP 31 ist die Erweiterung, die aus einem Ping ein Ping mit Zufallszahl und eine passende Antwort macht; ohne diese Anmeldung gilt der Partner als alt und wird nicht abgeräumt. Wer sich also einfach als alt ausgibt und langsam liest, lässt die Schlange unbegrenzt wachsen — bis zu 2 MB pro Stunde eingehend und 5 MB pro Stunde ausgehend. Knoten, die mit -blocksonly laufen, sind „deutlich weniger betroffen“, weil Transaktionsankündigungen den Großteil dessen ausmachen, was sich dort stapelt. Gefunden wurde dieser Fehler von Loupe am 15. September und unabhängig davon erneut vom Entwickler L0rinc am 21. September.

Der dritte Fehler ist als gering eingestuft und besteht aus einem Buchhaltungsfehler, der zu einer Abschaltung wird. Undo-Daten sind der Nachweis, welche Münzen ein Block ausgegeben hat; sie liegen in rev*.dat-Dateien und wurden nur durch einen 32-Bit-Zähler für die Schreibposition begrenzt. Ein Miner kann gültige Blöcke bauen, deren Undo-Daten weit größer sind als die Blöcke selbst, und eine einzelne Undo-Datei über 4 GiB treiben. Dann läuft der Zähler über, neuere Undo-Daten überschreiben ältere, die Datei wird abgeschnitten. Löst eine Reorganisation — also das Zurücknehmen bereits bestätigter Blöcke — später einen betroffenen Block ab, kann der Knoten seine Undo-Daten nicht mehr lesen und fährt herunter. Ein Neustart hilft nicht, nur ein vollständiger Neuaufbau des Index mit korrigierter Software. Unter Windows und auf 32-Bit-Systemen enden die Dateipositionsaufrufe bei 2 GiB; dort scheitert schon das Schreiben, und der Knoten stirbt bei jedem Neustart, mit ungefähr der halben Datenmenge und ganz ohne Reorganisation. Der Hinweis nennt eine Ausnutzung auf 64-Bit-Systemen unpraktisch und hält fest, dass 32-Bit-Systeme und Knoten, die ihre Blöcke auf FAT32 ablegen, auch nach der Aktualisierung betroffen bleiben. Die Korrektur speichert Dateipositionen als 64-Bit-Werte, mit 64-Bit-Aufrufen unter Windows, und lässt das Format auf der Platte unverändert.

In keinem der drei Hinweise steht eine CVE-Nummer, und der Bericht aus Marty Bents Team hält fest, dass zum Zeitpunkt der Offenlegung keine vergeben war. CVE ist das öffentliche Register für Sicherheitslücken: eine Nummer, unter der Scanner, Ticketsysteme und Prüfer dieselbe Lücke wiedererkennen. Dass sie fehlt, ist keine Nachlässigkeit, sondern Folge der neuen Regel — und der erste Punkt, an dem die schnelle Spur mit der Welt außerhalb zusammenstößt. Unternehmensweites Schwachstellenmanagement läuft über diese Nummern: Scanner suchen nach ihnen, Ticketsysteme sortieren nach ihnen, Prüfer fragen nach ihnen. Eine Korrektur, die mit Versionshinweis und Sicherheitshinweis erscheint, aber ohne Nummer, ist laut für Entwickler und leise für die Maschinerie, die entscheidet, wann die Infrastruktur einer Bank aktualisiert wird.

Der Scanner fand einen davon einundvierzig Tage vor der Korrektur

Hier weichen die öffentliche Erzählung und die Primäraufzeichnung voneinander ab, und diese Abweichung ist das Nützlichste an der ganzen Offenlegung.

Die Berichte vom 29. Oktober beschreiben einen Umschlag von fünf Tagen zwischen dem Fund des Modells und der korrigierten Version. Für den TCP-Fehler sagt die Zeitachse genau das. Für den BIP-31-Fehler saßen derselbe Scanner, derselbe Prüfweg und derselbe Melder auf einem bekannten, meldefähigen Problem — vom 15. September bis Antoine Poinsot am 26. Oktober eine Abhilfe öffnete. Einundvierzig Tage. Der Fehler war nicht geheim, weil ihn niemand finden konnte. Er blieb unkorrigiert, weil die Korrektur an einen Veröffentlichungszug gekoppelt war, und der Zug war für Ende Oktober angesetzt.

Zwei Fehler aus demselben Scanner, einundvierzig Tage auseinander

Diese Lücke ist kein Skandal. Ein Speicherfehler, der einen absichtlich fehlerhaft gebauten Partner über Wochen braucht, ist kein Notfall derselben Klasse wie ein Absturz durch ein einziges Paket. Aber die Lücke zeigt, welche Schranke die neue Regel tatsächlich beseitigt hat. Sie hat die Sperrfrist beseitigt, das absichtliche Warten zwischen Korrektur und Mitteilung. Sie hat nicht die Kopplung zwischen Korrektur und Veröffentlichung beseitigt, denn ein Backport muss für vier gepflegte Zweige gleichzeitig gebaut, getestet und ausgeliefert werden. Fünf Tage waren schnell, weil die Veröffentlichung ohnehin nahe war. Verschiebt man denselben Fund drei Wochen nach eine Hauptversion, ändert sich die Rechnung.

Die Fünf-Tage-Zahl ist deshalb eine Untergrenze des Machbaren und keine Beschreibung des Dauerzustands. Der Dauerzustand lautet: Entdecken ist billig und läuft ununterbrochen, die Sichtung macht ein Mensch, das Ausliefern ist periodisch. Nur der erste dieser drei Punkte hat diesen Monat eine Regeländerung bekommen.

Die Flotte

Versionen sind öffentlich. Knoten melden beim Verbindungsaufbau eine Kennung, den User-Agent, und die Momentaufnahme der erreichbaren Knoten vom Morgen des 29. Oktober, 07:26 UTC, enthält 18.209 Adressen. Davon meldeten 1.926 einen Bau von Bitcoin Knots, einer eigenständigen Umsetzung mit eigenem Veröffentlichungstakt. Sie sind hier getrennt gezählt, weil sich ihr Patch-Stand aus dieser Aufnahme nicht bestimmen lässt. Es bleiben 16.283 Knoten, die sich als Bitcoin Core ausgeben.

Von diesen 16.283 liefen 568 auf einer korrigierten Fassung: 201 auf 32.1, 267 auf 31.2, 17 auf 29.5, 11 auf 30.4, der Rest auf Nachbauten, die eine erkennbare Versionszeichenfolge melden. Das sind 3,5 Prozent. Weitere 10.750 Knoten, 66,0 Prozent, liefen auf einem Zweig ohne die Korrektur: 8.080 auf 31.1.0, 1.226 auf 31.0.0, 510 auf 30.2.0, 384 auf 30.0.0, 87 auf 32.0.0 — einer Marke, die das Projekt nie vollständig angekündigt hat. Und 4.965 Knoten, 30,5 Prozent, liefen auf 29.4.0 oder älter, also auf Fassungen, die jetzt außerhalb der Pflege stehen und diese Korrekturen nie erhalten werden.

Zur Zählweise, weil sie den Unterschied zwischen einem Befund und einer Behauptung ausmacht: gezählt wurden nur Kennungen der strengen Form /Satoshi:x.y.z/. Rund 940 weitere Knoten melden Zusätze in der Kennung, etwa den Namen einer fertigen Node-Distribution; sie stecken in dem Rest, der oben als „erkennbare Versionszeichenfolge“ erscheint. Wer anders zählt, verschiebt einzelne Posten um wenige Dutzend Knoten und die Prozentwerte um Zehntel. Die Größenordnung ändert das nicht.

Verteilung der Bitcoin-Core-Versionen, eigene Zählung von 16.283 Knoten

Wichtig ist nicht 3,5 gegen null. Wichtig ist 3,5 gegen die 66,0 Prozent, die heute mit einem Download und einem Neustart nachziehen könnten, und gegen die 30,5 Prozent, die ohne Versionssprung überhaupt nicht nachziehen können. Eine Backport-Strategie, die auf „jede gepflegte Version“ zielt, zielt im besten Fall auf zwei Drittel des Netzes. Und das Drittel außerhalb der Pflege ist das Drittel, das am längsten draußen ist — und damit meist das, das am schwersten zu erreichen ist.

Es gibt eine Lesart dieses Arguments, die die Gefahr übertreibt, und sie verdient ihren Platz. Die Aufnahme meldet Kennungen, keine Betriebssysteme, und der schwerste der drei Fehler trifft kein Linux. Die Stichprobe der erreichbaren Knoten ist verzerrt: zuhörende Knoten auf Adressen von Rechenzentren sind überproportional Linux, während Desktop-Wallets und kleine Heimnodes unter Windows und macOS sich selbst unterrepräsentieren, weil sie hinter einer Netzwerkübersetzung sitzen und nie eingehende Verbindungen annehmen. Die meisten der 8.080 Knoten auf 31.1.0 sind mit hoher Wahrscheinlichkeit Linux-Rechner in einem Aktualisierungsrhythmus, der in Quartalen gemessen wird, und für sie ist der TCP-Fehler ein Nicht-Ereignis. Ein abgestürzter Knoten ist außerdem keine gestohlene Wallet: keiner der drei Fehler bewegt Geld. Der realistische Schaden ist ein Knoten, der aufhört zu prüfen und weiterzugeben — was zählt, wenn dieser Knoten Zahlungen oder die Sicht eines Lightning-Kanals auf die Kette trägt, und überhaupt nicht zählt, wenn es ein Liebhaberknoten ist, der am Samstag neu gestartet wird.

Gibt man das alles zu, bleibt ein Teil der Messung stehen. Der BIP-31-Fehler trifft Linux. Der Undo-Datei-Fehler lässt 32-Bit-Systeme und FAT32-Datenträger auch nach der Aktualisierung dauerhaft exponiert. Die beruhigende Lesart „Linux ist in Ordnung“ deckt nur den lautesten der drei Fehler ab. Die leisen zwei sind die, die in einem Jahr noch im Feld stehen.

Die Verlustliste und der Lohn

Der Grund, die Scanner-Frage ernst zu nehmen, ist eine Rechnung, die das Jahr 2026 bereits hat. Eine Zusammenstellung, die Lightning.news für Bitcoin Magazine erstellt hat und die auf einer Liste von Protokollen mit Verlusten über 50.000 Dollar beruht, beziffert die Nettoverluste nach Einfrierungen und Rückzahlungen auf rund 2,35 Milliarden Dollar über 230 Protokolle in diesem Jahr, davon etwa 768 Millionen allein im September. Die Konzentration ist der Punkt: der größte Einzelverlust, die Räumung von Bitget über rund 387,5 Millionen Dollar am 24. September, kam aus Hot- und Warm-Wallets und wird von Chainalysis, Elliptic und TRM Labs nordkoreanischen Akteuren zugeschrieben, die Auszahlungsbefehle über Sicherheitsprodukte Dritter einschleusten, ohne einen privaten Schlüssel anzufassen. Der zweitgrößte, Blockstreams Liquid-Netz Anfang September, war ein Fehler in Elements, der rund 4.000 nicht gedeckte L-BTC erzeugte und sie gegen etwa 4.000 Bitcoin ausbuchte, damals knapp 320 Millionen Dollar; die selbsternannten White Hats gaben 3.400 BTC zurück und behielten rund 600. Kein Föderationsschlüssel wurde kompromittiert. Samson Mow hat den Vorgang als Teil einer „Lawine KI-gestützter Angriffe“ beschrieben. Das ist seine Deutung, kein gesicherter Befund, und so sollte man sie lesen.

Hardware-Wallets sind bei allem Lärm um sie in diesem Jahr ein kleinerer Posten in dieser Rechnung. Galaxy Research beziffert die Verluste aus dem Zufallszahlengenerator von Coinkite auf rund 1.596 bis 1.789 BTC, in der Größenordnung von 100 bis 130 Millionen Dollar. Das Muster, das hält, lautet: Wert sammelt sich dort, wo die Zahl der Menschen, die überzeugt werden müssen, am kleinsten ist — die Hot-Wallet einer Börse, der einzelne Prüfer einer Brücke, der Softwarefehler einer Sidechain. Ein Sprachmodell-Scanner ändert diese Geometrie nicht. Er senkt den Preis dafür, die Tür zu finden.

Das Tor ist die neue Sperrfrist

Dieselbe Woche brachte das Spiegelbild dieses Problems, und kaum jemand hat beides verbunden. Google DeepMind veröffentlichte Gemini 4 Carbon, ein Spitzenmodell mit Ausrichtung auf Cybersicherheit, mit 88,2 Prozent auf SEC-bench Pro für das Auffinden von Schwachstellen, 54,8 Prozent auf ExploitGym für deren Ausnutzung und 71,0 Prozent auf CWE-bench für das Schließen. Im neu aufgebauten Artificial Analysis Intelligence Index v5 belegte es mit einem Wert von 59 den ersten Platz.

Öffentlich zugänglich war es nicht. Carbon ging zuerst über Googles Fairwind-Programm an geprüfte Verteidiger, mit breiterem Entwicklerzugang „so bald wie möglich“.

Liest man das gegen die Entscheidung von Bitcoin Core, ergibt sich Folgendes. Im Oktober kam das Projekt zu dem Schluss, dass es schlimmer ist, eine Korrektur vor Leuten geheim zu halten, die sie mit einer Eingabeaufforderung wiederfinden können, als sie zu veröffentlichen — weil Geheimhaltung nur die Verteidigung verzögert. Google kam von der anderen Seite zum selben Befund und zog den entgegengesetzten Schluss: wenn ein Modell das Wiederfinden billig macht, beschränkt man das Modell. Beide beantworten dieselbe Frage — wer die Fähigkeit zuerst bekommt — und beide kaufen dieselbe Ware. Bitcoin Core kaufte fünf Tage. Google kaufte, was eine gestaffelte Freigabe eben kauft: die Zeit, bis eine gleichwertige Fähigkeit außerhalb des Tors existiert.

Dieses Intervall ist messbar, und es ist nicht großzügig. Auf demselben Index, auf dem Carbon 59 erreicht, fiel das stärkste dort gelistete offene Modell, Kimi K3.1 Pro, im Umbau auf v5 von 55 auf 46, und DeepSeek V4.1 Flash und GLM-5.3 stehen beide bei 32. Ein in derselben Runde zitierter Beobachter schätzt den Abstand zwischen amerikanischer und chinesischer Spitze auf etwa 3,3 Monate. Drei Monate Tor, drei Monate Aufholen bei offenen Gewichten: ungefähr die Länge der Sperrfrist, die Bitcoin Core gerade abgeschafft hat — erreicht von einer völlig anderen Richtung aus.

Artificial Analysis Intelligence Index v5, Stand dieser Woche

Ein Modell zu sperren ist eine Offenlegungspolitik in anderer Kleidung. Sie setzt voraus, dass Fähigkeit der knappe Einsatz ist, dass das Tor hält und dass Verteidiger den Vorsprung besser nutzen als Angreifer das Leck. Die Erfahrung mit Bitcoin Core sagt, dass die erste Annahme in einem wichtigen Punkt falsch ist: Fähigkeit ist nicht mehr knapp, knapp sind Prüfung, Auslieferung und Installation. Googles Tor kann keines der drei liefern.

Warum die Zahlen dieser Woche überhaupt prüfbar sind

Es gibt einen Grund, warum dieses Argument mit Zahlen statt mit Adjektiven geführt werden kann, und der Grund ist nicht, dass die Sicherheitswelt besser geführt wäre als die KI-Welt. Der Grund ist, dass Sicherheitsaussagen einen Gegenbeweis haben. Ein Speicherfehler stürzt den Knoten ab oder nicht; eine Versionszeichenfolge erscheint im Handschlag eines Partners oder nicht. Der am 28. Oktober veröffentlichte Hinweis kann sich im Schweregrad irren, im Mechanismus nicht. Jemand kann den Angriff an einem Nachmittag nachbauen und die Frage entscheiden.

Die Debatte über Messung in der KI hat keinen solchen Boden, und diese Woche zeigte die Belastung. Der v5-Index, der Carbon nach oben setzte, läuft zu 60 Prozent auf privaten Testsätzen, gewichtet vier Säulen zu je 25 Prozent (Wissensarbeit, Programmieren, Wissenschaft, Allgemeines) und erzeugt eine einzige Zahl, die entscheidet, wer einen Billionenmarkt anführt. Nathan Lamberts Zusammenfassung des Kompromisses ist der ehrlichste Satz, der darüber geschrieben wurde: „Hill-climbing is easy, knowing what to hill-climb is hard.“ Ein Index, der sich auf eine Zahl reduziert, ist gerade deshalb nützlich, weil er eine verlustbehaftete Verdichtung all dessen ist, was sich nicht auf eine Zahl bringen lässt.

Beide Felder teilen außerdem einen Nenner, der beide überragt. Die Octoverse-Zahlen von GitHub, diese Woche veröffentlicht, nennen 220 Millionen zusammengeführte Pull Requests pro Monat, 7,38 Milliarden Commits pro Monat und 30,3 Millionen neue Repositories pro Monat — jede dieser Größen rund verdreifacht in einem Jahr. Das ist die Fläche, die ein Sprachmodell-Scanner heute liest. Project Loupe fand einen Absturz aus der Ferne in der am intensivsten geprüften Open-Source-Codebasis, die es gibt, weil jemand ein Modell auf Code richtete, den kein menschliches Team je Zeile für Zeile lesen würde. Es gibt inzwischen Größenordnungen mehr Code als Prüfer, und die Scanner sind das Einzige, was diesem Verhältnis nachkommt.

Deshalb ist der Fehlerzustand des nächsten Jahres wahrscheinlich nicht ein Fehler, den niemand gefunden hat. Es wird ein Fehler sein, den alle gefunden haben, der in fünf Tagen korrigiert wurde und auf der Hälfte des Netzes noch läuft, weil niemand aktualisiert hat.

Was von hier aus tatsächlich prüfbar ist

Drei Dinge, und jedes hat eine Adresse.

Erstens die Versionsverteilung. Die neue Regel enthält die Behauptung, schnelle Offenlegung sei sicher, weil Betreiber mitziehen. Diese Behauptung ist in dreißig Tagen widerlegbar, indem man dieselbe Momentaufnahme erneut liest: steht die Gruppe der 8.080 Knoten auf 31.1.0 Mitte November noch, dann ist die Regel den Leuten davongelaufen, die sie schützen sollte, und der Handel — keine Sperrfrist gegen ein kürzeres Zeitfenster — hat das kürzere Zeitfenster nicht geliefert.

Zweitens die CVE-Frage. Erscheint der nächste als leicht auffindbar eingestufte Hinweis wieder ohne Nummer, lohnt der Blick, ob institutionelle Betreiber gleich schnell reagieren. Das Fehlen einer CVE-Nummer ist ein stiller Filter: er hält keinen Entwickler auf, er hält einen Scanner auf.

Drittens, ob das Tor hält. Taucht ein Modell mit Carbons Cyber-Werten in offenen Gewichten auf, bevor Google den Zugang ausweitet, dann hat das Fairwind-Programm weniger Zeit gekauft als die alte Sperrfrist, und das Argument, Fähigkeit müsse rationiert werden, verliert seine wichtigste empirische Stütze. Hält das Tor stattdessen ein Jahr, folgt die Gegenprobe, und die Begründung, angriffsfähige Modelle aus dem allgemeinen Umlauf zu halten, wird stärker, als vielen Verfechtern offener Modelle lieb ist.

Der makroökonomische Hintergrund hat daran nichts geändert, und das ist selbst der Punkt. Die US-Notenbank beließ den Zielkorridor am 28. Oktober bei 3,75 bis 4 Prozent, mit zehn zu zwei Stimmen; Gouverneurin Lisa Cook und die Präsidentin der Fed von Cleveland, Beth Hammack, stimmten für eine Anhebung um einen Viertelpunkt. Bitcoin Magazine merkt an, es sei das erste Mal seit 1992, dass ein Gouverneur und ein Regionalpräsident auf derselben Seite abweichen. Die Erklärung strich die vorausschauende Formel darüber, wann eine Anhebung zwei Prozent wiederherstellen könnte, und ersetzte sie durch das Versprechen, „die Anhäufung weiterer Informationen wird dem Ausschuss helfen, die Haltung der Politik zu bestimmen“. Bitcoin notierte zum Zeitpunkt dieser Fassung bei 79.992 Dollar (eigene Messung, 29. Oktober, 10:31 Uhr MEZ), rund ein Drittel unter dem Rekord von etwa 126.000 Dollar im Oktober 2025, und die börsengehandelten Spot-Fonds nahmen am 26. Oktober 110 Millionen Dollar und am 27. Oktober 176 Millionen Dollar auf.

Geld floss in denselben Tagen in dieses Asset, in denen die Software, die es sichert, korrigiert und nicht installiert wurde. Beides ist auf der Ebene eines einzelnen Akteurs vernünftig: der Käufer bepreist einen Fünfjahreshorizont, der Knotenbetreiber bepreist ein Wochenende. Das Aggregat ist das Problem. Ein monetäres Netzwerk, das sich über Prüfbarkeit verkauft, kann die Prüfung nicht an ein Modell auslagern, das schneller liest, als seine Betreiber installieren.

Der Patch ist nicht das Upgrade. Alles, was die neue Offenlegungsregel richtig gemacht hat, betraf den Patch.

Quellen

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