Il caso Stone Man
Dentro il problema di backup wallet Bitcoin che ha perso 8.999 BTC
Stone Man ha fatto ciò che gli utenti attenti dovevano fare: ha fatto il backup di wallet.dat. Poi un pagamento da 1 BTC e un riavvio hanno rivelato il difetto. Il backup c'era, la chiave per il resto da 8.999 BTC no.
La blockchain non ha mai perso le monete.
Il wallet ha perso la capacità di spenderli.
Questa distinzione trasforma la storia da un problema di USB difettosa a un problema di architettura del wallet. I primi Bitcoin non derivavano ogni chiave futura da una seed recuperabile. Un backup era solo un'istantanea delle chiavi esistenti al momento della copia.
Indice
La notte della perdita
Un backup accurato, un pagamento a se stessi di 1 BTC e un riavvio con conseguenze durature
Stone Man aveva accumulato 9.000 BTC e li aveva trasferiti in un client Bitcoin avviato da un live CD Debian. Il sistema live viveva in memoria, quindi spegnerlo avrebbe cancellato il wallet attivo. Prima ha copiato wallet.dat su una chiavetta.
- 01
Proteggi
Il wallet è stato salvato
Il wallet.dat da 9.000 BTC viene copiato dal sistema live su una chiavetta.
- 02
Autopagamento
Stone Man si invia circa 1 BTC
Mentre controllava quando un altro pagamento sarebbe stato confermato, Stone Man si invia circa 1 BTC. Il wallet spende l'intero output di 9.000 BTC e crea silenziosamente una nuova chiave di resto per il saldo.
- 03
Cancella
Il sistema live si spegne
Il wallet in memoria contenente la nuova chiave di cambio scompare prima che il backup venga aggiornato.
- 04
Ripristina
Il vecchio backup ritorna
La blockchain mostra la transazione, ma il wallet ripristinato non può spendere l'output di cambio da 8.999 BTC.
“Non avrei mai immaginato potesse compromettere tutto il mio saldo.”
Cosa sappiamo di Stone Man
Chi era Stone Man?
L'identità reale di Stone Man è sconosciuta. Il suo profilo BitcoinTalk era l'account 288. Nel forum ha detto di aver acquistato 9.000 BTC nel tempo, di aver usato Bitcoin su un live CD Debian e di aver salvato una copia di wallet.dat prima di spegnere il computer.
Non conosciamo il suo vero nome, dove vivesse, cosa facesse per lavoro o cosa sia successo dopo il thread. Le affermazioni successive sulla sua identità non sono state provate.
Alla ricerca della chiave mancante
Le ricerche della chiave sono iniziate nel 2010
Pochi minuti dopo che Stone Man ha chiesto aiuto, un altro utente si è offerto di controllare il vecchio wallet. Insti ha quindi ricostruito la transazione utilizzando i primi strumenti Bitcoin di Gavin Andresen. Per un recupero riuscito, il file wallet.dat salvato doveva contenere la chiave privata dell'indirizzo di resto. L'analisi del 2010 suggeriva che probabilmente non fosse così. Senza quella chiave, la blockchain poteva mostrare dove fossero le monete, ma nessuno poteva spostarle.
Il primo tentativo di recuperare la chiave
Gli utenti del forum hanno seguito entrambe le uscite della transazione, chiesto a Stone Man di elencare le chiavi nel suo wallet e trovato l'indirizzo di resto mancante. Hanno potuto spiegare la perdita, ma non recuperare la chiave.
Una nuova ricerca nel 2026
Nel 2026, un utente anonimo del forum ha dichiarato di aver testato oltre 6,5 milioni di chiavi possibili con una GPU. Nessuna corrispondeva all'indirizzo mancante. Ha detto che avrebbe avuto bisogno di dettagli da Stone Man e dal suo vecchio wallet per restringere la ricerca.
L'autopsia della transazione
Perché inviare 1 BTC ha spostato tutti i 9.000 BTC
Bitcoin spende gli output delle transazioni come unità intere. Il wallet di Stone Man ha consumato un output da 9.000 BTC, restituito 1 BTC all'indirizzo scelto e creato un secondo output per i restanti 8.999 BTC. Quel secondo output era il resto, non un pagamento rubato.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgIl fallimento nascosto
wallet.dat era un'istantanea, non una promessa sulle chiavi future
Il wallet Bitcoin originale memorizzava chiavi private generate indipendentemente. Quando serviva un nuovo indirizzo di cambio, poteva generare una nuova chiave dopo che il backup era stato fatto. Ripristinare il file più vecchio ripristinava le vecchie chiavi, ma non poteva ricreare una chiave casuale successiva.
Una nuova scansione della blockchain potrebbe ritrovare la transazione e mostrare dove sono andati gli 8.999 BTC. Non può però rigenerare la chiave privata mancante. Visibilità non significa controllo.
L'avvertimento è arrivato prima
Stone Man non è stato il primo a essere colpito dal cambio
Il 14 luglio 2010, quasi un mese prima del post di Stone Man, un altro utente descrisse lo stesso tipo di fallimento su scala minore. Aveva fatto il backup di un wallet con 1,21 BTC, donato 0,01 BTC, ripristinato il file vecchio e visto il saldo scendere a zero.
Entro il 21 luglio, gli utenti avvertivano esplicitamente che un vecchio backup poteva contenere la chiave spesa ma non la nuova chiave di cambio. Il pericolo era noto prima che gli 8.999 BTC lo rendessero indimenticabile.
Come è cambiato Bitcoin
Da chiavi singole a keypool, poi a wallet deterministici
La risposta non è arrivata come una soluzione perfetta. Bitcoin ha prima creato un buffer di sicurezza di chiavi future. I design successivi dei wallet hanno reso intere famiglie di chiavi recuperabili da una seed radice.
-
Fallimento osservato
Avviso di 1,20 BTC
Un utente ripristina un wallet vecchio dopo una donazione di 0,01 BTC e perde l'accesso all'output di cambio appena creato.
-
Proposta di design
Satoshi descrive una coda di chiavi future
Gli indirizzi pre-generati permettevano a un backup di contenere chiavi non ancora usate dal wallet.
-
Fallimento amplificato
Stone Man perde la chiave di cambio da 8.999 BTC
La stessa debolezza architetturale diventa impossibile da ignorare per la comunità.
-
Buffer di sicurezza implementato
Bitcoin 0.3.13.3 introduce il keypool
Un pool predefinito di 100 chiavi pre-generate offre ai backup una copertura futura limitata.
-
Standard deterministico
BIP 32 definisce un albero di chiavi da una singola seed
I wallet possono derivare chiavi future di ricezione e cambio da una radice recuperabile invece di memorizzare solo chiavi casuali non correlate.
-
HD di default
Bitcoin Core adotta la derivazione deterministica delle chiavi
Per i wallet HD appena creati, un backup corretto basato sulla seed può rigenerare le chiavi derivate del wallet.
103849419a9c014a69c76b6f96e48b66cbc838ca
Il commit ha modificato la creazione della transazione per riservare chiavi di cambio da un pool predefinito di 100 chiavi pre-generate invece di generare la chiave solo quando la transazione veniva costruita.
Cosa significa oggi
Le seed moderne hanno cambiato il recupero, ma non hanno reso i backup opzionali
I wallet gerarchici deterministici derivano molte chiavi da una sola seed, quindi il fallimento esatto di Stone Man non dovrebbe accadere se la seed e le informazioni di derivazione corrette sono ripristinate. Bitcoin Core ha introdotto i wallet HD nella versione 0.13. Ma chiavi importate, wallet non-HD vecchi, percorsi di derivazione sconosciuti, passphrase perse, backup danneggiati e procedure di recupero non testate possono ancora bloccare fondi.
Conosci il tipo di backup che possiedi
Frase seed, esportazione descriptor, file wallet.dat, backup hardware wallet e chiave privata importata non si ripristinano allo stesso modo.
Testa il recupero senza spostare fondi reali
Verifica che il wallet ripristinato derivi gli indirizzi di ricezione e cambio attesi prima che un'emergenza ti costringa a indovinare.
Tratta le chiavi importate come rischio separato
Le chiavi importate dopo la seed originale o il backup potrebbero necessitare di una loro esportazione e non sempre possono essere rigenerate dalla frase di recupero.
Migra con cura wallet legacy preziosi
Crea un wallet aggiornato da materiale di recupero fresco, verifica il backup, invia una piccola somma di prova e solo dopo sposta il saldo rimanente.
La lezione duratura
Un backup è completo solo quanto il modello di chiavi su cui si basa
La perdita di Stone Man non fu una rottura della crittografia di Bitcoin né un attaccante sconosciuto che svuotava un wallet. Fu un fallimento nel design del recupero reso visibile da una transazione ordinaria. La rete ha preservato il registro perfettamente; il vecchio backup ha preservato il momento sbagliato.
Fonti primarie e verifica
Segui il registro del forum, la transazione e il codice
Le affermazioni storiche sopra sono state verificate con post contemporanei su BitcoinTalk, il registro pubblico delle transazioni, il commit originale del keypool, BIP 32 e la documentazione attuale di Bitcoin Core.
Domande frequenti
Stone Man ha davvero perso 8.999 BTC?
La transazione pubblica ha speso un output da 9.000 BTC e creato output da 1 BTC e 8.999 BTC. Stone Man ha riferito che la chiave privata per l'indirizzo di cambio da 8.999 BTC era assente dal backup ripristinato, e l'indirizzo non aveva speso output al momento della verifica di questo articolo.
Perché il backup wallet.dat di Stone Man non ha recuperato le monete?
Il backup è stato creato prima che il wallet generasse la chiave privata per il nuovo indirizzo di cambio. I primi wallet non deterministici non potevano ricreare quella chiave casuale successiva da chiavi più vecchie o dalla blockchain.
L'output da 8.999 BTC era un hack o un pagamento a un attaccante?
Non serve un attaccante per spiegare la transazione. Gli 8.999 BTC erano il resto dell'autopagamento da 1 BTC di Stone Man. Il problema è stata la perdita della chiave privata necessaria per spendere quel resto.
Lo stesso problema di backup può accadere con una seed phrase moderna?
Un wallet deterministico correttamente ripristinato può derivare le chiavi di ricezione e cambio attese dalla seed corretta. Il recupero può comunque fallire se la seed è errata o incompleta, la derivazione sconosciuta, le chiavi importate separatamente, manca la passphrase o il backup non è stato testato.
Sappiamo cosa è successo a Stone Man?
Stone Man ha chiesto aiuto nel forum, ha detto di avere ancora il vecchio file wallet e ha risposto a domande tecniche. Successivamente ha smesso di scrivere. Non sappiamo perché né se abbia continuato a tentare di recuperare la chiave in privato.