Collasso dell'entropia: la tua chiave privata potrebbe non essere stata casuale sin dal giorno della sua nascita

Questo articolo era originariamente accessibile solo ai membri della colonna di Zhihu "Riferimenti alle criptovalute", ora lo pubblico permanentemente.

Poiché questa questione ha una certa urgenza ------ gli indirizzi interessati stanno venendo ripuliti in massa, ogni giorno che passa aumenta l'esposizione. Nasconderlo dietro un muro di pagamento non giova a nessuno.

Ti prego di leggerlo tutto, controlla la sezione 6 per confermare se sei nella lista e inoltra a chiunque possa essere colpito.

------------Di seguito il testo------------

41 minuti, 1.196 indirizzi svuotati. La caratteristica comune delle vittime è: non hanno mai mosso monete dopo il 2021. Tutto ciò che hai fatto per l'autogestione ------ backup offline, backup frammentato, Passphrase, multi-firma ------ protegge l'intera vita di questa chiave; ma nessuno è tornato a controllare la sua nascita. E il luogo di nascita della chiave non lascia alcuna traccia: il collasso dell'entropia è completamente inobservabile sulla catena, potrebbe essere stato vero per cinque anni, e oggi non puoi scoprirlo.

1. Quei 41 minuti

Il 30 luglio 2026, sulla blockchain di Bitcoin è apparsa una serie di transazioni molto strane.

La stranezza non risiede nell'importo, ma nel ritmo e negli obiettivi. In 41 minuti, 1.196 indirizzi sono stati svuotati. Questi indirizzi non hanno alcuna connessione tra loro, sono sparsi in diversi anni, paesi e abitudini d'uso. L'unico punto in comune è: la maggior parte dei loro proprietari non ha mai mosso queste monete dopo il 2021. Conservazione a freddo, detenzione a lungo termine, disciplina da manuale.

Entro il 2 agosto, il numero tracciato da Galaxy Research è: circa 1.367 Bitcoin, circa 88,6 milioni di dollari, oltre 4.500 indirizzi. E il sito di raccolta prove pubbliche creato successivamente, coldcardentropy.org, ha registrato un totale di 6.657 indirizzi unici sotto sei livelli di evidenza ------ di cui il primo gruppo di pulizia coordinata è stato di 500 transazioni, 594.47722484 BTC, preciso fino all'ottava cifra decimale.

Il giorno stesso, Coinkite ha ammesso la causa: il loro portafoglio hardware Coldcard, dal marzo 2021, ha continuato a generare chiavi private in modo errato.

Questa frase richiede una pausa per comprenderne il peso. Non è che il portafoglio sia stato hackerato, non è che le parole di recupero siano state divulgate, non è che qualcuno abbia ottenuto il dispositivo. È che ogni giorno di normale funzionamento di questi portafogli, ogni chiave generata, è stata più debole di decine di ordini di grandezza rispetto a come avrebbe dovuto essere. E questa situazione è stata vera dal marzo 2021, e fino al 30 luglio 2026, nessuno, nessun dato sulla catena, nessun dispositivo ha potuto dirti che era vero.

La maggior parte delle persone ------ compresi molti veterani che considerano l'autogestione una fede ------ comprende il rischio dell'autogestione in questo modo: la chiave privata è nelle tue mani, quindi il rischio è nelle tue mani; finché non divulghi le parole di recupero, non sei vittima di phishing, non cambi dispositivo, non sei minacciato con un attrezzo, le monete sono al sicuro. Tutte le fortificazioni sono costruite su questo passaggio di "custodia".

Credo sia più accurato dire che il punto più vulnerabile dell'autogestione non è la custodia, ma la generazione ------ nel momento in cui quella chiave è nata. E a differenza del rischio di custodia, il rischio di generazione è una "ipotesi di fiducia con dimensione temporale": potrebbe essere stata falsa in un certo momento passato, e in qualsiasi momento successivo, non puoi scoprirlo attraverso l'osservazione. Più freddo è il tuo portafoglio, più lungo è il periodo di esposizione.

2. Il certificato di nascita della chiave

Iniziamo a gettare via tutti i termini tecnici.

Le tue parole di recupero sono essenzialmente una serie di numeri casuali. La parola "casuale" porta con sé tutta la sicurezza ------ perché lo spazio delle chiavi private di Bitcoin è così vasto che non ha confini, la sicurezza non deriva da alcuna serratura, nessuna password, ma da una sola cosa: nessuno può indovinare quella serie di numeri.

Da dove proviene questa serie di numeri casuali? Nei portafogli hardware c'è un chip speciale che genera numeri casuali veri ------ rumore termico, fluttuazioni nei circuiti, l'incertezza del mondo fisico stesso. Genera 128 bit di casualità, il che significa che ci sono 2 elevato alla 128 possibilità, più degli atomi nell'universo. Ecco perché puoi mettere in sicurezza le tue monete su un foglio di carta con 24 parole scritte.

E l'incidente di quest'anno è: a causa di un errore nella scrittura di un interruttore di compilazione, quel chip di rumore fisico non è stato affatto attivato. Il dispositivo è tornato a utilizzare un generatore di numeri pseudo-casuali in un software ------ qualcosa che sembra casuale ma che può essere completamente ricalcolato. Il risultato è che i modelli Mk2/Mk3 hanno prodotto solo circa 40 bit di casualità effettiva.

Quarant'anni sono pochi? Circa un trilione di possibilità. Sembra molto, ma per un computer normale disposto a lavorare per qualche giorno, un trilione è una questione di un pomeriggio.

Facciamo un esempio

Hai comprato una cassaforte di alta qualità, il produttore promette che il cilindro della serratura ha 128 combinazioni. La metti nel seminterrato, saldandola al muro, e dividi la chiave in tre parti seppellendole in tre città. Cinque anni passano, la cassaforte non è mai stata forzata, le saldature sono intatte, le tre chiavi sono tutte presenti. Poi un giorno apri il seminterrato e la cassaforte è vuota.

Il motivo è: c'era un interruttore impostato male sulla linea di produzione del produttore, il cilindro della serratura della tua cassaforte ha effettivamente solo 40 combinazioni. La cassaforte non è stata forzata ------ è stata aperta con una chiave duplicata. E fin dal primo giorno di produzione, questa cosa è stata vera. Tutte le protezioni che hai fatto in questi cinque anni ------ saldature, frammentazione, localizzazione ------ proteggevano la possibilità che la cassaforte fosse forzata, mentre questa cassaforte non ha mai avuto bisogno di essere forzata.

Un aspetto più problematico è: non ci sono segnali di avvertimento. La cassaforte non emette suoni, la serratura non si allenta, non puoi notare alcuna anomalia anche se controlli ogni anno. L'unico momento in cui puoi sapere è quando viene aperta.

Questo è il nucleo di questo numero: siamo abituati a controllare l'intera vita di una chiave, ma non siamo mai tornati a controllare la sua nascita. E il luogo di nascita non lascia tracce.

3. Prezzo di --

   --

   Cinque anni causati da un #ifndef

3.1 Un fusibile montato al contrario

Nel marzo 2021, Coldcard ha effettuato una migrazione di base ------ spostando i calcoli crittografici all'affidabile ecosistema core di Bitcoin, introducendo anche la propria libreria libNgU. Questo è stato un miglioramento della qualità, con motivazioni del tutto legittime.

Il problema è sorto con un pezzo di codice di protezione introdotto durante questa migrazione. Nel file random.c (libngu, righe 22-31), lo sviluppatore ha scritto una protezione: se il generatore di numeri casuali hardware non è attivato durante la compilazione, restituisci un errore e interrompi la compilazione. Questa protezione utilizza le direttive di precompilazione del linguaggio C:

#ifndef MICROPY_HW_ENABLE_RNG

#error "È necessario un generatore di numeri casuali hardware"

#endif

Il significato di #ifndef è "se questo macro non è stato definito". L'idea di chi ha scritto questa protezione era: se qualcuno dimentica di attivare il generatore di numeri casuali hardware, la compilazione fallirà e l'incidente non potrà verificarsi.

Ma nella configurazione del firmware effettivo, questo macro è stato definito e il valore è 0.

Il #ifndef del linguaggio C chiede solo "è stato definito o no", non chiede "qual è il valore". Definirlo come 0 è comunque una definizione. Quindi questa protezione ha determinato che "è già definito, tutto è a posto", e l'errore non è mai stato attivato, mentre il valore 0 significa proprio "il generatore di numeri casuali hardware non è attivato".

Il fusibile è stato montato al contrario. Controlla solo se "il pezzo di interruttore è presente", non se "l'interruttore è impostato su ON".

Di conseguenza, il compilatore ha incluso il PRNG software fornito da MicroPython. Quel codice risale al maggio 2018 e, nel contesto di MicroPython, è una soluzione ragionevole; ma non era mai stato progettato per generare chiavi private di Bitcoin.

Da quel momento in poi, ogni Coldcard che esegue il firmware interessato, quando l'utente preme "genera nuovo seme", utilizza questa formula software, non quel chip di rumore fisico.

3.2 Quanto è piccolo quaranta?

I numeri forniti dal riesame tecnico di Coinkite sono:

• Mk2/Mk3 → spazio di ricerca effettivo circa 40 bit (dovrebbe essere 128 bit)
• Mk4/Mk5/Q → spazio di ricerca effettivo circa 72 bit (i componenti di sicurezza SE1/SE2 hanno mescolato parte dell'entropia indipendente, fornendo un certo sollievo)

Le versioni del firmware interessate sono Mk2/Mk3 da 4.0.1 a 4.1.9 (versione correttiva 4.2.0), Mk4/Mk5 inferiori a 5.6.0 (linea Edge inferiore a 6.6.0X), Q inferiori a 1.5.0Q (linea Edge inferiore a 6.6.0QX).

Qui c'è un dato che deve essere chiarito

Coinkite afferma ufficialmente che Mk4/Mk5/Q è 72 bit, mentre il rapporto di Blockhead del 3 agosto cita un'analisi che afferma che solo circa 32 bit sono realmente entrati nel seme finale.

La differenza tra questi due numeri non è una piccola discrepanza, ma una differenza di quaranta ordini di grandezza. 72 bit sono sicuri oggi ------ la potenza di calcolo globale non può esaurirli a breve; 32 bit sono più deboli dei 40 bit di Mk3, e sono una questione di pochi minuti. Un numero determina se "gli utenti di Mk4 possono migrare con calma" o "gli utenti di Mk4 sono attualmente in fase di pulizia".

Fino ad ora, la pulizia osservata si è concentrata sugli indirizzi a firma singola dell'era Mk3, il che supporta in linea di principio la posizione di Coinkite di 72 bit. Ma devo avvertire che questo non costituisce una prova. Gli aggressori ovviamente inizieranno a ripulire il lotto meno costoso. Questa questione stessa è una nota a piè di pagina del tema di questo numero ------ quando un'ipotesi è inobservabile, "non è successo nulla" non è mai una prova che "non succederà nulla".

3.3 L'open source è stato presente, ma non ha fermato nulla

Questo è il punto in cui i lettori a pagamento dovrebbero fermarsi.

Coldcard è un firmware open source. Ha un repository di codice pubblico, una revisione della comunità, una costruzione riproducibile ------ in teoria, questa è la configurazione di sicurezza più alta che un audit può fornire. È stato presente per tutto il tempo, ma non ha fermato nulla.

Le ragioni sono tre, una più controintuitiva dell'altra.

Primo livello: quella riga di codice nel sorgente sembra corretta

Il revisore, leggendo #ifndef MICROPY_HW_ENABLE_RNG + #error, ha l'impressione che "ci sia una protezione qui". Il difetto non risiede nella logica di quella riga, ma nella relazione tra essa e la configurazione di build in un altro file. La revisione del codice avviene file per file, funzione per funzione; questo bug si trova tra le fessure dei file.

Secondo livello: una build riproducibile dimostra "coerenza", non "correttezza"

La promessa di una build riproducibile è: chiunque, partendo dallo stesso sorgente, può generare un binario identico byte per byte, quindi il fornitore non ha inserito segreti. Questa promessa è stata completamente mantenuta in questo incidente: tutti possono riprodurre lo stesso binario, e quel binario contiene un generatore di numeri casuali pseudo-casuali software. La build riproducibile garantisce "quello che ricevi è ciò che è stato generato dal sorgente", non garantisce mai "quello che è stato generato dal sorgente è ciò che pensi sia".

Terzo livello - questo è il più critico: le firme delle funzioni dei due generatori di numeri casuali sono identiche

Coinkite ha chiaramente scritto questo nel suo resoconto: l'hardware RNG e il PRNG di fallback software appaiono identici all'esterno. Questo significa che, anche se qualcuno dovesse davvero fare reverse engineering del binario e controllare il percorso delle chiamate, vedrebbe lo stesso nome di funzione e lo stesso insieme di parametri. Per scoprire il problema, devi seguire a quale file obiettivo viene finalmente risolto il simbolo - un'azione che quasi nessuno farebbe in una revisione ordinaria.

Il modo in cui Coinkite ha risolto il problema conferma proprio questo: la nuova versione esclude esplicitamente l'oggetto PRNG di fallback di MicroPython e aggiunge un controllo dei simboli RNG in fase di build - se il file obiettivo a livello di scheda non fornisce rng_get(), o se l'implementazione di fallback non è stata completamente esclusa, la compilazione fallisce. In altre parole, non si sta riparando quella riga di codice, ma si sta trasformando l'"invisibile" in "osservabile in fase di compilazione".

C'è un dettaglio interessante: Coinkite sospetta che questo difetto latente da cinque anni possa essere stato scoperto da un modello AI durante la revisione del firmware open source. Il fondatore di Coinkite, NVK, ha affermato: "La revisione del codice assistita da AI ora può trovare bug latenti a una velocità superiore a quella dei più esperti nel settore".

Questa affermazione ha due lati. Il lato positivo è che questi difetti ipotetici, dormienti da anni, stanno diventando per la prima volta scopribili in massa. Il lato negativo è che anche gli aggressori hanno accesso agli stessi strumenti, e non hanno bisogno di rivelare responsabilmente prima. Tutto il codice open source, che non è cambiato a lungo e coinvolge primitive crittografiche, è appena entrato in una nuova era di rischio.

4. Questo spettacolo è stato messo in scena tre volte

Il peso del livello di abbonamento è centrale in questo capitolo. Il collasso dell'entropia non è una nuova invenzione dell'industria crittografica, è un tipo di incidente classico che si ripete nell'ingegneria crittografica, e ogni volta ha forme sorprendentemente simili.

4.1 Una riga di codice cancellata, silenziosamente per venti mesi

Nel settembre 2006, un manutentore di Debian, mentre impacchettava OpenSSL, ha cancellato due righe da md_rand.c: MD_Update(&m,buf,j);. La motivazione per la cancellazione era completamente benevola: queste due righe avrebbero letto memoria non inizializzata, causando allarmi continui nei tool di debug Valgrind e Purify. Accanto a una di queste righe c'era persino un commento /* purify complains */.

Il problema è che queste due righe fanno cose diverse in contesti diversi. L'autore originale ha protetto solo la riga realmente problematica con #ifndef PURIFY; il manutentore ha cancellato entrambe le righe.

Risultato: l'intero pool di semi casuali è diventato inefficace, l'unica fonte di "random" rimasta è l'ID del processo. E il limite massimo dell'ID del processo di Linux è 32.768. In altre parole, il numero totale di chiavi SSH, certificati SSL e chiavi crittografiche generati in tutto il mondo utilizzando Debian e le sue derivate è solo poco più di trentamila.

Questo difetto è stato scoperto il 13 maggio 2008 da Luciano Bello, dopo essere rimasto silente per circa 20 mesi. In quei 20 mesi, nessun server ha segnalato errori, nessun handshake è fallito, nessun segnale di allerta. Tutte le chiavi generate, matematicamente, nel formato e nell'uso, erano identiche a chiavi realmente sicure.

4.2 Un orologio a trentadue bit, silenziosamente per sei anni

Questa volta è accaduto direttamente a Bitcoin, ed è la forma più simile a questo incidente.

Le versioni 3.0.0 a 3.6.0 di Libbitcoin Explorer (strumento da riga di comando bx) utilizzavano l'algoritmo Mersenne Twister per generare semi - e questo PRNG utilizzava solo un orologio di sistema a 32 bit come seme. Una richiesta di semi a 256 bit otteneva in realtà solo 32 bit di entropia, circa 4,3 miliardi di possibilità, che l'hardware di consumo poteva esaurire in pochi giorni.

Cronologia: introdotto nel ottobre 2016 tramite PR#559, rilasciato con 3.0.0 nel marzo 2017, iniziò a essere sfruttato solo nel maggio 2023, il 12 luglio si verificò un grande furto coordinato (circa 29,65 BTC), il 21 luglio fu scoperto durante una risposta di emergenza, reso pubblico l'8 agosto, identificato come CVE-2023-39910.

Alla fine, oltre 2.600 portafogli colpiti sono stati identificati sulla rete principale di Bitcoin, con furti di oltre 900.000 dollari su più catene tra BTC, ETH, XRP, DOGE, SOL, LTC, BCH e ZEC.

Si prega di notare due numeri: latente per oltre sei anni; completamente invisibile sulla catena - prima del furto, questi portafogli sembravano identici a qualsiasi portafoglio normale.

4.3 Questa volta, il problema è emerso alla fine della catena di fiducia

Le meccaniche di questi tre incidenti sono quasi isomorfiche: una modifica ingegneristica benevola → la sorgente di entropia viene silenziosamente sostituita → latente per lungo tempo → un giorno viene raccolta in massa. Ma questa volta ci sono tre differenze sostanziali, e ognuna di esse va nella direzione peggiore.

Primo, la posizione è cambiata

L'incidente di Debian è avvenuto a livello di impacchettamento del sistema operativo, quello di Milk Sad è avvenuto in uno strumento da riga di comando - entrambi avevano ancora un "upstream/downstream" da considerare, gli utenti avevano almeno teoricamente altre opzioni. Coldcard è un dispositivo progettato per eliminare la fiducia. L'intera proposta di valore dei portafogli hardware è "non fidarti di alcun ambiente software, fidati di questo hardware dedicato". Quando il punto finale della catena di fiducia presenta problemi, non c'è un anello successivo sulla catena a cui tornare.

Secondo, il periodo di esposizione è correlato al comportamento degli utenti, ed è inverso

Il profilo delle vittime in questo caso è "persone che non hanno mosso monete dopo il 2021" - cioè il gruppo più disciplinato e conforme alle migliori pratiche. Più a lungo si bloccano le monete, più lungo è il periodo di esposizione, e più è probabile che si trovino nella lista. Le chiavi di Debian possono essere ruotate, i certificati SSL hanno già una scadenza; i semi di Bitcoin non vengono ruotati, vengono generati una volta e utilizzati a vita.

Terzo, il modo in cui vengono scoperti è cambiato

L'incidente di Debian è stato scoperto grazie a un ricercatore, quello di Milk Sad grazie a una retrospettiva di risposta all'emergenza dopo il furto. Questa volta potrebbe essere stato scoperto attivamente da un'AI. Questo significa che il tasso di scoperta di tali difetti sta aumentando strutturalmente - la buona notizia è che le mine esistenti verranno rimosse progressivamente, la cattiva notizia è che chi disinnesca le mine e chi le attiva ha la stessa mappa.

5. Quali numeri possono sostenere, quali non possono

Classificati per intensità in quattro livelli, la dichiarazione dell'azienda e la verifica di terze parti sono separate.

Primo livello · Verifica economica (fatti on-chain già avvenuti, i più solidi)

* Prima ondata di pulizia coordinata → 1.196 indirizzi svuotati in 41 minuti; 500 transazioni, 594.47722484 BTC | Fonte: coldcardentropy.org dataset di prove, 2026-07-30 * Fino al 2 agosto cumulativo → circa 1.367 BTC, circa 8,86 milioni di dollari, oltre 4.500 indirizzi | Fonte: Galaxy Research tracciamento, riportato da Blockhead, 2026-08-03 * Dimensione del dataset di prove → 6.657 indirizzi unici sotto sei livelli di evidenza | Fonte: coldcardentropy.org, 2026-08 * Profilo delle vittime → concentrato su indirizzi di cold storage non attivi dal 2021 | Fonte: incroci di più rapporti, 2026-07-31

Secondo livello · Dichiarazione del fornitore (cause tecniche, autorevoli ma da incrociare)

* Causa principale → random.c (libngu, righe 22-31) protetto da #ifndef MICROPY_HW_ENABLE_RNG, il firmware definisce il macro come 0, #error non viene attivato | Fonte: resoconto tecnico di Coinkite, 2026-07/08 * Punto di introduzione → marzo 2021 migrazione di libNgU; il codice di fallback di MicroPython risale a maggio 2018 | Fonte: stesso * Valore di entropia → Mk2/Mk3 circa 40 bit; Mk4/Mk5/Q circa 72 bit | Fonte: stesso * Zona cieca di audit → le firme delle funzioni di due implementazioni RNG sono identiche, l'audit binario non può distinguere | Fonte: stesso * Metodo di riparazione → esclusione esplicita dell'oggetto PRNG di fallback + controllo dei simboli RNG in fase di build, mancanza porta a fallimento della compilazione | Fonte: stesso

Terzo livello · Dati chiave con divergenze (devi giudicare tu stesso)

* Valore reale di entropia di Mk4/Mk5/Q → Coinkite afferma circa 72 bit, analisi di terze parti afferma solo circa 32 bit entrano nel seme finale | Fonte: resoconto di Coinkite vs Blockhead, 2026-08-03. La differenza di quaranta ordini di grandezza determina direttamente l'urgenza per questo gruppo di utenti; fino alla pubblicazione non si sono visti pubblicamente riconciliare le due parti.

Quarto livello · Opinioni e congetture (le più deboli, non sostenibili)

* Coinkite sospetta che il difetto possa essere stato scoperto durante la revisione del firmware open source da parte di un modello AI; NVK afferma che la revisione assistita da AI è più veloce degli esperti umani più esperti. * I ricercatori indipendenti ritengono che un multisig composto esclusivamente da dispositivi colpiti sia ancora vulnerabile e che sia necessaria una maggioranza di firmatari non colpiti ------ questo è un giudizio di terze parti, non una posizione ufficiale di Coinkite.
Un'illusione da abbattere ---------
Molte persone si sono sentite sollevate nel vedere "firmware di riparazione rilasciato". Coinkite è molto chiara: l'aggiornamento del firmware non modifica né ripara i seed già generati. La versione del firmware gestisce le chiavi generate in futuro, non quelle già esistenti. Questa è la frase più facilmente fraintendibile di questo incidente, e anche la più costosa.
6. Ordinare per urgenza: chi deve muoversi oggi =================
Qualunque sia l'argomento, la sicurezza dei fondi dei lettori deve venire prima. Ordinare per urgenza, dal più alto al più basso.
Primo livello · Trasferimento immediato ----------
Seed generati su Mk2/Mk3 con firmware da 4.0.1 a 4.1.9, senza aggiungere entropia da dadi e senza impostare una BIP39 Passphrase. Questo è il lotto che sta venendo esaminato. Il criterio di giudizio è la versione del firmware in esecuzione sul dispositivo al momento della generazione del seed, non quando hai acquistato il dispositivo.
Secondo livello · Trasferimento il prima possibile ----------
Seed generati su Mk4/Mk5/Q prima delle rispettive versioni di riparazione. Se la discrepanza tra 72 bit e 32 bit non è stata chiarita, agire secondo l'ipotesi peggiore ------ il modo corretto di gestire questo tipo di discrepanza è sempre quello di prendere il limite inferiore.
Terzo livello · Probabilmente sicuro, ma da verificare -----------------
* Seed generati altrove e importati in Coldcard ------ Coinkite conferma che non rientrano in questo problema, poiché non sono prodotti da questo generatore. * Seed generati con almeno 50 lanci di dadi equi, indipendenti e mai registrati o trapelati ------ Coinkite afferma che non sono influenzati da questo problema. * TAPSIGNER, OPENDIME, SATSCARD non sono colpiti. * Mk1, Mk2 non sono stati ufficialmente inclusi da Coinkite nella descrizione.
Gli utenti di multisig devono prestare particolare attenzione a questo punto ------------
Un multisig composto esclusivamente da dispositivi colpiti non è sicuro. Il multisig protegge da furti, guasti o coercizioni a punto singolo, ma non può prevenire "tutte le chiavi dei firmatari provenienti dallo stesso generatore difettoso". Questo è il livello di difesa più facilmente sovrastimato in questo incidente ------ hai bisogno di una maggioranza di firmatari non colpiti, non basta dire "ho un multisig, quindi sto bene".
Tre avvertimenti riguardo al trasferimento stesso -----------
Primo, il trasferimento è un'azione rischiosa. L'avviso di Bitcoin Well è molto pertinente: le perdite causate da un trasferimento affrettato potrebbero superare il problema che stai cercando di evitare. Errori nel copiare il backup, non verificare l'indirizzo di ricezione sullo schermo del dispositivo, questi errori non scompariranno solo perché il tuo nuovo seed ha un valore di entropia perfetto. L'ordine corretto è: installare il firmware di riparazione verificato → generare un nuovo seed → registrare e verificare il backup → controllare l'indirizzo di ricezione sullo schermo del dispositivo → inviare prima una piccola transazione di prova → trasferire il saldo solo dopo aver confermato la ricezione → non distruggere il vecchio backup fino a conferma totale.
Secondo, non toccare alcun "servizio di recupero seed". Dopo incidenti di questo tipo, inevitabilmente emergono truffatori che affermano di poter aiutarti a recuperare i tuoi beni, ma vogliono solo una cosa.
Terzo, puoi utilizzare il controllo locale degli indirizzi su coldcardentropy.org ------ specifica chiaramente che la verifica avviene localmente nel browser, senza caricamenti o registrazioni, inserendo solo indirizzi pubblici, mai inserire frasi di recupero, chiavi private, passphrase, PIN o file di esportazione del portafoglio. Ma ricorda l'esonero di responsabilità del sito: non essere trovato non significa essere sicuro.
7. A chi è stato trasferito il costo di questo incidente ===============
Primo, il rischio è passato da "operazioni dell'utente" a "catena di costruzione del fornitore", ma la responsabilità non è stata trasferita -------------------------------------
Tutte le variabili che l'utente può controllare ------ custodia, backup, offline, disciplina ------ sono state completamente annullate in questo incidente. La variabile che decide realmente la vita o la morte è qualcosa che l'utente non può osservare né esaminare: il valore di un macro al momento della compilazione da parte del fornitore. E nella narrazione dell'autogestione, le perdite sono a carico dell'utente: non ci sono assicurazioni sui depositi, non c'è assistenza clienti, non ci sono ripristini. L'autogestione ti dà il controllo degli asset, ma ti trasferisce anche parte del rischio che non puoi controllare.
Secondo, il marchio "open source e auditabile" è stato rivalutato --------------------
Il valore dell'open source è reale, ma questo incidente ha tracciato un confine chiaro: l'open source garantisce che "il codice può essere visto", non garantisce che "ci sia qualcuno che lo guarda". Quando il difetto risiede nella configurazione di costruzione, o nella risoluzione dei simboli di due funzioni con lo stesso nome, l'azione predefinita della comunità di revisione non può coprire quel livello. Quando vedrai "open source, costruzione riproducibile" come punto di vendita per la sicurezza, dovresti chiedere: chi controlla la risoluzione dei simboli? Ci sono affermazioni durante il periodo di costruzione?
Terzo, il costo è stato trasferito a chi rispetta maggiormente le regole -----------------
Questo è il punto più pungente di questo incidente. Le persone che effettuano transazioni frequenti, cambiano spesso portafoglio e mettono i fondi sugli exchange, sono riuscite a evitare il problema. Mentre coloro che hanno generato una volta nel 2021, hanno messo tutto in un luogo sicuro e non lo hanno toccato per cinque anni, sono esattamente quelli sulla lista. Quando il periodo di esposizione al rischio è correlato alla durata di detenzione, il lungo termine diventa un fattore di rischio. Non è una questione morale, è una questione strutturale ------ ma cambierà la comprensione di alcune persone riguardo al "cold storage".
Quarto, questo non è un caso isolato, ma una tendenza in formazione ---------------------
Se guardiamo gli incidenti di luglio 2026: circa 200 milioni di dollari, 34 casi. Di cui AFX Trade 24,15 milioni (chiave del validatore), Ostium 18 milioni (chiave del firmatario dell'oracolo), Triple-A 11,8 milioni (hot wallet), WEMIX 6,25 milioni (chiave del proprietario) ------ tutti legati a chiavi e autorizzazioni; mentre i tradizionali difetti di contratto hanno solo Wanchain 10 milioni, Bonzo Lend 9,05 milioni, Verus Bridge 7,54 milioni. Le statistiche di Blockaid mostrano che nel primo semestre del 2026, i progetti crittografici rubati hanno superato il miliardo di dollari. La superficie di attacco si è strutturalmente spostata da "errore di scrittura del contratto" a "problemi con la fonte, custodia e catena di autorizzazione delle chiavi". E il collasso dell'entropia è la forma estrema di questa tendenza: non è che le chiavi siano state rubate, è che le chiavi non sono mai state generate in modo veramente casuale.
8. Dire una parola giusta per Coinkite ===================
Scrivere completamente il miglior argomento contro.
Il miglior controargomento: questo è un incidente ingegneristico controllato e ben definito, non sufficiente a sostenere una conclusione così ampia sul "rischio dell'autogestione nella fase di generazione" ------------------------------------------------
Si sviluppa così: il confine del difetto è molto chiaro ------ produttore specifico, modello specifico, intervallo di firmware specifico; gli utenti che utilizzano entropia da dadi o Passphrase non sono colpiti; i seed importati non sono colpiti; Coinkite ha riconosciuto il problema il giorno dell'incidente, ha rilasciato il firmware di riparazione il giorno successivo e ha pubblicato un'analisi tecnica completa, la velocità di gestione è tra le migliori del settore. Più importante, questo dimostra che l'ecosistema open source sta funzionando: il difetto è stato scoperto, divulgato e riparato, e l'intero processo è pubblico e verificabile. E 88,6 milioni di dollari, rispetto alla capitalizzazione di mercato totale di Bitcoin, o anche rispetto al miliardo di dollari rubati nel primo semestre del 2026, non è così grande. Per quanto riguarda Mk4/Mk5/Q, i 72 bit sono sicuri per il futuro prevedibile, la maggior parte degli utenti non è realmente a rischio.
Cosa ne penso ----
Accetto ogni fatto di questo controargomento, e credo che la velocità di gestione meriti persino un elogio ------ in questo settore, ci sono pochi fornitori che ammettono il problema lo stesso giorno e rilasciano una riparazione il giorno successivo, pubblicando la causa completa.
Ma evita la vera questione: il problema non è "quanto è grande questa perdita", ma "abbiamo un modo per sapere che esiste prima che si verifichi la prossima perdita".
Debian è rimasta silenziosa per 20 mesi, Milk Sad per 6 anni, Coldcard per 5 anni. Tre incidenti, nessuno dei quali è stato scoperto da "monitoraggio anomalo" ------ due grazie a casuali revisioni del codice, uno grazie a un'analisi retrospettiva dopo un furto, e questo potrebbe essere scoperto grazie a scansioni AI. Durante tutto il periodo di silenzio, tutti i cruscotti erano verdi. Non è una questione di fortuna, è che queste ipotesi sono intrinsecamente inobservabili: un seed con insufficiente entropia appare identico a un seed perfetto sulla blockchain, sul dispositivo e in qualsiasi monitoraggio.
Quindi la mia conclusione non è "i portafogli hardware non possono essere usati" ------ al contrario, i portafogli hardware rimangono la scelta più ragionevole per la maggior parte delle persone, non intendo spingere nessuno verso gli exchange. La mia conclusione è un giudizio strutturale: > La sicurezza di un sistema dipende dalla sua ipotesi più debole; e la gestibilità di un sistema dipende da quante di queste ipotesi sono osservabili. Negli ultimi dieci anni, il mondo crittografico ha investito enormi energie nel "rendere più difficile l'attacco", ma quasi nulla nel "scoprire quando le ipotesi falliscono". Il collasso dell'entropia è solo il primo campione sufficientemente costoso di questo vuoto, così costoso da non poter essere ignorato.
Controllo delle truffe (parlare di meccanismi non equivale a dare un'approvazione, questo deve essere scritto) ---------------------
Coinkite è un'azienda canadese attiva da molti anni, il fondatore NVK è noto e attivo pubblicamente, i prodotti sono open source, con repository di codice pubblico e costruzione riproducibile, ha riconosciuto l'incidente il giorno stesso, ha rilasciato il firmware di riparazione il giorno successivo e ha pubblicato un'analisi tecnica dettagliata fino al file e alla riga. Non ci sono problemi di fuga o team anonimi o backdoor malevole ------ al contrario, proprio perché è uno dei più trasparenti nel settore, questo incidente merita di essere preso sul serio da tutti: se pratiche ingegneristiche come questa possono rimanere silenziose per cinque anni, quelle aziende che non sono open source, non fanno costruzioni riproducibili e non pubblicano le cause, saranno in una situazione ancora peggiore, e non lo saprai mai.

È importante avvisare i lettori riguardo ai rischi secondari degli incidenti: chiunque ti contatti attivamente, affermando di poter aiutarti a verificare o recuperare beni, e richieda di fornire parole chiave o file del portafoglio, è un truffatore. La maggiore opportunità creata da questo incidente non è sulla blockchain, ma nel social engineering.

9. Cinque domande da porre a qualsiasi sistema in cui desideri affidare i tuoi beni

Questo è ciò che realmente vogliamo consegnare in questa edizione. Riduci il tema a cinque domande e portale a qualsiasi sistema in cui desideri affidare i tuoi beni: portafoglio, bridge, oracolo, custode, stablecoin, L2, soluzioni multi-firma.

Prima domanda: da dove proviene la casualità? Ci sono prove che dimostrano che è stata realmente invocata?

Non chiedere "è necessario un generatore di numeri casuali hardware?", ma chiedi "cosa succede se il generatore di numeri casuali hardware non viene invocato?". La risposta corretta è solo una: fallimento della compilazione o fallimento dell'avvio. Qualsiasi design che "torna silenziosamente all'implementazione software" sta aspettando una mattina tra cinque anni. Criterio: ci sono asserzioni in fase di costruzione o di esecuzione, e non solo commenti e promesse documentali.

Seconda domanda: se il codice sorgente è corretto, il binario prodotto è corretto?

La costruzione riproducibile dimostra che "tutti producono la stessa cosa", ma non dimostra che "ciò che è stato prodotto è corretto". Il difetto di questo caso vive esattamente in questa fessura. Criterio: oltre alla costruzione riproducibile, ci sono verifiche a livello simbolico - cioè, verifica a quale implementazione finale si è risolto la funzione chiave. Fai particolare attenzione ai casi in cui due implementazioni condividono la stessa firma di funzione: questo è un naturale punto cieco per l'audit.

Terza domanda: ci sono valori che dovrebbero essere ottenuti dinamicamente, ma sono stati codificati in modo statico?

Le fonti di entropia sono una categoria, un'altra categoria è quella delle costanti hard-coded. Quello che abbiamo visto nell'incidente delle stablecoin, "l'oracolo ha codificato il prezzo a $1.00", e quello di questo caso, "tornare a un numero casuale fisso", sono la stessa malattia: una quantità che dovrebbe riflettere lo stato reale esterno è stata sostituita con una quantità che non cambia mai, e il sistema non genera errori a causa di ciò. Criterio: elenca tutti i valori nel sistema che "dovrebbero cambiare, ma non li hai mai visti cambiare" e chiedi uno per uno perché.

Quarta domanda: chi può firmare? Questo insieme è cambiato silenziosamente?

L'insieme dei firmatari, i privilegi di amministrazione, le chiavi di aggiornamento - queste modifiche spesso non generano eventi visibili per gli utenti. Negli incidenti di luglio, AFX Trade, Ostium e WEMIX sono tutti crollati a questo livello. Criterio: ci sono eventi on-chain per le modifiche, ci sono lock temporali, c'è un terzo che può verificare indipendentemente l'attuale insieme.

Quinta domanda (domanda meta, la più importante): se questa ipotesi è falsa, il sistema me lo dirà? Se non lo fa, da quanto tempo è falsa e posso scoprirlo?

Ripeti ogni risposta delle prime quattro domande attraverso questo filtro. I rischi osservabili sono problemi ingegneristici, i rischi non osservabili sono problemi di esistenza. I primi possono essere gestiti tramite monitoraggio e gestione della risposta, i secondi possono essere resi osservabili solo in fase di progettazione - non ci sono mezzi di riparazione successivi.

Il nucleo di questo framework è un cambiamento di prospettiva: spostare il problema dell'audit della sicurezza da "ci sono vulnerabilità nel codice" a "quali ipotesi, se false, non attiveranno un allerta nel sistema". La prima domanda ha infiniti riscontri, non si può mai finire di indagare; la seconda domanda ha solitamente non più di dieci risposte, e una volta scritte, ognuna di esse può essere trasformata in un'asserzione.

10. Dove potrei sbagliare

Argomentazione "in realtà non è nuovo"

"Numeri casuali deboli portano alla compromissione delle chiavi" è un contenuto classico nei testi di ingegneria crittografica, sia Debian che Milk Sad lo hanno incluso nei loro casi studio. Se in questa edizione si fosse parlato solo di questo, sarebbe stato eliminato direttamente dal test "lo sapevo già". I progressi sono tre, i lettori possono giudicare se sono sufficienti: primo, l'osservabilità come dimensione indipendente - non è "ci saranno errori", ma "se ci sono errori ci sarà un segnale", questa dimensione è praticamente assente nelle discussioni di sicurezza mainstream; secondo, i confini della costruzione riproducibile - dimostra coerenza e non correttezza, e l'uso di funzioni con lo stesso nome porta a un punto cieco simbolico, questo è qualcosa che anche molti professionisti della sicurezza tendono a dare per scontato; terzo, la correlazione tra periodo di esposizione e durata di possesso, questa intuizione controintuitiva rovescia l'idea che "più a lungo si conserva un cold storage, più è sicuro". Se hai già chiarito questi tre punti, questa edizione non è effettivamente utile per te.

Il paradigma alternativo più forte

Forse ho invertito la causalità: la vera lezione non è "le ipotesi di fiducia non sono osservabili", ma "non scommettere sulla sicurezza a 128 bit su un'unica implementazione". Da questa prospettiva, la risposta non è l'osservabilità, ma la ridondanza - utilizzare entropia XOR da due fonti indipendenti, utilizzare dispositivi di diversi fornitori per multi-firma, utilizzare entropia da dadi incorporati. Se le soluzioni future del settore si evolvono principalmente lungo la ridondanza piuttosto che l'osservabilità **, allora il focus di questo framework è stato posto nel posto sbagliato. Questa è la strada che considero la più probabile per rovesciare questa tesi.

Riflettendo tra tre anni sulle cause di morte più probabili

L'audit assistito da AI eliminerà in massa questo tipo di difetti esistenti entro due anni, l'implosione dell'entropia diventerà un termine storico, e "le ipotesi di fiducia non osservabili" saranno dimostrate come un problema auto-dissolvente - i progressi degli strumenti lo trasformeranno direttamente in qualcosa di osservabile. Questa probabilità non è bassa. La mia difesa è: mentre la velocità di rimozione dei difetti aumenta, anche la velocità di scansione degli attaccanti aumenta, e non hanno obbligo di divulgazione. È troppo presto per concludere se l'effetto netto sia positivo o negativo.

Quali dati attuali potrebbero essere una falsa prosperità

Due. Primo, "l'osservazione della pulizia si concentra su Mk3 single-signature" - questo probabilmente riflette solo la classificazione dei costi degli attaccanti, e non il margine di sicurezza reale di Mk4/Mk5/Q, considerarlo come prova che "il nuovo modello è sicuro" è pericoloso. Secondo, il numero di 8,860 milioni di dollari - questo conta solo ciò che è già stato trasferito, e non ciò che è già stato esposto; la differenza tra i 6,657 indirizzi unici registrati su coldcardentropy.org e le perdite finali rappresenta l'inventario non ancora raccolto, non l'inventario sicuro.

11. Torniamo a fare il bilancio tra dodici mesi

Entrare nel libro delle previsioni. Non prevedere i prezzi, ma prevedere i comportamenti strutturali.

Previsione centrale (12 mesi)

Nei prossimi 12 mesi, il settore mostrerà cambiamenti strutturali osservabili nel modo in cui gestisce "entropia e generazione di chiavi" - almeno un produttore di portafogli hardware mainstream introdurrà pubblicamente asserzioni di fonti di entropia in fase di costruzione o di esecuzione (e non solo la promessa di utilizzare RNG hardware), e ci sarà almeno un altro difetto di livello primitivo crittografico scoperto grazie all'audit assistito da AI, che è rimasto latente per oltre tre anni (indipendentemente dal fatto che abbia causato perdite). Allo stesso tempo, gli incidenti significativi del 2026 continueranno a concentrarsi principalmente su chiavi / autorizzazioni / livello di generazione, piuttosto che sul livello di logica contrattuale.

Indicatori di osservazione a 3 mesi (fino al 2026-11)

• Se le perdite finali dell'incidente Coldcard si fermano a 1,400 BTC o continuano a diffondersi agli indirizzi registrati su coldcardentropy.org
• Se Coinkite e terzi rendono pubblici i bilanci riguardanti le discrepanze di 72 bit / 32 bit di Mk4/Mk5/Q
• Se altri produttori di portafogli hardware rilasciano dichiarazioni di auto-verifica, e se la dichiarazione è "abbiamo utilizzato RNG hardware" o "abbiamo aggiunto asserzioni di costruzione" - la differenza di formulazione è la prima domanda del framework di questa edizione
• Se ci sono frodi su larga scala di social engineering rivolte alle vittime di questo incidente

Indicatori di osservazione a 6 mesi (fino al 2027-02)

• Se qualche produttore ha scritto asserzioni di fonti di entropia e verifiche a livello simbolico nei processi di costruzione o nei rapporti di audit pubblici
• Se i fornitori di soluzioni multi-firma iniziano a richiedere esplicitamente che "i firmatari provengano da fornitori diversi / fonti di entropia diverse"
• Se si verifica un altro difetto di generazione di entropia o chiavi latente da oltre tre anni

Indicatori di osservazione a 12 mesi (fino al 2027-08)

• Se il numero di difetti storici scoperti grazie all'audit assistito da AI aumenta significativamente, e se il divulgatore è un ricercatore o un attaccante
• Se la percentuale di chiavi / autorizzazioni / livello di generazione negli incidenti statisticamente continua a superare quella del livello di logica contrattuale
• Se ci sono requisiti normativi o standard di settore riguardanti la "verificabilità delle fonti di entropia"

Condizioni di falsificazione (scrivo, mi prendo la responsabilità)

1. Nei prossimi 12 mesi, le risposte dei produttori mainstream si limitano generalmente a "cambiare l'implementazione RNG / rafforzare la revisione del codice", senza che alcuna azienda introduca asserzioni di costruzione o esecuzione verificabili pubblicamente → indica che "l'osservabilità" non è una soluzione adottata dal settore, il focus di questo framework è stato posto nel posto sbagliato, e il valore pratico della tesi è stato sovrastimato;
2. Negli incidenti significativi dei prossimi 12 mesi, i difetti di logica contrattuale tornano a essere predominanti (superando la percentuale di chiavi e autorizzazioni) → indica che il campione di luglio era solo rumore a breve termine, e che la direzione di giudizio sulla "migrazione strutturale della superficie di attacco" è errata;
3. La controversia su Mk4/Mk5/Q viene infine confermata come 32 bit e ampiamente spazzata via, mentre io ho giudicato nel testo che la sua urgenza fosse inferiore a quella di Mk3 → ho commesso un errore nel giudizio pratico più critico, e anche se la tesi stessa è valida, devo correggere pubblicamente.

Disclaimer

Questo articolo non prevede alcun prezzo di asset, non costituisce alcun consiglio di investimento o di acquisto/vendita. Le specifiche aziende e prodotti menzionati nel testo sono utilizzati solo per illustrare meccanismi tecnici e strutture di rischio, non rappresentano una valutazione commerciale o una raccomandazione, né indicano che altri prodotti siano più sicuri. I passaggi di migrazione nel testo sono informazioni pubbliche organizzate e non costituiscono consigli di sicurezza personalizzati; qualsiasi operazione che coinvolga chiavi private e parole chiave può comportare perdite di beni irreversibili, si prega di seguire le indicazioni ufficiali dei produttori e di assumersi la responsabilità delle decisioni. Chiunque ti chieda parole chiave, chiavi private, Passphrase o file di esportazione del portafoglio è un truffatore.

Dati e fonti

Tutti i dati sono stati verificati ad agosto 2026, le dichiarazioni dei produttori e le notizie di terzi sono contrassegnate in colonne separate.

Dichiarazioni dei produttori (prima mano)

• Approfondimento tecnico sul problema dell'entropia, blog ufficiale di Coinkite --- random.c (righe 22--31 di libngu) #ifndef MICROPY_HW_ENABLE_RNG guardia non valida, macro definita come 0, migrazione di libNgU introdotta a marzo 2021, codice di fallback di MicroPython risalente a maggio 2018, Mk2/Mk3 circa 40 bit, Mk4/Mk5/Q circa 72 bit, le firme delle funzioni di implementazione RNG sono identiche, il modo di riparazione è escludere gli oggetti di fallback + verifica dei simboli in fase di costruzione: https://blog.coinkite.com/entropy-technical-backgrounder/
• Versioni interessate e di riparazione: Mk2/Mk3 4.0.1--4.1.9 (riparato 4.2.0), Mk4/Mk5 < 5.6.0 (Edge < 6.6.0X), Q < 1.5.0Q (Edge < 6.6.0QX); "l'aggiornamento del firmware non modifica o ripara i semi già generati": come sopra e annuncio di Coinkite, 31-07-2026

Notizie e prove di terze parti

• Incidente di entropia COLDCARD --- Controllo indirizzo e prove --- sei livelli di prova, 6.657 indirizzi unici, prima ondata di 500 transazioni 594.47722484 BTC, ricerca locale del browser non carica, "non colpito non equivale a sicuro": https://coldcardentropy.org/
• Un bug di Coldcard di cinque anni ha permesso agli hacker di indovinare le chiavi del portafoglio bitcoin, conferma Coinkite, Blockhead, 03-08-2026 --- fino al 2 agosto circa 1.367 BTC / circa 8,86 milioni di dollari / oltre 4.500 indirizzi, tracciamento di Galaxy Research; analisi di terze parti afferma che Mk4/Mk5/Q ha solo circa 32 bit nel seme finale: https://www.blockhead.co/2026/08/03/coldcard-hardware-wallets-shipped-with-broken-randomness-for-five-years-coinkite-confirms/
• Coinkite rilascia firmware corretto dopo il bug di Coldcard; probabilmente coinvolta l'IA nella violazione, Bitcoin Magazine, 31-07-2026 --- versione del firmware corretta, dichiarazione di NVK sull'esame assistito dall'IA, oltre 70 milioni di dollari in 24 ore: https://bitcoinmagazine.com/business/coinkite-releases-fixed-firmware-after-coldcard-bug-ai-likely-involved-in-the-hack
• Difetto del portafoglio hardware Coldcard collegato a un furto di bitcoin da 70 milioni di dollari in 41 minuti, The Hacker News, agosto 2026 --- 1.196 indirizzi in 41 minuti: https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
• Vulnerabilità COLDCARD: Cosa devono sapere i proprietari, Bitcoin Well --- la determinazione dell'impatto si basa sulla versione del firmware al momento della generazione del seme, eccezione per l'importazione del seme e 50 lanci di dadi di entropia, TAPSIGNER/OPENDIME/SATSCARD non colpiti, multisig composto interamente da dispositivi colpiti rimane vulnerabile (studio di terze parti), passaggi di migrazione e avviso che "la migrazione affrettata comporta maggiori rischi": https://bitcoinwell.com/coldcard-vulnerability

Precedenti storici

• Bug del numero casuale in Debian Linux, Schneier on Security, maggio 2008 --- due righe di MD_Update in md_rand.c eliminate, commento /* purify complains */, introdotto a settembre 2006, scoperto da Luciano Bello il 13 maggio 2008, unica fonte casuale degradata a ID di processo, limite predefinito di Linux 32.768: https://www.schneier.com/blog/archives/2008/05/random_number_b.html
• Divulgazione completa di Milk Sad (CVE-2023-39910), milksad.info --- Libbitcoin Explorer 3.0.0--3.6.0, bx seed usa Mason rotation + semina di orologio a 32 bit, introdotto con PR#559 a ottobre 2016, rilasciato con 3.0.0 a marzo 2017, sfruttato a partire da maggio 2023, circa 29.65 BTC rubati il 12 luglio 2023, scoperto il 21 luglio 2023, divulgato l'8 agosto 2023, oltre 2.600 portafogli sulla mainnet, perdite cross-chain superiori a 900.000 dollari, latente per sei anni e senza visibilità on-chain: https://milksad.info/disclosure.html

Prove di tendenza (incidente simile a luglio 2026)

• Hacks cripto di luglio 2026: quasi 200 milioni di dollari persi tra portafogli, DeFi e ponti --- circa 200 milioni di dollari per tutto il mese, 34 incidenti; AFX Trade 24.150.000 dollari (chiave del validatore), Ostium 18.000.000 dollari (chiave del firmatario dell'oracolo), Triple-A 11.800.000 dollari (portafoglio caldo), WEMIX 6.250.000 dollari (chiave del proprietario), Wanchain 10.000.000 dollari, Bonzo Lend 9.050.000 dollari, Verus Bridge 7.540.000 dollari: https://cryip.co/july-2026-crypto-hacks-nearly-200m-lost-wallets-defi-bridges/
• Blockaid: oltre 1 miliardo di dollari rubati a progetti crittografici nel primo semestre del 2026, citato dal rapporto settimanale di Cryptoticker, agosto 2026: https://cryptoticker.io/en/crypto-news-today-weekly-wrap-august-2026/