Distributed computing

[RayRiding]

Would it be possible to implement a sort of distributed network, whereas (select) friends could contribute their CPU power? Or, say I have a long word list, would it make a difference to the password checking order if I mixed the words up in the list, ie; from alphabetical to reverse alphabetical, or totally random? I have friends willing to help but obviously want to avoid duplicate checks!

[gurnec]

Yes, from the command-line help:

--worker ID#/TOTAL#   divide the workload between TOTAL# servers, where each
                      has a different ID# between 1 and TOTAL#

So if you had 3 machines working on a single wallet, all using the same tokens.txt and command line, one would add --worker 1/3, the second would add --worker 2/3, and the third --worker 3/3.

This is only effective for "slow" wallets such as full-node Bitcoin or Armory, it's fairly useless for "fast" wallets like MultiBit Classic or (most formats of) Electrum. For fast wallets, multiple machines won't be much if any faster, and you could be better off using alternative software (written in C instead of Python).

would it make a difference to the password checking order

Yes, changes to the order of tokens does affect the order in which passwords are tried.

[rterwedo]

@gurnec re: cahnges to order of tokens.

If we have 4 workers - and 100 pwds to try, does worker 1 try pwd 1-25, worker 2, 26-50, etc or does worker 1 try pwd 1, 5, 9, etc?

I have always tried to structure token list to bring variables I thought were more likely closer to the front of the generated list (ie I assume option 2 above).

[gurnec]

If we have 4 workers - and 100 pwds to try, does worker 1 try pwd 1-25, worker 2, 26-50, etc or do they does worker 1 try pwd 1, 5, 9, etc?

The latter, each worker tries every fourth password. You can see it in this code here; each worker does a division (by the total # of workers), takes the remainder, and skips 3 out of every 4 passwords from your example.

I have always tried to structure token list to bring variables I thought were more likely closer to the front of the generated list (ie I assume option 2 above).

The details get complicated (I can't even remember them all), but yes that's the best thing to do. Earlier tokens in the file are tried earlier than later ones (on all workers); this is documented in the code here.

[rterwedo]

@gurnec In this case, and for large keyspaces, it seems each worker counts their own pwd list (all of them). It seems it would make sense to run from a pre-gen pwd file for each worker, yes? Since this would disable autosave, you would also have to sort out where to restart if one got interrupted, unless you merge that one commit I assume =)