pull down to refresh
10 sats \ 5 replies \ @jimmysong 30 Aug 2023 \ parent \ on: Need help recovering wallet from 2010 bitcoin
12 bytes/8 bytes/16 bytes/4 bytes
There's no obvious way to get 32 bytes, which is the typical length of a private key. I guess it could be that the last 4 bytes are not anything and the first 3 chunks are 32 bytes + 4 byte checksum. If it were and you had those question marks in those places, that's 10 question marks or 40 bits that you have to roll through or 2^40 of attempts. That's about a trillion different possibilities, which is doable, especially with some GPUs. I did 2^44 in about 2 days a while back and that cost about $800 to rent the requisite GPUs if I remember correctly. So, 2^40 should be 1/16th of that, or 3 hours and $50? But there's some custom code that needs to be written to calculate the address and there's no guarantee that that's what these letters mean.
Quick update on my effort to recover a corrupted 66-character private key from 2010. Thanks again for all the helpful input.
Plan A assumed the key had two extraneous hex characters. I ran btcrecover across all 2,145 two-character deletions with no luck.
I’m now shifting to a more advanced typo-correction pass (Plan B). The goal is to fully exhaust the “it’s just hex typos” hypothesis using btcrecover’s richer error models: mixed errors (one deletion plus one substitution), adjacent swaps, and systematically increasing the allowed typo count to 3–4 while managing runtime.
In parallel, I’m lining up Plan C. FinderOuter is on the table, though its Mono dependency is a downside for a clean offline setup. I also considered a custom Python script, but for multi-typo searches btcrecover’s C/Cython backend is likely the better bet.
There’s also a more complex angle: the mangled WIF hypothesis. If this isn’t a raw hex key, it could be a fragment of a hex-decoded WIF. A decoded WIF is 74 (uncompressed) or 76 (compressed) characters, including version, key, optional compression flag, and a 4-byte checksum. That would imply my 66-char string is missing 8–10 characters rather than having 2 extra. Recovery here would mean inserting the right characters to satisfy both the derived address and the WIF checksum—brute-force is likely infeasible without stronger constraints.
I’d appreciate any tips on btcrecover flag combos or optimizations for mixed typo models, thoughts on the plausibility of the mangled WIF scenario (especially with 8–10 missing decoded chars), and any other corruption models I should be considering.
reply
Hi folks, I'm still working on this. I have an address.db to check against and several different btcrecover commands I've tried, but without success so far. I'm sure I"m missing some things with the setup. I also create a btcrecover_gui frontend to help me. "https://github.com/gurnec/btcrecover/pull/565" I don't know if btcrecover is the best tool for me to use?
reply
deleted by author
deleted by author
deleted by author