Stone Man-fallet

Inuti Bitcoin-plånboksproblemet som förlorade 8 999 BTC

Stone Man gjorde som försiktiga användare uppmanades: säkerhetskopiera wallet.dat. Sedan avslöjade en 1 BTC-betalning och en omstart felet. Säkerhetskopian fanns, men nyckeln till 8 999 BTC-växeln gjorde inte det.

Blockkedjan förlorade aldrig mynten.

Plånboken förlorade förmågan att spendera dem.

Den skillnaden gör detta från en historia om en dålig USB-enhet till en historia om plånboksarkitektur. Tidig Bitcoin härledde inte varje framtida nyckel från en återställbar seed. En säkerhetskopia var bara en ögonblicksbild av nycklarna som fanns när den kopierades.

Natten för förlusten

En noggrann säkerhetskopia, en 1 BTC självbetalning och en omstart med bestående följder

Stone Man hade samlat 9 000 BTC och flyttat dem till en Bitcoin-klient som kördes från en Debian live-CD. Det aktiva systemet kördes i minnet, så en avstängning skulle radera plånboken. Han kopierade först wallet.dat till en flash-enhet.

  1. 01

    Skydda

    Plånboken är säkerhetskopierad

    Den 9 000 BTC wallet.dat kopieras från det aktiva systemet till en flash-enhet.

  2. 02

    Självbetalning

    Stone Man skickar ungefär 1 BTC till sig själv

    Medan han kontrollerade när en annan betalning skulle bekräftas skickar Stone Man ungefär 1 BTC till sig själv. Plånboken använder hela utgången på 9 000 BTC och skapar tyst en ny växelnyckel för resten.

  3. 03

    Radera

    Det aktiva systemet stängs av

    Den minnesbaserade plånboken med den nya växelnyckeln försvinner innan säkerhetskopian uppdateras.

  4. 04

    Återställ

    Den gamla säkerhetskopian återvänder

    Blockkedjan visar transaktionen, men den återställda plånboken kan inte spendera växelutgången på 8 999 BTC.

“Jag drömde aldrig att det kunde äventyra hela mitt saldo.”

Stone Man, BitcoinTalk, 11 augusti 2010— (översatt)

Det vi vet om Stone Man

Vem var Stone Man?

Stone Mans verkliga identitet är okänd. Hans BitcoinTalk-profil var konto 288. I forumet sa han att han köpt 9 000 BTC över tid, använt Bitcoin på en Debian live-CD och sparat en kopia av wallet.dat innan han stängde av datorn.

Vi vet inte hans riktiga namn, var han bodde, vad han arbetade med eller vad som hände efter tråden. Senare påståenden om hans identitet har inte bevisats.

Jakten på den saknade nyckeln

Folk började leta efter nyckeln år 2010

Några minuter efter att Stone Man bad om hjälp erbjöd sig en annan användare att kontrollera den gamla plånboken. Insti byggde sedan om transaktionen med tidiga Bitcoin-verktyg från Gavin Andresen. En lyckad återställning krävde att den sparade wallet.dat innehöll den privata nyckeln för växeladressen. Analysen från 2010 antydde att så troligen inte var fallet. Utan den nyckeln kunde blockkedjan visa var mynten fanns, men ingen kunde flytta dem.

Augusti 2010

Det första försöket att återställa nyckeln

Forumdeltagare följde båda transaktionsutgångarna, bad Stone Man lista nycklarna i sin plånbok och hittade den saknade växeladressen. De kunde förklara förlusten men kunde inte återställa nyckeln.

Maj 2026

En ny sökning år 2026

År 2026 sa en anonym forumanvändare att de testat över 6,5 miljoner möjliga nycklar med en GPU. Ingen matchade den saknade adressen. De behövde detaljer från Stone Man och hans gamla plånbok för att begränsa sökningen.

Transaktionsobduktionen

Varför en överföring på 1 BTC flyttade alla 9 000 BTC

Bitcoin spenderar transaktionsutgångar som hela enheter. Stone Mans plånbok använde en 9 000 BTC-utgång, skickade tillbaka 1 BTC till den adress han valde och skapade en andra utgång för resterande 8 999 BTC. Den andra utgången var växel, inte en stöldbetalning.

Transaktions-ID eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf
Växeladress 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg

Det dolda felet

wallet.dat var en ögonblicksbild, inte ett löfte om framtida nycklar

Den ursprungliga Bitcoin-plånboken lagrade oberoende genererade privata nycklar. När den behövde en ny växeladress kunde den generera en ny nyckel efter att säkerhetskopian gjorts. Att återställa den äldre filen återställde de gamla nycklarna, men kunde inte återskapa en senare slumpmässig nyckel.

En omscanning av blockkedjan kan hitta transaktionen igen. Den kan visa vart 8 999 BTC tog vägen. Men den kan inte återskapa den saknade privata nyckeln. Synlighet är inte kontroll.

Säkerhetskopia på flash-enhet Känd nyckel A Kan känna igen och spendera den ursprungliga utgången
Skapad efter säkerhetskopian
Raderad aktiv plånbok Saknad växelnyckel B Nödvändig för att spendera 8 999 BTC-utgången

Varningen kom först

Stone Man var inte den första som fastnade på växel

Den 14 juli 2010, nästan en månad före Stone Mans inlägg, beskrev en annan användare samma typ av fel i mindre skala. De säkerhetskopierade en plånbok med 1,21 BTC, donerade 0,01 BTC, återställde den gamla filen och såg saldot falla till noll.

Före betalning 1,21 BTC i en utgång
Donation 0,01 BTC
Växel bakom en ny nyckel 1,20 BTC

Den 21 juli varnade användare tydligt för att en gammal säkerhetskopia kunde innehålla den använda nyckeln men inte den nygenererade växelnyckeln. Risken var känd innan 8 999 BTC gjorde den oförglömlig.

Hur Bitcoin förändrades

Från lösa nycklar till keypool, sedan till deterministiska plånböcker

Svaret kom inte som en perfekt lösning. Bitcoin skapade först en säkerhetsbuffert av framtida nycklar. Senare plånboksdesigner gjorde hela familjer av nycklar återställbara från en rotseed.

  1. Fel observerat

    En varning på 1,20 BTC

    En användare återställer en gammal plånbok efter en donation på 0,01 BTC och förlorar tillgång till den nyss skapade växelutgången.

  2. Föreslagen design

    Satoshi beskriver en kö av framtida nycklar

    Förgenererade adresser skulle låta en säkerhetskopia innehålla nycklar som plånboken ännu inte använt.

  3. Fel förstärkt

    Stone Man förlorar växelnyckeln till 8 999 BTC

    Samma arkitektoniska svaghet blir omöjlig för communityn att ignorera.

  4. Säkerhetsbuffert levererad

    Bitcoin 0.3.13.3 får en keypool

    En standardpool med 100 förgenererade nycklar ger säkerhetskopior ett begränsat fönster för framtida täckning.

  5. Deterministisk standard

    BIP 32 definierar ett träd av nycklar från en seed

    Plånböcker kan härleda framtida mottagnings- och växelnycklar från en återställbar rot istället för att bara lagra orelaterade slumpmässiga nycklar.

  6. HD som standard

    Bitcoin Core inför deterministisk nyckelhärledning

    För nyss skapade HD-plånböcker kan en korrekt seed-baserad säkerhetskopia återskapa plånbokens härledda nycklar.

Implementeringshistorik SVN r163 · Bitcoin 0.3.13.3
103849419a9c014a69c76b6f96e48b66cbc838ca

Commiten ändrade transaktionsskapandet för att reservera växelnycklar från en standardpool med 100 förgenererade nycklar istället för att generera nyckeln först när transaktionen byggdes.

Vad detta betyder idag

Moderna seeds förändrade återställning, men gjorde inte säkerhetskopior valfria

Hierarkiska deterministiska plånböcker härleder många nycklar från en seed, så exakt Stone Man-fel bör inte inträffa när rätt seed och härledningsinformation återställs. Bitcoin Core införde HD-plånböcker i version 0.13. Men importerade nycklar, gamla icke-HD-plånböcker, okända härledningsvägar, förlorade lösenfraser, skadade säkerhetskopior och otestade återställningsprocedurer kan fortfarande låsa in medel.

01

Veta vilken typ av säkerhetskopia du har

En seedfras, descriptor-export, wallet.dat-fil, hårdvaruplånbokssäkerhetskopia och importerad privat nyckel återställs inte på samma sätt.

02

Testa återställning utan att flytta riktiga medel

Verifiera att den återställda plånboken härleder förväntade mottagnings- och växeladresser innan en nödsituation tvingar dig att gissa.

03

Behandla importerade nycklar som en separat risk

Nycklar importerade efter originalseed eller säkerhetskopia kan behöva egen export och kan inte alltid återskapas från återställningsfrasen.

04

Migrera värdefulla äldre plånböcker försiktigt

Skapa en aktuell plånbok från färskt återställningsmaterial, verifiera säkerhetskopian, skicka en liten testsumma och flytta sedan återstående saldo.

Den bestående lärdomen

En säkerhetskopia är bara så komplett som nyckelmodellen bakom den

Stone Mans förlust var inte ett brott mot Bitcoins kryptografi och inte en okänd angripare som tömde en plånbok. Det var ett återställningsdesignfel som blev synligt genom en vanlig transaktion. Nätverket bevarade huvudboken perfekt; den gamla säkerhetskopian bevarade fel tidpunkt.

Mynt synliga på kedjan Privat nyckel återställbar från säkerhetskopia

Vanliga frågor

Förlorade Stone Man verkligen 8 999 BTC?

Den offentliga transaktionen spenderade en 9 000 BTC-utgång och skapade utgångar på 1 BTC och 8 999 BTC. Stone Man rapporterade att den privata nyckeln för 8 999 BTC-växeladressen saknades i den återställda säkerhetskopian, och adressen hade inte spenderat några utgångar när denna artikel verifierades.

Varför återställde inte Stone Mans wallet.dat-säkerhetskopia mynten?

Säkerhetskopian skapades innan plånboken genererade den privata nyckeln för den nya växeladressen. Tidiga icke-deterministiska plånböcker kunde inte återskapa den senare slumpmässiga nyckeln från äldre nycklar eller från blockkedjan.

Var 8 999 BTC-utgången en hack eller en betalning till en angripare?

Ingen angripare behövs för att förklara transaktionen. De 8 999 BTC var växelutgången från Stone Mans 1 BTC självbetalning. Felet var att förlora den privata nyckeln som behövdes för att spendera växeln.

Kan samma plånboksbackup-problem hända med en modern seedfras?

En korrekt återställd deterministisk plånbok kan härleda förväntade mottagnings- och växelnycklar från rätt seed. Återställning kan ändå misslyckas om seed är fel eller ofullständig, härledningen okänd, nycklar importerade separat, lösenfras saknas eller säkerhetskopian aldrig testats.

Vet vi vad som hände med Stone Man?

Stone Man bad forumet om hjälp, sa att han fortfarande hade den gamla plånboksfilen och svarade på tekniska frågor. Han slutade senare att posta. Vi vet inte varför eller om han fortsatte försöka återställa nyckeln privat.

Fortsätt undersökningen

Se var plånbokssäkerhet kan brista

Stone Man förlorade tillgången eftersom en backup missade en ny växelnyckel. Jämför med COLDCARD-fallet, där nycklarna fanns men vissa skapades med svag slump, och med address poisoning, där ägaren signerar fel mottagare.