Built a specialized wallet recovery solver for the genuinely "lost" cases

[GigaBrainGain]

Hi all, first post here.

Over the past year  have been building a custom recovery tool, but not for the usual "forgot my password" cases that btcrecover and similar tools already handle well.
I'm going after the harder tail-end: wallets people have basically given up on, where the info is too fragmented for standard brute force to touch in a reasonable time.

What's different is that I wrote custom CUDA kernels for this, hitting 100M+ combinations/minute on a laptop GPU (a lot more on an A100/H200).
Each thread can search its own slice of the space independently instead of duplicating work.
For BIP-39 phrases I built flexible word-pool logic such as known words at fixed positions, known words with unknown positions.
And also probabilistic narrowing (e.g. if several known words start with certain letters, that shifts the odds on what's likely in the unknown slots).
No guarantees, but it cuts the effective search space down a lot in the right cases.

I'm currently testing it on my own BTC/ETH wallet (also the 1000BTC puzzle for difficulty tests on known wallets).

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.

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.

Also happy to talk approach/algorithms with anyone working on similar search problems.

Since this is my first post, I hope everything is fine with the section or "how" I wrote it.

[joniboini]

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?

[nc50lc]

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.0
TL;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.

[Cricktor]

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.

[GigaBrainGain]

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.0
TL;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!

[nc50lc]

What I'm actually looking for, real, well-documented cases that are genuinely stuck or before or exceeding giving up (understandable).

-snip-

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.

There's more to it than just the range.
And when he mentioned the puzzle keys, it's meant only for testing his partial WIF's case.

You should contact the OP to guess if his case is legit and if it fits your criteria since he didn't disclose any vital information in that thread.
A sample 1:1 case would be enough to demonstrate how you'll going to solve it.
I doubt that he will hand you the actual partial WIF though, maybe once you built a solid reputation.

[BitMaxz]

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.

Why not create your own wallet, deposit a small amount, and try to mess up with your own backup? At least, you have your own preferences rather than looking for someone else's wallet based on such information; no one will give you a real wallet unless they are attempting to scam you.


Are you planning to share this tool? But based in your response above, it's a yes, and you want to hand the tool over privately. This is honestly suspicious. How can we be sure that the tool is safe if you don't share the open-source code?

You are a new user with no trust or well-documented history with this tool. Sharing open-source code is straightforward; anyone can review the source code and determine whether the tool contains keyloggers or malware. If you really care about safety, upload it to GitHub and share the open-source code. No one would trust you if you didn't provide anything other than trying to connect some people here and distribute the tool without knowing how safe it is.

[Pmalek]

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!

If you don't want to give your work away for free, that's understandable. That's your right and your decision. Only you know how much effort and time it took to create it. But you also have to understand that you will be faced with more mistrust than someone who took the open-source route. You are brand-new here and if a complex recovery of someone's coins is going to work, that person will be required to hand over to you sensitive data and information. When people see such a request in public, they are going to write warnings not to do that and to never send wallet info to unknown people on the internet.

[GigaBrainGain]

Thanks for the latest comments of all of you! I totally get your arguments and regarding the being "new", I think at one point you are always new. I come from statistics and data science and spent my time with solving problems in other domains, since my long interest of crypto I came to the idea to finally solve problems in that domain too. Thus, whenever you decide to do something new, it could be a cross-domain, in that sense you are always a "newbie". Regarding "just sending over", I believe/experienced that genuine interest in a matter of urge to be solved, comes anyway with connecting and setting ground rules or willingness of each party (TBD). On high stake cases, this is not a quick "hey, here you go, do your thing". Probably those cases are comparable with "donating blood", thousands do that standardized (btcrecover), but for a high risk surgery, you need to lay out options, plan feasibility, risks and potential outcomes. Just to sort in my project a bit. Time will tell and in the meantime I optimize and build showcases.

[Pmalek]

Thanks for the latest comments of all of you! I totally get your arguments and regarding the being "new", I think at one point you are always new. I come from statistics and data science and spent my time with solving problems in other domains, since my long interest of crypto I came to the idea to finally solve problems in that domain too. Thus, whenever you decide to do something new, it could be a cross-domain, in that sense you are always a "newbie".

We were all new at one point in time. There is no argument there. But not all of us were new and required/asked for money and/or sensitive data to be sent to us. That's a big difference. Being new on a forum, where you read, write, and communicate with others is a normal thing. I don't need to be trusted to say what's on my mind. But for other people to give me something of theirs that has value, they will want to know who I am and can they trust me based on how I have conducted myself during my stay here or elsewhere. It's also true that people may drop their guard and initial caution if all previous recovery attempts have failed. They may see it as having reached a point where they have nothing to lose.

You mentioned a history and solving problems in data science and statistics. Is there something tangible there that you could share with the community to show your expertise and help in building trust? Something that a potential "lost case" client can see and realize that they are talking to an individual who knows what they are doing.

[nc50lc]

-snip-

Hey, someone posted a seemingly legit case of lost Electrum password in Technical Support board.
You might want to give it a try, link: /index.php?topic=5595100.0

OP already posted links to its "hash" so you can immediately try without asking for the actual wallet files.
DYOR first of course.

[Nikando]

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.

In my opinion I find that a concept of creating a verifiable sample case is quite feasible in terms of such a recovery tool. It's very reassuring to be able to verify whether the application can actually solve the problem for which we know there is a solution and no harm is done to user's wallet or sensitive data.

When answering the question "Would it be better to choose open source" I can understand the valid arguments made by each side. On one side, it can be nice to have the source code and be able to review the software; however, I can understand that the developer might have some valid concerns about forks and spun off versions.

For me, the "good compromise" may be using both approaches together. The docs with test cases, signed releases, reproducibility of builds, and how to verify released binary could give you almost as much confidence even without source code.

Regarding the recovery tool targeting valuable wallets, I believe that verification is virtually as significant as recovery.

[Cricktor]

If a recovery case requires days, weeks or even months of computational work aka energy expenditure aka money spent for the energy used, you definitely want to make sure your toolchain is capable of finding a solution.

It's not fool proof, but I would want to be confident that my toolchain works and finds a solution if there's one. I don't want to have to guess if nothing is found, does this mean, my starting parameters were bad or the toolchain is buggy and was never capable of doing what it was supposed to do.

Running an opaque closed-source tool with valuable recovery data implies a clean, secure and offline recovery environment. You don't want some unknown and unaudited tool to steal your data or worse, infest your local environment.

Open-source and reproducible builds are the only guarantee that the source code you can read is exactly what has built the executable. Everything else is hope and prayers.