Entropie-Kollaps: Dein privater Schlüssel könnte seit seiner Geburt nicht zufällig sein

Dieser Artikel war ursprünglich nur für Mitglieder der Zhihu-Kolumne „Krypto-Referenz“ zugänglich, jetzt mache ich ihn dauerhaft öffentlich.

Da dieses Thema zeitkritisch ist - die betroffenen Adressen werden massenhaft bereinigt, und je länger du wartest, desto mehr bist du exponiert. Es bringt niemandem etwas, es hinter einer Bezahlschranke zu verstecken.

Bitte lies es vollständig, überprüfe in Abschnitt 6, ob du auf der Liste stehst, und leite es an alle weiter, die betroffen sein könnten.

------------Hier beginnt der Haupttext------------

41 Minuten, 1.196 Adressen wurden geleert. Das gemeinsame Merkmal der Opfer ist: Sie haben seit 2021 keine Coins mehr bewegt. Alles, was du für die Selbstverwahrung getan hast - Offline, fragmentierte Backups, Passphrase, Multisig - schützt das gesamte Leben dieses Schlüssels; aber niemand hat jemals überprüft, wie er geboren wurde. Und der Geburtsort des Schlüssels hinterlässt keine Spuren: Entropie-Kollaps ist auf der Blockchain völlig unbeobachtbar, er könnte seit fünf Jahren wahr sein, und du kannst es heute nicht herausfinden.

1. Diese 41 Minuten

Am 30. Juli 2026 tauchten auf der Bitcoin-Blockchain eine Reihe merkwürdiger Transaktionen auf.

Das Merkwürdige lag nicht im Betrag, sondern im Rhythmus und Ziel. Innerhalb von 41 Minuten wurden 1.196 Adressen geleert. Diese Adressen standen in keinem Zusammenhang zueinander, sie waren über verschiedene Jahre, Länder und Nutzungsgewohnheiten verteilt. Das einzige gemeinsame Merkmal ist: Die meisten ihrer Besitzer haben seit 2021 keine Coins mehr bewegt. Kaltlagerung, langfristige Aufbewahrung, lehrbuchmäßige Disziplin.

Bis zum 2. August verfolgte Galaxy Research die Zahlen: etwa 1.367 Bitcoins, etwa 88,6 Millionen USD, über 4.500 Adressen. Und die nachträglich eingerichtete öffentliche Beweisstelle coldcardentropy.org registrierte insgesamt 6.657 einzigartige Quelladressen unter sechs Beweisstufen - darunter war die erste Welle der koordinierten Bereinigung 500 Transaktionen, 594.47722484 BTC, genau auf acht Dezimalstellen.

Am 30. Juli gab Coinkite den Grund zu: Ihr Coldcard-Hardware-Wallet hatte seit März 2021 private Schlüssel auf fehlerhafte Weise generiert.

Dieser Satz braucht einen Moment, um sein Gewicht zu verstehen. Es war nicht so, dass das Wallet gehackt wurde, dass die Mnemonik geleakt wurde oder dass jemand das Gerät in die Hände bekam. Es ist so, dass jedes einzelne Schlüssel, das an jedem Tag, an dem diese Wallets normal arbeiteten, erzeugt wurde, um Dutzende von Größenordnungen schwächer war, als es hätte sein sollen. Und das ist seit März 2021 wahr, und von diesem Tag bis zum 30. Juli 2026 gab es keine Hinweise von irgendjemandem, von irgendwelchen On-Chain-Daten oder Geräten, die dir sagen konnten, dass es wahr ist.

Die überwiegende Mehrheit der Menschen - einschließlich vieler erfahrener Spieler, die Selbstverwahrung als Glaubenssatz betrachten - versteht das Risiko der Selbstverwahrung so: Der private Schlüssel ist in deiner Hand, also liegt das Risiko auch in deiner Hand; solange du die Mnemonik nicht leakt, nicht gefischt wirst, nicht das Gerät wechselst und nicht unter Druck gesetzt wirst, sind die Coins sicher. Alle Verteidigungsanlagen basieren auf diesem „Aufbewahrungs“-Aspekt.

Ich denke, es ist genauer zu sagen: Der schwächste Punkt der Selbstverwahrung liegt nicht in der Aufbewahrung, sondern in der Generierung - im Moment der Geburt dieses Schlüssels. Und im Gegensatz zum Aufbewahrungsrisiko ist das Generierungsrisiko eine Art „Vertrauensannahme mit zeitlicher Dimension“: Es könnte zu einem früheren Zeitpunkt falsch gewesen sein, und zu jedem späteren Zeitpunkt kannst du es nicht durch Beobachtung herausfinden. Je kälter dein Cold Wallet, desto länger die Expositionszeit.

2. Die Geburtsurkunde des Schlüssels

Lass uns zunächst alle technischen Begriffe beiseite werfen.

Deine Mnemonik ist im Wesentlichen eine Reihe von Zufallszahlen. Das Wort „zufällig“ trägt die gesamte Sicherheit - denn der private Schlüsselraum von Bitcoin ist so groß, dass es keine Grenzen gibt, die Sicherheit kommt nicht von irgendwelchen Schlössern oder Passwörtern, sondern von einer einzigen Sache: Niemand kann deine Reihe erraten.

Woher kommt diese Reihe von Zufallszahlen? In Hardware-Wallets gibt es einen speziellen Chip, der echte Zufallszahlen aus physikalischem Rauschen erzeugt - thermisches Rauschen, Schaltkreisfluktuationen und andere Unsicherheiten der physischen Welt. Er erzeugt 128 Bit Zufälligkeit, was bedeutet, dass es 2 hoch 128 Möglichkeiten gibt, mehr als die Atome im Universum. Das ist der Grund, warum du deine Coins beruhigt auf einem Blatt Papier mit 24 Wörtern aufbewahren kannst.

Und der Vorfall diesmal ist: Wegen eines falsch gesetzten Kompilierungsschalters wurde dieser physikalische Rauschchip überhaupt nicht aufgerufen. Das Gerät fiel zurück auf einen Pseudo-Zufallszahlengenerator in einer Software - etwas, das durch eine Formel berechnet wird, das zufällig aussieht, aber tatsächlich vollständig nachberechnet werden kann. Das Ergebnis ist, dass die Modelle Mk2/Mk3 nur etwa 40 Bit effektive Zufälligkeit erzeugten.

Wie viel sind 40 Bit? Etwa eine Billion Möglichkeiten. Das klingt viel, aber für einen normalen Computer, der bereit ist, ein paar Tage zu laufen, ist eine Billion eine Nachmittagsaufgabe.

Ein Beispiel

Du hast einen hochwertigen Safe gekauft, der Hersteller verspricht, dass der Schließzylinder 128 Bit Kombinationen hat. Du stellst ihn in den Keller, schweißt ihn an die Wand, und die Schlüssel sind in drei Teile geteilt und in drei Städten vergraben. Fünf Jahre vergehen, der Safe wurde nie aufgebrochen, die Schweißnähte sind intakt, alle drei Schlüssel sind vorhanden. Dann öffnest du eines Tages den Keller und der Safe ist leer.

Der Grund ist: Auf der Produktionslinie des Herstellers war ein Schalter falsch eingestellt, der Schließzylinder deiner Charge hatte tatsächlich nur 40 Bit Kombinationen. Der Safe wurde nicht aufgebrochen - er wurde mit einem Schlüssel geöffnet. Und von dem ersten Tag an war das wahr. Alle Schutzmaßnahmen, die du in diesen fünf Jahren getroffen hast - Schweißen, Fragmentierung, verschiedene Standorte - schützten nur vor der Möglichkeit, dass der Safe aufgebrochen wird, während dieser Safe nie aufgebrochen werden musste.

Ein weiteres Problem ist: Es gibt keine Anzeichen dafür. Der Safe macht keinen Lärm, das Schloss wird nicht locker, und du kannst bei deiner jährlichen Überprüfung keine Anomalien feststellen. Der einzige Moment, in dem du es wissen kannst, ist der Moment, in dem er geöffnet wird.

Das ist der Kern dieser Ausgabe: Wir sind es gewohnt, das Leben eines Schlüssels zu überprüfen, aber wir haben nie zurückgeschaut, um seine Geburt zu überprüfen. Und der Geburtsort hinterlässt keine Spuren.

3. ---Preis

   --

   Fünf Jahre ausgelöst durch ein #ifndef

3.1 Falsch herum eingebautes Sicherungselement

Im März 2021 führte Coldcard eine grundlegende Migration durch - die Verschlüsselungsoperation wurde auf die bewährte libsecp256k1 des Bitcoin-Kern-Ökosystems umgestellt, und die eigene libNgU-Bibliothek wurde eingeführt. Dies war eine Qualitätsverbesserung, die Motivation war völlig legitim.

Das Problem lag in einem Schutzcode, der mit dieser Migration eingeführt wurde. In random.c (libngu, Zeilen 22-31) schrieb der Entwickler eine Sicherung: Wenn der Hardware-Zufallszahlengenerator beim Kompilieren nicht aktiviert ist, wird ein Fehler ausgegeben und die Kompilierung gestoppt. Diese Sicherung verwendete die C-Präprozessoranweisung:

#ifndef MICROPY_HW_ENABLE_RNG

#error "Hardware-Zufallszahlengenerator erforderlich"

#endif

Die Bedeutung von #ifndef ist „Wenn dieses Makro nicht definiert ist“. Der Gedanke desjenigen, der diese Sicherung schrieb, war: Solange jemand vergisst, den Hardware-Zufallszahlengenerator zu aktivieren, wird die Kompilierung fehlschlagen, und ein Unfall kann nicht passieren.

In der tatsächlichen Firmware-Konfiguration war dieses Makro jedoch definiert, und der Wert war 0.

Die C-Sprache fragt bei #ifndef nur „wurde es definiert oder nicht“, nicht „wie hoch ist der Wert“. Es als 0 zu definieren, bedeutet auch, dass es definiert wurde. Daher stellte diese Sicherung fest: „Es ist bereits definiert, alles ist in Ordnung“, #error wurde nie ausgelöst, die Kompilierung verlief reibungslos - während der Wert 0 genau bedeutet, dass „der Hardware-Zufallszahlengenerator nicht aktiviert ist“.

Die Sicherung wurde falsch herum eingebaut. Sie prüft, ob „der Schalter dieses Bauteils vorhanden ist“, nicht ob „der Schalter auf ON gestellt ist“.

Daher baute der Compiler die in MicroPython integrierte Software-Rückfall-PRNG ein. Dieser Code kann bis Mai 2018 zurückverfolgt werden und ist im Kontext von MicroPython ein vernünftiger Fallback; er war jedoch nie für die Verwendung mit Bitcoin-Privatschlüsseln gedacht.

Von diesem Moment an lief bei jedem Coldcard, das die betroffene Firmware verwendete, das Software-Formelprogramm, wenn der Benutzer auf „Neuen Seed generieren“ drückte, und nicht der physikalische Rauschchip.

3.2 Wie klein sind 40 Bit?

Die technischen Rückblicke von Coinkite geben folgende Zahlen an:

• Mk2/Mk3 → Effektiver Suchraum etwa 40 Bit (sollte 128 Bit sein)
• Mk4/Mk5/Q → Effektiver Suchraum etwa 72 Bit (Sicherheitselement SE1/SE2 mischte etwas unabhängige Entropie ein, was teilweise abmilderte)

Die betroffenen Firmware-Versionen sind Mk2/Mk3 von 4.0.1 bis 4.1.9 (Reparaturversion 4.2.0), Mk4/Mk5 unter 5.6.0 (Edge-Linie unter 6.6.0X), Q unter 1.5.0Q (Edge-Linie unter 6.6.0QX).

Hier gibt es eine Datenabweichung, die unbedingt angesprochen werden muss

Coinkite gibt offiziell an, dass Mk4/Mk5/Q 72 Bit hat, während der Bericht von Blockhead am 3. August eine Analyse zitiert, die besagt, dass tatsächlich nur etwa 32 Bit in den endgültigen Seed gelangten.

Der Unterschied zwischen diesen beiden Zahlen ist kein kleiner Unterschied, sondern eine Differenz von vierzig Größenordnungen. 72 Bit sind heute sicher - die globale Rechenleistung kann sie kurzfristig nicht vollständig erschöpfen; 32 Bit sind jedoch noch schwächer als die 40 Bit von Mk3 und sind in wenigen Minuten geknackt. Eine Zahl entscheidet darüber, ob „Mk4-Nutzer in Ruhe migrieren können“ oder „Mk4-Nutzer gerade ausgeräumt werden“.

Bis jetzt konzentrierten sich die beobachteten tatsächlichen Räumungen auf die Einzelunterschriftenadressen aus der Mk3-Ära, was in Richtung Coinkites 72-Bit-Aussage spricht. Aber ich möchte darauf hinweisen: Das ist kein Beweis. Angreifer werden natürlich zuerst die kostengünstigsten Adressen räumen. Diese Angelegenheit selbst ist eine Fußnote zu diesem Thema - wenn eine Annahme unbeobachtbar ist, ist „es ist noch nichts passiert“ nie ein Beweis dafür, dass „es nicht passieren wird“.

3.3 Open Source war die ganze Zeit anwesend, hat aber nicht aufgehalten

Das ist der Punkt, an dem die Leser, die für den gesamten Artikel bezahlen, innehalten sollten.

Coldcard ist Open-Source-Firmware. Es gibt ein öffentliches Code-Repository, Community-Überprüfungen und reproduzierbare Builds - das ist theoretisch die höchste Konfiguration, die eine Sicherheitsprüfung bieten kann. Es war die ganze Zeit anwesend, hat aber nicht aufgehalten.

Es gibt drei Schichten, die eine nach der anderen kontraintuitiv sind.

Erste Schicht: Die Zeile im Quellcode sieht richtig aus

Der Prüfer liest #ifndef MICROPY_HW_ENABLE_RNG + #error und hat den Eindruck, dass "hier ein Schutz vorhanden ist". Der Fehler liegt nicht in der Logik dieser Zeile, sondern in der Beziehung zu den Build-Konfigurationen in einer anderen Datei. Code-Reviews erfolgen datei- und funktionsweise; dieser Bug versteckt sich in den Lücken zwischen den Dateien.

Zweite Schicht: Reproduzierbare Builds beweisen "Konsistenz", nicht "Richtigkeit"

Das Versprechen eines reproduzierbaren Builds ist: Jeder kann aus demselben Quellcode ein identisches Binärformat erstellen, sodass der Hersteller keine versteckten Änderungen vorgenommen hat. Dieses Versprechen wurde in diesem Vorfall vollständig erfüllt - jeder konnte dasselbe Binärformat reproduzieren, und dieses Binärformat enthielt eine Software-Pseudo-Zufallszahl. Ein reproduzierbarer Build garantiert, dass "das, was du bekommst, aus dem Quellcode erstellt wurde", es garantiert jedoch niemals, dass "das, was aus dem Quellcode erstellt wurde, das ist, was du denkst".

Dritte Schicht - diese Schicht ist am gefährlichsten: Die Funktionssignaturen der beiden Zufallszahlengeneratoren sind identisch

Coinkite hat in seiner Analyse ausdrücklich darauf hingewiesen: Der Hardware-RNG und der Software-Backup-PRNG sehen nach außen hin identisch aus. Das bedeutet, selbst wenn jemand tatsächlich das Binärformat zurückverfolgt und den Aufrufpfad überprüft, sieht er denselben Funktionsnamen und dieselbe Parametergruppe. Um das Problem zu entdecken, muss man verfolgen, auf welche Ziel-Datei das Symbol letztendlich aufgelöst wurde - das ist eine Aktion, die fast niemand bei einer regulären Prüfung durchführen würde.

Die Reparaturmethode von Coinkite bestätigt genau dies: Die neue Version schloss explizit das Backup-PRNG-Objekt von MicroPython aus und fügte eine RNG-Symbolprüfung zur Build-Zeit hinzu - wenn die plattformspezifische Ziel-Datei rng_get() nicht bereitstellt oder die Backup-Implementierung nicht vollständig ausgeschlossen ist, schlägt die Kompilierung direkt fehl. Das bedeutet, dass nicht diese Zeile repariert wurde, sondern dass "das Unsichtbare" in "zur Compile-Zeit Sichtbares" umgewandelt wurde.

Ein weiterer interessanter Punkt: Coinkite vermutet, dass dieser seit fünf Jahren latente Fehler möglicherweise von einem KI-Modell entdeckt wurde, als es das Open-Source-Firmware überprüfte. Der Gründer von Coinkite, NVK, sagte: "KI-unterstützte Code-Überprüfungen können jetzt schneller als die erfahrensten Experten der Branche latente Bugs aufdecken."

Dieser Satz hat zwei Seiten. Die positive Seite ist: Solche seit Jahren schlummernden hypothetischen Fehler werden zum ersten Mal in großen Mengen entdeckt. Die negative Seite ist: Angreifer haben Zugriff auf dieselben Werkzeuge, und sie müssen nicht zuerst verantwortungsbewusst offenlegen. Alle Open-Source-Codes, die lange unverändert geblieben sind und kryptographische Primitive betreffen, sind gerade in eine neue Risikophase eingetreten.

4. Diese Aufführung hat insgesamt dreimal stattgefunden

Das Gewicht der Mitgliedschaft steht in diesem Abschnitt im Vordergrund. Entropie-Kollaps ist keine neue Erfindung der Kryptoindustrie, sondern eine Art klassischer Vorfall, der in der kryptographischen Ingenieurwissenschaft immer wieder auftritt, und jede Form ist erstaunlich ähnlich.

4.1 Eine Zeile gelöschter Code, zwanzig Monate lang still

Im September 2006 löschte ein Debian-Wartender beim Packen von OpenSSL zwei Zeilen MD_Update(&m,buf,j); aus md_rand.c. Die Motivation für das Löschen war völlig wohlwollend: Diese beiden Zeilen würden nicht initialisierten Speicher lesen und dazu führen, dass die Debugging-Tools Valgrind und Purify ständig Alarm schlagen. Neben einer Zeile stand sogar der Kommentar /* purify complains */.

Das Problem ist, dass diese beiden Zeilen in unterschiedlichen Kontexten unterschiedliche Dinge tun. Der ursprüngliche Autor schützte nur die tatsächlich problematische Zeile mit #ifndef PURIFY; der Wartende löschte beide Zeilen.

Das Ergebnis: Der gesamte Zufallszahlenspeicher versagte, die einzige verbleibende "zufällige" Quelle war die Prozess-ID. Und die Standard-Prozess-ID-Obergrenze von Linux beträgt 32.768. Das bedeutet, dass die gesamte Anzahl der SSH-Schlüssel, SSL-Zertifikate und Verschlüsselungsschlüssel, die weltweit mit Debian und seinen Derivaten generiert wurden, nur etwas mehr als 30.000 Möglichkeiten hatte.

Dieser Fehler wurde am 13. Mai 2008 von Luciano Bello entdeckt und blieb etwa 20 Monate lang unbemerkt. In diesen 20 Monaten meldete kein Server einen Fehler, kein Handshake schlug fehl, es gab keine Anzeichen. Alle generierten Schlüssel waren mathematisch, im Format und in der Verwendung identisch mit echten sicheren Schlüsseln.

4.2 Ein 32-Bit-Zeitgeber, sechs Jahre lang still

Diesmal geschah es direkt bei Bitcoin und war der Form des aktuellen Vorfalls am nächsten.

Die Versionen 3.0.0 bis 3.6.0 des Libbitcoin Explorer (Befehlszeilentools bx) verwendeten den Mersenne-Twister-Algorithmus zur Generierung von Seeds - und dieser PRNG verwendete nur einen 32-Bit-Systemzeitgeber als Saat. Bei einer Anfrage nach einem 256-Bit-Seed betrug die tatsächlich erhaltene Entropie nur 32 Bit, etwa 4,3 Milliarden Möglichkeiten, die mit Verbrauchshardware in wenigen Tagen vollständig durchprobiert werden konnten.

Zeitleiste: Eingeführt im Oktober 2016 durch PR#559, veröffentlicht mit 3.0.0 im März 2017, wurde es erst im Mai 2023 ausgenutzt, am 12. Juli fand ein großangelegter koordinierter Diebstahl (ca. 29,65 BTC) statt, am 21. Juli wurde es während der Notfallreaktion entdeckt, am 8. August öffentlich bekannt gegeben, nummeriert als CVE-2023-39910.

Schließlich wurden über 2.600 betroffene Wallets im Bitcoin-Hauptnetz identifiziert, und über 900.000 US-Dollar wurden über mehrere Ketten wie BTC, ETH, XRP, DOGE, SOL, LTC, BCH und ZEC gestohlen.

Bitte beachten Sie zwei Zahlen: Über sechs Jahre latent; auf der Kette gab es keinerlei Sichtbarkeit - vor dem Diebstahl sahen diese Wallets aus wie jede andere normale Wallet.

4.3 Diesmal war das Problem am Ende der Vertrauenskette

Die Mechanismen der drei Vorfälle sind fast identisch: Eine wohlwollende Ingenieuranpassung → Entropiequelle wird stillschweigend ersetzt → langfristig latent → eines Tages wird sie massenhaft geerntet. Aber dieses Mal gibt es drei wesentliche Unterschiede, und jeder geht in eine schlechtere Richtung.

Erstens, der Standort hat sich geändert

Der Vorfall bei Debian ereignete sich auf der Ebene des Betriebssystem-Package-Managements, der Vorfall bei Milk Sad geschah in einem Befehlszeilentool - beide hatten noch "Upstream/Downstream" zu berücksichtigen, und die Benutzer hatten theoretisch andere Optionen. Coldcard hingegen ist ein Gerät, das speziell entwickelt wurde, um Vertrauen zu eliminieren. Der gesamte Wertvorschlag von Hardware-Wallets besteht darin, "kein Vertrauen in irgendeine Softwareumgebung zu haben, sondern in diese spezielle Hardware zu vertrauen". Wenn das Ende der Vertrauenskette selbst ein Problem hat, gibt es keine nächste Stufe auf der Kette, auf die man zurückgreifen kann.

Zweitens, die Expositionszeit ist positiv korreliert mit dem Benutzerverhalten, und zwar umgekehrt

Das Profil der Opfer ist "Personen, die seit 2021 keine Coins mehr bewegt haben" - also die Disziplinärsten, die am besten den Best Practices entsprechen. Je mehr Sie Ihre Coins inaktiv halten, desto länger ist Ihre Expositionszeit, und desto wahrscheinlicher sind Sie auf der Liste. Die Schlüssel von Debian können rotiert werden, SSL-Zertifikate haben von Natur aus eine Gültigkeitsdauer; die Bitcoin-Seeds werden nicht rotiert, einmal generiert, ein Leben lang verwendet.

Drittens, die Entdeckungsmethode hat sich geändert

Der Vorfall bei Debian wurde durch den zufälligen Entdeckungs eines Forschers aufgedeckt, der Vorfall bei Milk Sad wurde durch eine Rückverfolgung nach dem Diebstahl aufgedeckt. Dieses Mal könnte es von einer KI aktiv entdeckt worden sein. Das bedeutet, dass die Entdeckungsrate solcher Fehler strukturell steigt - die gute Nachricht ist, dass bestehende Landminen nach und nach beseitigt werden, die schlechte Nachricht ist, dass die Menschen, die die Minen räumen, und die, die auf sie treten, dieselbe Karte haben.

5. Welche Zahlen können tragen, welche nicht

Nach Stärke in vier Stufen unterteilt, Unternehmensberichte und Drittanbieter-Validierung getrennt.

Erste Stufe · Wirtschaftliche Validierung (bereits geschehene on-chain Fakten, am härtesten)

• Erste koordinierte Säuberung → 1.196 Adressen innerhalb von 41 Minuten geleert; 500 Transaktionen, 594.47722484 BTC | Quelle: coldcardentropy.org Beweisdatenbank, 2026-07-30
• Bis zum 2. August kumuliert → etwa 1.367 BTC, etwa 88,6 Millionen USD, über 4.500 Adressen | Quelle: Galaxy Research Tracking, berichtet von Blockhead, 2026-08-03
• Umfang der Beweisdatenbank → Insgesamt 6.657 einzigartige Quelladressen unter sechs Beweisstufen | Quelle: coldcardentropy.org, 2026-08
• Opferprofil → Konzentriert auf kalte Speicheradressen, die seit 2021 nicht mehr bewegt wurden | Quelle: Kreuzverweise aus mehreren Berichten, 2026-07-31

Zweite Stufe · Unternehmensberichte (technische Ursachen, autoritär, aber müssen quergelesen werden)

• Ursache → random.c (libngu, Zeilen 22-31) wird durch #ifndef MICROPY_HW_ENABLE_RNG geschützt, die Firmware definiert das Makro als 0, #error wurde nicht ausgelöst | Quelle: Coinkite technische Analyse, 2026-07/08
• Zeitpunkt der Einführung → März 2021 libNgU Migration; der Upstream MicroPython-Backup-Code kann bis Mai 2018 zurückverfolgt werden | Quelle: dasselbe
• Entropiewert → Mk2/Mk3 etwa 40 Bit; Mk4/Mk5/Q etwa 72 Bit | Quelle: dasselbe
• Auditblindstelle → Zwei RNG-Implementierungsfunktionssignaturen sind identisch, binäre Überprüfungen können nicht unterscheiden | Quelle: dasselbe
• Reparaturmethode → Explizite Ausschluss des Backup-PRNG-Objekts + RNG-Symbolprüfung zur Build-Zeit, Fehlen führt zu Kompilierungsfehler | Quelle: dasselbe

Dritte Stufe · Schlüsselzahlen mit Meinungsverschiedenheiten (müssen selbst beurteilt werden)

• Der tatsächliche Entropiewert von Mk4/Mk5/Q → Coinkite behauptet etwa 72 Bit, Drittanbieteranalysen behaupten, dass nur etwa 32 Bit in den endgültigen Seed gelangen | Quelle: Coinkite Analyse vs Blockhead, 2026-08-03. Ein Unterschied von vierzig Größenordnungen, der die Dringlichkeit dieser Benutzer direkt bestimmt; bis zur Veröffentlichung gab es keine öffentliche Abstimmung zwischen beiden Parteien.

Vierte Stufe · Meinungen und Spekulationen (am weichsten, tragen nicht)

• Coinkite vermutet, dass der Fehler möglicherweise durch die Überprüfung des Open-Source-Firmware durch ein KI-Modell entdeckt wurde; NVK behauptet, dass die KI-gestützte Überprüfung schneller ist als die erfahrensten menschlichen Experten.
• Unabhängige Forscher glauben, dass Multi-Signaturen, die ausschließlich aus betroffenen Geräten bestehen, weiterhin anfällig sind und eine Mehrheit aus nicht betroffenen Signierern bestehen muss - dies ist die Einschätzung Dritter und nicht die offizielle Position von Coinkite.

Eine Illusion, die beseitigt werden muss

Viele Menschen atmen auf, wenn sie "Die Firmware wurde aktualisiert" lesen. Coinkite selbst sagt es sehr deutlich - das Upgrade der Firmware ändert oder repariert nicht die bereits generierten Seeds. Die Firmware-Version betrifft die zukünftigen Schlüssel, nicht den bereits generierten. Dies ist der Satz, der in diesem Vorfall am häufigsten missverstanden wird und auch der teuerste.

6. Nach Dringlichkeit priorisieren: Wer muss heute handeln

So schön das Thema auch ist, die Sicherheit der Coins der Leser hat Vorrang. Nach Dringlichkeit von hoch nach niedrig.

Erste Kategorie · Sofortige Migration

Bei Mk2/Mk3, mit Firmware-Versionen von 4.0.1 bis 4.1.9 generierte Single-Signature-Seeds, ohne Würfel-Entropie und ohne BIP39-Passphrase. Diese Kategorie ist die, die gerade angegriffen wird. Das Kriterium ist die Firmware-Version, die auf dem Gerät lief, als der Seed generiert wurde, nicht wann das Gerät gekauft wurde.

Zweite Kategorie · So schnell wie möglich migrieren

Bei Mk4/Mk5/Q, Seeds, die vor den jeweiligen Reparaturversionen generiert wurden. Solange die Diskrepanz zwischen 72-Bit und 32-Bit nicht geklärt ist, handeln Sie nach der schlimmsten Annahme - die richtige Vorgehensweise bei solchen Diskrepanzen ist immer, die untere Grenze zu nehmen.

Dritte Kategorie · Wahrscheinlich sicher, aber Überprüfung wert

• Seeds, die anderswo generiert und in Coldcard importiert wurden - Coinkite bestätigt, dass sie nicht von diesem Problem betroffen sind, da sie nicht aus diesem Generator stammen.
• Seeds, die mit mindestens 50 fairen, unabhängigen und niemals aufgezeichneten oder offengelegten Würfel-Entropien generiert wurden - Coinkite sagt, dass sie in Bezug auf dieses Problem nicht betroffen sind.
• TAPSIGNER, OPENDIME, SATSCARD sind nicht betroffen.
• Mk1, Mk2 sind nicht offiziell von Coinkite in den Erklärungsbereich aufgenommen.

Multi-Signatur-Nutzer sollten besonders auf diesen Punkt achten

Multi-Signaturen, die ausschließlich aus betroffenen Geräten bestehen, sind nicht sicher. Multi-Signaturen schützen vor Einzelpunkt-Diebstahl, Einzelpunkt-Ausfall und Einzelpunkt-Erpressung, sie schützen jedoch nicht davor, dass "alle Schlüsselinhaber von demselben defekten Generator stammen". Dies ist die am häufigsten überschätzte Verteidigung in diesem Vorfall - was Sie brauchen, ist eine Mehrheit aus nicht betroffenen Signierern, nicht "Ich habe eine Multi-Signatur, also bin ich in Sicherheit".

Drei Erinnerungen zur Migration selbst

Erstens, Migration ist ein riskanter Schritt. Die Warnung von Bitcoin Well ist sehr treffend: Verluste, die durch hastige Migration entstehen, können schneller eintreten als das Problem, dem Sie entkommen möchten. Fehler beim Kopieren von Backups, das Überprüfen der Empfangsadresse auf dem Gerätescreen - diese Fehler verschwinden nicht, nur weil Ihre neue Seed-Entropie perfekt ist. Die richtige Reihenfolge ist: Installieren Sie die verifizierte Reparatur-Firmware → Generieren Sie einen neuen Seed → Notieren und Überprüfen Sie das Backup → Überprüfen Sie die Empfangsadresse auf dem Gerätescreen → Senden Sie zuerst eine kleine Testüberweisung → Bestätigen Sie den Eingang, bevor Sie das Guthaben migrieren → Zerstören Sie das alte Backup nicht, bevor das gesamte Guthaben bestätigt ist.

Zweitens, berühren Sie keinen "Seed-Wiederherstellungsdienst". Nach solchen Vorfällen tauchen immer Betrüger auf, die behaupten, Ihnen bei der Wiederherstellung Ihrer Vermögenswerte zu helfen; sie wollen nur eines.

Drittens, Sie können die Adresse mit der lokalen Abfrage von coldcardentropy.org überprüfen - es wird klar angegeben, dass die Abfrage lokal im Browser erfolgt, nicht hochgeladen oder aufgezeichnet wird, und nur öffentliche Adressen eingegeben werden; geben Sie niemals Mnemonics, private Schlüssel, Passphrase, PIN oder Wallet-Exportdateien ein. Aber denken Sie daran, dass die Website ihren eigenen Haftungsausschluss hat: Nicht getroffen bedeutet nicht sicher.

7. Wer trägt die Kosten dieses Vorfalls

Erstens, das Risiko wurde von "Benutzeraktionen" auf "Herstellerproduktionslinien" übertragen, aber die Verantwortung wurde nicht übertragen.

Alle Variablen, die der Benutzer kontrollieren kann - Aufbewahrung, Backup, Offline, Disziplin - sind in diesem Vorfall vollständig ausgefallen. Die Variablen, die über Leben und Tod entscheiden, sind Dinge, die ein Benutzer nicht beobachten oder überprüfen kann: der Wert eines Makros, das der Hersteller beim Kompilieren verwendet hat. Und in der Erzählung der Selbstverwahrung trägt der Benutzer die Verluste selbst: keine Einlagensicherung, kein Kundenservice, kein Rollback. Selbstverwahrung gibt Ihnen die Kontrolle über die Vermögenswerte, bringt aber auch einige Risiken mit sich, die Sie nicht kontrollieren können.

Zweitens, das Etikett "Open Source und auditierbar" wurde neu bewertet.

Der Wert von Open Source ist real, aber dieser Vorfall hat eine klare Grenze gezogen: Open Source garantiert, dass "der Code angesehen werden kann", garantiert jedoch nicht, dass "es jemanden gibt, der schaut". Wenn der Fehler in der Build-Konfiguration oder in der Symbolauflösung von zwei gleichnamigen Funktionen steckt, kann die Standardaktion der Community-Überprüfung nicht auf dieser Ebene abgedeckt werden. Wenn Sie in Zukunft "Open Source, reproduzierbare Builds" als Sicherheitsmerkmal sehen, sollten Sie eine zusätzliche Frage stellen: Wer überprüft die Symbolauflösung? Gibt es Assertions in der Build-Phase?

Drittens, die Kosten wurden auf die diszipliniertesten Personen übertragen.

Das ist der schmerzhafteste Teil dieses Vorfalls. Personen, die häufig handeln, oft die Wallet wechseln oder ihre Coins an Börsen aufbewahren, haben es geschafft, während diejenigen, die 2021 einmal generiert und fünf Jahre lang nicht berührt haben, genau auf der Liste stehen. Wenn die Dauer der Risikoexposition positiv mit der Haltedauer korreliert, wird der langfristige Ansatz selbst zu einem Risikofaktor. Das ist kein moralisches Problem, sondern ein strukturelles Problem - aber es wird tatsächlich die Sichtweise einiger Menschen auf "Cold Storage" verändern.

Viertens, dies ist kein Einzelfall, sondern eine sich abzeichnende Trendlinie.

Wenn man sich die Vorfälle im Juli 2026 ansieht: etwa 200 Millionen Dollar, 34 Vorfälle. Darunter AFX Trade 24,15 Millionen (Validator-Schlüssel), Ostium 18 Millionen (Orakel-Signierer-Schlüssel), Triple-A 11,8 Millionen (Hot Wallet), WEMIX 6,25 Millionen (Owner Key) - alles Schlüssel und Berechtigungen; während traditionelle Vertragsfehler nur Wanchain 10 Millionen, Bonzo Lend 9,05 Millionen, Verus Bridge 7,54 Millionen ausmachten. Blockaid berichtet, dass im ersten Halbjahr 2026 über 1 Milliarde Dollar in Krypto-Projekten gestohlen wurden. Die Angriffsfläche hat sich strukturell von "Fehler im Vertrag" zu "Probleme mit der Herkunft, Aufbewahrung und Autorisierung von Schlüsseln" verschoben. Und die Entropie-Kollaps ist die extreme Form dieser Trendlinie: Es sind nicht die Schlüssel, die gestohlen wurden, sondern die Schlüssel wurden nie wirklich zufällig generiert.

8. Ein gerechtes Wort für Coinkite

Lassen Sie uns das stärkste Argument vollständig darlegen.

Das stärkste Gegenargument: Dies ist ein kontrolliertes, klar abgegrenztes Ingenieurproblem, das nicht ausreicht, um die Schlussfolgerung "Selbstverwahrungsrisiken im Generierungsprozess" zu stützen.

Die Grenzen des Fehlers sind sehr klar - spezifischer Hersteller, spezifisches Modell, spezifischer Firmware-Bereich; Benutzer, die Würfel-Entropie oder Passphrase verwenden, sind nicht betroffen; importierte Seeds sind nicht betroffen; Coinkite hat am Tag des Vorfalls anerkannt, am nächsten Tag die Reparatur-Firmware veröffentlicht und eine vollständige technische Analyse veröffentlicht, die in der Branche als überdurchschnittlich gilt. Noch wichtiger ist, dass dies genau beweist, dass das Open-Source-Ökosystem funktioniert: Der Fehler wurde entdeckt, offengelegt und behoben, der gesamte Prozess ist öffentlich einsehbar. Und 88,6 Millionen Dollar sind im Vergleich zur Gesamtmarktkapitalisierung von Bitcoin oder sogar zu den über 1 Milliarde Dollar, die im ersten Halbjahr 2026 gestohlen wurden, nicht viel. Was Mk4/Mk5/Q betrifft, so sind 72-Bit in absehbarer Zukunft sicher, die überwiegende Mehrheit der Benutzer befindet sich tatsächlich nicht in der Gefahrenzone.

Wie ich darüber denke

Ich erkenne jede Tatsache dieses Gegenarguments an, und ich halte die Geschwindigkeit der Reaktion für lobenswert - in dieser Branche sind nur wenige Hersteller bereit, am selben Tag zuzugeben, am nächsten Tag zu reparieren und die vollständige Ursache offenzulegen.

Aber es umgeht die eigentliche Aussage: Das Problem ist nicht "Wie groß ist dieser Verlust", sondern "Haben wir eine Möglichkeit, zu wissen, dass es existiert, bevor der nächste Verlust eintritt?".

Debian war 20 Monate still, Milk Sad 6 Jahre, Coldcard 5 Jahre. In drei Vorfällen wurde keiner von "Überwachung entdeckt Anomalien" gefunden - zwei wurden durch zufälliges Durchsehen des Codes entdeckt, einer durch Rückverfolgung nach einem Diebstahl, und dieser könnte durch KI-Scanning entdeckt werden. Während der gesamten Stille waren alle Instrumententafeln grün. Das ist kein Glücksproblem, sondern ein Designproblem, das diese Annahmen unbeobachtbar macht: Ein Seed mit unzureichender Entropie sieht auf der Blockchain, auf dem Gerät und in jeder Überwachung genau wie ein perfekter Seed aus.

Deshalb ist mein Fazit nicht "Hardware-Wallets sind unbrauchbar" - im Gegenteil, Hardware-Wallets sind nach wie vor die vernünftigste Wahl für die meisten Menschen, und ich habe nicht vor, irgendjemanden zu Börsen zu drängen. Mein Fazit ist eine strukturelle Einschätzung:

Die Sicherheit eines Systems hängt von der schwächsten Annahme ab; und die Verwaltbarkeit eines Systems hängt davon ab, wie viele dieser Annahmen beobachtbar sind. Die Krypto-Welt hat in den letzten zehn Jahren enorme Anstrengungen unternommen, um "Angriffe schwieriger zu machen", aber kaum etwas in die Richtung investiert, "zu entdecken, wenn Annahmen fehlschlagen". Der Entropie-Kollaps ist nur das erste ausreichend teure Beispiel in dieser Lücke, das so teuer ist, dass man es nicht ignorieren kann.

Betrugsüberprüfung (das Erklären des Mechanismus bedeutet nicht, dass man ihn unterstützt, dieser Abschnitt muss geschrieben werden)

Coinkite ist ein seit vielen Jahren bestehendes kanadisches Unternehmen, der Gründer NVK ist namentlich bekannt und aktiv, die Produkte sind Open Source, mit einem öffentlichen Code-Repository und reproduzierbaren Builds. Am Tag des Vorfalls wurde anerkannt, am nächsten Tag wurde die Reparatur-Firmware veröffentlicht, und eine technische Analyse wurde bis auf Datei- und Zeilennummer veröffentlicht. Hier gibt es keine Probleme mit dem Verschwinden, anonymen Teams oder böswilligen Hintertüren - im Gegenteil, gerade weil es sich um eines der transparentesten Unternehmen in dieser Branche handelt, sollte dieser Vorfall von allen ernst genommen werden: Wenn solche Ingenieurpraktiken fünf Jahre still bleiben können, wird es bei Herstellern, die nicht Open Source sind, keine reproduzierbaren Builds haben und keine Ursachen offenlegen, nur schlimmer werden, und Sie werden es niemals wissen.

Es ist wichtig, die Leser auf die sekundären Risiken von Vorfällen hinzuweisen: Jeder, der Sie aktiv kontaktiert und behauptet, Ihnen bei der Überprüfung oder Wiederherstellung von Vermögenswerten helfen zu können, und der Sie auffordert, Ihre Seed-Phrase oder Wallet-Dateien bereitzustellen, ist ein Betrüger. Die größte Chance, die dieser Vorfall geschaffen hat, liegt nicht auf der Blockchain, sondern im Social Engineering.

9. Fünf Fragen, die Sie jedem System stellen sollten, dem Sie Vermögenswerte anvertrauen

Das ist das, was in dieser Ausgabe wirklich geliefert werden soll. Verdichten Sie die Fragestellung auf fünf Fragen und stellen Sie diese jedem System, dem Sie Vermögenswerte anvertrauen wollen - Wallets, Bridges, Oracles, Custodians, Stablecoins, L2, Multisig-Lösungen.

Erste Frage: Woher kommt die Zufälligkeit? Gibt es Beweise, dass sie tatsächlich aufgerufen wurde?

Fragen Sie nicht: "Brauchen wir Hardware-Zufallszahlen?", sondern fragen Sie: "Was passiert, wenn die Hardware-Zufallszahlen nicht aufgerufen wurden?" Die richtige Antwort kann nur eine sein: Kompilierungsfehler oder Startfehler. Jedes Design, das "stillschweigend auf die Software-Implementierung zurückfällt", wartet auf einen Morgen in fünf Jahren. Kriterium: Gibt es zur Bau- oder Laufzeit Behauptungen, und nicht nur Kommentare und Dokumentationsversprechen.

Zweite Frage: Ist der Quellcode korrekt, ist das kompilierte Binärfile dann auch korrekt?

Reproduzierbare Builds beweisen, dass "alle das Gleiche gebaut haben", beweisen jedoch nicht, dass "das Gebaute korrekt ist". Der Fehler dieser Ausgabe liegt genau in dieser Lücke. Kriterium: Gibt es neben reproduzierbaren Builds auch symbolische Überprüfungen - d.h. die Überprüfung, auf welche Implementierung die Schlüssel-Funktionen letztendlich aufgelöst wurden? Besonders vorsichtig sein sollten Sie, wenn zwei Implementierungen dieselbe Funktionssignatur verwenden: Das ist ein natürlicher blinder Fleck bei Audits.

Dritte Frage: Gibt es Werte, die dynamisch abgerufen werden sollten, aber fest codiert sind?

Entropiequellen sind eine Kategorie, eine andere sind hartkodierte Konstanten. In der letzten Ausgabe haben wir im Stablecoin-Vorfall gesehen, dass "Oracles den Preis auf $1,00 hart codiert haben", und in diesem Fall "auf eine feste Formel für Zufallszahlen zurückgegriffen wurde" - das ist dieselbe Krankheit: Eine Größe, die den externen realen Zustand widerspiegeln sollte, wurde durch eine unveränderliche Größe ersetzt, und das System meldet keinen Fehler. Kriterium: Listen Sie alle Werte im System auf, die "sich ändern sollten, aber die Sie noch nie gesehen haben, dass sie sich ändern", und fragen Sie einzeln, warum.

Vierte Frage: Wer kann unterschreiben? Hat sich diese Menge stillschweigend geändert?

Die Menge der Unterzeichner, Administratorrechte, Upgrade-Schlüssel - diese Änderungen führen oft nicht zu sichtbaren Ereignissen für die Benutzer. In den Vorfällen im Juli sind AFX Trade, Ostium und WEMIX alle an dieser Ebene gescheitert. Kriterium: Gab es Änderungen mit On-Chain-Ereignissen, gibt es Zeitverriegelungen, gibt es Dritte, die die aktuelle Menge unabhängig überprüfen können?

Fünfte Frage (Meta-Frage, die wichtigste): Wird das System mir sagen, wenn diese Annahme falsch ist? Wenn nicht, wie lange ist es schon falsch, und kann ich das herausfinden?

Überprüfen Sie die Antworten auf die ersten vier Fragen erneut durch dieses Sieb. Sichtbare Risiken sind Ingenieurprobleme, nicht sichtbare Risiken sind Existenzprobleme. Erstere können durch Überwachung und Reaktionsmanagement angegangen werden, letztere können nur in der Entwurfsphase in beobachtbare Größen umgewandelt werden - nachträglich gibt es keine Abhilfemaßnahmen.

Der Kern dieses Rahmens ist ein Perspektivwechsel: Stellen Sie die Frage der Sicherheitsprüfung von "Gibt es Schwachstellen im Code?" um in "Welche Annahmen sind falsch, wenn das System nicht alarmiert?" Die erste Frage hat unendlich viele Antworten, die niemals vollständig überprüft werden können; die zweite Frage hat normalerweise nicht mehr als zehn Antworten, und nachdem sie niedergeschrieben wurde, kann jede in eine Behauptung umgewandelt werden.

10. Wo könnte ich falsch liegen

"Eigentlich nicht neu" Argumentation

"Schwache Zufallszahlen führen zur Kompromittierung von Schlüsseln" ist ein klassisches Thema in der kryptographischen Ingenieurwissenschaft, das sowohl in Debian als auch in Milk Sad in Fallstudien behandelt wurde. Wenn diese Ausgabe nur bis zu diesem Punkt geht, sollte sie durch den "Ich wusste es schon" Test direkt ausgeschlossen werden. Die Zuwächse liegen an drei Stellen, die die Leser zur Beurteilung der Angemessenheit heranziehen können: Erstens ist die Nichtbeobachtbarkeit eine unabhängige Dimension - nicht "wird es Fehler geben?", sondern "wenn es Fehler gibt, wird es ein Signal geben?", diese Dimension fehlt in den gängigen Sicherheitsdiskussionen; zweitens die Grenzen reproduzierbarer Builds - sie beweisen Konsistenz, nicht Korrektheit, und zusammen mit gleichnamigen Funktionen führt dies zu symbolischen blinden Flecken, was selbst viele Sicherheitspraktiker als selbstverständlich ansehen; drittens die gegenintuitive Schlussfolgerung, dass die Expositionszeit mit der Haltedauer korreliert, die direkt die Intuition "je länger die kalte Lagerung, desto sicherer" umkehrt. Wenn Sie sich über diese drei Punkte bereits im Klaren sind, ist diese Ausgabe für Sie tatsächlich nicht relevant.

Das stärkste alternative Paradigma

Vielleicht habe ich die Kausalität umgekehrt: Die echte Lektion ist nicht "Vertrauen auf Annahmen ist nicht beobachtbar", sondern "Setzen Sie nicht die Sicherheit von 128 Bit auf eine einzige Implementierung". Aus dieser Perspektive ist die Antwort nicht Beobachtbarkeit, sondern Redundanz - verwenden Sie Entropie von zwei unabhängigen Quellen, verwenden Sie Multisignaturen mit Geräten verschiedener Hersteller, verwenden Sie eigene Würfel-Entropie. Wenn die zukünftigen Branchenlösungen hauptsächlich in Richtung Redundanz und nicht in Richtung Beobachtbarkeit **evolutionieren, dann habe ich den Schwerpunkt dieses Rahmens falsch gesetzt. Das ist der wahrscheinlichste Weg, um diese These zu widerlegen.

Drei Jahre später: Rückblick auf die wahrscheinlichsten Todesursachen

KI-unterstützte Audits werden in zwei Jahren eine große Anzahl dieser Arten von Mängeln beseitigen, Entropie-Kollaps wird ein historischer Begriff, und "nicht beobachtbare Vertrauensannahmen" werden sich als ein selbstauflösendes Problem erweisen - Fortschritte bei den Werkzeugen machen es direkt beobachtbar. Die Wahrscheinlichkeit ist nicht gering. Mein Argument ist: Während die Geschwindigkeit der Mängelbeseitigung steigt, steigt auch die Geschwindigkeit, mit der Angreifer scannen, und sie haben keine Offenlegungspflicht. Ob der Nettoeffekt gut oder schlecht ist, ist jetzt zu früh, um ein Urteil zu fällen.

Welche aktuellen Daten könnten falscher Glanz sein

Zwei. Erstens "Die beobachtete Säuberung konzentriert sich auf Mk3-Einzelunterschrift" - das spiegelt wahrscheinlich nur die Kostenreihenfolge der Angreifer wider und nicht die tatsächlichen Sicherheitsmargen von Mk4/Mk5/Q. Es ist gefährlich, dies als Beweis dafür zu betrachten, dass "neue Modelle in Ordnung sind". Zweitens die Zahl von 88,6 Millionen Dollar - sie zählt nur das, was bereits abgezogen wurde, nicht das, was bereits exponiert wurde; die 6.657 einzigartigen Quelladressen, die auf coldcardentropy.org registriert sind, und die Differenz zu den endgültigen Verlusten repräsentieren den Bestand, der noch nicht geerntet wurde, nicht den sicheren Bestand.

11. Nach zwölf Monaten zurückkommen und abgleichen

Fallen Sie in das Vorhersagebuch. Vorhersagen Sie nicht die Preise, sondern das strukturelle Verhalten.

Kernprognose (12 Monate)

In den nächsten 12 Monaten wird es beobachtbare strukturelle Veränderungen in der Branche im Umgang mit "Entropie und Schlüsselerzeugung" geben - mindestens ein führender Hardware-Wallet-Hersteller wird öffentlich Entropiequellen für die Bau- oder Laufzeit einführen (und nicht nur versprechen, Hardware-RNG zu verwenden), und es wird mindestens einen weiteren Fall von kryptographischen Mängeln geben, die seit mehr als drei Jahren latent sind und durch KI-unterstützte Audits entdeckt werden (unabhängig davon, ob Verluste entstanden sind oder nicht). Gleichzeitig werden die bedeutenden Vorfälle im Jahr 2026 weiterhin auf der Ebene von Schlüsseln/Berechtigungen/Erzeugung liegen und nicht auf der Ebene der Vertragslogik.

3-Monats-Beobachtungsindikatoren (bis 2026-11)

• Ob die endgültigen Verluste des Coldcard-Vorfalls auf dem Niveau von 1.400 BTC stagnieren oder sich weiter auf die 6.657 Adressen ausweiten, die auf coldcardentropy.org registriert sind.
• Ob Coinkite und Dritte öffentlich über die 72-Bit/32-Bit-Diskrepanz von Mk4/Mk5/Q abgleichen.
• Ob andere Hardware-Wallet-Hersteller Selbstprüfungsberichte veröffentlichen und ob die Berichte besagen, dass "wir Hardware-RNG verwendet haben" oder "wir haben Bauzeitbehauptungen hinzugefügt" - der Unterschied in der Formulierung ist die erste Frage dieses Rahmens.
• Ob es zu großangelegten Social Engineering-Betrügereien gegen die Opfer dieses Vorfalls kommt.

6-Monats-Beobachtungsindikatoren (bis 2027-02)

• Ob Hersteller Entropiequellenbehauptungen und symbolische Überprüfungen in öffentliche Bauprozesse oder Auditberichte aufnehmen.
• Ob Multisignaturanbieter beginnen, klar zu verlangen, dass "Unterzeichner von verschiedenen Herstellern / unterschiedlichen Entropiequellen stammen".
• Ob es erneut zu einem latent bestehenden Mangel in der Entropie oder Schlüsselerzeugung kommt, der länger als drei Jahre besteht.

12-Monats-Beobachtungsindikatoren (bis 2027-08)

• Ob die Anzahl der historischen Mängel, die durch KI-unterstützte Audits entdeckt wurden, signifikant ansteigt und ob die Offenleger Forscher oder Angreifer sind.
• Ob der Anteil der Schlüssel/Berechtigungen/Erzeugungsebene in den Unfallstatistiken weiterhin höher ist als der der Vertragslogikebene.
• Ob es Anforderungen an die "Überprüfbarkeit von Entropiequellen" auf der Ebene von Regulierungs- oder Branchenstandards gibt.

Falsifizierungsbedingungen (ich schreibe es fest, ich übernehme die Verantwortung)

1. Wenn in den nächsten 12 Monaten die Reaktionen der führenden Hersteller allgemein auf "Ändern der RNG-Implementierung / Verstärkung der Codeüberprüfung" beschränkt bleiben, ohne dass ein Hersteller öffentlich überprüfbare Bau- oder Laufzeitbehauptungen einführt → zeigt, dass "Beobachtbarkeit" nicht die Lösung ist, die in der Branche tatsächlich angenommen wird, der Schwerpunkt dieses Rahmens falsch gesetzt wurde und der praktische Wert der These überschätzt wurde;
2. Wenn die bedeutenden Vorfälle in den nächsten 12 Monaten erneut auf Vertragslogikfehler zurückzuführen sind (mit einem Anteil, der den der Schlüssel- und Berechtigungsstufen übersteigt) → zeigt, dass die Stichprobe aus dem Juli nur kurzfristiger Lärm war und die Richtung der Beurteilung "strukturelle Verschiebung der Angriffsfläche" falsch ist;
3. Wenn die Kontroversen um Mk4/Mk5/Q letztendlich als 32-Bit bestätigt werden und großflächig gefegt werden, während ich in dem Artikel die Dringlichkeit als geringer als Mk3 beurteile → habe ich bei der entscheidendsten praktischen Beurteilung einen Fehler gemacht, und selbst wenn die These selbst gültig ist, muss ich öffentlich korrigieren.

Haftungsausschluss

Dieser Artikel prognostiziert keine Preise für Vermögenswerte und stellt keine Anlage- oder Handelsberatung dar. Die in diesem Artikel genannten spezifischen Hersteller und Produkte dienen nur zur Veranschaulichung technischer Mechanismen und Risikostrukturen und stellen keine kommerzielle Bewertung oder Empfehlung dar, noch bedeutet es, dass andere Produkte als sicherer angesehen werden. Die in diesem Artikel beschriebenen Migrationen sind öffentliche Informationszusammenstellungen und stellen keine personalisierte Sicherheitsberatung dar; alle Operationen, die private Schlüssel und Seed-Phrasen betreffen, können zu irreversiblen Vermögensverlusten führen, bitte befolgen Sie die offiziellen Anleitungen der Hersteller und tragen Sie selbst die Verantwortung für Ihre Entscheidungen. Jeder, der Sie nach Ihrer Seed-Phrase, Ihrem privaten Schlüssel, Ihrer Passphrase oder Ihren Wallet-Exportdateien fragt, ist ein Betrüger.

Daten und Quellen

Alle Daten wurden im August 2026 überprüft, die Aussagen der Hersteller und die Berichterstattung Dritter sind entsprechend gekennzeichnet.

Herstellerangaben (Ersthand)

【Zusammenfassung (reiner Text, kann leer sein)】：

• Technischer Tiefgang in das Entropieproblem, Coinkite offizieller Blog --- random.c (libngu Zeilen 22--31) #ifndef MICROPY_HW_ENABLE_RNG Wächterfehler, Makro auf 0 definiert, Migration von libNgU im März 2021 eingeführt, Upstream MicroPython Rückfallcode bis Mai 2018 zurückverfolgbar, Mk2/Mk3 etwa 40 Bit, Mk4/Mk5/Q etwa 72 Bit, zwei RNG Implementierungsfunktionssignaturen identisch, Reparaturmethode durch Ausschluss der Rückfallobjekte + symbolische Überprüfung zur Bauzeit: https://blog.coinkite.com/entropy-technical-backgrounder/
• Betroffene und reparierte Versionen: Mk2/Mk3 4.0.1--4.1.9 (Reparatur 4.2.0), Mk4/Mk5 < 5.6.0 (Edge < 6.6.0X), Q < 1.5.0Q (Edge < 6.6.0QX); "Firmware-Upgrade ändert oder repariert nicht die bereits generierten Seeds": siehe oben und Coinkite-Ankündigung, 31.07.2026

Dritte Berichterstattung und Beweisführung

• COLDCARD Entropievorfall --- Adressprüfung und Beweise --- sechs Beweisstufen, 6.657 einzigartige Quelladressen, erste Welle 500 Transaktionen 594.47722484 BTC, lokale Browserabfragen werden nicht hochgeladen, "Nicht getroffen bedeutet nicht sicher": https://coldcardentropy.org/
• Ein fünf Jahre alter Coldcard-Bug ließ Hacker Bitcoin-Wallet-Schlüssel erraten, bestätigt Coinkite, Blockhead, 03.08.2026 --- bis zum 2. August etwa 1.367 BTC / etwa 88,6 Millionen USD / über 4.500 Adressen, Galaxy Research verfolgt; Dritte Analyse behauptet, Mk4/Mk5/Q hätten nur etwa 32 Bit in den endgültigen Seed erreicht: https://www.blockhead.co/2026/08/03/coldcard-hardware-wallets-shipped-with-broken-randomness-for-five-years-coinkite-confirms/
• Coinkite veröffentlicht reparierte Firmware nach Coldcard-Bug; KI wahrscheinlich an dem Vorfall beteiligt, Bitcoin Magazine, 31.07.2026 --- reparierte Firmware-Version, NVK über KI-unterstützte Überprüfung, innerhalb von 24 Stunden über 70 Millionen USD: https://bitcoinmagazine.com/business/coinkite-releases-fixed-firmware-after-coldcard-bug-ai-likely-involved-in-the-hack
• Coldcard Hardware Wallet Fehler verbunden mit 70 Millionen USD Bitcoin Diebstahl in 41 Minuten, The Hacker News, August 2026 --- 1.196 Adressen in 41 Minuten: https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
• COLDCARD Verwundbarkeit: Was Besitzer wissen müssen, Bitcoin Well --- Betroffene werden anhand der Firmware-Version zum Zeitpunkt der Seed-Generierung bestimmt, Import von Seeds und 50 Würfelentropie als Ausnahme, TAPSIGNER/OPENDIME/SATSCARD nicht betroffen, alle aus betroffenen Geräten bestehenden Multisigs bleiben anfällig (Dritte Forschung), Migrationsschritte und Warnung, dass "eilige Migration ein höheres Risiko birgt": https://bitcoinwell.com/coldcard-vulnerability

Historische Präzedenzfälle

• Zufallszahl-Bug in Debian Linux, Schneier on Security, Mai 2008 --- md_rand.c zwei Zeilen MD_Update wurden gelöscht, /* purify complains */ Kommentar, im September 2006 eingeführt, am 13. Mai 2008 von Luciano Bello entdeckt, einzige Zufallsquelle degeneriert zu Prozess-ID, Linux Standardobergrenze 32.768: https://www.schneier.com/blog/archives/2008/05/random_number_b.html
• Milk Sad vollständige Offenlegung (CVE-2023-39910), milksad.info --- Libbitcoin Explorer 3.0.0--3.6.0, bx seed verwendet Mersenne-Twister + 32-Bit-Uhrensaat, im Oktober 2016 durch PR#559 eingeführt, im März 2017 mit 3.0.0 veröffentlicht, ab Mai 2023 ausgenutzt, am 12. Juli 2023 etwa 29,65 BTC gestohlen, am 21. Juli 2023 entdeckt, am 8. August 2023 offengelegt, über 2.600 Wallets im Hauptnetz, über 900.000 USD Verlust über mehrere Ketten, sechs Jahre latent und keine Sichtbarkeit on-chain: https://milksad.info/disclosure.html

Trendbeweise (Vorfälle im Juli 2026)

• Juli 2026 Krypto-Hacks: Fast 200 Millionen USD verloren über Wallets, DeFi und Brücken --- im gesamten Monat etwa 200 Millionen USD, 34 Vorfälle; AFX Trade 24,15 Millionen USD (Validator-Schlüssel), Ostium 18 Millionen USD (Orakel-Signatur-Schlüssel), Triple-A 11,8 Millionen USD (Hot Wallet), WEMIX 6,25 Millionen USD (Besitzer-Schlüssel), Wanchain 10 Millionen USD, Bonzo Lend 9,05 Millionen USD, Verus Bridge 7,54 Millionen USD: https://cryip.co/july-2026-crypto-hacks-nearly-200m-lost-wallets-defi-bridges/
• Blockaid: Über 1 Milliarde USD in Krypto-Projekten im ersten Halbjahr 2026 gestohlen, zitiert von Cryptoticker Wochenbericht, August 2026: https://cryptoticker.io/en/crypto-news-today-weekly-wrap-august-2026/