--worker command slows down number of tries/s

[alexwaltz]

I was using btcrecover on multiple servers, and I noticed that when using the --worker command, the number of tries slows down.
The more workers I use the worst it is.

This behavior is consistent on Mac and Ubuntu.

Also persists with --enable-opencl or just using CPU.

I read a comment in another issue saying that this may be because of the structure of the token list, anchor files.
If so can anyone explain why this is, and what would be a good practice to use in the future?

I was trying to crack a 12 word seed, where 2 of the words are completely unknown, and other ones had multiple candidates.
The tokenlist file used on the servers was structured as such.
(I used the software to crack this bounty, so I'm fine with sharing the exact file I used)

^1^buyer
^2^city ^2^forest ^2^tree ^2^roof ^2^address ^2^cabin ^2^chimney ^2^estate ^2^lawn ^2^mansion ^2^nature ^2^outdoor ^2^outside ^2^village ^2^property ^2^region ^2^road ^2^rural ^2^wood
^3^wolf ^3^alpha ^3^animal ^3^moon ^3^vicious ^3^wild
ALL BIP39 words the ^4^ prefix in front of each word
^5^drastic
^6^dust ^6^flower ^6^powder ^6^chalk ^6^dune ^6^debris ^6^dirt ^6^salt ^6^purity ^6^sample ^6^sand ^6^speed ^6^crystal ^6^dose
^7^opinion
^8^park
^9^oven ^9^cook ^9^food ^9^kitchen ^9^fire ^9^stove ^9^gas
^10^start
^11^rural
ALL BIP39 words with the ^12^ in front of each word.

Maybe worth mentioning I also used --no-dupchecks

[3rdIteration]

This is normal, you are hiring bottleneck on seed/password generation.

[alexwaltz]

Sorry, but it's not really obvious to me how that is the case.

As I understand the script is deterministic and the --worker command should have the effect of trying seeds from a certain indice onwards.

I am confused as to why is the number of passwords/s decreases.

I ran these commands on my Mac with a 2.6 GHz 6-Core Intel Core i7:

• python3.9 seedrecover.py --no-dupchecks --mnemonic-length 12 --language EN --dsw --wallet-type ethereum --addr-limit 1 --addrs 0x... --tokenlist tokenlist.txt --bip32-path "m/44'/60'/0'/0" --no-eta - 35 kPs/

• python3.9 seedrecover.py --no-dupchecks --mnemonic-length 12 --language EN --dsw --wallet-type ethereum --addr-limit 1 --addrs 0x... --tokenlist tokenlist.txt --bip32-path "m/44'/60'/0'/0" --no-eta --worker 1/2 - 27 kPs/

• python3.9 seedrecover.py --no-dupchecks --mnemonic-length 12 --language EN --dsw --wallet-type ethereum --addr-limit 1 --addrs 0x... --tokenlist tokenlist.txt --bip32-path "m/44'/60'/0'/0" --no-eta --worker 1/5 - 14 kPs/

• python3.9 seedrecover.py --no-dupchecks --mnemonic-length 12 --language EN --dsw --wallet-type ethereum --addr-limit 1 --addrs 0x... --tokenlist tokenlist.txt --bip32-path "m/44'/60'/0'/0" --no-eta --worker 1/10 - 7.5 kPs/

[3rdIteration]

Because it's still generating the same number of potential seeds and skipping hashing the ones that aren't applicable to that particular worker.

For most wallet types this isn't an issue, as hashing is the main bottleneck, but BIP39 seeds bottleneck at seed generation on a single powerful PC.

This could be resolved (and single system performance booster too) by writing a more advanced seed generator.