Also, it's actually wasteful checking for only one address, one should maintain a list of bitcoin addresses. Also, for a speed up, one can also use two loops, one for bitcoin addresses, whose pubkeys are unknown, and those who are known. This way you avoid doing unnecessary sha256+ripemd hashing giving some speed up.
Brainflayer uses a Bloom filter so it can check hundreds of millions of RIPEMD160 addresses simultaneously, although these days with a lot (10%+) of false positives. I don't know whether it would be possible to shoehorn a Bloom filter implementation (including the filter data) into a GPU application. The Brainflayer implementation addresses 2^32
bits (512MB of RAM), but the filter is badly saturated by the large number of Bitcoin addresses, so you would need to use a lot more RAM for the filter data.
Sorry I am not familiar with bloom filters.
Bitcoin addresses are indeed a lot, but not many of them are of interest. It's pointless to add a Bitcoin address with a balance of <0.01 or <0.10 to the list. Keep the list more or less small, I mean the first 200k blocks have enough coins I guess, if they aren't spent.
https://en.wikipedia.org/wiki/Bloom_filterBasically it's a compressed data structure that lets you do an efficient lookup to check whether a key (in this case, a used Bitcoin address) exists in a set. The return is either:
- This key is absolutely NOT in the set
- This key may be in the set (possible false positive)
The tradeoff is between memory usage and false positive rate. When Brainflayer was released, a Bloom filter with 2^32 bits was sufficient to keep the number of false positives low, but now that the number of addresses has increased significantly the false positive rate is too high.
You do make a good point that you would only need to try to crack addresses which are funded. I'm doing brainwallet cracking for interest, not criminal intent, so I want to cover the entire address space; even obscure wallets with zero balance that were last used years ago.
Random bruteforce cracking is unlikely to ever work anyway, so this discussion is largely academic.