VanitySearch (Yet another address prefix finder)

[Jean_Luc]

@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

[1714737738]

1714737738

[1714737738]

1714737738

[1714737738]

1714737738

[student4ever]

@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

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?

[COBRAS]

@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

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 ?

[student4ever]

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

[COBRAS]

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

[nc50lc]

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.

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.

[bangbumbang]

And what next do with this ?   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.

[TheArchaeologist]

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!

[Jean_Luc]

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

[student4ever]

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

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?

[TheArchaeologist]

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.

[student4ever]

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

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.

[Jean_Luc]

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.

[TheArchaeologist]

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..

[Jean_Luc]

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.

[shlomogold]

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

what exactly do you need to search a pubkey for? what's the point?
let's say you have found a pubkey with funds, so?

[bangbumbang]

... I think it would be best to create an AI for this task.

AI is not really an intelligence rather a system that is a little "smarter" than traditional algos..
imagine this..
for a neural network u use a set of data with wich u train your model and leave a bit at the end that is not used for training but testing.
the training of this model however is no magic it is most likely just a bunch of "fancy" numerical aglorithms that most likely still just try the stupidest random things.. but a lot lot lot of them
then after the first run it is determined what stupid random choices actually brought on the desired result and the model "remembers" on what grounds these positive results where based on and achieved.
all that is called an "epoch" and is repeated. in the second epoch almost the same random stupid choices run is repeated but almost all of them now factor in what randomly brought on results in the first epoch.
this goes on for however many epochs you want or maybe until another epoch can't refine or beat the results of the previous run.
at that point the learning is done and cant be improved without changes to the model.

the problem in relation to this EC task here is simply that the first epoch would never yield any result'SSSSSS if even one (most likely not) so there would never be any result from wich to learn from.
and even IF u found something:
1. it would take the same time or more TO FIND as if u just used JC's prog
2. multiple results that would be needed to "learn" something aka training the model again same or more time needed
3. the math used by the EC prevents extracting anything "learnable" by whatever model u use in the AI

at least "3." is the theory and if someone would find a way to produce or force some state in with you could "infer" some information you would have found a way to produce collisions in the prosess like some researchers a few years ago.. they found a flaw in "SHA1"?! if i remember correctly..

and if that happend btc would imedietly collapse and be worthless or some realy nice whitehat hacker would work with the team on changing the algo while keeping everything under wraps..

[Jean_Luc]

what exactly do you need to search a pubkey for? what's the point?
let's say you have found a pubkey with funds, so?

Personally We (me and zielar) are searching only for puzzle transactions, we have found 2 keys together with funds and of course, we got them !

[bangbumbang]

what exactly do you need to search a pubkey for? what's the point?
let's say you have found a pubkey with funds, so?

then you could use the kangaroo algo and try to calculate the private key to that public key and get access to the funds
or rather to use kagaroo instead of vanity search to do it faster

[bangbumbang]

Personally We (me and zielar) are searching only for puzzle transactions, we have found 2 keys together with funds and of course, we got them !

what r u'r rigs like?
really 256 x v100? that would be damn impressive ;-)