I also analyzed the blockchain and found all Bitcoin addresses from Gavin's faucet that still has exactly 5 BTC left in it. Here they are in case anyone is interested:

12pcpC4NG6PHifMREyNjnR41PFuudKRM7f 12rQnKpEVv7prwpBucoFVrXDyshpe9sYZy 13toU2eP1aCdnmhjcLWbd8wJgP6D8MVHB7 13xpydFpNmf2ByyjjmcGF1zXdnPs2zQDY1 14F9j4e4WZroFNNVgdCLUaiGTdy1J9BrFQ 167efihXWqHsfussQcj711bXZGQPiePXq8 18piBJepQAmi33zHqDdgWRUvDgYaCgTch4 1Axjj8761sjBQM4Jt2Fq12KwyQA2Z4D2jE 1C4ScBCmcFSz4mmZ6a9nmGq6zkRfUzJAr7 1CtwTtk4DnvNfxQ9Qd1GAgrH7EzbqX9GrJ 1CWqFwfmxEVeHFf1RmuJwUPDLmN6pBHBW5 1DEUUd6Fue8pVvxkT6uRPk9APnnmjxecgY 1DnYvSf65MwEbtW9C5FhbYrqRE3AYg7j4x 1DYFqhdKDkHYytVn66QWKGY4PUebNYH9j9 1G1jAXvQopW3Cris9fxscn9pVWzy9KmdR2 1GqyMrauH8Ws7vWQ3HfB7eeQGR35tThCAT 1GZnkxbjWwQqX8vVXE52ZeZ7P5HHsmBh83 1H26F45ywpZJvGE2f1bWraDmH7E2FnKn5P 1H2vJJ2t6cC2TVw5oqJAPmTt6gs1wizmUu 1HoVneq7AK2x5F5BuivamTsZchVkAxPkCK 1J2aamKZe9pRxGUy6Kfc22hXUKLrxAY4bb 1K1p9F4vWqHP825pYSB9S2MEB3eTUBw32t 1K9156Feso5aVTuoQBa28cpnNwp4agBnG4 1Kog7hAjgVTJQtEGsxsikNU7fV13pamzTP 1NA7gCCfS9Ye5gdpWkmSBJrvhjQByE4VLf 1PF7C5376DXmuE4yWYffujSzCrvEM9HR7D 1PF7UANHt5f7VGsD8f5MAhWsJzsiWv8rRr 1PNZCfCHQo7N42AsdCBfeZP9XGMUYgJZAc 1PvHppN9n5zobsX1ZAr1bE81huUhqjeErn 1rD82Qit1uFVaXZ6YXjm9Ecfmed9eobrr

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.

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.

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?

I'm still working on this.

How do you do that?

Thanks me too!

Wow that’s pretty early. Hal’s wife paying bills asks children’s college?

Let’s hope so

I suppose it will continue to increase

Yep

Lol