I think the focus of your idea should be how to generate the address you want to scan.
Believe me, it doesn't make much sense to scan a library generating from number or a downloading library, because countless people have already done the same thing.
Again, completely random generation does not make much sense, because the sample library is too large.
You should plan your ideas carefully. If you have a creative idea, it makes sense to practice it.
Let's get dirty here on this subject. LBC just goes 1 to N, and uses each 'n' to solve the Q=nP problem, where Q is public key, and n i private key ( 64 hex) and P is the ECDSA 'point' for btc, secp256k.
Now what LBC does is 1*P, then hashes Q and looks in a 'bloom filter' to see if that hash has value, this requires a database ( or bloom filter ) of all known hashes of public-keys, the problem is that the 'funds.blf' bloom filter that LBC uses is garbage long ago I run some high value hash160 values through that blf, and it didn't catch them which tells me that the BLF used by LBC is worthless, which means that even if it hit a high-value hashed-public key, it would flag it!
***
Now let's look at the state of the art in this subject, first lets take 2015 'brain-flayer' which worked, as some 2,000 high-value keys were found and the funds were nabbbed, here what is done is a large dictionary say 14 billion words is hashed one at a time, and that hash is the 'private-key' so a Q is calculated, then 'brainflayer' looks to hash all public-keys near that 'Q' and uses a bloom-filter ( which are bits to mark known hash high value addresses ), if a Q matches the hash, then Brain-Flayer prints out the hash, and private-key(pair), then anybody can 'sweep' that address and nab the funds.
Problem is that 2012-2014 'brain-wallets' were the rage, by 2015 all funds had been swept, today you can run 'brain-flayer' all you wish on a trillion words, sentences, ... but you will never find a private-key that yields any funds, because there are 100's if not 1000's of people two steps ahead of you.
***
Now state of the ART, there are TWO area's
1.) is the hashed compressed/uncompressed public keys that are used in bitcoin post 2012, earlier they used raw public-keys which are much better to work with,
2.) the raw public-key, this is ideal, because there is less computation, you just generate a private key, and do the Q=n*P multiplication, and then check if that 'Q' has value ( satoshi's coins)
Given that most of the public-keys are still around and some 100k still have value, its a goldmine for people that want to work in that area, and its far better than working with hashed public-keys, as you will find post 2013 in bitcoin blockchain.
***
Something needs to be said about 'bloom-filters' they're bit-arrays that are kept in memory, and say you have 500 million hashed public key compressed addresses we call 'hash160', you can mark your bloom filter to hold info for all these keys, in say a 32 gb bloom filter, and its a O(1) calc as you compute Hash(Q), and then look to see if that n*P generated your 'gold'
Now the problem of course is 32GB in memory, means you must run a 64GB computer, but nobody said this stuff was easy
If somebody wanted to do the LBC correctly, they would say work with a 512mb bloom filter, which would handle the 50k high-value public keys called 'pristine' from early bitcoin, then using that bloom filter run through the Q=n*P calcs using intelligence.
***
The problem with the 'linear' bullshit as done by LBC, is that there are 10**77 private keys in BITCOIN (ECDSA secp256k1), even though your bloom is 50k, that be 50e3, your still chances of a hit are 1 in 10e74, even if LBC had 4 billion ppl ( all on earth ), his chances would still be 10E60, and remember there are 10e23 atoms to a mole, and we're talking about most of the atoms in the known universe. This is why linear is a waste of time.
People for 300+ years have studied these LARGE prime number, and much is known about factoring these primes, this is how I tackle this problem, by factoring primes, which leads to the search space dropping from 2**256 to 2**40, then using super fast GPU, you can fairly quickly factor a large 'Q' public key, note that the Q has two parts (X,Y), you don't need one or the either, just one, if you know X, you can calc Y, and vice verse, so that drops the search space smaller,
***
The way I tackle this problem is 'FACTOR' all the public-keys known to date by scrubbing the block-chain of all public keys, and then using advanced state the art discrete-log solvers, along the way while I find private-public key pairs that don't match my criteria, I keep them if they match my bloom filters, I might find 10k such pairs a day, which means millions a month,
The search space for known BITCOIN used addresses unlike public keys is 50k versus 500Million, or perhaps as much as 2 billion, while I'm doing say a daily search on all 'lint' pairs, I will use a TRIE which is a 256GB ordered-list of all known hashed addresses ever used having value or not, and look to see if one of my pairs match, if they do, then it goes into another database.
The IDEA here is we're searching for the GOLD by intelligent factoring, but along the way we're also keeping any gold-dust seen, now there is NO way for LBC to do this cuz, they just use the basic 2015 512mb, that misses all
Another thing is that high-value key-pairs are grouped as familys, so once your 'close' you can find pairs from the same family.
When I do the factoring, I use 1080 GPU class boards, where I can put a 8GB bloom filter, so I can catch say 512MB addresses, which are essentially almost all the addresses ( hashed ) with value, also because the bloom-is done on board gpu, and all the calcs, its easy to get more than 100 Million keys/sec scanned, which is 100X faster than brain-flayer, and ten times faster than super-vanity
***
Another major part of all this is managing addresses hashed, and managing key-pairs found, and looking at the memory-pool updating new addresses, and then scanning those new addresses in the 'found' key-pair database.
I find in general the 'management' problem of all this to be the most over-whelming problem, as once most of the gpu sw is working, its pretty much done, but the database management problem of dozens of 64gb blooms and many 256 gb TRIES means you need to invest in lots of hard-disk ( ssd )
