liberlume-content-v3
lang: it
title: I numeri dell'incidente Coldcard, verificati in casa
summary: Fra il 30 luglio e il 1° agosto 2026 migliaia di indirizzi creati con i Coldcard Mk2 e Mk3, dai seed nati da un generatore difettoso, sono stati svuotati. I numeri dell'incidente rifatti in casa con un nodo Bitcoin e gli artefatti aperti di nodsig: 1.366 BTC da 4.560 indirizzi, le regole che isolano i gruppi, il confronto con Perera e Galaxy, dove sono i fondi.
btc-anchor: 969003,000000000000000000015856107d8546d2821369235a47f97ca073da7d33ae60
prev: genesis
--- body ---
Fra la fine di luglio e l'inizio di agosto del 2026 migliaia di indirizzi
Bitcoin creati, secondo i report, con i portafogli hardware Coldcard Mk2 e
Mk3 sono stati svuotati.
La causa sta a monte della catena: dal firmware 4.0.0 del 17 marzo
2021 fino alla correzione del 31 luglio 2026 i seed di quei modelli nascevano
da un generatore di numeri casuali difettoso, che lasciava poche decine di
bit di incertezza invece di 128: abbastanza pochi da provarli tutti. Chi li
ha ricostruiti ha potuto spendere. Secondo Galaxy Research, il danno si
aggira sui 115 milioni di dollari. Il lato del generatore, compresi i modelli
più recenti, che avevano un difetto più lieve, è raccontato in [«Quanto è
grande "praticamente impossibile"?»](/it/entropia-del-seed/).
Qui si approfondisce un altro ambito: che cosa resta scritto sul registro.
I numeri dell'incidente che circolano vengono da pochi analisti, soprattutto
Praveen Perera per la prima ondata e Galaxy Research, la divisione di ricerca
di Galaxy Digital, per il conteggio complessivo. Su un registro pubblico non
serve prenderli sulla parola: **si possono rifare, e lo si può fare in
casa**, con un nodo proprio e strumenti aperti, in ore e non in settimane.
Rifatti, i numeri reggono dove i report sono precisi, divergono dove i
criteri sono diversi, e si fermano dove la catena smette di dire chi ha
agito. Le date e le finestre di partenza vengono dai report pubblici; la
misura è indipendente. Vale per qualunque registro pubblico e completo: chi
ha i dati rifà il conto senza dipendere da chi l'ha fatto per primo.
Per non demandare fiducia o solamente per esercizio.
## Che cosa serve
Un nodo Bitcoin conserva i blocchi in ordine di tempo, e in quell'ordine
risponde bene ed in modo efficiente: che cosa c'è nel blocco tale, che cosa ha speso la
transazione tale. Le domande su un incidente chiedono i dati in un altro ordine.
Quando ha ricevuto fondi per la prima volta questo indirizzo, e quante volte? La sua
chiave era già comparsa sulla catena prima del furto? Le sue monete sono mai
state spese insieme a quelle di altri indirizzi? Sono domande per indirizzo,
per chiave, per spesa, e al nodo costano una rilettura dell'intera storia
ogni volta.
Le domande su un incidente e l'ordine che chiedono. Il nodo conserva i blocchi in ordine di tempo e risponde bene a che cosa contiene un blocco o che cosa spende una transazione. Le domande per indirizzo (primo arrivo, ricezioni, spese), per chiave (era già comparsa?) e per spesa (con quali altre monete?) chiedono indici costruiti una volta: la storia delle monete, l'archivio delle chiavi rivelate, le spese comuni, con i comandi di nodsig 3.4.0 accanto. Per le settimane recenti il nodo basta, perché i blocchi si rileggono.
Per le settimane dell'incidente il nodo basta: sono undicimila blocchi e si
rileggono. Per il passato è più utile avere indici costruiti una volta, che
rispondono nell'ordine delle domande. In questa analisi sono quelli di
[nodsig](https://github.com/amenano/nodsig), uno strumento aperto che
costruisce dalla catena, in forma riproducibile, l'indice delle monete, la
loro storia e l'archivio delle chiavi rivelate.
| strato | blocchi (altezze) | come è verificato |
|---|---|---|
| base sigillata, cioè chiusa con impronte pubbliche: indice, storia, archivio delle chiavi rivelate, intestazioni | 1-957.301 (fino al 9 luglio 2026) | impronte (in fondo); in più 1,87 milioni di fee e 3,74 milioni di serrature confrontate col nodo, tutte uguali |
| strato recente, letto dal nodo | 957.302-968.533 (9 luglio-25 settembre 2026) | per ogni blocco: hash, legame col precedente, le due impronte che legano le transazioni al blocco (radice di Merkle e impegno del witness), fee ricalcolate dalle monete spese |
Produrre gli indici ha un costo, e va messo accanto a ciò che questi fanno risparmiare.
La base si costruisce una volta: circa 129 ore di macchina e 960 GB. Dopo, le
domande diventano interrogazioni:
| domanda | col solo nodo | con gli indici |
|---|---|---|
| rileggere 282.351 blocchi (2021-2026), con fee e altezze delle monete spese | circa 50 ore e 500 GB letti (stima dal ritmo misurato, 0,64 secondi a blocco) | 3 h 41 |
| rileggere i 1.251 blocchi dell'incidente, con le monete spese | 12 minuti misurati, con tre processi (0,57 secondi a blocco) | non serve |
| profilo di 1.891 indirizzi: primo arrivo, ricezioni, spese | una passata sulla storia, o un indicizzatore esterno | circa 90 secondi |
| la chiave di 265.869 indirizzi era già comparsa? | non si può chiedere senza rileggere tutti i dati di sblocco | circa un'ora |
Il ritmo di lettura è stato misurato due volte, con due letture indipendenti
dei blocchi, a 0,64 e a 0,54-0,57 secondi a blocco: col solo nodo i cinque
anni costerebbero fra 42 e 50 ore. Il confronto giusto, però, non è solo col
nodo: un indicizzatore di indirizzi coprirebbe il profilo e le spese comuni,
non l'archivio delle chiavi rivelate.
Un limite vale per tutto il pezzo: gli indirizzi taproot e quelli a chiave
nuda (p2pk) non si ricostruiscono dai dati di sblocco, e nella rilettura dei
cinque anni restano fuori; nel periodo recente sono il 16,4% degli
svuotamenti. Nei gruppi dell'incidente non ce n'è nessuno. I tipi di
indirizzo, e che cosa ciascuno mostra quando si spende, sono in [«Le
serrature di Bitcoin»](/it/serrature-bitcoin/).
## La prima ondata
La prima ondata si può ricalcolare al satoshi, il centomilionesimo di bitcoin, dai soli
byte dei blocchi, e il numero noto dai report pubblici regge:
| misura | Perera | rifatta dai byte |
|---|---|---|
| svuotamenti (transazioni) | 1.195 | 1.195 |
| input (monete spese) | 2.350 | 2.350 |
| valore | 1.082,65318922 BTC | 1.082,65318922 BTC |
| blocchi (altezze) | 960.183, consolidazione nel 960.191 | 960.183-960.191 |
| quando (ora del blocco, UTC) | 30 luglio, 01:10-01:51 | 30 luglio, 01:10-01:51 |
La ricostruzione non usa un elenco di transazioni o di indirizzi. Parte
dalla descrizione che Perera dà della prima ondata (i blocchi, una
transazione per ogni indirizzo svuotato con un solo output, gli stessi
valori di versione, locktime e sequence, la fee pari a 30 volte una stima
fissa), la traduce in regole e la applica ai blocchi. Ne escono gli stessi numeri
del report, al satoshi. Perera le aveva trovate risalendo dai quattro indirizzi di
destinazione pubblicati da Galaxy; qui nessun indirizzo viene dato in
partenza. Dei 1.195 indirizzi Perera ne pubblica 153, quelli che non ha
ricondotto a un seed: sono tutti fra quelli ricostruiti qui, con lo stesso
blocco, lo stesso numero di input e lo stesso valore. È stata rifatta due volte, con due letture indipendenti dei
blocchi; la seconda, dai soli nove blocchi dell'ondata e in venti secondi,
usa regole ancora più povere, senza la formula della fee, e ritrova lo
stesso insieme. Le parole che servono da qui in avanti nascono da questo
caso.
Ogni transazione è uno **svuotamento**: un solo output e nessun resto
(l'output che riporta al mittente la differenza), verso un indirizzo
diverso. Lo svuotamento è **semplice** quando gli input vengono tutti da un
indirizzo, come qui: un indirizzo per transazione. Le destinazioni sono
quattro **collettori**, indirizzi che ricevono svuotamenti da molti
indirizzi diversi, nuovi. Entro sette blocchi tre transazioni ne riuniscono
quasi tutto il contenuto; i 32,45 BTC arrivati nello stesso blocco della
consolidazione sono rimasti sul collettore. Galaxy conta 1.196 indirizzi per
lo stesso importo al satoshi; dalla catena risultano 1.195 transazioni da
1.195 indirizzi, e nessun'altra transazione paga i quattro collettori in
quei blocchi. La differenza di uno resta senza spiegazione.
1.195 indirizzi non sono 1.195 persone. Perera, che ha rifatto il generatore
difettoso, ha ricostruito 328 seed, cioè 328 portafogli: dietro quei seed ci
sono 1.042 dei 1.195 indirizzi e 949,70 dei 1.082,65 bitcoin, l'87,72 per
cento. La catena da sola conta indirizzi; per contare i portafogli bisogna
rifare il generatore difettoso.
Un passo dell'analisi è individuare alcuni dati che possono caratterizzare le singole
transazioni e come queste sono scritte nel registro.
Ciò che accomuna le 1.195 transazioni è il **marchio** di un programma,
dove programma vuol dire qualunque software che costruisce e firma transazioni:
il portafoglio di un utente lo è, e lo è lo strumento usato per l'attacco.
Il protocollo lascia libere molte scelte di dettaglio, e ogni programma le fa
a modo suo. La prima è la **costruzione**: versione 2, locktime 0 (nessuna
attesa prima di essere valida), sequence al valore massimo su tutti gli
input (nessuna sostituzione possibile). Sono campi che ogni transazione porta
e che insieme riconoscono una famiglia di programmi, non uno solo.
La seconda è la fee. Il protocollo non dice come calcolarla. Ogni programma
la ricava da una tariffa e da una dimensione della transazione, e siccome la
fee si decide prima di firmare, la dimensione è sempre una stima. Il
programma di queste transazioni, come ha descritto Perera, usa una stima
fissa, sempre la stessa a parità di input: 42 byte virtuali più 68 per ogni
input da indirizzi p2wpkh (91 per i p2sh, 148 per i p2pkh). Il byte virtuale
è l'unità con cui si misura lo spazio nel blocco. La stima si moltiplica per
una tariffa intera: 30 satoshi per byte virtuale, 30 sat/vB. Ne esce una fee
che è sempre un multiplo esatto di quella stima, in tutte le 1.195. Molti
programmi arrivano alla fee in altri modi, con tariffe non intere o stime
diverse, e le loro fee non cadono su quella griglia: è questo che restringe
il campo.
Il terzo dettaglio è la firma. La lunghezza di una firma ECDSA, lo schema
usato da questi indirizzi, dipende da un suo numero interno, r: circa una
volta su due serve un byte in più, quindi le firme sono da 72 o 71 byte
quasi a metà. Bitcoin Core, dal 2018, ripete il calcolo finché non esce la
versione corta. Nella prima ondata, su 2.350 firme, quelle da 72 byte sono il
48%; nelle 279.492 transazioni costruite come Core o Sparrow fra luglio e
settembre, il 4%. La fee restringe la famiglia a un programma, le firme
aiutano a distinguere programmi diversi che usano la stessa formula.
L'ultimo tratto riguarda gli indirizzi svuotati, e lo si è misurato su
questi: fondi arrivati tutti dopo il 17 marzo 2021, la data del firmware
difettoso; quasi sempre una sola ricezione; chiave mai rivelata, cioè mai
comparsa sulla catena in una spesa; per lo più monete ferme da anni. È il
**profilo** degli indirizzi svuotati. È anche il profilo dei depositi freddi
(una ricezione, mai una spesa): da solo non separa un attacco da un
servizio, e non dice con quale dispositivo l'indirizzo è nato. Di questi
tratti solo il primo viene dal difetto stesso: un seed nato col firmware
difettoso esiste solo da quella data. Gli altri descrivono chi usa un
Coldcard come deposito.
Messi in fila, questi dettagli fanno da filtro, a maglie sempre più strette:
| livello | che cosa guarda | quanto è comune | che cosa dice |
|---|---|---|---|
| costruzione | versione 2, locktime 0, sequence al massimo | dal 1° al 25 settembre, fuori dall'incidente: svuotamenti da 310.784 indirizzi | una famiglia di programmi |
| marchio | la costruzione, più una fee che è un multiplo esatto della stima fissa | nello stesso periodo: 109.059 svuotamenti da 65.554 indirizzi, a 1-3 sat/vB | un programma, o pochi |
| episodio | il marchio a 10 sat/vB o più, in un picco nel tempo | nei cinque anni prima dell'incidente: 709, quasi tutti piccoli | un'attività ripetuta di quel programma |
| la prima ondata | l'episodio, più collettori comuni e il profilo degli indirizzi svuotati | 1.195 indirizzi in 41 minuti, a 30 sat/vB | un episodio dell'incidente |
Il filtro serve a trovare le transazioni della prima ondata fra milioni di
altre, e a cercare lo stesso marchio negli anni precedenti. Non serve ad
attribuire. **Il marchio dice quale programma, non chi lo usa**: dal 1°
settembre lo stesso marchio, a tariffe più basse, lo usa un programma molto
diffuso. Per questo, nelle regole di questo pezzo, costruzione e marchio da
soli non bastano mai a fare un gruppo.
## Come si riconosce e caratterizza un gruppo
Sulla catena un incidente non ha etichette. Si può identificare quando alcune regole
isolano transazioni che si somigliano più di quanto il caso consenta, e le
regole valgono qualcosa solo se sono state fissate dove la risposta era nota
e poi applicate dove non lo era. Il lavoro ha tre fasi: **tarare** le regole
sulla prima ondata, **cercare** i gruppi nella finestra dell'incidente,
**verificare** dove la risposta non si sa. Ciò che le regole isolano si
chiama **gruppo**. Un gruppo che anche Perera o Galaxy attribuiscono
all'attacco si chiama **ondata**: la prima, e quella a due passi.
Le regole sono otto, scritte per questa indagine; gli script che
le applicano non sono pubblici. Esternamente all'analisi svolta proviene la
descrizione della prima ondata fatta da Perera (che ha ricostruito uno strumento
simile a quello presumibilmente usato dall'attaccante): è servita a tarare le regole,
ed è per questo che alcune ne portano traccia. Le soglie sono quelle usate;
conta di più la logica. Le regole non hanno tutte lo stesso ruolo:
due, il picco e il collettore, girano su tutte le transazioni e trovano i candidati;
le altre esaminano i candidati o li descrivono.
| | regola | che cosa guarda | quando scatta | origine |
|---|---|---|---|---|
| R1 | forma | una transazione | è uno svuotamento. La forma semplice si cerca su tutta la storia; quella a più indirizzi solo in analisi mirate, perché è anche la forma di chi riunisce i propri indirizzi | questa indagine; la forma semplice è quella che Perera descrive per la prima ondata |
| R2 | picco | gli svuotamenti con la stessa costruzione, o con lo stesso marchio, in sei blocchi (circa un'ora) | quando superano il doppio del 99° percentile, cioè del valore che solo una finestra su cento supera, nelle due settimane prima e dopo, esclusa la giornata attorno; con un minimo di 30, o di 10 per il marchio | questa indagine, tarata sulla prima ondata |
| R3 | collettore | le destinazioni degli svuotamenti | quando molti indirizzi convergono su pochi: almeno 20 verso uno, e destinazioni diverse non più di una ogni dieci svuotamenti. Che il collettore fosse nuovo è stato controllato dopo, collettore per collettore | questa indagine, tarata sui quattro collettori della prima ondata |
| R4 | marchio | fee e costruzione | la costruzione della prima ondata e una fee multipla esatta della stima fissa, a 10 sat/vB o più. La lunghezza delle firme non filtra: distingue programmi con la stessa formula | la formula della fee è nel report di Perera; qui è stata misurata, estesa a ogni tariffa intera da 10 in su e agli altri tipi di indirizzo, e completata con le firme |
| R5 | profilo | gli indirizzi svuotati | su tutti i candidati, quasi nessuna moneta anteriore al firmware (al massimo l'1%); sui gruppi che il pezzo nomina, il profilo completo: primo arrivo, ricezioni, spese, chiave | questa indagine, misurato sulla prima ondata |
| R6 | seguito | che cosa succede ai fondi dopo | le destinazioni vengono spese insieme, o svuotate insieme; e dove arrivano i fondi: coinjoin, THORChain, servizi, memo. Riconoscere gli arrivi è a sua volta una regola, e ha sbagliato una volta: il 21 settembre, un recupero scambiato per un coinjoin, poi corretto | questa indagine |
| R7 | unione | gruppi o destinazioni | le destinazioni dell'uno sono le sorgenti dell'altro, o vengono spese insieme | questa indagine |
| R8 | secondo passo | svuotamenti uno a uno | un picco di svuotamenti uno a uno con la costruzione della famiglia e una tariffa intera, da indirizzi finanziati da non più di tre giorni ma non inoltrati subito (età mediana di almeno 24 blocchi, circa quattro ore): è la regola che cerca le ondate a due passi | questa indagine, nata dal secondo passo dell'ondata a due passi e usata sugli anni precedenti |
Il coinjoin è una transazione che mescola monete di molti proprietari per
confonderne la provenienza; THORChain è un servizio che scambia bitcoin con
altre monete su altre catene; il memo è un breve testo scritto nella
transazione stessa.
Il flusso dell'indagine in tre fasi. Tarare, dove la risposta è nota: la descrizione di Perera dà la prima ondata, 1.195 indirizzi, su cui si misurano il marchio e il profilo e si tarano picco e collettore. Cercare, dal 30 luglio al 7 agosto: picchi e collettori (R2, R3) trovano i gruppi delle 5:48 e delle 7:34 del 31 luglio; il picco di una costruzione (R2; poi la stessa stima fissa, R4, e la regola del secondo passo, R8) trova il secondo passo dell'ondata a due passi, 288 indirizzi p2wsh, e il seguito dei fondi all'indietro (R6) porta al primo passo, 1.891 indirizzi; l'unione (R7) lega i due passi. Verificare, dove la risposta non si sa: le stesse regole sulla storia 2021-2026 trovano 709 episodi, nessuno come la prima ondata; una lettura che non usa nulla dei report ritrova da sola il 31 luglio, e nella versione rivista anche la prima ondata. Su ogni gruppo il profilo (R5) e il seguito dei fondi (R6) descrivono, non decidono.
Le tre fasi, e che cosa controlla ciascuna:
1. **tarare**, dove la risposta è nota. La descrizione di Perera dà la prima
ondata; su di essa si misurano marchio (R4) e profilo (R5), e si tarano
picco e collettore (R2, R3). Le regole sono state provate lì e corrette
prima di leggere il resto. Il picco, per costruzione, si misura sempre
contro le settimane vicine, non contro un valore scelto;
2. **cercare**, dal 30 luglio al 7 agosto. Picco e collettore (R2, R3)
girano su tutte le transazioni dello strato recente, dal 9 luglio al 25
settembre, e producono un elenco di candidati; profilo, seguito dei fondi
e unione (R5, R6, R7) li esaminano uno per uno, e scartano servizi e
migrazioni. Fuori dalla finestra il collettore trova altri 48 candidati,
quasi tutti monete appena arrivate, girate da servizi: il profilo li
scarta. Nella finestra restano i gruppi delle 5:48 e delle 7:34 e un
picco del 1° agosto: 283 svuotamenti uno a uno, con la stessa fee, verso
indirizzi p2wsh nuovi. Quella fee si rivela la stessa stima fissa della
prima ondata, adattata all'output (R4); risalendo da lì a chi aveva
finanziato quegli indirizzi (R6 all'indietro) si trova il primo passo.
Dal secondo passo nasce la regola R8, usata poi per cercarne altri negli
anni precedenti;
3. **verificare**, dove la risposta non si sa. Le stesse regole rileggono la
storia dal 2021: se l'attacco ha precedenti simili, devono comparire. Una
lettura che non usa nulla dei report deve ritrovare da sola il periodo
anomalo. Sono le due controprove, più avanti.
I gruppi emergono dall'elenco dei candidati, non sono cercati esplicitamente.
Fa eccezione la prima ondata, che viene dalla descrizione di Perera. La tabella che dice quale regola ha
deciso ciascun gruppo, più avanti, è una ricostruzione fatta dopo.
La taratura ha un prezzo, e va dichiarato: regole ricavate da transazioni
scelte con la descrizione di Perera cercano, per costruzione, cose come
quelle già descritte. Nella finestra dell'incidente il prezzo è basso, e lo
si misura sui blocchi: nelle finestre della prima ondata e dei gruppi delle 5:48
e delle 7:34, la sola regola del collettore trova anche i collettori di servizi
che raccolgono depositi, e a separarli basta, senza la formula di Perera,
l'età delle monete. Quelle dell'attacco erano ferme in mediana da 148-210 mila
blocchi, tre o quattro anni; quelle dei servizi da 1-1.838 blocchi,
al più due settimane. Nella rilettura degli anni precedenti il prezzo è alto,
perché lì si cerca il marchio del programma: lo dicono le controprove.
## Oltre la prima ondata: gruppi, non autori
Dopo la prima ondata le regole isolano altri tre gruppi, tutti entro la
mattina del 1° agosto. Due prendono il nome dall'ora del loro primo blocco,
il 31 luglio: il gruppo delle 5:48 e il gruppo delle 7:34. Pagano 10 e 50
sat/vB sulla dimensione della transazione e non sulla stima fissa: non hanno
il marchio della prima ondata, e li hanno costruiti programmi diversi da
quello della prima ondata.
| gruppo | blocchi (altezze) | quando (ora del blocco, UTC) | indirizzi | BTC svuotati | nelle fonti |
|---|---|---|---|---|---|
| prima ondata | 960.183-960.191 | 30/07 01:10-01:51 | 1.195 | 1.082,65 | Perera; Galaxy, Wave 1 |
| gruppo delle 5:48 | 960.352-960.356 | 31/07 05:48-05:58 | 352 | 30,19 | Galaxy, Wave 2 (352 indirizzi) |
| gruppo delle 7:34 | 960.363-960.369 | 31/07 07:34-08:36 | 1.122 | 45,93 | non nominato |
| ondata a due passi | 960.396-960.471, poi 960.519-960.520 | 31/07 12:23 → 01/08 06:27 | 1.891 | 207,73 | Galaxy, Wave 3 |
| **totale** | | | **4.560** | **1.366,49** | |
Il totale degli indirizzi è una somma: eventuali indirizzi comuni a due
gruppi non sono stati cercati. Galaxy conta il gruppo delle 5:48 come
Wave 2, ma lo stesso gruppo finisce in una transazione di recupero, sotto:
per questo qui resta un gruppo e non un'ondata.
Le 48 ore dell'incidente, dal 30 luglio al 1° agosto 2026, ora dei blocchi in UTC. Prima ondata: 30 luglio 01:10-01:51, 1.195 indirizzi, 30 sat/vB. Gruppo delle 5:48: 31 luglio 05:48-05:58, 352 indirizzi, 10 sat/vB. Gruppo delle 7:34: 31 luglio 07:34-08:36, 50 sat/vB, 1.122 indirizzi. Ondata a due passi: il primo passo il 31 luglio 12:23-22:25, 1.891 indirizzi, per lo più a circa 200 sat/vB; il secondo il 1° agosto 05:48-06:27, 288 indirizzi p2wsh, 10 sat/vB. Il 31 luglio è il giorno della correzione del firmware (4.2.0). Nei 2.145 blocchi dal 14 al 29 luglio la tariffa mediana dei blocchi era 1,02 sat/vB. Dati: blocchi letti dal nodo.
L'ondata a due passi è quella che Galaxy chiama «Wave 3». Gli indirizzi
svuotati sono 1.891, tutti nel primo passo: il 31 luglio 296 transazioni li
svuotano, fino a dieci per transazione, e ne mandano i fondi a 288
indirizzi nuovi di passaggio, non a un collettore. È per questo che R3 non
la vede. Nel secondo passo, il 1° agosto, ciascuno dei 288 indirizzi di
passaggio viene svuotato a sua volta verso un indirizzo p2wsh nuovo, cioè
protetto da uno script che resta nascosto finché l'indirizzo non spende. Gli
invii sono quasi tutti nello stesso blocco e con la stessa fee: un invio in
blocco da un solo programma. Degli 11 indirizzi
che hanno speso entro il 25 settembre, tutti e 11 rivelano uno script a due
firme su due (2-di-2), con 22 chiavi tutte diverse; le 22 firme sono tutte
corte, un'abitudine del software che firma. Per i 277 fermi lo script resta
nascosto. Galaxy li descrive tutti come casseforti a due firme: per gli 11
la forma coincide, per gli altri non si può dire.
L'ondata a due passi, in BTC. Il 31 luglio 296 transazioni svuotano 1.891 indirizzi, fino a dieci per transazione, verso 288 indirizzi nuovi di passaggio (207,73 BTC). Il 1° agosto i 288 vengono svuotati uno per uno verso 288 indirizzi p2wsh nuovi, con la stessa fee in 283 transazioni (207,09 BTC arrivati). Al 25 settembre: 20,50 BTC verso THORChain il 2 settembre, 70,26 BTC in coinjoin il 5 e il 7, 116,33 BTC fermi in 277 indirizzi p2wsh. Dati: blocchi letti dal nodo fino al 968.533.
Nei 2.145 blocchi fra il 14 e il 29 luglio la tariffa mediana del mercato,
pesata sulla dimensione delle transazioni, era 1,02 sat/vB: i gruppi
dell'incidente pagano da 10 a 200 volte tanto, come mostra la sintesi dei
gruppi più avanti.
Da quali regole nasce ciascun gruppo si legge per colonne, nella tabella che
segue: la prima ondata è l'unica in cui scattano insieme picco, collettori e
marchio; i due gruppi minori vengono dai collettori, senza marchio; l'ondata
a due passi sfugge ai collettori in entrambi i passi, e il primo passo
emerge solo seguendo i fondi all'indietro dal secondo (✓ applicata e
soddisfatta; ✗ applicata e non soddisfatta; il trattino indica una regola
non applicata). Nelle celle, le transazioni sono gli svuotamenti, gli
indirizzi sono quelli svuotati, le destinazioni sono gli indirizzi che
ricevono:
| regola | prima ondata | gruppo delle 5:48 | gruppo delle 7:34 | due passi: primo passo | due passi: secondo passo |
|---|---|---|---|---|---|
| **regola decisiva** | la descrizione di Perera; fra le regole di questo pezzo la ritrovano R3 e R4, che però sono tarate su di lei | R3 | R3 | R6, all'indietro dal secondo passo | R2 e R4 |
| R1 forma: che svuotamenti sono | ✓ semplici: 1.195 transazioni, una per indirizzo | ✓ semplici le 31 transazioni del picco; delle 93 in tutto, 52 svuotano più indirizzi insieme | ✓ semplici: 1.214 transazioni da 1.122 indirizzi | ✓ a più indirizzi: 296 transazioni da 1.891 indirizzi, fino a 10 per transazione | ✓ semplici, uno a uno: 289 transazioni da 288 indirizzi di passaggio |
| R2 picco: svuotamenti in una finestra di sei blocchi, contro la soglia | ✓ 627 e 416 transazioni in due finestre, soglia 52 (circa 24 e 16 volte il massimo delle settimane di confronto) | ✓ appena: 31 transazioni, soglia 30 | ✓ 953 e 248 transazioni in due finestre, soglia 30 (almeno 63 e 16 volte) | — | ✓ 283 transazioni in una finestra, soglia 30 (almeno 19 volte) |
| R3 collettore: dove vanno i fondi | ✓ 4 collettori, che ricevono da 500, 491, 104 e 100 indirizzi | ✓ 1 collettore; 352 indirizzi in tutto | ✓ 1 collettore, che riceve da 1.122 indirizzi | ✗ nessun collettore: 288 destinazioni diverse, indirizzi di passaggio | ✗ nessun collettore: 288 destinazioni diverse, indirizzi p2wsh |
| R4 marchio: la fee | ✓ 30 volte la stima fissa, in 1.195 transazioni su 1.195 | ✗ 10 sat/vB sulla dimensione della transazione, non sulla stima | ✗ 50 sat/vB sulla dimensione della transazione, non sulla stima | ✗ come regola, salvo un picco di 12 indirizzi; la formula a 200 volte la stima torna in 77 transazioni su 296 | ✓ variante per output p2wsh: 10 volte la stima in 288 transazioni su 289 (la 289ª arrotondata di un byte) |
| R6 seguito, all'indietro | — | — | — | ✓ risalendo dai 288 indirizzi di passaggio alle 296 transazioni che li hanno finanziati | — |
| R7 unione | ✓ i 4 collettori sono un solo gruppo: stessi blocchi, due consolidati nella stessa transazione | — | — | ✓ col secondo passo: le sue 288 destinazioni sono le sorgenti del secondo | ✓ col primo passo |
| R8 secondo passo | — | — | — | — | ✓ la regola è nata qui |
I valori di R2 nella tabella vengono da una prima versione della regola, che
confrontava ogni finestra con il massimo di due settimane fisse, una prima e
una dopo l'incidente: di qui i «volte il massimo». La versione nella tabella
delle regole, con il 99° percentile di due settimane mobili attorno a ogni
finestra, è quella applicata ai cinque anni precedenti; sul periodo recente
ritrova gli stessi gruppi.
Il profilo non decide, ma distingue gli indirizzi svuotati da quelli di un
servizio, e nei gruppi è lo stesso:
| profilo (R5) | prima ondata (1.195 indirizzi) | gruppo delle 5:48 (i 31 del picco) | gruppo delle 7:34 (1.201 transazioni a tariffa esatta) | due passi (1.891 indirizzi) |
|---|---|---|---|---|
| con monete anteriori al firmware | nessuno | nessuno | nessuno | nessuno |
| una sola ricezione | 86% | 29 su 31 | 89% | 93% |
| chiave mai rivelata | 97% | 29 su 31 | 98% | 99% |
| monete ferme da 3 anni o più | 56% | 20 su 31 | 69% | 61% |
Gli altri 321 indirizzi del gruppo delle 5:48 non sono stati profilati;
quelli del secondo passo sono indirizzi di passaggio, senza storia.
Le stesse forme, però, le lasciano soggetti diversi. Il gruppo delle 5:48
lo mostra: consolidato il 7 agosto, il 21 settembre i suoi fondi entrano in
una transazione che nel memo dichiara un trust di recupero, un ente del
Wyoming creato per restituire i fondi a chi li ha persi. Galaxy la conta fra
i recuperi dei white hat, cioè di chi ha usato la stessa falla per spostare
per primo i fondi ancora raggiungibili, e restituirli. **Un recupero e un
furto hanno la stessa forma** finché i fondi non arrivano a una destinazione
che si dichiara. Per questo il pezzo dice «gruppo» per ciò che le regole
isolano, e dei fondi dice soltanto ciò che si vede: fermi, verso THORChain,
in un coinjoin, in una transazione con un memo.
## Gli indirizzi svuotati
Gli indirizzi svuotati raccontano cinque anni di depositi.
Per ciascuno, la moneta più vecchia fra quelle svuotate dice almeno da
quando l'indirizzo teneva fondi. Nei quattro gruppi, 4.560 indirizzi,
le monete coprono tutti i trimestri dal marzo 2021, con i più fitti fra la
fine del 2021 e la metà del 2022, e nessuna è anteriore al firmware:
Quando erano nate le monete svuotate: per ogni indirizzo, il trimestre della moneta più vecchia fra quelle svuotate, dal 17 marzo 2021 (firmware 4.0.0) al luglio 2026. Prima ondata (1.195 indirizzi) e, insieme, gli altri tre gruppi (3.365). Gli indirizzi coprono tutti i trimestri, con i più fitti fra la fine del 2021 e il 2022; nessuna moneta è anteriore al firmware. Dati: blocchi letti dal nodo.
È la misura della moneta svuotata, non del primo arrivo di fondi, che
richiede la base; con quasi sempre una sola ricezione, le due cose quasi
coincidono.
Il valore è distribuito in modo diverso fra i gruppi:
| valore svuotato per indirizzo | prima ondata | ondata a due passi | gruppo delle 7:34 | gruppo delle 5:48 |
|---|---|---|---|---|
| indirizzi | 1.195 | 1.891 | 1.122 | 352 |
| mediana | 0,27 BTC | 0,014 BTC | 0,010 BTC | 0,010 BTC |
| il più grande | 51,07 BTC | 13,34 BTC | 4,97 BTC | 8,00 BTC |
| metà del valore sta in | 58 indirizzi | 42 indirizzi | 85 indirizzi | 3 indirizzi |
| il 10% più ricco degli indirizzi tiene | 64% del valore | 80% del valore | 56% del valore | 77% del valore |
| tipi di indirizzo | 1.182 p2wpkh, 7 p2sh, 6 p2pkh | tutti p2wpkh | 1.112 p2wpkh, 10 p2pkh | tutti p2wpkh |
La prima ondata ha svuotato indirizzi con saldi venti volte più alti degli
altri gruppi: come se chi l'ha fatta avesse cominciato dai più ricchi. È una
lettura; la catena mostra i saldi, non le scelte.
Un dettaglio riguarda gli importi. Il primo pagamento ricevuto da ogni
indirizzo svuotato, confrontato con i primi pagamenti ricevuti da indirizzi
nuovi negli stessi blocchi e con quelli di indirizzi rimasti mai spesi (i
depositi freddi, la base più simile):
| primo pagamento | indirizzi svuotati (%) | indirizzi nuovi (%) | depositi freddi (%) |
|---|---|---|---|
| meno di 0,001 BTC | 10,4% | 33,8% | 51,5% |
| 0,001-0,01 BTC | 23,3% | 36,9% | 22,8% |
| 0,01-0,1 BTC | 35,2% | 19,0% | 16,1% |
| 0,1-1 BTC | 25,3% | 7,1% | 7,9% |
| 1-10 BTC | 5,4% | 2,5% | 1,4% |
| 10 BTC o più | 0,4% | 0,6% | 0,2% |
| multiplo esatto di 0,01 BTC | 11,4% | 1,7% | 2,6% |
| multiplo esatto di 0,001 BTC | 17,2% | 3,2% | 4,3% |
| numero di indirizzi | 4.206 | 20.637 | 2.101 |
Gli indirizzi contati sono quelli dei quattro gruppi con un primo pagamento
nella base, prima del 9 luglio: non ci sono i 20 finanziati dopo, né gli
indirizzi del gruppo delle 5:48 fuori dal picco, che non sono stati
profilati. Gli indirizzi svuotati avevano ricevuto più spesso importi medi e
tondi: è coerente con acquisti o prelievi mandati una volta su un deposito
freddo. È una forma, non un'identità; e i depositi freddi di confronto sono
per metà spiccioli.
## Dove sono i fondi
Al 25 settembre più di nove bitcoin su dieci non si sono mossi:
| gruppo | BTC svuotati | dove sono, al 25 settembre (BTC arrivati) |
|---|---|---|
| prima ondata | 1.082,65 | fermi: 1.050,12 su tre output consolidati, 32,45 sul collettore mai consolidato |
| gruppo delle 7:34 | 45,93 | fermi, dopo una consolidazione |
| gruppo delle 5:48 | 30,19 | 30,18 nella transazione del trust di recupero, il 21 settembre |
| ondata a due passi | 207,73 | 116,33 fermi in 277 indirizzi p2wsh; 70,26 in coinjoin il 5 e il 7 settembre; 20,50 verso THORChain il 2 settembre |
| **totale** | **1.366,49** | |
Nella terza colonna le cifre sono quelle arrivate: la differenza con la
seconda sono le fee pagate lungo la strada, meno di un bitcoin in tutto.
Fermo non vuol dire perso né restituito: vuol dire che nessuno ha ancora
speso quelle monete. Di ciò che si è mosso, 120,94 BTC, meno di un decimo,
la catena dice la strada fino al coinjoin, a THORChain o al memo del trust;
oltre, non segue.
## Due misure, un confronto
Il totale di questo pezzo, 1.366 BTC da 4.560 indirizzi, non coincide
con quello di Galaxy, e non è un disaccordo. Le tre fonti contano cose
diverse:
| | Perera | Galaxy | questo pezzo |
|---|---|---|---|
| che cosa conta | la prima ondata, transazione per transazione | le ondate e i gruppi che attribuisce all'incidente | i gruppi che le regole di questa indagine isolano dal 30 luglio al 7 agosto |
| con che cosa | la catena, a partire dai quattro collettori pubblicati da Galaxy, e il generatore rifatto: 328 seed ricostruiti | la catena, con criteri non pubblicati | la sola catena: nodo e artefatti di nodsig |
| data | 12 agosto | fino al 24 agosto | istantanea al 25 settembre |
| totale | 1.082,65 BTC | 1.789,28 BTC | 1.366,49 BTC |
Ogni differenza si riconduce a un criterio, e dove non ci si riesce resta
dichiarata aperta:
| confronto | qui | Galaxy | da dove viene la differenza |
|---|---|---|---|
| totale | 1.366,49 BTC, 4.560 indirizzi | 1.789,28 BTC al 24 agosto | 422,79 BTC: in parte lotti con una costruzione che queste regole non guardano (sotto); il resto è aperto |
| ondata a due passi / Wave 3 | 1.891 indirizzi svuotati, 288 indirizzi p2wsh di arrivo, 207,73 BTC | 1.912 indirizzi svuotati, 293 indirizzi p2wsh di arrivo, 208,24 BTC | criterio: qui l'invio del 1° agosto; Galaxy unisce anche gli indirizzi spesi insieme dopo, fra cui uno creato il 3 agosto da 58 indirizzi e speso il 6 settembre con nove dei 288 |
| gruppo delle 5:48 / Wave 2 | 352 indirizzi, 30,19 BTC | 352 indirizzi, 30,19 BTC | nessuna: è lo stesso gruppo, con gli stessi numeri |
| Footprint E, uno dei gruppi minori più grandi | nessun gruppo | 2.148 indirizzi, 209,94 BTC | costruzione diversa, fuori da queste regole |
Un confronto regge solo con la data accanto. I conteggi di Galaxy sono
cresciuti con l'indagine: 1.367 BTC al 1° agosto, 1.596 al 4, 1.778 al 14,
1.789,28 al 24 agosto, l'ultimo pubblicato, che è quello usato qui. Il primo
è quasi identico al totale di questo pezzo; se le due somme contengano gli
stessi gruppi, da fuori non si può dire. Gli indirizzi totali non si
confrontano: per lo stesso importo le fonti riportano conteggi diversi
(oltre 5.200 in una, 8.680 in un'altra), segno di perimetri che non sono
dichiarati. Galaxy, inoltre, non ha pubblicato l'elenco dei suoi indirizzi:
lo ha condiviso con exchange e autorità. Il confronto indirizzo per
indirizzo, che chiuderebbe gran parte della differenza, da fuori non si può
fare.
Galaxy chiama «Wave» le ondate che attribuisce all'incidente, e «footprint»,
con una lettera, i gruppi minori che riconosce da tratti comuni delle
transazioni: a metà agosto ne contava alcune decine. La Footprint E usa la
costruzione di Bitcoin Core, il programma di riferimento, e di Sparrow, un
altro portafoglio molto usato: entrambi scrivono nel locktime l'altezza
corrente e segnalano che la fee si può alzare. Non è la costruzione della
prima ondata. Per vedere che cosa c'è con la costruzione di Core e Sparrow,
la finestra dal 30 luglio all'8 agosto è stata riletta con un criterio
scritto prima di contare, in quattro passi:
1. lotti: svuotamenti a più indirizzi (R1) di almeno 50 indirizzi;
2. profilo (R5): monete tutte posteriori al firmware e ferme da almeno 30
giorni, e almeno l'80% degli indirizzi col profilo degli indirizzi
svuotati;
3. seguito (R6): per ogni destinazione, se fino al 25 settembre viene spesa
insieme ad altre; due destinazioni sono legate se una stessa transazione
le spende entrambe;
4. scarto dei servizi: un legame non conta se nasce da una transazione con
50 o più input quasi tutti estranei, la forma di un servizio che raccoglie
i depositi di molti clienti.
Gli esiti:
| misura | valore |
|---|---|
| lotti trovati | 292 transazioni, 37.500 indirizzi, 1.365,54 BTC (una somma vicina al totale dei gruppi solo per caso) |
| destinazioni | 290 indirizzi diversi |
| destinazioni senza legami con altre | 259 indirizzi |
| gruppi legati da spese comuni, senza un servizio di mezzo | 7 gruppi: 26 destinazioni, 63,74 BTC |
| il lotto da 795 indirizzi del 2 agosto, che Galaxy mette nella Footprint E | isolato |
| la serie di lotti di spiccioli fra il 1° e il 3 agosto, col resto identico di 0,0004 BTC | un solo proprietario, secondo la spesa comune: circa 8.570 indirizzi, 4,64 BTC |
Nove destinazioni su dieci restano isolate: è la forma di molti proprietari
indipendenti che spostano i fondi dei propri indirizzi dormienti verso
indirizzi nuovi, spesso con importi tondi. Con queste regole la Footprint E
non si separa dalle migrazioni, e non si ricostruisce a forza. Se rientra
nel totale di Galaxy, ne spiegherebbe quasi metà della differenza. Si legge
bene invece la serie di spiccioli: migliaia di indirizzi di pochi centesimi
raccolti, secondo la spesa comune, da un solo proprietario. Se sia chi
svuota anche le chiavi di poco valore o un servizio che consolida, dalla
catena non si dice. Anche la spesa comune ha il suo limite: è un indizio di
proprietà comune, non una prova.
Dietro la differenza c'è anche una ragione più generale: **ci sono due modi
di sapere**. Dalle chiavi: si rifà il generatore difettoso, si elencano i
seed possibili, se ne derivano gli indirizzi e si guarda quali sono stati
svuotati. È la strada che Perera ha seguito per 1.042 dei 1.195 indirizzi,
e dà la risposta vera, indipendente da come
si è comportato chi ha svuotato. Dal comportamento: si legge come si muovono
i fondi, e si dipende sempre da un'ipotesi su chi agisce. Questo pezzo segue
solo la seconda strada, e di proposito: elencare i seed deboli vorrebbe dire
avere in mano le chiavi di chi ha ancora fondi. Dove Galaxy attribuisce e
queste regole no, come per la Footprint E, è probabile che la differenza
stia lì, anche se Galaxy non ha pubblicato il metodo.
## Le controprove
Il difetto risale al marzo del 2021, e la domanda viene da sé: è stato
sfruttato prima del luglio 2026? Due controprove rispondono per quanto le
regole permettono.
La prima rilegge i 282.351 blocchi scritti dal rilascio del firmware, con le
stesse regole, in tre passi:
1. conta gli **episodi**: finestre di sei blocchi consecutive in picco (R2)
di svuotamenti col marchio della prima ondata (R4), a 10 sat/vB o più. La
soglia tiene fuori il programma diffuso di settembre, che paga 1-3
sat/vB. Gli episodi sono 709, 565 piccoli (meno di 30 svuotamenti e meno
di 1 BTC) e 144 più grandi; 116 dei 144 hanno anche le firme come la
prima ondata. È il rumore di fondo di una famiglia di programmi;
2. sceglie i candidati con i collettori (R3) e la coerenza col firmware
(R5). **Nessuno somiglia alla prima ondata**: nessuno arriva a centinaia
di indirizzi verso pochi collettori, e il maggiore, 45 BTC, va a 12
destinazioni diverse;
3. profila uno per uno i cinque più vicini (R5 completo): uno solo ha il
profilo degli indirizzi svuotati, ed è piccolo, nell'aprile del 2025, 12
indirizzi e 5,75 BTC, con i fondi finiti in un servizio.
La regola del secondo passo (R8), applicata agli stessi cinque anni, trova
27 picchi uno a uno, nessuno di scala paragonabile: il maggiore vale 3,72
BTC.
Episodi con il marchio della prima ondata (fee multipla esatta della stima fissa, a 10 sat/vB o più), per trimestre, dal secondo trimestre 2021 al 9 luglio 2026: 709 in tutto, 565 piccoli (meno di 30 svuotamenti e meno di 1 BTC) e 144 grandi; il trimestre più fitto è il secondo del 2024, con 172. Nessuno somiglia alla prima ondata, che conta da sola 1.195 svuotamenti in un episodio e sta fuori scala. Il grafico dice che con queste regole non ci sono episodi simili, non che non ci siano stati attacchi. Dati: rilettura dei blocchi 674.951-957.301 con gli artefatti di nodsig.
Il limite di questa controprova è largo, e va detto per intero: le regole
vedono chi si comporta come il responsabile della prima ondata. Restano
fuori, fra gli altri:
- chi svuota a meno di 10 sat/vB, per esempio con piccole prove, perché la
soglia che toglie il programma di settembre toglie anche loro;
- gli svuotamenti a più indirizzi, perché nella storia si cerca solo la
forma semplice;
- chi svuota poche chiavi per volta, che non fa picco;
- chi manda i fondi a molti indirizzi nuovi invece che a un collettore, come
il primo passo dell'ondata a due passi;
- gli indirizzi taproot e p2pk, che la rilettura non ricostruisce.
Un attacco fatto diversamente, prima del 2026, qui non comparirebbe.
La seconda controprova non usa nulla dei report: né la costruzione, né il
profilo, né le date. Conta, in finestre di sei ore, gli indirizzi con monete
ferme da più di un anno che finiscono in collettori nuovi, e segnala le
finestre sopra il 99° percentile di due mesi e mezzo di blocchi. Il giorno
più anomalo emerge da solo: il 31 luglio (blocchi 960.336-960.479, tre
finestre consecutive), e fra i collettori ricompaiono il gruppo delle 7:34 e il
gruppo delle 5:48. Non vede la prima ondata: 1.195 indirizzi in una
finestra restano sotto la soglia, che è di 5.455. Fra le finestre che la
superano ci sono consolidazioni di polvere, migliaia di indirizzi da pochi
satoshi riuniti in una volta: contando indirizzi, pesano quanto un attacco.
Conta anche i proprietari che consolidano i propri indirizzi.
Una versione rivista toglie la polvere e prende la soglia da mille finestre
estratte a caso nei cinque anni, con regole fissate prima di guardare i
dati. Per ogni finestra di 36 blocchi, circa sei ore, conta gli indirizzi
che mandano a una stessa destinazione, insieme ad almeno altri 19, più di
10.000 satoshi di monete ferme da almeno un anno. Legge le stesse tabelle
nei cinque anni e nel periodo recente, e perciò vede solo gli svuotamenti da
un solo indirizzo:
| finestra | indirizzi verso destinazioni comuni (numero) | posto su 8.155 finestre | stessi, in BTC | posto |
|---|---|---|---|---|
| soglia (99° percentile delle finestre estratte) | 555 | — | 21,97 | — |
| prima ondata | 1.008 | 53 | 544,68 | 5 |
| gruppo delle 7:34 | 1.040 | 51 | 43,52 | 34 |
| gruppo delle 5:48 | 38 | 914 | 0,63 | 580 |
| secondo passo | 0 | — | 0 | — |
La prima ondata e il gruppo delle 7:34 superano la soglia; il gruppo delle
5:48 no, e il secondo passo, uno a uno, per costruzione nemmeno. Il
conteggio da solo però non è specifico: nei cinque anni la soglia la
superano 83 finestre, quasi tutte consolidazioni di piccoli importi verso
una sola destinazione, con una mediana di 5 BTC. E contare solo monete ferme
da un anno fa perdere 187 dei 1.195 indirizzi della prima ondata, 181 perché
le loro monete erano più giovani. Se si guarda anche il valore, le finestre
anomale in entrambe le misure sono tre in cinque anni: la prima ondata, il
gruppo delle 7:34 e una del 12 giugno 2022. Quest'ultima non c'entra con
l'incidente, e lo dice il firmware: sono monete multifirma nate quasi tutte
prima (6.466 righe su 6.496), consolidate a 3 sat/vB. Lo conferma ciò che la
sua destinazione riceve dopo, circa 15.600 svuotamenti nei 400 blocchi
seguenti: una raccolta continua, cioè un servizio. Una regola che guarda solo
il passato, però, non l'avrebbe scartata: prima di quella finestra la
destinazione non aveva ricevuto niente. La combinazione è stata scelta dopo
aver visto i risultati, e resta un'indicazione, non una prova. Dice però
che, senza nulla dei report, la prima ondata si sarebbe potuta trovare, in
compagnia di un solo falso allarme in cinque anni.
## La reazione
La catena registra anche la reazione. Qui un indirizzo è a rischio se ha
monete create dopo il firmware, ferme da almeno 30 giorni, e la chiave mai
rivelata. Nella settimana dal 31 luglio al 6 agosto (blocchi
960.326-961.333) gli indirizzi a rischio spostati sono stati quattro volte
la media delle tre settimane precedenti. Se si guardano solo le transazioni
costruite come Bitcoin Core o Sparrow, cioè con programmi diversi da quello
usato nell'attacco, il rapporto sale a otto. Il controllo dice quanto di
questo è specifico: le monete create prima del firmware, che non erano a
rischio, nella stessa settimana salgono di 2,5 volte.
Indirizzi con il profilo a rischio spostati per settimana, dal 9 luglio al 24 settembre 2026, divisi per la media delle tre settimane prima dell'incidente (normale = 1), e lo stesso conteggio per le monete create prima del firmware 4.0.0, che non erano a rischio. Nella settimana dal 31 luglio al 6 agosto i primi salgono a 4,07 volte il normale, il controllo a 2,50. Conteggi su un campione di un blocco ogni dieci; l'ultima settimana, parziale, è esclusa. Dati: blocchi letti dal nodo.
Il conteggio è fatto su un campione di un blocco ogni dieci. Riportato alla
catena, dice che nella settimana si sono spostati fra 200.000 e 390.000
indirizzi a rischio in più del normale: l'estremo alto moltiplica per dieci
l'eccesso del campione, l'estremo basso toglie anche l'aumento generale
misurato dal controllo. I bitcoin non si stimano dal campione, perché poche
monete grandi dominano. E quanti di quegli spostamenti fossero di possessori
Coldcard, la catena non lo dice.
Il secondo rialzo, fra il 20 e il 27 agosto, non viene dall'incidente:
almeno metà è fatta da consolidazioni di polvere, lotti fissi da 400 monete
verso pochi indirizzi, a tariffe di circa 2 sat/vB. La misura conta gli
indirizzi, non i bitcoin, e così la polvere pesa quanto una moneta vera.
## Perché le forme cambiano
Quel che segue è una lettura: la catena mostra le forme, non chi agisce né
perché. Messi in fila, i gruppi non si somigliano:
| | prima ondata | gruppo delle 5:48 | gruppo delle 7:34 | primo passo | secondo passo |
|---|---|---|---|---|---|
| quando (ora del blocco, UTC) | 30/07 01:10 | 31/07 05:48 | 31/07 07:34 | 31/07 12:23 | 01/08 05:48 |
| costruzione | nessuna sostituzione possibile | sostituzione possibile | sostituzione possibile | nessuna sostituzione possibile | nessuna sostituzione possibile |
| fee (sat/vB), e volte la mediana del mercato | 30 sulla stima fissa, 29 volte | 10 sulla dimensione della transazione, 10 volte | 50 sulla dimensione della transazione, 49 volte | circa 200 in 210 transazioni su 296, circa 200 volte | 10 sulla stima fissa, 10 volte |
| forma | una transazione per indirizzo, 4 collettori | molte transazioni da più indirizzi, 1 collettore | una transazione per indirizzo, 1 collettore | fino a 10 indirizzi per transazione, nessun collettore | uno a uno verso indirizzi p2wsh |
| firme corte cercate | no (48% da 72 byte) | non misurato | no (circa metà da 72 byte) | non misurato | no (52% da 72 byte); sì nelle spese di settembre |
| mediana svuotata per indirizzo | 0,27 BTC | 0,010 BTC | 0,010 BTC | 0,014 BTC | — |
| dove sono i fondi, al 25 settembre | fermi | trust di recupero | fermi | al secondo passo | coinjoin, THORChain, fermi |
Tre spiegazioni, che non si escludono.
1. **Più attori, dopo che il difetto diventa noto.** La prima ondata cade il
30 luglio, prima della correzione del firmware: chi l'ha fatta
probabilmente sapeva in anticipo. Dal 31 i gruppi hanno costruzioni, fee
e destini diversi, e uno si dichiara un recupero. Anche Galaxy conta
decine di footprint;
2. **lo stesso attore che cambia strategia**, dalla prima ondata ai due
passi. Li accomunano la stima fissa con tariffe intere, la costruzione e
le firme senza la ricerca di quelle corte. Dopo quattro collettori ben
visibili vengono fondi sparsi, indirizzi 2-di-2 e coinjoin, cioè fondi
più difficili da seguire. Ma il marchio lo usa anche un programma
diffuso: stesso strumento non vuol dire stessa mano;
3. **bersagli che si esauriscono, e una corsa.** La prima ondata prende
saldi venti volte più alti degli altri gruppi; dal 31 luglio i
proprietari spostano i fondi, e il bacino si restringe. Pagare 200 volte
il mercato ha senso solo se qualcuno è in gara per gli stessi indirizzi:
altri attaccanti, chi voleva restituire, i proprietari stessi.
Una modalità sola, ripetuta finché ci sono indirizzi pieni, sarebbe stata
plausibile finché il difetto lo conosceva uno solo. Da quando è pubblico
conta arrivare primi, e la fretta, i cambi di programma e le tariffe da
corsa sono coerenti con questo. Quale spiegazione pesi di più, la catena da
sola non lo dice.
## Rifare i numeri
Ogni numero di questa pagina si rifà. Gli artefatti dipendono solo dalla
catena: dagli stessi blocchi escono gli stessi file, byte per byte, e chi li
costruisce fino al blocco 957.301 ottiene le stesse impronte.
| artefatto | impronta |
|---|---|
| indice delle monete (outpoint-index-v3) | `c5ab330944162f2a70df92d2163210742fa8bb11c66e6211b017cf4058471f70` |
| storia, fee e spese comuni (outpoint-derived-v3) | `4650474c729ce9f011484e50f7f4f3cc8f2fe5e89bb2efeb7abe59686499413e` |
| archivio delle chiavi rivelate (reveal-archive-v4) | `a4b678c52089cbb4a86bf54583947bbc565aab16e855b1ab2e53d7e312b404f7` |
| intestazioni (headers-v2) | `6af1fed6c48f59461efefbb0868a2e002fcfb68cb7fd578a10fca2b538cbe5d4` |
Le interrogazioni sono comandi di nodsig 3.4.0. Dove nessun comando basta
serve uno script proprio; gli script di questa indagine non sono pubblici,
ma le regole che li guidano sono quelle scritte sopra, e bastano per
riscriverli. Riscritte da capo per controllo, su una seconda lettura dei
blocchi, le stesse regole riportano la prima ondata al satoshi e il secondo
passo dell'ondata a due passi a 288 indirizzi p2wsh di arrivo e 207,09 BTC.
| passo | comando di nodsig 3.4.0 | oppure |
|---|---|---|
| profilo di un indirizzo: primo arrivo, ricezioni, spese | `derived history`; per un elenco `check --file` | per gli aggregati, l'esempio `examples/address-set-profile/` |
| la chiave era già comparsa prima di un'altezza? | `check --key`, `archive lookup` | |
| spese comuni | `derived cospends` | |
| fee di una transazione | `derived fee` | |
| altezza delle monete spese | `index lookup` | |
| memo di una transazione (dati in un output OP_RETURN) | `graph show`, fino al 9 luglio | dopo, lettura dei blocchi |
| costo degli artefatti | `nodsig report` | |
| blocchi recenti, svuotamenti e picchi, seguito dei fondi dopo il 9 luglio, settimane e lettura senza i report | | script sul nodo, con le regole di questo pezzo |
| tariffe, età e tipi delle monete svuotate, per i blocchi dell'incidente | | il JSON dei blocchi dal nodo, che porta fee, dimensione e le monete spese |
I tempi dipendono soprattutto da come si leggono i dati. La tabella degli
svuotamenti dei cinque anni, 96,8 milioni di righe e 10,9 GB, la lettura
cieca rivista la ripercorre dal disco USB in 4-6 minuti, misurati con due
programmi scritti in modo indipendente, se legge a blocchi da 16 MB e separa
i campi da sé. Con il lettore CSV generico e le letture piccole predefinite,
attraverso il montaggio di una macchina virtuale, ci vogliono 36 minuti:
stessi numeri, byte per byte. Bastano tre accorgimenti: letture grandi e in
sequenza, in una passata sola; un lettore semplice quando il formato lo
permette; un tetto alla memoria. Tenendo in memoria una finestra alla volta,
la lettura non supera i 53 MB.
La base di questo pezzo si ferma al 9 luglio 2026, prima dell'incidente, e
le settimane successive sono state lette dal nodo. Con la base estesa fino a
fine settembre diventerebbero comandi anche il profilo degli indirizzi
svuotati più di recente, il seguito dei fondi e i memo. Resterebbero lettura
dei blocchi il riconoscimento dei gruppi e i dettagli interni delle
transazioni (versione, locktime, sequence, firme), che gli artefatti non
conservano. Quei dettagli si possono prendere da qualunque fonte, anche da
un block explorer, e verificare contro i propri artefatti: l'identificativo
della transazione per i suoi campi, l'intestazione del blocco per le firme.
nodsig ha i pezzi per farlo, non ancora un comando.
## Che cosa dice la catena
Resta aperto ciò che le regole non raggiungono: dove sta la parte restante
della differenza con Galaxy, se prima del 2026 ci sono stati attacchi con un
altro comportamento, quanti degli spostamenti di quella settimana fossero di
chi aveva un Coldcard.
La catena dice che cosa è successo alle monete, non chi le ha mosse né
perché. Ma lo dice a chiunque la rilegga, con gli stessi byte per tutti. È la
differenza fra un numero ricevuto e un numero verificato: il primo chiede
fiducia in chi l'ha contato, il secondo chiede soltanto un nodo, degli
indici e il tempo di rifare il conto.
## Riferimenti
- Praveen Perera, [«Inside Wave 1: Tracing the Attacker's Steps Through the
1,082 BTC Coldcard Drain»](https://praveenperera.com/blog/coldcard-mk3-weak-rng-wave1/),
12 agosto 2026: la prima ondata, transazione per transazione.
- Galaxy Research, [thread di aggiornamento sull'incidente](https://x.com/glxyresearch/status/2088252639767085417)
e [sulla Wave 3](https://x.com/glxyresearch/status/2096785347929608296), su X.
- Decrypt, [«Coldcard Bitcoin Thefts Slow, But Losses Could Top $150 Million:
Galaxy»](https://decrypt.co/375656/coldcard-bitcoin-thefts-slow-losses-top-150-million),
14 agosto 2026: i conteggi di Galaxy per ondate e footprint.
- The Crypto Times, [«Galaxy Finds $115M Lost in Coldcard Exploit Across 8,865
Addresses»](https://www.cryptotimes.io/2026/08/24/galaxy-finds-115m-lost-in-coldcard-exploit-across-8865-addresses/),
24 agosto 2026: il conteggio di Galaxy usato per il confronto.
- CoinDesk, [«Bitcoin cold-wallet attack spreads to 4,500 addresses as losses
near $89 million»](https://www.coindesk.com/tech/2026/08/02/bitcoin-cold-wallet-attack-spreads-to-4-500-addresses-as-losses-near-usd89-million),
1° agosto 2026: il primo conteggio di Galaxy su tre ondate.
- The Crypto Times, [«52.37 BTC From Coldcard Exploit Moved Into Wyoming
Recovery Trust for Victim Return»](https://www.cryptotimes.io/2026/09/22/52-37-btc-from-coldcard-exploit-moved-into-wyoming-recovery-trust-for-victim-return/),
22 settembre 2026.
- TRM Labs, [«The Largest Hardware Wallet Exploit of 2026: Inside the USD 116
Million Coldcard Hack»](https://www.trmlabs.com/resources/blog/the-largest-hardware-wallet-exploit-of-2026-inside-the-usd-116-million-coldcard-hack).
- Coinkite, [avviso di sicurezza sulla generazione dei seed](https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/)
e [storia delle versioni del firmware Mk3](https://github.com/Coldcard/firmware/blob/master/releases/History-Mk3.md):
4.0.0 del 17 marzo 2021, 4.2.0 del 31 luglio 2026.
- [nodsig](https://github.com/amenano/nodsig), release `v3.4.0`, e l'esempio
[`examples/address-set-profile/`](https://github.com/amenano/nodsig/tree/db08314/examples/address-set-profile)
al commit `db08314`.