Decent Newsroom
Sign In

Die Grenze stand in der Spezifikation

By Roger November 9, 2026 · Edited November 9, 2026
In 72 Stunden: ein unbegrenzter Puffer in Eclair, ein weltweiter Stopp von LNbits und ein Vorschlag, Solanas dauerhafte Nonces zu streichen. Vier Fehler, eine fehlende Zeile — und die Frage, wer diese Grenze künftig durchsetzt.
Die Grenze stand in der Spezifikation

In 72 Stunden: ein unbegrenzter Puffer in Eclair, ein weltweiter Stopp von LNbits und ein Vorschlag, das Solana-Merkmal zu löschen, das 270 Millionen Dollar gekostet hat. Vier Fehler, eine fehlende Zeile.

Am Sonntag um 12:33 Uhr UTC forderte das Projekt LNbits seine Betreiber auf, die Erweiterung Paywall abzuschalten. Um 13:56 Uhr UTC folgte die Anweisung, alles abzuschalten. Zu diesem Zeitpunkt hatte der Betreiber eines Telegram-Trinkgeld-Bots bereits zugesehen, wie 2.285.545 Satoshi aus einer Instanz verschwanden, die er selbst betreibt — abgezogen zwischen 09:22 und 14:00 Uhr UTC von Konten, die Minuten zuvor angelegt worden waren. Der Gründer des Projekts rechnete mit einer Fehlerbereinigung binnen 24 bis 48 Stunden. Eine neue Version mit Versionsnummer gibt es bis heute nicht; die neueste ist v1.6.2 vom 18. September. Der Fehler ist aber auf einem öffentlichen Zweig sichtbar, und die Commit-Nachrichten benennen einen Mechanismus, den das Projekt sonst nirgends beschrieben hat.

Das war der laute Fall. Der leise ist der lehrreichere.

Ebenfalls am Sonntag veröffentlichte ACINQ auf dem Bitcoin-Entwicklerforum Delving Bitcoin eine Offenlegung im Ton einer Werkstattrechnung: Jeder Gegenüber, der eine TCP-Verbindung zu einem Eclair-Knoten der Version 0.14.0 aufbauen konnte, konnte ihn dazu bringen, Commitment-Signaturen zu puffern, bis dem Prozess der Speicher ausging. Kein Kanal nötig, kein Geld direkt entwendet, behoben in 0.14.1. Liest man die Beschreibung, stellt man fest: Die Spezifikation hatte genau das längst verboten. BOLT 2 schreibt vor, dass ein empfangender Knoten ein start_batch mit einer batch_size, die nicht echt größer als 1 ist, ignorieren MUSS, und begrenzt den Stapel auf 20. Eclairs Code prüfte die Obergrenze und vergaß die Untergrenze.

Und am Donnerstag, dem 5. November, reichte ein Entwickler von Anza mit SIMD-0723 einen Vorschlag ein, Solanas dauerhafte Nonces (durable nonces) ganz zu streichen: jenes Merkmal, das einem Angreifer erlaubte, Transaktionen im Voraus zu signieren, sie länger als eine Woche liegen zu lassen und damit im April mindestens 270 Millionen Dollar aus dem Protokoll Drift zu ziehen. Der Vorschlag repariert keine Prüfung. Er entfernt die Fähigkeit. Frühestens wirksam werden kann er am 5. Mai 2027.

Zweiundsiebzig Stunden: SIMD-0723, die Abschaltanweisung von LNbits, die Eclair-Offenlegung und der über Nacht hochgeladene Reparaturzweig

Drei Vorfälle, drei Begriffe, eine Form. In jedem Fall existierte die Regel, sie war aufgeschrieben, und sie wurde an der Stelle nicht durchgesetzt, an der der Zustand wuchs. Das knappe Gut dieser Branche ist nicht mehr Code. Es ist die Durchsetzung.

Ein Nullwert, wo eine Eins stehen müsste

Fangen wir mit dem Eclair-Fehler an, weil er das sauberste Exemplar ist.

Ein Lightning-Kanal hat normalerweise eine Finanzierungstransaktion, also braucht eine Kanaländerung eine commitment_signed-Nachricht. Ein Splice macht das komplizierter: Solange Splice-Transaktionen unbestätigt sind, weiß keine Seite, welche der Kandidaten-Transaktionen am Ende in einen Block kommt. Also muss eine Änderung für jeden Kandidaten signiert werden. Bei N offenen Splices verschickt der Sender N + 1 Commitment-Signaturen, und der Empfänger muss diesen Haufen als eine einzige logische Änderung behandeln. start_batch kündigt den Haufen an: mit Kanal-Kennung, einer 16-Bit-Zahl batch_size und dem Nachrichtentyp, der folgen wird — 132, commitment_signed. Eclair hält diese Nachrichten in PeerConnection fest, bis die angekündigte Anzahl erreicht ist, und reicht sie dann als ein CommitSigBatch an den Kanal weiter.

Weil der Empfänger sie zwischenspeichert, setzt BOLT 2 eine harte Obergrenze von 20 auf diese Zahl — „um übermäßiges Einreihen zu verhindern, das zum Denial-of-Service gegen empfangende Knoten missbraucht werden könnte“. BOLT 2 setzt aber auch eine Untergrenze, und diese Untergrenze ist der Fehler. Eclairs Lesepfad in PeerConnection, verkürzt aus der Offenlegung:

} else if (msg.batchSize > 20) { … } else { … Some(PendingCommitSigBatch(msg.channelId, msg.batchSize, Nil)) }

Eine batch_size von 0 kam durch. Danach wurde jede eintreffende commitment_signed für diese Kanal-Kennung an die offene Liste gehängt, und die Abschlussprüfung verglich den gezählten Stand mit 0. Da der Zähler nach der ersten Nachricht bei 1 beginnt, erreicht er die 0 nie, der Stapel wird nie fertig, und die Liste wächst so schnell, wie der Angreifer nachliefert. Nur die 0 löst das aus; ein Stapel von 1 ist sofort vollständig — vermutlich der Grund, warum es niemandem auffiel.

Vier Einzelheiten machen aus einem Logikfehler einen Fernschalter. PeerConnection prüft nie, ob die Kanal-Kennung zu einem echten Kanal gehört; der Angreifer braucht also keinen Kanal und keine Einzahlung. Auf dieser Ebene prüft niemand Signaturen, jede Nachricht darf sich deshalb der Rahmen-Grenze von 65.535 Byte nähern. Jede Nachricht wird gegenüber dem Transport quittiert, bevor sie gepuffert wird; es gibt also keinen Gegendruck. Der Speicher wächst mit Leitungstempo. Und der Puffer lebt so lange wie die Verbindung: Der Angreifer muss nur auf Pings antworten und alles vermeiden, was den Stapel abschließt.

Die Kanalgrenzen des Knotens helfen nicht. max-no-channels begrenzt eingehende Verbindungen ohne Kanal auf 64 — das ist eine Grenze für Verbindungen, nicht für den Speicher, den eine einzelne verbrauchen darf. Eine Verbindung genügt.

Die Offenlegung ist vorsichtig mit der Wirkung, und das sollten wir auch sein: Der Fehler öffnet keinen direkten Zugang zu Guthaben. Das Risiko ist indirekt und der Art nach schlimmer. Ein Lightning-Knoten muss online sein, um auf einen widerrufenen Zustand zu reagieren und HTLCs abzuwickeln, bevor sie verfallen. Ein HTLC ist eine bedingte Zahlung im Kanal: Sie gilt nur, wenn der Empfänger innerhalb einer Frist einen Beleg vorlegt, sonst fällt das Geld an den Sender zurück. Ein Knoten, den jeder, der seinen Port erreicht, beliebig oft zum Absturz bringen kann, ist ein Knoten, der sich genau in dem Fenster offline halten lässt, in dem Offlinesein Geld kostet. Das ist der Unterschied zwischen einem Ausfall der Verfügbarkeit und einem Ausfall der Verwahrung.

Die Reparatur ist eine Bedingung, die batch_size <= 1 zurückweist, wie es die Spezifikation verlangt, und sie kam mit 0.14.1. Die Versionsgeschichte seither ist für sich ein Argument: 0.14.3 am 14. September, 0.14.4 am 15. Oktober, 0.14.5 am 20. Oktober, 0.14.6 am 27. Oktober. Vier Veröffentlichungen in sechs Wochen, jede als Sicherheits-Härtung beschrieben, mehrere mit namentlich genannten externen Forschern, eine mit Dank an „project Loupe“. Einen Lightning-Knoten im Jahr 2026 zu betreiben ist keine jährliche Pflichtübung. Es ist ein Abonnement.

Die dreigliedrige Kette der Verwahrung

LNbits ist der umgekehrte Fall: kein Protokoll-Sonderfall, sondern eine Anwendung, die Konten ausgibt.

Was am Montagmorgen gesichert ist: Das Projekt hat seine Betreiber am 8. November gegen 13:56 Uhr UTC nach einer Angriffswelle komplett offline geschickt. Der gehostete Dienst unter my.lnbits.com wurde mit abgeschaltet. Der bislang einzige dokumentierte Verlust sind 2.285.545 Satoshi von der Instanz hinter einem Telegram-Trinkgeld-Bot; dessen Betreiber hat zugesagt, die Nutzer aus eigener Tasche zu entschädigen, und bestätigt, dass die Mittel bis zu einer Fehlerbereinigung eingefroren sind. Der Angriffsmechanismus ist nicht veröffentlicht. Unbefugte Kontoanlage mit anschließenden unbefugten Auszahlungen ist alles, was feststeht; ob der Fehler in der Kontoschicht oder in einer Erweiterung sitzt, ist öffentlich nicht bekannt.

Seit dem Abschalten sind auf einem Zweig namens fix_ssrf drei Commits des Projektgründers erschienen, der unter „Arc“ schreibt; der letzte um 00:07 Uhr UTC am 9. November. Zusammen beschreiben sie eher die Form der Reparatur als den Angriff: ein neues Modul, dessen Beschreibung lautet „Reject user-controlled requests back to the deployment itself“ — also vom Nutzer gesteuerte Anfragen zurück auf die eigene Installation abweisen; ein zweites Modul, das einen Hostnamen auflöst und die resultierenden Adressen prüft, bevor eine Anfrage hinausgeht; neunzig geänderte Zeilen im LNURL-Dienst; und, in einem eigenen Commit, „default new account creation false + push users toward invitations“, also Kontoanlage standardmäßig aus und Nutzer Richtung Einladungen. Dazu kommen 564 Zeilen neuer Tests. Das Projekt hat keine Nachanalyse veröffentlicht, deshalb ist der Zusammenhang zwischen diesen Commits und dem Diebstahl meine Schlussfolgerung aus Zeitpunkt und Inhalt, nicht seine Aussage. Die Richtung ist allerdings eindeutig: vom Nutzer gelieferte Adressen, die den Server gegen sich selbst rufen lassen, und eine standardmäßig offene Kontoanlage.

Die Fehlerklasse ist für das Projekt nicht neu. Seine öffentliche Sicherheitsdatenbank enthält einen Eintrag vom April 2025 mit dem Titel „Server-Side Request Forgery via LNURL Authentication Callback in LNbits Lightning Network Payment System“. Eine SSRF ist eine Anfrage, die der Server auf Geheiß eines Außenstehenden stellt — und die ins innere Netz führen kann, wenn niemand die Zieladresse prüft. Neunzehn Monate später zwang dieselbe Klasse jede Instanz offline. Das ist das Wartungsargument in einem Satz: Eine Reparatur für eine Fehlerklasse ist keine Reparatur der Klasse.

Am Montag um 10:35 Uhr mitteleuropäischer Zeit notierte Bitcoin bei 74.211 Dollar — eigene Auswertung der Kursdaten, Stand 9. November 2026. Damit entsprechen die 2.285.545 Satoshi rund 1.696 Dollar; die Multiplikation ist meine, nicht die des Betreibers. Gegen die 270 Millionen Dollar im Solana-Fall ist das Verhältnis beinahe komisch. Dann schauen wir, wer bezahlt hat: keine Stiftung, kein risikokapitalfinanziertes Protokoll, sondern eine Person, die einen Trinkgeld-Bot betreibt und Fremden aus der eigenen Tasche das Geld zurückerstattet. Die Verluste dieser Fehlerklasse landen bei dem, der den Nutzern am nächsten und den Prüfern am fernsten ist.

Der strukturelle Punkt, den die Analyse von TFTC gut trifft: Ein Nutzer eines Telegram-Trinkgeld-Bots glaubt, er vertraue einem Bot. Tatsächlich vertraut er dem Betreiber des Bots, der einer LNbits-Instanz vertraut, die dem Softwarestapel von LNbits vertraut, der einem Knoten im Hintergrund vertraut. Vier Glieder, und eines davon ist eine Hobby-Installation mit einer Kontoanlage, die für das ganze Internet offenstand.

Es gibt eine Ironie in den Versionsnotizen des Projekts. LNbits v1.6.0, am 2. September veröffentlicht, führte WASM-Erweiterungen ein und erklärte das so: „With more people building software with LLMs, LNbits v1.6.0 proudly introduces WASM extensions! WASM extensions are tightly sandboxed, meaning they can be vibe coded and shared without the security risks associated with traditional extensions.“ Das Projekt sah die kommende Flut maschinell geschriebener Erweiterungscodes und baute den Sandkasten dafür. Zehn Wochen später lief ein Angriff über die Kontoanlage und ausgehende Anfragen — über den Kern, nicht über eine Erweiterung. Die Ränder zu kapseln hilft nicht, wenn der Kern jede ihm gereichte Adresse abruft und jedem, der fragt, ein Konto öffnet.

Ich behaupte nicht, dass beides zusammenhängt; die Nachanalyse wird es sagen. Ich behaupte, dass die Schicht, um die man sich Sorgen machte, nicht die Schicht war, die versagte. Das ist der Normalfall in der Sicherheitsarbeit und der Grund, warum „wir haben X gehärtet“ nie eine Antwort auf „ist das sicher?“ ist.

Das Merkmal löschen ist auch eine Reparatur

Solanas dauerhafte Nonces sind das dritte Exemplar und das teuerste.

Jede gewöhnliche Solana-Transaktion trägt einen aktuellen Blockhash. Bei 200-Millisekunden-Slots verfällt dieser Stempel nach etwa dreißig Sekunden. Das ist eine Eigenschaft, keine Schwäche: Eine Signatur ist an einen Moment gebunden, eine signierte Transaktion kann also nicht aufgehoben und später auf Kosten des Unterzeichners wiederverwendet werden. Verwahrer und Börsen signieren jedoch auf abgeschotteten Rechnern, und eine Signatur von dort ins Netz zu bringen dauert länger als dreißig Sekunden. Dauerhafte Nonces ersetzen den Blockhash durch einen Stempel, der nie veraltet. Die Bindung an die Zeit wird bewusst entfernt, damit der Vorgang überhaupt möglich ist.

Im April verschafften sich Angreifer im Voraus signierte Freigaben, ließen die Transaktionen mehr als eine Woche liegen — lange genug, dass niemand mehr auf die konkrete Freigabe achtete — und zogen damit am 1. April mindestens 270 Millionen Dollar aus Drift. Drift ordnete die Operation später einer staatlich gestützten Gruppe aus Nordkorea zu.

SIMD-0723, am 5. November von Gabe Rodriguez von Anza eingereicht, wählt Entfernen statt Reparieren: „After activation, every transaction needs a recent blockhash.“ Der Vorschlag stützt sich nicht auf Drift. Er stützt sich auf Jahre von Fehlern, darunter einen Vorfall von 2022, bei dem eine fehlgeschlagene Transaktion sowohl über den Blockhash- als auch über den Nonce-Pfad verarbeitet wurde und das Hauptnetz etwa 4,5 Stunden anhielt. Der Vorschlag setzt keine Aktivierung vor dem 5. Mai 2027 und gibt mindestens sechs Monate für den Umstieg, gerechnet ab Veröffentlichung; die eigene Abschaltungsseite der Stiftung sagt weiterhin „No date set“, was den Termin nach hinten schieben könnte.

Die Nutzungszahlen erklären, warum das nie durch Aufklärung zu reparieren war. Transaktionen mit dauerhaften Nonces machten in einem Messzeitraum im Juni etwa 3 Prozent des Verkehrs auf Solana aus, zahlten aber 30 Prozent aller Prioritätsgebühren: eine kleine, gebührenunempfindliche, latenzempfindliche Kundschaft. Nur 555 Konten verschickten 97,5 Prozent davon, nach Daten des Forschers Max Resnick, die in der Diskussion des Vorschlags zitiert werden. Das ist die Form eines Merkmals, das für eine Handvoll Institutionen existiert, instand gehalten wird, weil sie dafür zahlen, und für alle anderen ein systemisches Risiko trägt.

Ein Merkmal für 555 Konten: dauerhafte Nonces bei 3 Prozent der Transaktionen und 30 Prozent der Prioritätsgebühren

Die mechanische Lehre lässt sich auf jedes System übertragen, auch auf Bitcoin: Eine Fähigkeit, die eine Signatur von der Zeit löst, ist kein Komfortmerkmal. Sie ist eine Daueroption für jeden, der die Signatur hält. Und die richtige Antwort darauf ist, wenn man das einmal verstanden hat, nicht ein Warnhinweis in der Dokumentation, sondern die Streichung der Option — mit einem Umstiegsfenster in Monaten, nicht in Tagen.

Der stille vierte Fall

Der Sonderfall ist überhaupt kein Sicherheitsvorfall. Am 8. November schrieb ein Support-Mitarbeiter von Gem Wallet auf Delving Bitcoin eine alltägliche Beschwerde: Nutzer kopieren eine Taproot-Empfangsadresse, versuchen bei einer Börse abzuheben und erhalten „invalid address“, weil der sendende Dienst kein bc1p annimmt. Aus Sicht des Nutzers hat die Wallet eine kaputte Adresse erzeugt. Der Beitrag fragt die Wallet-Teams, ob sie für den Empfang standardmäßig Taproot oder SegWit verwenden und wie sie den Unterschied kenntlich machen.

Das ist ein Beitrag eines Beteiligten. Es ist keine Erhebung, und ich werde es nicht als eine ausgeben. Aber es benennt denselben Fehler in einer anderen Tonlage: eine Vorgabe, die technisch korrekt und betrieblich falsch ist. Die Regel, um die es hier geht, ist keine Puffergrenze. Es ist die installierte Basis: was die Gegenseite akzeptiert. Eine Wallet, die das neueste Adressformat als Standard ausliefert, hat für das Protokoll optimiert und den tatsächlichen Zustand des Netzes ignoriert — und die Person, die die Abweichung entdeckt, ist ein Nutzer, der sein Geld nicht bewegen kann. Taproot-Adressen beginnen mit bc1p, ältere SegWit-Adressen mit bc1q; beide sind gültig, aber nicht jede Börse hat die neuere Form nachgezogen.

Drei der vier Geschichten dieser Woche handeln von einer Grenze, die dort fehlte, wo Zustand wuchs. Die vierte handelt von einer Vorgabe, die gewählt wurde, ohne die andere Seite zu messen. Beides sind Fehler derselben Disziplin: zu wissen, was das System um einen herum tatsächlich tut, im Unterschied zu dem, was es laut Spezifikation tun soll.

Vier Fälle, ein Muster: was fehlte, wie repariert wurde und was es kostete

Wer prüft die Prüfung

Damit stellt sich die unbequeme Frage von 2026: Wenn die Spezifikation die Antwort längst enthielt, warum brauchte es eine Offenlegung, um sie anzuwenden?

Die Antwort ist zum Teil Arithmetik. Eine Untersuchung von Faros, zitiert in einem Gespräch von Latent Space mit Mihail Eric, Lehrbeauftragter in Stanford und Leiter von Monaco AI, ergab: Teams mit hoher KI-Nutzung führten 98 Prozent mehr Pull Requests zusammen, während sich ihre Prüfzeit für Pull Requests um 91 Prozent verlängerte. Codeerzeugung wurde billig; die Warteschlange vor den wenigen Leuten, die ihn freigeben können, wurde länger. Erics eigenes Beispiel ist ein Lehrplan, der mitten im Kurs umgeschrieben werden musste: Der erste Durchlauf von Stanford CS146S hatte neun Aufgaben und ein Abschlussprojekt, und im nächsten Durchlauf konnten Studierende einen großen Teil davon in einem Zug erledigen. Als er einen Saal voller Stanford-Studienanfänger und -Juniors fragte, wie sie programmieren, nutzte jeder einzelne Befragte bereits einen Agenten.

Also änderte sich die Aufgabenstellung. Studierende arbeiten jetzt an einem Open-Source-Projekt, und der Betreuer prüft ihren Patch. „You can ask an agent to implement a feature in an afternoon“, sagt Eric in dem Gespräch. „You still have to find out whether the maintainer wants it, why the code behaves the way it does, and what else your patch might break.“ Man kann einen Agenten bitten, ein Merkmal an einem Nachmittag zu bauen. Man muss trotzdem herausfinden, ob der Betreuer es will, warum der Code sich so verhält, wie er sich verhält, und was der Patch sonst noch kaputt macht.

Das ist dieselbe Fähigkeit, die der Eclair-Fehler verlangte, im Kleinen: nicht die Bedingung schreiben, sondern wissen, dass die Bedingung dorthin gehört und dass ihr Fehlen eine Folge hat. Simon Willsons Wochenendversuch zeigt, wie schnell die Erzeugungsseite geworden ist und wie wenig sie entscheidet. Er bat ein Modell, eine SQLite-Erweiterung in C und in Rust zu bauen: Die Rust-Varianten kamen auf 321 KB und 298 KB, die C-Variante auf 14 KB, und die Rust-Version war schneller. Die Erklärung — Rusts Gleitkomma-Parser ist doppelt so schnell wie Cs strtod — führte zu einer zweiten Aufforderung, und das Modell schrieb einen C-Parser mit Clingers schnellem Pfad, der beide schlug. Gemessen über 2 Millionen Zeilen fielen die Kosten je Zeile bei gemischten Daten von 67 Nanosekunden in der ersten C-Version auf 19 in der zweiten, gegenüber 46 und 41 für die beiden Rust-Varianten. Stunden Expertenarbeit in zwei Aufforderungen komprimiert, und der einzige Schritt, den ein Mensch noch verantworten musste, war die Entscheidung, welcher Zahl man glaubt.

Die Marge, die die Wartung bezahlt

Jetzt der Teil, der das mit Geld verbindet, weil Wartung eine Kostenposition ist und Kostenpositionen gestrichen werden.

Die Inflationsdaten für September, die ich an diesem Morgen selbst beim amerikanischen Statistikamt BLS abgerufen habe, statt irgendwem zu glauben: Der Erzeugerpreisindex für Endnachfrage stand im September 2026 bei 159,613 gegenüber 150,100 ein Jahr zuvor, ein Plus von 6,34 Prozent; der Verbraucherpreisindex für alle städtischen Haushalte stand bei 336,940 gegenüber 324,800, ein Plus von 3,74 Prozent. Die Lücke beträgt 2,60 Prozentpunkte, und die Erzeugerpreise steigen etwa 1,7-mal so schnell wie die Verbraucherpreise. Beide Werte und die Lücke sind meine eigene Division der veröffentlichten Indexstände; die Indexwerte sind die des BLS. Der Erzeugerpreisindex misst, was Unternehmen für ihre Produkte bekommen — deshalb ist er die Größe, die eine Marge erzählt.

Der Vorbehalt zählt: Erzeuger- und Verbraucherpreise sind verschiedene Warenkörbe mit anderen Gewichten und anderer Behandlung von Wohnen und Dienstleistungen. Die Lücke ist also ein Näherungswert für Margendruck, keine Messung davon. Aber die Richtung ist nicht subtil. Wenn die Preise, die Unternehmen erhalten, um 6,3 Prozent steigen und die Preise, die Haushalte zahlen, um 3,7 Prozent, dann absorbiert etwas dazwischen 2,6 Punkte — und das Ding dazwischen ist eine Gewinn- und Verlustrechnung. Die ersten Budgets, die in dieser Lage gestrichen werden, sind die ohne Umsatz dahinter: Prüfungen, Abhängigkeits-Upgrades, der Entwickler, der Versionsnotizen liest.

Dem gegenüber steht das Kapital, das anderswo zugesagt wird. SpaceX bittet eine texanische Stadt um eine Grundsteuerbefreiung für ein 24-Milliarden-Dollar-Projekt in Starbase: eine Rechenzentrumsanlage mit eigenem gasbefeuertem Kraftwerk, 35 Turbinen, 748 Megawatt. Dasselbe Unternehmen hält 18.712 Bitcoin, zum Zeitpunkt der Meldung etwa 1,39 Milliarden Dollar wert — nach der Rechnung von CoinDesk rund ein Siebzehntel der Projektkosten. Ein einzelnes Unternehmen kann 24 Milliarden Dollar für Rechenleistung aufbringen, und 8 Prozent davon sind mehr als sein gesamtes Bitcoin-Vermögen.

Ich mache nicht den bequemen Punkt, dass das Geld an der falschen Stelle liege. Rechenleistung in dieser Größenordnung ist eine Wette auf einen echten Produktivitätssprung, und die Leute, die sie platzieren, sind keine Narren. Der Punkt ist enger und schwerer zu bestreiten: Das Kapital für neue Fähigkeiten ist gewaltig, das Kapital für die Korrektheit bestehender Systeme ist es nicht, weil Korrektheit keine Umsatzzeile hat. In der Lücke zwischen diesen beiden Finanzierungswelten leben diese Vorfälle.

Das stärkste Gegenargument

Die ehrliche Fassung des skeptischen Falls: Das sind vier unzusammenhängende Nachrichten in einem Nachrichtenzyklus, ausgewählt, weil sie dramatisch sind, und die Systeme haben sich binnen Tagen selbst korrigiert. Eclair lieferte eine Ein-Bedingungs-Reparatur. Solana streicht das Merkmal. LNbits-Reparaturen wurden binnen zwei Tagen erwartet. Die 270 Millionen Dollar waren der Verlust eines einzelnen Protokolls im April, kein systemisches Ereignis, und die Satoshi von einem Trinkgeld-Bot sind ein Rundungsfehler gegen das tägliche Lightning-Volumen. So gelesen ist meine „eine fehlende Zeile“ Mustererkennung auf Zufall, und die Fehlerquote der Branche sinkt, nicht steigt.

Das nehme ich ernst, weil die Basisrate von „alles ist kaputt“-Essays hoch ist und ihr Vorhersagewert niedrig. Drei Dinge ziehen mich in die andere Richtung. Erstens zeigt der Eclair-Fall, dass der Fehler nicht im Schwierigen liegt: Niemand hat das Stapelprotokoll falsch entworfen; jemand schrieb eine von zwei geforderten Bedingungen. Das ist der Fehlermodus, der mit dem Codevolumen wächst, und Codevolumen ist das, was Agenten vervielfachen. Zweitens sagt die Reparaturfrequenz — vier Sicherheitsveröffentlichungen in sechs Wochen für eine einzige Implementierung —, dass der Strom der Offenlegungen inzwischen kontinuierlich ist, was man erwartet, wenn mehr Leute hinsehen und mehr Leute ausliefern. Drittens sind die Kosten dieser Fehler ungleich verteilt: LNbits’ Verlust traf einen freiwilligen Betreiber, Drifts Verlust traf die Nutzer eines Protokolls, während die Einheit, die es jeweils hätte verhindern können, diejenige ist, die die nächste Version schreibt.

Wo der Skeptiker recht hat: Nichts davon spricht dafür, dass die Systeme in der Summe ungesund sind. Bitcoins Basisschicht hatte keinen vergleichbaren Vorfall, und die hier beschriebenen Lightning-Fehler sind Implementierungsfehler mit schnellen Reparaturen, keine Designfehler des Protokolls. Die bisherige Bilanz stützt „das ist beherrschbar“, nicht „das ist fatal“.

Der ehrliche Teil

Was ich nicht getan habe und nicht vorgeben werde. Ich habe keinen dieser Codes geprüft. Der Angriffsmechanismus von LNbits ist vom Projekt nicht veröffentlicht. Was ich habe, ist ein Reparaturzweig: Commit-Nachrichten und ein Diff, die zeigen, wohin die Reparatur ging, nicht, was ein Angreifer tat. Und noch enthält keine mit Versionsnummer versehene Veröffentlichung sie. Die Faros-Zahlen erreichen mich über die Notizen eines Podcasts, nicht über die Untersuchung selbst, und die Nutzungszahlen zu den dauerhaften Nonces stammen aus einem Messzeitraum eines Forschers im Juni, also aus einer Momentaufnahme, nicht aus einer Vollerhebung. Der bc1p-Beitrag ist die Meldung einer Person. Und meine Inflationsrechnung ist genau das: eine Division von vier veröffentlichten Indexständen, kein Modell.

Was daraus folgt

Wenn Durchsetzung das knappe Gut ist, folgen daraus drei Praktiken, und keine von ihnen verlangt Heldentum.

Prüfe die Grenze dort, wo die Warteschlange ist, nicht dort, wo die Spezifikation sie nennt. Eclairs Autoren hatten die richtige Konstante vor sich und verglichen sie mit der falschen Seite eines Bereichs. Der Ort zum Hinsehen ist überall dort, wo eine Nachricht eine Reservierung auslöst, die nach der Quittierung der Nachricht bestehen bleibt — gibt es keinen Gegendruck zwischen „empfangen“ und „gepuffert“, bestimmt der Angreifer die Eingaberate, nicht du.

Behandle „kein Kanal erforderlich“ als eigene Schwereklasse. Fehler, die einen finanzierten Kanal verlangen, kosten den Angreifer Kapital und hinterlassen eine Spur in der Kette. Fehler, die jede TCP-Verbindung erreicht, kosten nichts und hinterlassen nichts. Die Eclair-Offenlegung ordnet das richtig ein: Sie braucht keinen Kanal, und sie sagt es im ersten Absatz.

Miss die installierte Basis, bevor du eine Vorgabe änderst. Das neueste Adressformat, die neueste API-Version, das neueste Signaturverfahren: alles korrekt in der Spezifikation, alles geeignet, einen Nutzer gegen eine Gegenseite zu brechen, die sich nicht bewegt hat. Die Taproot-Frage wird nicht durch ein Protokollargument entschieden. Sie wird davon entschieden, welche Börsen bc1p in diesem Quartal annehmen.

Und eine Gewohnheit für die Leute, die inzwischen maschinell geschriebene Patches prüfen: Die Frage ist nicht, ob der Code tut, was die Beschreibung sagt. Die Frage ist, welche Regel die Beschreibung nie erwähnt — denn dort lebt die fehlende Bedingung, und die Beschreibung wird hervorragend sein.

Die Null, die Eclair annahm, stand in einem Feld, von dem die Spezifikation sagte, es könne nicht null sein. In einem System, in dem wöchentlich Tausende Commits von Autoren eintreffen, die die Spezifikation nie gesehen haben, ist die einzige Verteidigung ein Prüfer, der den Satz kennt. Dieser Prüfer ist jetzt der Engpass. Für ihn zu zahlen ist billiger, als für den Patch zu zahlen, und weit billiger, als für den Ausfall zu zahlen.

Quellen

#bitcoin #lightning #sicherheit #geldpolitik #netzwerk
Write a comment