Le cas Stone Man
Au cœur du problème de sauvegarde Bitcoin qui a fait perdre 8 999 BTC
Stone Man a fait ce que les utilisateurs prudents devaient faire : sauvegarder wallet.dat. Puis un paiement de 1 BTC et un redémarrage ont révélé la faille. La sauvegarde existait. La clé de la sortie de monnaie de 8 999 BTC, non.
La blockchain n’a jamais perdu les pièces.
Le portefeuille a perdu la capacité de les dépenser.
Cette distinction transforme cette histoire d’une clé USB défectueuse en une histoire d’architecture de portefeuille. Bitcoin ancien ne dérivait pas chaque clé future d’une graine récupérable. Une sauvegarde n’était qu’un instantané des clés existantes au moment de la copie.
Table des matières
La nuit de la perte
Une sauvegarde minutieuse, un paiement à soi-même de 1 BTC, et un redémarrage aux conséquences durables
Stone Man avait accumulé 9 000 BTC et les avait transférés dans un client Bitcoin lancé depuis un live CD Debian. Le système en mémoire, l’arrêt effacerait le portefeuille actif. Il a d’abord copié wallet.dat sur une clé USB.
- 01
Protéger
Le portefeuille est sauvegardé
Le wallet.dat des 9 000 BTC est copié du système actif vers une clé USB.
- 02
Autopaiement
Stone Man s’envoie environ 1 BTC
En vérifiant la confirmation d’un autre paiement, Stone Man s’envoie environ 1 BTC. Le portefeuille dépense la totalité des 9 000 BTC et crée discrètement une nouvelle clé de change pour le reste.
- 03
Effacer
Le système actif s’éteint
Le portefeuille en mémoire contenant la nouvelle clé de monnaie disparaît avant que la sauvegarde ne soit mise à jour.
- 04
Restaurer
L’ancienne sauvegarde revient
La blockchain montre la transaction, mais le portefeuille restauré ne peut pas dépenser la sortie de monnaie de 8 999 BTC.
“Je n’aurais jamais imaginé que cela puisse compromettre tout mon solde.”
Ce que nous savons de Stone Man
Qui était Stone Man ?
La véritable identité de Stone Man est inconnue. Son profil BitcoinTalk était le compte 288. Sur le forum, il a déclaré avoir acheté 9 000 BTC au fil du temps, utilisé Bitcoin sur un live CD Debian, et sauvegardé une copie de wallet.dat avant d’éteindre l’ordinateur.
Nous ne connaissons pas son vrai nom, son lieu de résidence, son métier, ni ce qu’il est advenu après le fil. Les affirmations ultérieures sur son identité n’ont pas été prouvées.
À la recherche de la clé manquante
La recherche de la clé a commencé en 2010
Quelques minutes après que Stone Man a demandé de l’aide, un autre utilisateur a proposé de vérifier l’ancien portefeuille. Insti a ensuite reconstruit la transaction avec les premiers outils Bitcoin de Gavin Andresen. Pour réussir la récupération, le fichier wallet.dat sauvegardé devait contenir la clé privée de l’adresse de change. L’analyse de 2010 suggérait que ce n’était probablement pas le cas. Sans cette clé, la blockchain pouvait indiquer où se trouvaient les bitcoins, mais personne ne pouvait les déplacer.
La première tentative de récupération de la clé
Les membres du forum ont suivi les deux sorties de la transaction, demandé à Stone Man de lister les clés de son portefeuille et ont trouvé l’adresse de la monnaie manquante. Ils ont pu expliquer la perte, mais pas récupérer la clé.
Une nouvelle recherche en 2026
En 2026, un utilisateur anonyme du forum a déclaré avoir testé plus de 6,5 millions de clés possibles avec un GPU. Aucune ne correspondait à l’adresse manquante. Il a indiqué qu’il aurait besoin de détails de Stone Man et de son ancien portefeuille pour réduire la recherche.
L’autopsie de la transaction
Pourquoi envoyer 1 BTC a déplacé les 9 000 BTC
Bitcoin dépense les sorties de transaction en unités entières. Le portefeuille de Stone Man a consommé une sortie de 9 000 BTC, renvoyé 1 BTC à l’adresse choisie, et créé une seconde sortie pour les 8 999 BTC restants. Cette seconde sortie était de la monnaie, pas un paiement volé.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgL’échec caché
wallet.dat était un instantané, pas une promesse sur les clés futures
Le portefeuille Bitcoin original stockait des clés privées générées indépendamment. Lorsqu’il avait besoin d’une nouvelle adresse de monnaie, il pouvait générer une nouvelle clé après la sauvegarde. Restaurer l’ancien fichier restaurait les anciennes clés, mais ne pouvait pas recréer une clé aléatoire ultérieure.
Une nouvelle analyse de la blockchain pourrait retrouver la transaction et montrer où sont passés les 8 999 BTC. Mais elle ne recréera pas la clé privée manquante. Voir n’est pas contrôler.
L’avertissement est venu en premier
Stone Man n’était pas le premier piégé par la monnaie
Le 14 juillet 2010, presque un mois avant le post de Stone Man, un autre utilisateur a décrit le même type d’échec à plus petite échelle. Il a sauvegardé un portefeuille contenant 1,21 BTC, fait un don de 0,01 BTC, restauré l’ancien fichier, et vu le solde tomber à zéro.
Dès le 21 juillet, les utilisateurs avertissaient qu’une ancienne sauvegarde pouvait contenir la clé dépensée mais pas la clé de monnaie nouvellement générée. Le danger était connu avant que 8 999 BTC ne le rendent inoubliable.
Comment Bitcoin a évolué
Des clés isolées au pool de clés, puis aux portefeuilles déterministes
La réponse n’est pas venue sous forme d’une correction parfaite. Bitcoin a d’abord créé un tampon de sécurité de clés futures. Les portefeuilles ultérieurs ont rendu récupérables des familles entières de clés à partir d’une graine racine.
-
Échec observé
Avertissement de 1,20 BTC
Un utilisateur restaure un ancien portefeuille après un don de 0,01 BTC et perd l’accès à la sortie de monnaie nouvellement créée.
-
Conception proposée
Satoshi décrit une file d’attente de clés futures
Les adresses pré-générées permettent à une sauvegarde de contenir des clés que le portefeuille n’a pas encore utilisées.
-
Échec amplifié
Stone Man perd la clé de monnaie des 8 999 BTC
La même faiblesse architecturale devient impossible à ignorer pour la communauté.
-
Tampon de sécurité livré
Bitcoin 0.3.13.3 intègre un pool de clés
Un pool par défaut de 100 clés pré-générées offre aux sauvegardes une couverture limitée dans le temps.
-
Standard déterministe
BIP 32 définit un arbre de clés à partir d’une seule graine
Les portefeuilles peuvent dériver les clés futures de réception et de monnaie à partir d’une racine récupérable au lieu de stocker uniquement des clés aléatoires non liées.
-
HD par défaut
Bitcoin Core adopte la dérivation déterministe des clés
Pour les portefeuilles HD récents, une sauvegarde correcte basée sur la graine peut régénérer les clés dérivées du portefeuille.
103849419a9c014a69c76b6f96e48b66cbc838ca
Le commit a modifié la création de transaction pour réserver les clés de monnaie depuis un pool par défaut de 100 clés pré-générées au lieu de générer la clé uniquement lors de la construction de la transaction.
Ce que cela signifie aujourd’hui
Les graines modernes ont changé la récupération, mais n’ont pas rendu les sauvegardes optionnelles
Les portefeuilles déterministes hiérarchiques dérivent de nombreuses clés d’une seule graine, donc l’échec exact de Stone Man ne devrait pas se produire si la bonne graine et les informations de dérivation sont restaurées. Bitcoin Core a introduit les portefeuilles HD en version 0.13. Mais les clés importées, les anciens portefeuilles non-HD, les chemins de dérivation inconnus, les phrases secrètes perdues, les sauvegardes endommagées et les procédures de récupération non testées peuvent toujours bloquer des fonds.
Sachez quel type de sauvegarde vous possédez
Une phrase de récupération, une exportation de descripteur, un fichier wallet.dat, une sauvegarde de hardware wallet et une clé privée importée ne se restaurent pas de la même manière.
Tester la récupération sans déplacer de fonds réels
Vérifiez que le portefeuille restauré génère les adresses de réception et de monnaie attendues avant qu’une urgence ne vous force à deviner.
Considérez les clés importées comme un risque distinct
Les clés importées après la graine ou la sauvegarde originale peuvent nécessiter une exportation propre et ne peuvent pas toujours être régénérées à partir de la phrase de récupération.
Migrez soigneusement les portefeuilles anciens précieux
Créez un portefeuille actuel à partir d’un matériel de récupération récent, vérifiez sa sauvegarde, envoyez un petit test, puis déplacez le solde restant.
La leçon durable
Une sauvegarde n’est complète que si le modèle de clés sous-jacent l’est
La perte de Stone Man n’était pas une faille cryptographique ni un attaquant inconnu vidant un portefeuille. C’était un échec de conception de récupération révélé par une transaction ordinaire. Le réseau a parfaitement conservé le registre ; l’ancienne sauvegarde a conservé le mauvais instant.
Sources principales et vérification
Suivez le fil du forum, la transaction et le code
Les affirmations historiques ci-dessus ont été vérifiées avec les posts contemporains de BitcoinTalk, le registre public des transactions, le commit original du pool de clés, BIP 32, et la documentation actuelle du portefeuille Bitcoin Core.
Questions fréquentes
Stone Man a-t-il vraiment perdu 8 999 BTC ?
La transaction publique a dépensé une sortie de 9 000 BTC et créé des sorties de 1 BTC et 8 999 BTC. Stone Man a signalé que la clé privée de l’adresse de monnaie de 8 999 BTC était absente de la sauvegarde restaurée, et que l’adresse n’avait dépensé aucune sortie lors de la vérification de cet article.
Pourquoi la sauvegarde wallet.dat de Stone Man n’a-t-elle pas récupéré les pièces ?
La sauvegarde a été créée avant que le portefeuille ne génère la clé privée pour la nouvelle adresse de monnaie. Les portefeuilles non déterministes anciens ne pouvaient pas recréer cette clé aléatoire ultérieure à partir des clés plus anciennes ou de la blockchain.
La sortie de 8 999 BTC était-elle un piratage ou un paiement à un attaquant ?
Aucun attaquant n’est nécessaire pour expliquer la transaction. Les 8 999 BTC étaient la monnaie de l’autopaiement de 1 BTC de Stone Man. L’échec vient de la perte de la clé privée nécessaire pour dépenser cette monnaie.
Le même problème de sauvegarde peut-il survenir avec une phrase de récupération moderne ?
Un portefeuille déterministe restauré correctement peut générer ses clés de réception et de monnaie attendues à partir de la bonne graine. La récupération peut échouer si la graine est erronée ou incomplète, si la configuration de dérivation est inconnue, si des clés ont été importées séparément, si une phrase secrète manque, ou si la sauvegarde n’a jamais été testée.
Savons-nous ce qu’il est advenu de Stone Man ?
Stone Man a sollicité l’aide du forum, affirmant posséder toujours l’ancien fichier wallet, et a répondu aux questions techniques. Il a ensuite cessé de publier. Nous ignorons pourquoi ni s’il a poursuivi en privé ses tentatives de récupération de la clé.