De Stone Man zaak
Binnen het Bitcoin Wallet Backup Probleem dat 8.999 BTC verloor
Stone Man deed wat zorgvuldige gebruikers werd aangeraden: backup maken van wallet.dat. Toen onthulden één betaling van 1 BTC en één herstart de fout. De backup bestond, de sleutel voor de 8.999 BTC wisseloutput niet.
De blockchain heeft de munten nooit verloren.
De wallet verloor de mogelijkheid om ze te besteden.
Dat onderscheid maakt er een verhaal over wallet-architectuur van in plaats van een slechte USB-drive. Vroege Bitcoin leidde niet elke toekomstige sleutel af van één herwinbare seed. Een backup was slechts een momentopname van de sleutels die bestonden toen het werd gekopieerd.
Inhoudsopgave
De nacht van het verlies
Een zorgvuldige backup, een zelfbetaling van 1 BTC en een herstart met blijvende gevolgen
Stone Man had 9.000 BTC verzameld en verplaatste ze naar een Bitcoin client draaiend vanaf een Debian live CD. Het live systeem draaide in het geheugen, dus afsluiten zou de actieve wallet wissen. Hij kopieerde eerst wallet.dat naar een flashdrive.
- 01
Beschermen
De wallet is geback-upt
De 9.000 BTC wallet.dat wordt van het live systeem naar een flashdrive gekopieerd.
- 02
Zelfbetaling
Stone Man stuurt ongeveer 1 BTC naar zichzelf
Terwijl hij wachtte op de bevestiging van een andere betaling, stuurde Stone Man ongeveer 1 BTC naar zichzelf. De wallet gaf de volledige output van 9.000 BTC uit en maakte ongemerkt een nieuwe change key voor het resterende bedrag aan.
- 03
Wissen
Het live systeem wordt afgesloten
De in-memory wallet met de nieuwe wisselsleutel verdwijnt voordat de backup wordt vernieuwd.
- 04
Herstellen
De oude backup keert terug
De blockchain toont de transactie, maar de herstelde wallet kan de 8.999 BTC wisseloutput niet besteden.
“Ik had nooit gedacht dat het mijn hele saldo kon compromitteren.”
Wat we weten over Stone Man
Wie was Stone Man?
De echte identiteit van Stone Man is onbekend. Zijn BitcoinTalk-profiel was account 288. In het forum zei hij dat hij in de loop van de tijd 9.000 BTC had gekocht, Bitcoin gebruikte op een Debian live-cd en een kopie van wallet.dat had opgeslagen voordat hij de computer uitschakelde.
We kennen zijn echte naam niet, waar hij woonde, wat hij voor werk deed of wat er na de discussie gebeurde. Latere beweringen over zijn identiteit zijn niet bewezen.
Op zoek naar de ontbrekende sleutel
Mensen begonnen in 2010 naar de sleutel te zoeken
Enkele minuten nadat Stone Man om hulp vroeg, bood een andere gebruiker aan om de oude wallet te controleren. Insti reconstrueerde vervolgens de transactie met vroege Bitcoin-tools van Gavin Andresen. Voor een succesvolle herstel moest de opgeslagen wallet.dat de private key van het change-adres bevatten. De analyse uit 2010 suggereerde dat dit waarschijnlijk niet het geval was. Zonder die sleutel kon de blockchain wel tonen waar de munten waren, maar kon niemand ze verplaatsen.
De eerste poging om de sleutel te herstellen
Forumgebruikers volgden beide transactie-uitgangen, vroegen Stone Man om de sleutels in zijn wallet op te sommen en vonden het ontbrekende wisseladres. Ze konden het verlies verklaren, maar niet de sleutel terugvinden.
Een nieuwe zoektocht in 2026
In 2026 zei een anonieme forumgebruiker dat ze meer dan 6,5 miljoen mogelijke sleutels met een GPU hadden getest. Geen enkele kwam overeen met het ontbrekende adres. Ze zeiden dat ze details van Stone Man en zijn oude wallet nodig hadden om de zoektocht te verkleinen.
De transactie-autopsie
Waarom het verzenden van 1 BTC alle 9.000 BTC verplaatste
Bitcoin besteedt transactie-uitgangen als hele eenheden. Stone Man's wallet gebruikte één 9.000 BTC output, stuurde 1 BTC terug naar zijn gekozen adres en maakte een tweede output aan voor de resterende 8.999 BTC. Die tweede output was wisselgeld, geen diefstalbetaling.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgDe verborgen fout
wallet.dat was een momentopname, geen belofte over toekomstige sleutels
De originele Bitcoin wallet bewaarde onafhankelijk gegenereerde privésleutels. Wanneer een nieuw wisseladres nodig was, kon het een nieuwe sleutel genereren nadat de backup was gemaakt. Het herstellen van het oudere bestand herstelde de oude sleutels, maar kon geen latere willekeurige sleutel recreëren.
Een blockchain-heranalyse kan de transactie terugvinden en tonen waar de 8.999 BTC naartoe gingen. De ontbrekende privésleutel kan echter niet worden gereconstrueerd. Zichtbaarheid is geen controle.
De waarschuwing kwam eerst
Stone Man was niet de eerste die door wisselgeld werd getroffen
Op 14 juli 2010, bijna een maand voor Stone Man's bericht, beschreef een andere gebruiker hetzelfde soort fout op kleinere schaal. Ze maakten een backup van een wallet met 1,21 BTC, doneerden 0,01 BTC, herstelden het oude bestand en zagen het saldo naar nul dalen.
Tegen 21 juli waarschuwden gebruikers expliciet dat een oude backup de gebruikte sleutel kon bevatten, maar niet de nieuw gegenereerde wisselsleutel. Het gevaar was bekend voordat 8.999 BTC het onvergetelijk maakte.
Hoe Bitcoin veranderde
Van losse sleutels naar een keypool, daarna naar deterministische wallets
De oplossing kwam niet als één perfecte fix. Bitcoin maakte eerst een veiligheidsbuffer van toekomstige sleutels. Latere wallet ontwerpen maakten hele families sleutels herwinbaar uit één root seed.
-
Fout waargenomen
Een waarschuwing van 1,20 BTC
Een gebruiker herstelt een oude wallet na een donatie van 0,01 BTC en verliest toegang tot de nieuw aangemaakte wisseloutput.
-
Ontwerp voorgesteld
Satoshi beschrijft een wachtrij van toekomstige sleutels
Vooraf gegenereerde adressen laten een backup sleutels bevatten die de wallet nog niet had gebruikt.
-
Fout versterkt
Stone Man verliest de 8.999 BTC wisselsleutel
Dezelfde architecturale zwakte wordt onmogelijk voor de community om te negeren.
-
Veiligheidsbuffer geleverd
Bitcoin 0.3.13.3 krijgt een keypool
Een standaardpool van 100 vooraf gegenereerde sleutels geeft backups een beperkte toekomstige dekking.
-
Deterministische standaard
BIP 32 definieert een boom van sleutels vanuit één seed
Wallets kunnen toekomstige ontvangstadressen en wisselsleutels afleiden van een herwinbare root in plaats van alleen ongebruikte willekeurige sleutels op te slaan.
-
Standaard HD
Bitcoin Core introduceert deterministische sleutelafleiding
Voor nieuw aangemaakte HD wallets kan één correcte seed-ondersteunde backup de afgeleide sleutels van de wallet opnieuw genereren.
103849419a9c014a69c76b6f96e48b66cbc838ca
De commit wijzigde het aanmaken van transacties om wisselsleutels te reserveren uit een standaardpool van 100 vooraf gegenereerde sleutels in plaats van de sleutel pas te genereren bij het bouwen van de transactie.
Wat dit vandaag betekent
Moderne seeds veranderden herstel, maar maakten backups niet optioneel
Hiërarchische deterministische wallets leiden veel sleutels af uit één seed, dus de exacte Stone Man fout zou niet moeten optreden als de juiste seed en afleidingsinformatie worden hersteld. Bitcoin Core introduceerde HD wallets in versie 0.13. Maar geïmporteerde sleutels, oude niet-HD wallets, onbekende afleidingspaden, verloren wachtwoorden, beschadigde backups en ongeteste herstelprocedures kunnen nog steeds fondsen blokkeren.
Weet welk type backup u heeft
Een seed phrase, descriptor export, wallet.dat-bestand, hardware-wallet backup en geïmporteerde privésleutel herstellen niet op dezelfde manier.
Test herstel zonder echte fondsen te verplaatsen
Verifieer dat de herstelde wallet de verwachte ontvangstadressen en wisseladressen afleidt voordat een noodsituatie u dwingt te gokken.
Behandel geïmporteerde sleutels als een apart risico
Sleutels geïmporteerd na de originele seed of backup hebben mogelijk een eigen export nodig en kunnen niet altijd worden hersteld met de recovery phrase.
Migreer waardevolle legacy wallets zorgvuldig
Maak een actuele wallet van verse herstelgegevens, verifieer de backup, stuur een kleine testbetaling en verplaats dan pas het resterende saldo.
De blijvende les
Een backup is slechts zo compleet als het onderliggende sleutelsysteem
Stone Man's verlies was geen breuk in Bitcoin's cryptografie en geen onbekende aanvaller die een wallet leegroofde. Het was een herstelontwerpfout zichtbaar gemaakt door een gewone transactie. Het netwerk bewaarde het grootboek perfect; de oude backup bewaarde het verkeerde moment.
Primaire bronnen en verificatie
Volg het forumverslag, de transactie en de code
De historische claims hierboven zijn gecontroleerd aan de hand van hedendaagse BitcoinTalk berichten, het publieke transactieregister, de originele keypool commit, BIP 32 en de huidige Bitcoin Core wallet documentatie.
Veelgestelde vragen
Heeft Stone Man echt 8.999 BTC verloren?
De publieke transactie besteedde één 9.000 BTC output en maakte outputs van 1 BTC en 8.999 BTC aan. Stone Man meldde dat de privésleutel voor het 8.999 BTC wisseladres ontbrak in de herstelde backup, en het adres had geen outputs besteed toen dit artikel werd geverifieerd.
Waarom herstelde Stone Man's wallet.dat backup de munten niet?
De backup werd gemaakt voordat de wallet de privésleutel voor het nieuwe wisseladres genereerde. Vroege niet-deterministische wallets konden die latere willekeurige sleutel niet recreëren uit oudere sleutels of de blockchain.
Was de 8.999 BTC output een hack of een betaling aan een aanvaller?
Er is geen aanvaller nodig om de transactie te verklaren. De 8.999 BTC was de wisseloutput van Stone Man's 1 BTC zelfbetaling. De fout was het verliezen van de privésleutel om dat wisselgeld te besteden.
Kan hetzelfde wallet backup probleem optreden met een moderne seed phrase?
Een correct herstelde deterministische wallet kan de verwachte ontvangstadressen en wisselsleutels afleiden van de juiste seed. Herstel kan mislukken als de seed onjuist of incompleet is, de afleidingsmethode onbekend is, sleutels apart zijn geïmporteerd, een wachtwoord ontbreekt of de backup nooit getest is.
Weten we wat er met Stone Man is gebeurd?
Stone Man vroeg het forum om hulp, zei dat hij het oude wallet-bestand nog had en beantwoordde technische vragen. Later stopte hij met posten. We weten niet waarom en ook niet of hij privé naar de sleutel bleef zoeken.