Topic: VanitySearch (Yet another address prefix finder) - page 28. (Read 32072 times)

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?

Rather than searching for addresses you should search for pubkey with funds (there are a lot) with a kangaroo or rho program.
It will be much faster, ~2.4e19 years with rho or kangaroo against ~9e28 years with address finder (on 256xTelsa V100)
Do not use my kangaroo program which is limited to 125 bit range key search !

Edit:
For instance this pubkey:
02545d2c25b98ec8827f2d9bee22b7a9fb98091b2008bc45b3b806d44624dc038c (1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx)
hold 69370BTC

If you give a full address as target and let VanitySearch run for the next billion years you might be able to find a match. Too bad you won't be a life to see the result

But seriously: If you are trying this kind of tooling to get rich fast you are wasting your time!

the point is that u can give vs a list of addresses with balance in them and if it finds a private key then it is one to an address with btc in it.

Of course it will generate fresh addresses, the chance to get a collision with an existing "1NiNja" address with balance is extremely low to impossible.

The address should be the same as the one with the balance (from the 1st to last characters), not just the prefix.
Vanitysearch isn't designed to do whatever you're trying to do, but it can try to search for the private key of a complete address if you want to.

1NiNja


And what next do with this ?   vanitysearch generate only absolutely fresh addresses ((( no ballance, target addres starting with 1NiNja and balance newer fined....




Br

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

Good day. What is a full address ? This is a simple address starting with 1 like a 1CPaziTqeEixPoSFtJxu74uDGbpEAotZom or something else ?

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?

@student
If you are looking for full addresses, do not enter in the list a part of them (for instance the 15 first char)
It will be faster to enter full addresses.
That's true that there is 2^96 priv key for an address and if you perform 2^96 key you will find a collision but that would also imply that you search for the whole address range, on the blockchain there is no 2^160 address with fund and it is not possible to have a file of 2^160 address.
So if you want to find a collision between 2 priv key that give the same address, consider using BTCCollider which would require "only" 2^80 operations to reach the collision.
https://github.com/JeanLucPons/BTCCollider

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.

Not to disagree that these are large numbers but I think the math is a little off...
If the universe contains 10^80 atoms then there are 6,842,277,657,836,000,000,000,000,000,000 times more atoms in the universe than there are RIPEMD160 bitcoin addresses, 2^160.
Even if you think there is a unique address for each possible hex private key, 16^64; 10^80 is still larger.
What I do agree with is that one CPU has just a good of a chance of finding a specific bitcoin address as does a single GPU rig. However, if the GPU number is high enough, I'd put my money on the GPUs...the odds will increase as the number of GPUs increase.

How many this in brainflare hours ?

p.s. Braiflare calculate 40 Bill.key/h

?

I assume you target a very specific set of addresses (as we all do). Not trying to be a spoilsport here, but
I did some math and here is what we have:

10B/s
100B/10 s
1T/100 s
10T/1000 s
100T/10000 s
1 Quadr/100 000 s
10 Quadr/1 000 000 s
100 Quadr/ 10 000 000 s
1Quint/100 000 000 s or 27,777 h or 3.2 years
10Quint/1 000 000 000 s or >30 years
100 Quint/10 000 000 000 s or >300 years

1 grain of sand contains roughly 40 quintillion atoms or 4.33×10*19
the whole universe contains 10*80 atoms which is almost equal to the
number of all bitcoin addresses.
so in 30 years you're only able to check 1/4 of a grain of sand when you need
to check the whole universe in order to find those addresses.
so basically me using my laptop which produces 100M/sec and you using
your x14 times more powerful equipment, we still have almost the same chance
because of such huge numbers.

sorry if this is off topic but I think it can give people a good and clear view of what
we are dealing here with

Maybe this wil be helpfull for your development

https://github.com/ryancdotorg/brainflayer

Brainflare is popular product some years ago...

Jean_Luc, I read  info what brainflare on CPU get 40 billiard om keys/Hour. This is faste then VanitySearch ? Can see brainflare and if you interested get function from brainflare and made code for CUDA



Br

VanitySearch can search for fulll adresses but it is unlikely it founds something.
I will try tomorrow with a set of addresses an see if I manage to reproduce the issue.

Vanytysearch working WITH ANY ADDRESSES or not ?

Is any a method for convert finded prefix for hexPrivKey ?


Br.

self compiled 1.17 with cuda 10.2 -> NOT working
your exe 1.17       with cuda 10.2 -> working

your exe 1.17       with cuda 11   -> NOT working
your exe 1.18       with cuda 10.2 -> NOT working but no surprise
your exe 1.18       with cuda 11   -> NOT working bit of a surprise

self compiled 1.18 with cuda 11   -> not tested as of now

i was a litte frustrated because i couldnt figure out why my complies didnt work on 10.2 with 1.17 (compilation went ok exe just didnt work.. same error as above) also because a few weeks ago there was someone posting here that they didn't have any problems compiling 1.17 to a running state after a small issue he had.

and now with 1.18 and cuda 11 i'm totaly confused as to why.

PS: 1.17 with cuda 10.0 self compiled on linux was working fine, if i want to use it though i have to run this on a windows system..

Do you have the same issue with the 1.17 and CUDA 10.0 ?


When searching, are you using only compressed, both, only uncompressed ?

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.