Note that AI can solve "smooth" problems. So it is not possible to create a neural network to try to solve ECDLP because crypto over elliptic curve is highly non linear (contrary of smooth) and this non linearity is the base of the blockchain security. Lots of tests of non linearity (unpredictablty) are performed before that a hash function or a crypto system is used.
Topic: VanitySearch (Yet another address prefix finder) - page 29. (Read 33086 times)
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.
What exactly would the AI do in your idea?I don't know what you mean by "published" their pubK but you should know that:
- Almost all coinbase transactions (newly generated coins) in the first two years were paid out to public key (P2PK-addresses). In other words: all these public keys are known as they are "published" in the blockchain.
- For all the P2PKH-addresses the public key is not known, only the hash, unless the address has been used even a single time in an outgoing transaction. In that case the public key is known and once again "published" in the blockchain.
So instead of claiming only a fraction of addresses have published their public keys I would say most of them are known. But once again: if you think you can use the "published" public key in order to find the corresponding private key I have bad news for you. That is not going to happen..
Why did you limited it to 125 bit range?
Exactly because of what said by TheArchaeologist, 125 bit range is already very large range will require ~1 year on 256 V100.
If you count only the energy, puzzle #110 and #115 was with benefit but #120 is not or you need to get a low cost electricity.
Anyway, the mods to do in order to increase this limit is simple.
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.
Even considering this small faction, you will still have more odds to win with a kangaroo or rho program.
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
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
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.
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
I know you know Jean Luc but for the "get rich fast" newbies out there: just because the public key is known doesn't mean you will be able to find the private key by bruteforcing. The only time this has been done is with specific puzzle-transactions in which along with the public key the search space is predefined.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
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
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
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
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
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.
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!
And what next do with this ? 
vanitysearch generate only absolutely fresh addresses ((( no ballance, target addres starting with 1NiNja and balance newer fined....
vanitysearch generate only absolutely fresh addresses ((( no ballance, target addres starting with 1NiNja and balance newer fined.... 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.
And what next do with this ? vanitysearch generate only absolutely fresh addresses ((( no ballance, target addres starting with 1NiNja and balance newer fined....
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. vanitysearch generate only absolutely fresh addresses ((( no ballance, target addres starting with 1NiNja and balance newer fined.... 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.
Good day. What is a full address ? This is a simple address starting with 1 like a 1CPaziTqeEixPoSFtJxu74uDGbpEAotZom or something else ?
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
1NiNja
Code:
PubAddress: 1NiNja1bZEwSL4NvhK1MZZY31jA5vGeBd4
Priv (WIF): p2pkh:Kx6GszNqyYEe5wX6vkygTMFqumcLXK7Brm61TFztYUr9Ns5wrzan
Priv (HEX): 0x1A030B2AD8ACB52999AF455DCEFB684A39F0529637347A6E136DCD993F7D0498
PubAddress: 1NiNja1b1rbYVDeMrcV6rfwLpQGZbd1cFZ
Priv (WIF): p2pkh:KwkNBqYiFoQVc9EAxHthJJXqKHLDJXNTCCouzr54yNS3uRJKT6rG
Priv (HEX): 0xFC52C6D5DE3EB203C9E444EA230B96A9B8FEC78CC405697BD63BC1262C32B42
PubAddress: 1NiNja1bQkkLTnBWVK5Gi5cjniWvZrfWtx
Priv (WIF): p2pkh:KwmFUubhmNB6BCmxerE3WaaXZ4cc68AnrgCx4cfnyPDDRmrjZomD
Priv (HEX): 0x1039A4BF5938B9DF04080118459504B9DED61B9B7EE514DD5E206BE264693D48
PubAddress: 1NiNja1bBgqx2V6ikP8yYKDLaCxfP43B71
Priv (WIF): p2pkh:L1bKsJMjjcKCu32ph1r7KchbkS4fbfmabcvfa2tANtH7aX1npBPV
Priv (HEX): 0x827822C58B12AAC72A1254C5D9D4ABC783D366FABB656DF55E30E4DD50DDF139
And what next do with this ?
vanitysearch generate only absolutely fresh addresses ((( no ballance, target addres starting with 1NiNja and balance newer fined.... Br
Good day. What is a full address ? This is a simple address starting with 1 like a 1CPaziTqeEixPoSFtJxu74uDGbpEAotZom or something else ?
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
@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
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
ok. Thank you. I tried it with 1000 full adresses...
Good day. What is a full address ? This is a simple address starting with 1 like a 1CPaziTqeEixPoSFtJxu74uDGbpEAotZom or something else ?
@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
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
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
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.
4Bk/s as in Billions? that's quite impressive. what is your rig consist of?
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 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
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.
4Bk/s as in Billions? that's quite impressive. what is your rig consist of?
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 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
How many this in brainflare hours ?
p.s. Braiflare calculate 40 Bill.key/h
? 4Bk/s as in Billions? that's quite impressive. what is your rig consist of?
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 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
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.
I will try tomorrow with a set of addresses an see if I manage to reproduce the issue.
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
Jump to: