Improve password generation to be multi-threaded

[KyleF0X]

Hi, Could we please get multi-core support for the ETA calculation at the start? I know it can be disabled by --no-eta but its really useful to see how long its going to take, and how long left.

The problem is for big jobs, it can take DAYS just to calculate the ETA.

Or if you could point me in the right direction, i could try do this myself...

Cheers.

[3rdIteration]

You would need to re-work the deterministic password generation algo for this, as it currently runs on a single thread. (Both for the ETA generation and actually running the recovery)

This is also the reason why you hit a ceiling based on single thread performance if you have a system with a tone of cores. (So the system may fail to fully utilize all of the cores)

[KyleF0X]

You would need to re-work the deterministic password generation algo for this, as it currently runs on a single thread. (Both for the ETA generation and actually running the recovery)

Thanks for the fast reply. Ive been trying to get a reasoning AI to recode it for me. I was having the best experience with Grok 3 "think" enabled, but ran out of free prompts.

Where is the ETA function housed? It doesnt appear in btcrecover.py or seedrecover.py

I wonder if the password count cant just be done mathematically, instead of counted. 12 factorial for example = 12! = 12×11×10×9×8×7×6×5×4×3×2×1 = 479,001,600

Then the ETA could just adjust its self depending on your current hash rate?

[3rdIteration]

You need to re-read what I posted. This isn't just about the ETA functionality...

[KyleF0X]

Well, I do get multi threaded CPU performance when the recovery starts, and GPU, its only at the "counting passwords" ETA stage do i see only a single core being used...

This is the command i currently run: python seedrecover.py --no-dupchecks --enable-opencl --mnemonic-length 12 --language EN --dsw --wallet-type ethereum --addr-limit 1 --addrs 0x0000000000000000000000000000000000000000 --tokenlist ./seeds2.txt --bip32-path "m/44'/60'/0'/0" --threads 20

To me (not an expert) it seems like its trying to count all the permutations before running recovery, to give a total number the ETA can work from. But this is just a math problem that a calculator can do in seconds, unless im missing something?

Regardless, i do see all my threads get used once recovery starts, but not at the "counting passwords" phase, just one core only.

[3rdIteration]

Read my initial comment again. When running the recovery, the seed/password generator only runs on a single tread. (Even though the hashing and checking is multi threaded)

[KyleF0X]

I made some modifications that have changed the way the ETA is calculated. Now it uses MATH based on the number of seed words in the file specified by --tokenlist.

So now all the permutations are instantly calculated, and once recover starts, the hash rate will determine the ETA. This saves HUGE amount of time by not waiting for the "counting" phase, but still gives the user an ETA, which is important for long recovery jobs.

I cant seem to upload them here? I figured out how to do a pull request. hope you like the new code. feel free to edit it.

[3rdIteration]

Just bring a PR. It will also need to consider the --typos arguments and expanding wildcards correctly, so you should add some tests that demonstrate this.

Guide on how to bring a PR is here: https://docs.github.com/en/desktop/working-with-your-remote-repository-on-github-or-github-enterprise/creating-an-issue-or-pull-request-from-github-desktop

Edit: If it doesn't handle these cases then it needs to at least check for the presence of any --typos arguments or any expanding wildcards in the tokenlist and only use the "simplified" calculation if there aren't any of these present.