PubK are only published if the adress has been used for an outgoing transaction. Of course ~ 80% of the adresses had an outgoing transaction, but for example the big wallets like 1Feex... has never had an outgoing transaction - therefore the pubK is not "published" on the blockchain.
Once again: my goal is not to find wallets with balance. My goal is to find lyrical prefixes.

Now I started something for such an "AI". Yes, it is nonlinear, but with a big dataset and epoches the AI may could crack the whole process, because it is still static, since A -> B. I took 50k pairs of random uncompressed adresses and splitted them into 2 cvs with input and output. I started 100k epoches. If it does not work it is ok, but it is worth a try.

Why did you limited it to 125 bit range?
Yes, but only a fraction of all adresses have published their pubK... I think it would be best to create an AI for this task.

Yes, but in my case I am not looking for adresses with balance. I am looking for very long and short lyrical prefixes. So this software is the right one. Would it be possible to make a AI for this task?

Can you post the privK for that adress as well?
Yes, it is basically a full lengh adress starting with 1 followed by ~ 33 letters.
I have used prefixes like 1isnottrue and 1isgood
That means that I dont care about the other letters coming after my prefix

is this auction still active?
And where did you bought 300 BTC on a wallet without password? Is there a plattform for such deals?

ok. Thank you. I tried it with 1000 full adresses, but the gpu shows me that it is going up to 80% and down to 0%, so the speed decrease is still there, but a bit flatter.
So far I have a file of ~ 10M adresses. It is just to increase the possibility that I will find a collusion. The file has ~350 MB. And that is enough to make it possible to find something in reasonable time I think. At least if you can increase the speed and I will get more rigs to work
Can you make the speed of the software the same, so it doesnt matter if you are looking for 1 or 10M adresses? Or is that impossible?

First of all: There are maybe 2^160 possible adresses, but not every base number leads to an actual adress. There are about 2^96 possible private keys so far, which can lead to diffenrent adresses if you hash them compressed or uncompressed.
So I dont need to hash 2^160, just 2^96 keys to uncompressed.

With 10 Bk/s and 10 M adresses I am looking for I have the probability of finding an adresses by luck once every 300 years.
However I will increase the rig number and gpus involved to have a speed of 10 Tk/s = 10 000 Bk/s so than I will have have an adress by luck in less than a year. Maybe vanitysearch will also increase speed in the future, so that I don´t need that many gpu hardware.

However we could also make a deeplearning process out of it where the systems learns which binary input change will lead to a prefixed output?
Maybe my maths is not correct, but who cares... I do it for fun and the chance is bigger than 0 and can be increased by speed and number of prefixes. And the softwares in this field increased the speed dramatically over the last years. For example the LBC was happy to have 150 Mk/s with 50 people in a pool and vanitygen was fast if you had 400 kK/s. So yes, it becomes more likely that someone will have luck.
I have 2 rigs at work and 1 comes next week. So as more rigs I am putting to work as more likely it is that I will have luck.

It is a rig of 8 gtx 1060 6gb and yes B stand for billion. I have 2 of that type and right now I am building one with 2080 super.
Since we are now in the billions, we should also use x Bk/s, because 4000 Mk/s is shit. I better write 4 Bk/s. With my new rig I can expect about 10 Bk/s.
However I have significant speed loss if I am searching for a large number of prefixes. With about 10k prefixes I am down to 700 Mk/s, but I just parsed some data and want to search for 10M prefixes. I dont know where the speed will be with so many prefixes. In oclvanitygen there were no impact on the speed - doesnt matter if you are looking for 10 or 10M prefixes. But vanitysearch is still 5-6 times faster with so many prefixes.

I was thinking of doing an FPGA, but with this much speed I dont need an FPGA. I probably just put more rigs on this task.

I have a problem:

ocl vanitygen runs at a speed of 4000 Mk/s on my rig and today he printed out some thing like this - numbers are for example:

index found: 553
CPU hash: 123456789
GPU hash: 123456789

Delta found: 1234567 Delta started again: 123456

I have 2 identical hashes, but he did not sow the PrivK.
How can I get to the adress and privK with this information?
I also have the prefix of the adress, since it shows me the index number of my prefix search file.

Hi,

why is the software failing when I am looking for more than 50 prefixes?
It looses speed dramatically. With my Rig I have 4 Bk/s and the speed goes as I increase the number of prefixes.
Can you please fix it? So that it doesnt matter if you are looking for 50 prefixes or 5 000 000. Otherwise oclvanitygen would be better for a large number of prefixes.....

Do you think that an FPGA would apply for this task?

Yes, thank you. I know. Right now I am running it on EC2/AWS using CPU and running it on a PC on GPU as well. However I thought that there may is a way to speed it up or have a more efficient way? I mean the EC2 is expensive with no result yet. After 4 months. And yes, I am considering using the IBM QS One for this. I guess that is the only speedup  


How can i tell oclvanitygen to have specific ranges of privK? So that he generates for example privk(Start) 5student4ever...........1 to privk(End) 5student4ever...........9 ?