Der Fall Stone Man
Das Backup, das 8.999 BTC unerreichbar machte
Stone Man tat, was damals empfohlen wurde: Er sicherte wallet.dat. Eine Zahlung über 1 BTC und ein Neustart zeigten jedoch das Problem. Das Backup war vorhanden, der Schlüssel für den Change-Output über 8.999 BTC nicht.
Die Bitcoin blieben auf der Blockchain.
Das Wallet verlor die Fähigkeit, sie auszugeben.
Der USB-Stick war nicht das Problem. Frühe Bitcoin-Wallets konnten später neue, unabhängige Schlüssel erzeugen. Ein Backup enthielt nur die Schlüssel, die beim Kopieren bereits vorhanden waren.
Inhaltsverzeichnis
Die Nacht des Verlusts
Ein sorgfältiges Backup, eine Selbstzahlung über 1 BTC und ein Neustart mit Folgen
Stone Man hatte 9.000 BTC angesammelt und in einen Bitcoin-Client übertragen, der von einer Debian-Live-CD lief. Das Live-System lag im Arbeitsspeicher; beim Herunterfahren würde das aktive Wallet verschwinden. Deshalb kopierte er wallet.dat zuerst auf einen USB-Stick.
- 01
Schützen
Das Wallet ist gesichert
Die wallet.dat des Wallets mit 9.000 BTC wird vom Live-System auf einen USB-Stick kopiert.
- 02
Zahlung an sich selbst
Stone Man sendet etwa 1 BTC an sich selbst
Während er auf die Bestätigung einer anderen Zahlung wartete, schickte Stone Man etwa 1 BTC an sich selbst. Das Wallet gab dabei den gesamten Output über 9.000 BTC aus und erzeugte für die übrigen 8.999 BTC unbemerkt einen neuen Change-Schlüssel.
- 03
Löschen
Das Live-System wird heruntergefahren
Das Wallet im Arbeitsspeicher enthält den neuen Change-Schlüssel, wird aber gelöscht, bevor das Backup aktualisiert werden kann.
- 04
Wiederherstellen
Das alte Backup wird eingespielt
Die Blockchain zeigt die Transaktion, doch das wiederhergestellte Wallet kann den Change-Output über 8.999 BTC nicht ausgeben.
“Ich hätte nie gedacht, dass es mein gesamtes Guthaben gefährden könnte.”
Was wir über Stone Man wissen
Wer war Stone Man?
Stone Mans echte Identität ist unbekannt. Bekannt ist nur sein BitcoinTalk-Nutzerkonto Nr. 288. Dort schrieb er, dass er die 9.000 BTC nach und nach gekauft, Bitcoin von einer Debian-Live-CD genutzt und wallet.dat vor dem Herunterfahren gesichert hatte.
Wir kennen weder seinen echten Namen noch seinen Wohnort oder Beruf. Auch was nach dem Thread geschah, ist unbekannt. Spätere Behauptungen über seine Identität wurden nicht belegt.
Suche nach dem fehlenden Schlüssel
Die Suche nach dem Schlüssel begann 2010
Wenige Minuten nachdem Stone Man um Hilfe gebeten hatte, bot ein anderer Nutzer an, das alte Wallet zu prüfen. Insti rekonstruierte die Transaktion mit frühen Bitcoin-Werkzeugen von Gavin Andresen. Eine Wiederherstellung wäre nur möglich gewesen, wenn die gesicherte wallet.dat den privaten Schlüssel der Change-Adresse enthalten hätte. Die Analyse von 2010 deutete darauf hin, dass genau dieser Schlüssel vermutlich fehlte. Ohne ihn zeigte die Blockchain zwar, wo die Bitcoin lagen, doch niemand konnte sie ausgeben.
Der erste Versuch, den Schlüssel zu finden
Forennutzer prüften beide Outputs, baten Stone Man um eine Liste der Schlüssel in wallet.dat und fanden die fehlende Change-Adresse. Sie konnten den Verlust erklären, den Schlüssel aber nicht finden.
Eine neue Suche im Jahr 2026
2026 schrieb ein anonymer Forennutzer, er habe mit einer GPU mehr als 6,5 Millionen mögliche Schlüssel getestet. Keiner gehörte zur gesuchten Adresse. Für eine gezieltere Suche brauche er Angaben von Stone Man und Daten aus dem alten Wallet.
Die Transaktion im Detail
Warum eine Zahlung über 1 BTC den gesamten 9.000-BTC-Output bewegte
Bitcoin gibt einen Transaktions-Output immer vollständig aus. Stone Mans Wallet verwendete deshalb den gesamten Output über 9.000 BTC. Es schickte 1 BTC an seine eigene Adresse und legte die übrigen 8.999 BTC in einen neuen Change-Output. Das war keine Zahlung an einen Dieb.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgDer versteckte Fehler
wallet.dat war nur eine Momentaufnahme der vorhandenen Schlüssel
Das ursprüngliche Bitcoin-Wallet speicherte unabhängig erzeugte private Schlüssel. Brauchte es eine neue Change-Adresse, konnte der zugehörige Schlüssel erst nach dem Backup entstehen. Die alte Datei brachte zwar die alten Schlüssel zurück, nicht aber diesen später zufällig erzeugten Schlüssel.
Ein erneuter Blockchain-Scan findet die Transaktion und zeigt, wo die 8.999 BTC liegen. Den fehlenden privaten Schlüssel kann er nicht erzeugen. Die Bitcoin zu sehen bedeutet nicht, sie ausgeben zu können.
Die Warnung kam zuerst
Stone Man war nicht der Erste mit diesem Change-Problem
Am 14. Juli 2010, fast einen Monat vor Stone Mans Beitrag, beschrieb ein anderer Nutzer denselben Fehler in kleinerem Umfang. Er sicherte ein Wallet mit 1,21 BTC, spendete 0,01 BTC, stellte die alte Datei wieder her und sah, wie das Guthaben auf null fiel.
Bis zum 21. Juli warnten Nutzer ausdrücklich: Ein altes Backup konnte zwar den bereits verwendeten Schlüssel enthalten, nicht aber den neu erzeugten Change-Schlüssel. Die Gefahr war bekannt, bevor 8.999 BTC den Fall unvergesslich machten.
Wie sich Bitcoin verändert hat
Von einzelnen Schlüsseln über den Keypool zu deterministischen Wallets
Die Lösung kam in mehreren Schritten. Zuerst bekam Bitcoin einen Vorrat vorab erzeugter Schlüssel. Spätere Wallets konnten alle benötigten Schlüssel aus einem Root-Seed ableiten.
-
Fehler beobachtet
Die Warnung mit 1,20 BTC
Ein Nutzer stellt nach einer Spende über 0,01 BTC ein altes Wallet wieder her und verliert den Zugriff auf den neu erzeugten Change-Output.
-
Vorgeschlagene Lösung
Satoshi schlägt eine Reserve künftiger Schlüssel vor
Vorab generierte Adressen erlauben, dass ein Backup Schlüssel enthält, die das Wallet noch nicht verwendet hat.
-
Fehler mit großen Folgen
Stone Man verliert den Schlüssel für den Change-Output über 8.999 BTC
Danach konnte die Community die architektonische Schwäche nicht mehr ignorieren.
-
Sicherheitspuffer veröffentlicht
Bitcoin 0.3.13.3 bekommt einen Keypool
Ein Vorrat aus 100 vorab erzeugten Schlüsseln gibt einem Backup begrenzten Schutz für künftig verwendete Schlüssel.
-
Deterministische Wallets
BIP 32 definiert einen Schlüsselbaum aus einem Seed
Wallets können künftige Empfangs- und Change-Schlüssel aus einem wiederherstellbaren Root-Seed ableiten, statt nur voneinander unabhängige Zufallsschlüssel zu speichern.
-
Standardmäßig HD
Bitcoin Core nutzt deterministische Schlüsselableitung
Für neu erstellte HD-Wallets kann ein korrektes, seed-gesichertes Backup die abgeleiteten Schlüssel wiederherstellen.
103849419a9c014a69c76b6f96e48b66cbc838ca
Der Commit änderte die Transaktionserstellung: Change-Schlüssel wurden nun aus einem Keypool mit standardmäßig 100 vorab erzeugten Schlüsseln reserviert, statt erst beim Bau einer Transaktion neu zu entstehen.
Was das heute bedeutet
Moderne Seeds veränderten die Wiederherstellung, machten Backups aber nicht überflüssig
Hierarchisch-deterministische Wallets leiten viele Schlüssel aus einem Seed ab. Der genaue Stone-Man-Fehler sollte deshalb nicht auftreten, wenn Seed und Ableitungsinformationen korrekt wiederhergestellt werden. Bitcoin Core führte HD-Wallets mit Version 0.13 ein. Importierte Schlüssel, alte Nicht-HD-Wallets, unbekannte Ableitungspfade, verlorene Passphrasen, beschädigte Backups und ungetestete Wiederherstellungen können Guthaben trotzdem unzugänglich machen.
Kennen Sie die Art Ihres Backups
Seed-Phrase, Descriptor-Export, wallet.dat-Datei, Hardware-Wallet-Backup und importierte private Schlüssel werden unterschiedlich wiederhergestellt.
Wiederherstellung testen, ohne echtes Guthaben zu bewegen
Prüfen Sie, ob das wiederhergestellte Wallet die erwarteten Empfangs- und Change-Adressen ableitet, bevor Sie in einem Notfall raten müssen.
Behandeln Sie importierte Schlüssel als eigenes Risiko
Nach dem ursprünglichen Seed oder Backup importierte Schlüssel benötigen möglicherweise einen eigenen Export und können nicht immer aus der Wiederherstellungsphrase generiert werden.
Guthaben aus alten Wallets sicher übertragen
Erstellen Sie ein aktuelles Wallet aus frischem Wiederherstellungsmaterial, prüfen Sie das Backup, senden Sie einen kleinen Testbetrag und übertragen Sie erst dann den Restbetrag.
Was wir daraus lernen
Ein Backup schützt nur die Schlüssel, die das Wallet sichern kann
Weder die Bitcoin-Kryptografie noch ein Angreifer verursachte den Verlust. Das Problem lag im alten Backup-Modell. Die Blockchain speicherte die Transaktion korrekt, aber das Backup enthielt den später erzeugten Schlüssel nicht.
Primärquellen und Prüfung
Quellen, Transaktion und Code prüfen
Die historischen Aussagen wurden anhand zeitgenössischer BitcoinTalk-Beiträge, der öffentlichen Transaktionsdaten, des ursprünglichen Keypool-Commits, BIP 32 und der aktuellen Wallet-Dokumentation von Bitcoin Core geprüft.
Häufige Fragen
Hat Stone Man wirklich 8.999 BTC verloren?
Die Transaktion verwendete einen Output über 9.000 BTC und erzeugte zwei neue Outputs: 1 BTC und 8.999 BTC. Laut Stone Man fehlte im wiederhergestellten Backup der private Schlüssel für die Change-Adresse. Bei unserer Prüfung waren die 8.999 BTC noch nicht ausgegeben.
Warum reichte Stone Mans wallet.dat-Backup nicht aus?
Das Backup entstand, bevor das Wallet den privaten Schlüssel für die neue Change-Adresse erzeugte. Frühe nicht-deterministische Wallets konnten diesen später zufällig erzeugten Schlüssel weder aus älteren Schlüsseln noch aus der Blockchain rekonstruieren.
War der 8.999-BTC-Output ein Hack oder eine Zahlung an einen Angreifer?
Für diese Transaktion war kein Angreifer nötig. Die 8.999 BTC waren der Change-Output aus Stone Mans Zahlung von 1 BTC an sich selbst. Verloren ging der private Schlüssel für diesen Output.
Kann das gleiche Wallet-Backup-Problem mit einer modernen Seed-Phrase auftreten?
Ein korrekt wiederhergestelltes deterministisches Wallet kann seine Empfangs- und Change-Schlüssel aus dem richtigen Seed ableiten. Die Wiederherstellung kann trotzdem scheitern: etwa bei einem falschen Seed, einer fehlenden Passphrase, unbekannten Ableitungspfaden oder separat importierten Schlüsseln.
Was geschah später mit Stone Man?
Stone Man bat im Forum um Hilfe, bestätigte, dass er die alte Wallet-Datei noch hatte, und beantwortete technische Fragen. Später schrieb er nichts mehr. Wir wissen nicht, warum und ob er privat weiter nach dem Schlüssel suchte.