Not trying to collect wallet details or sell anything, just want hard problems worth throwing serious "smart" compute at. If it's not a fit I will say so straight up.
Maybe you should look for existing threads about wallet recovery and see if anyone has shared some details on their case. I don't think most of them are comfortable sharing their data with a relatively new tool from a newbie.
How many scenarios have you tried with your own generated wallet? As far as I can remember, major cases of losing backups are related to losing wallet file, mixing up words, typo in seed phrase, corrupted wallet files, etc. Have you tried making a corrupted wallet or near impossible to brute force wallet and see if your tool can achieve reasonable result?
Thanks for your idea with the threads, since I focused on building the software, I didn't lookup for active cases but assume that those will come up more likely as time moves on. Yes I tried corrupted files (such as recovering bytes) or encoding issues. I did all against known original states (otherwise I wouldn't know the outcome of course), but for specific active cases I would for sure customize it individually for sure.
What I'm actually looking for, real, well-documented cases that are genuinely stuck or before or exceeding giving up (understandable).
That will be tough.
Those unsolved "
missing characters" threads out here are mostly those who have fake stories or vague recollection of what actually happened.
For wallet.dat passphrase, mostly (
90%) of them are trying to decrypt fake wallet.dat that they've bought online.
Anyways,
Try this one, OP seem to be quite active (
last login, 5 days ago):
https://bitcointalk.org/index.php?topic=5581585.0(
thread title is irrelevant, it's auto-named by the mod who separated the thread from a similar solved issue)
To get a clearer picture, it's originally a reply to this thread with already solved issue:
https://bitcointalk.org/index.php?topic=5580016.0TL;DR: This "
solved" issue should've been a lot easier but the OP had been entering a partial WIF with a typo.
Disclaimer: I didn't vouch for you when I pointed you to that thread.
Thanks for making me away of those fake stories, yes that protection needs to be both ways (not wasting my time either).
Regarding the referring to the posts (thanks), yes those 140, 145, 150, 155, 160 puzzles have the benefit of the public key is known, but searching in the wrong range doesn't help indeed.
For now I'm not open-sourcing it right now. I've seen too many recovery tools get forked and quietly loaded with malware. (I audited a lot open-source seemingly "legit" repos).
Keeping it closed until I have got a safe way to handle that and especially since I spent countless hours and optimization on it.
My personal opinion on this is:
I won't run closed-source code if I had a recovery case of my own. Period!
Can't follow your arguments. If your tool were open-source, you'd have your own repository, your signed executable(s), preferably reproducible builds, so that anybody could verify that your open source creates exactly your published binary for which cryptographic signatures exist and are verifiable.
Any software can be loaded with a malware payload. What's that for an argument? I don't care if e.g. there are fake Electrum wallets because I don't download Electrum from any other location than the official one and I never skip to check the digital signature.
What I'm actually looking for, real, well-documented cases that are genuinely stuck or before or exceeding giving up (understandable).
I really enjoy solving very complex problems, thus I'm also interesting in failed recovery attempts already behind them to learn and adapt.
Not trying to collect wallet details or sell anything, just want hard problems worth throwing serious "smart" compute at. If it's not a fit I will say so straight up.
You could construct verifiable sample cases where the solution is known and therefore recovery results can be checked.
If I had a recovery case, I would always verify first if my toolchain is capable and properly working to find a correct recovery solution before I spend time and possibly money for crunching power. The constructed sample case could be somewhat simpler to solve to avoid having to spend too much time and usually energy for toolchain verification.
That is completely valid regarding closed-source binaries, but to be clear, it was never meant to be a tool I just hand over for others to run. My primary reason for keeping it closed right now is simply the sheer amount of time, research, and optimization I have poured into these custom CUDA kernels (software and developing time is not free either). It really comes down to the core dilemma of these edge cases, if someone has a genuinely lost wallet that standard tools like btcrecover cannot solve, such as cases with complex structural fragmentation, their choices are either to stay completely stuck or to collaborate (anyway it has to be customized on that specific case, analyzing worthiness etc.) using a different approach. I am not reaching out to spam people or pitch a download. I posted here so that if anyone facing an otherwise hopeless case needs serious help and custom algorithms, they know this option exists. That said, I 100% agree on the input of synthetic benchmarks, I have to spin up blog or something similar for signed test cases. Really appreciate the honest feedback, it is very helpful, thanks!
