search

3rdIteration / btcrecover

BTCRecover is an open source wallet password and seed recovery tool. For seed based recovery, this is primarily useful in situations where you have lost/forgotten parts of your mnemonic, or have made an error transcribing it. (So you are either seeing an empty wallet or gettign an error that your seed is invalid) For wallet password or passphrase recovery, it is primarily useful if you have a reasonable idea about what your password might be.
https://btcrecover.readthedocs.io/
GNU General Public License v2.0
604 stars 193 forks source link

--worker command slows down number of tries/s #356

Closed alexwaltz closed 2 years ago

alexwaltz commented 2 years ago

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 commented 2 years ago

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

alexwaltz commented 2 years ago

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:

3rdIteration commented 2 years ago

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.