pull down to refresh
1765 sats \ 9 replies \ @jennann OP 30 Aug 2023 \ parent \ on: Need help recovering wallet from 2010 bitcoin
Thanks Jimmy. Big fan of your writing. I think a script is a good idea.
Below is the exact format including the location of the question marks, but I did change each character to something random and different than the original. When I get off work later I will try adding the 0x in front of each side, but still unsure of significance of the question marks. At first I wasn't sure if I had two 40 character length keys, or one 66-80 character keys Not sure why question marks would only be in half the writing.
0486 | 4AE5F | 41BC
A58F | 3FB3A | 1AD7
34F6 | 2AEB9
37A4 | 4AE5F
7?A4 | ?42? | 6F?? | ??D8
71?D | 6?A? | ?FCA | 86B?
32?F
7F?B
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
The really odd thing here is the 5-letter hex found in the second column of the first 4 lines. Hex almost always come in pairs as each byte is 8 bits and each hex letter is 4 bits.
So doing some math 15 bytes in first chunk, 9 bytes, second chunk. 16 bytes third chunk, 4 bytes fourth chunk. 40 bytes is too much for a private key (they're 32 bytes) and 24 could be it, I guess. I can write you a script that you can run to check if the 24 bytes come out to the address you were looking at. I'm guessing it's uncompressed SEC since it's so early, and that's a detail you're going to need to know about for address generation. DM me on Twitter if you want to try it.
reply
Sorry, that was an accident when writing the example. Every block is only four characters. How does that change things?
The only other thing I can think about if nothing else works, is I took the Bitcoin Core backup it gave me and converted it into to HEX, so if someone found it they wouldn't know what is was.
We hear all about these examples now, but I wasn't aware of those risks back then.
reply
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.
reply
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