Let's get dirty here on this subject. LBC ( Large Bitcoin Collider ) just d ( the private key number ) goes 1 to N, and uses each 'd' to solve the Q(x,y)=d*P(x,y) problem, where Q is public key, and 'd' private key (32 bytes/64 hex char) and P is the ECDSA 'generator point' for btc, secp256k1.
Now what LBC does is Q=d*P, then hashes ( sha256) 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 NOT flag it! ( Which begs the question, is/was his stuff a plant to lead scavengers astray?? )
The reason for mentioning LBC is that they are a base-point for this process, they use 'old tools' and small bloom-filters and they linearly process through the private keys 1 to N, where N is 10e77, which is a number that exceeds the number of atoms in the universe. Which means that even if all the space aliens in the universe were to join team-LBC and work in concert, they would still never reach 'N'.
Which leads to "INFLECTION", our goal is to use modern math ideas in the field of ECLDP ( Eliptic Curve Discrete Logarithm Problem ) to find private-keys using the most modern GPU hardware methods.
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 nabbed, here what was done is a large dictionary say 14 billion words is hashed one word 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.
[ popular brain-wallets were 'cat', 'dog', 'satoshi1', all generated by 'hashing' SHA256('text'), and using that hash as the private-key ]
1.) Hashed Public-keys, compressed and non-compressed, are used in bitcoin post 2013, called HASH160 addresses, earlier they used raw public-keys which are much better to work with. Compression just means that only the 'x' part of the Q(x,y) is used, which means that compression uses 1/2 the space, non-compressed means the full Q(x,y) both x & y coordinates are used, no big deal either way, using algebra, if you know x or y, you can calculate the other. Bitcoin ecdsa is just an equation that says y**2 = x***3 + 7.
2.) The raw public-key Q(X,Y), this is ideal, because there is less computation, you just generate a private key, and do the Q=d*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. Hashed public keys are still useful, my point is that given the 'easy stuff' is still on the ground there is no point in digging deep.
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=d*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 10e72, even if LBC had 4 billion ppl ( all on earth ), his chances would still be 10E62 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. If all the ALIENS in the universe worked for LBC, they probably still would NEVER find all or many bitcoin high-value gold.
People for 300+ years have studied these LARGE Eliptic Curve prime numbers, and much is known about factoring these primes, this is how we tackle this problem, by factoring primes; The problem even has a name its called ECDLP, which leads to the search space dropping from 2**256 to 2**160 to 2**80 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 'inflection' tackles 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-gen
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 bloom-filter's and many 256 gb TRIES means you need to invest in lots of hard-disk ( ssd )
Mail today to firstname.lastname@example.org for information, Safer communication, use z_address ( zen cash messaging wallet ) zcdm7xs4ZdKD4bLZTcv24xywN9ZYjSfttCfcuZzoosK4NZfbNE1fRdXMoX6a6xsVccwHhTzhhouSGucd7wuy73Eh3JoHFGV