Vanitygen: Vanity bitcoin address generator/miner [v0.22]

[BlackHatCoiner]

Could you break it down for me as a process that happens inside Vanitygen rather than using math?

Forget the maths mentioned above. Consider given that there's a way we can multiply a point with a number (which is the private key) and end up with another point. The new point's coordinates along with a prefix in the front consist the public key. That very public key is then hashed a bunch of times and with some extra steps we result in the Bitcoin address.

So the list of procedures, vanity implements is the following:

• Generates a random number and multiply it with a known point (called G) to get your public key.
• Takes that public key and hashes it to get an address. (Technical explanation)
• Repeats the above steps until the program finds an address that starts with the defined characters you want.

[1714111244]

1714111244

[1714111244]

1714111244

[1714111244]

1714111244

[DannyHamilton]

Could you break it down for me as a process that happens inside Vanitygen rather than using math?

Bitcoin uses Elliptic Curve (EC) Cryptography for its Digital Signature Algorithm (DSA), which is why you'll often see it referred to as ECDSA.

With ECDSA, everyone agrees on a specific point on the curve to be a starting point. This point will generally be written as G when it's being discussed.

The private key is just a large integer. (You'll often see it written as p when it's being discussed). With bitcoin, it's a random number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336

To get your public key (which is a point on the curve that you'll often see written as Q when it's being discussed), you use a point addition process to add the point G to itself, and then add G to that result, and then add G to that result, and so on. Your private key (p) is the number of times to perform that addition.

Think about this in terms of numbers (instead of points) for a moment. If I ADD the number 5 to itself 7 times, the result is the same as the number 5 MULTIPLIED by 7.
5 + 5 + 5 + 5 + 5 + 5 + 5 = 35
5 * 7 = 35

The same is true with point arithmetic in Elliptic Curve Cryptography.  If I add the point G to itself p times, the result is the same as multiplying p times G.
G + G + G + . . . + G = p * G

So, now, if I give you a temporary public key (we'll call it Q here), and you add point G to it (using the arithmetic rules of Elliptic Curve Cryptography), the new point that you get is another public key.  Since you added G exactly 1 more time, it's the public key for a private key that is exactly 1 + my temporary private key.


So, let's say you start with my temporary public key (Q), and you keep adding G and checking the address associated with each new public key that you get. You keep track of how many times you added G to the starting public key (let's call that number of times r).  Eventually, you find an address that meets the "vanity" requirements that I want.  You can then report r back to me. I can just add r to the temporary private key (lets call that q) that I used to generate the initial temporary public key (Q), and I'll get the exact private key (p) that will result in that address.  However, since I never told you the temporary private key (q) that I used initially to generate the public key (Q) that I gave you, you have no way of knowing what the new private key (p) is.  You ONLY know that it is r more than my starting point (q).  As such, the new private key (p) is just as secure as the one I gave you (q).  As long as nobody ever knows what temporary private key (q) I used to start the process, they don't know what the new number is at the end of the process.

So, using the math that pooya87 supplied earlier there effectively 3 public keys (P, Q, and R) each with their own private key (p, q, and r respectively).

P = Q + R
(Vanity Public Key = Temporary Starting Public Key + the Public Key the searcher added to get the vanity address)

p*G = Final vanity private key (p) times the starting point G. This is just another representation of the Vanity Public Key P, but it is in terms of the final private key p, as we discussed that the result of p * G is the public key.

q*G = The temporary private key (q) that the requestor started with times the starting point G. This is just another representation of Q, the temporary public key that the requestor started with and which they gave to the searcher to find the vanity address with, but it is in terms of the temporary private key (q) that the requestor never gave to the searcher.

r*G = The incremental private key (r) times the starting point G. This is just another representation of the Public Key the searcher added to get the vanity address (R), but in terms of r, the number of times they had to add G to the temporary public key Q to get to the vanity address.

So:
p*G = q*G + r*G
(hopefully, you can see from above that this is just another way of saying P = Q + R)

By factoring out the starting point (G), we are left with what I described earlier...  the requestor can just add the incremental value (r) that the searcher used when searching for the vanity address to the temporary starting private key (q), and the result will be the new private key (p) of the vanity address:
p = q+r

Of those three values, the ONLY one that the searcher knows is r.  Since he doesn't know the temporary private key (q), it's impossible for him to know the final private key (p), but he can tell the requestor that the private key for the vanity address is exactly (r) more than whatever the temporary private key (q) was for the temporary public key (Q) that he started with.

[Tanagi]

Could you break it down for me as a process that happens inside Vanitygen rather than using math?

Bitcoin uses Elliptic Curve (EC) Cryptography for its Digital Signature Algorithm (DSA), which is why you'll often see it referred to as ECDSA.

With ECDSA, everyone agrees on a specific point on the curve to be a starting point. This point will generally be written as G when it's being discussed.

The private key is just a large integer. (You'll often see it written as p when it's being discussed). With bitcoin, it's a random number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336

To get your public key (which is a point on the curve that you'll often see written as Q when it's being discussed), you use a point addition process to add the point G to itself, and then add G to that result, and then add G to that result, and so on. Your private key (p) is the number of times to perform that addition.

Think about this in terms of numbers (instead of points) for a moment. If I ADD the number 5 to itself 7 times, the result is the same as the number 5 MULTIPLIED by 7.
5 + 5 + 5 + 5 + 5 + 5 + 5 = 35
5 * 7 = 35

The same is true with point arithmetic in Elliptic Curve Cryptography.  If I add the point G to itself p times, the result is the same as multiplying p times G.
G + G + G + . . . + G = p * G

So, now, if I give you a temporary public key (we'll call it Q here), and you add point G to it (using the arithmetic rules of Elliptic Curve Cryptography), the new point that you get is another public key.  Since you added G exactly 1 more time, it's the public key for a private key that is exactly 1 + my temporary private key.


So, let's say you start with my temporary public key (Q), and you keep adding G and checking the address associated with each new public key that you get. You keep track of how many times you added G to the starting public key (let's call that number of times r).  Eventually, you find an address that meets the "vanity" requirements that I want.  You can then report r back to me. I can just add r to the temporary private key (lets call that q) that I used to generate the initial temporary public key (Q), and I'll get the exact private key (p) that will result in that address.  However, since I never told you the temporary private key (q) that I used initially to generate the public key (Q) that I gave you, you have no way of knowing what the new private key (p) is.  You ONLY know that it is r more than my starting point (q).  As such, the new private key (p) is just as secure as the one I gave you (q).  As long as nobody ever knows what temporary private key (q) I used to start the process, they don't know what the new number is at the end of the process.

So, using the math that pooya87 supplied earlier there effectively 3 public keys (P, Q, and R) each with their own private key (p, q, and r respectively).

P = Q + R
(Vanity Public Key = Temporary Starting Public Key + the Public Key the searcher added to get the vanity address)

p*G = Final vanity private key (p) times the starting point G. This is just another representation of the Vanity Public Key P, but it is in terms of the final private key p, as we discussed that the result of p * G is the public key.

q*G = The temporary private key (q) that the requestor started with times the starting point G. This is just another representation of Q, the temporary public key that the requestor started with and which they gave to the searcher to find the vanity address with, but it is in terms of the temporary private key (q) that the requestor never gave to the searcher.

r*G = The incremental private key (r) times the starting point G. This is just another representation of the Public Key the searcher added to get the vanity address (R), but in terms of r, the number of times they had to add G to the temporary public key Q to get to the vanity address.

So:
p*G = q*G + r*G
(hopefully, you can see from above that this is just another way of saying P = Q + R)

By factoring out the starting point (G), we are left with what I described earlier...  the requestor can just add the incremental value (r) that the searcher used when searching for the vanity address to the temporary starting private key (q), and the result will be the new private key (p) of the vanity address:
p = q+r

Of those three values, the ONLY one that the searcher knows is r.  Since he doesn't know the temporary private key (q), it's impossible for him to know the final private key (p), but he can tell the requestor that the private key for the vanity address is exactly (r) more than whatever the temporary private key (q) was for the temporary public key (Q) that he started with.

Thank you so much Danny, this is by far the best explanation I have ever read.

The time you have taken to break everything down and present it in such a clear and readable way is fantastic and very much appreciated.

[Tanagi]

So, using the math that pooya87 supplied earlier there effectively 3 public keys (P, Q, and R) each with their own private key (p, q, and r respectively).

P = Q + R
(Vanity Public Key = Temporary Starting Public Key + the Public Key the searcher added to get the vanity address)

p*G = Final vanity private key (p) times the starting point G. This is just another representation of the Vanity Public Key P, but it is in terms of the final private key p, as we discussed that the result of p * G is the public key.

q*G = The temporary private key (q) that the requestor started with times the starting point G. This is just another representation of Q, the temporary public key that the requestor started with and which they gave to the searcher to find the vanity address with, but it is in terms of the temporary private key (q) that the requestor never gave to the searcher.

r*G = The incremental private key (r) times the starting point G. This is just another representation of the Public Key the searcher added to get the vanity address (R), but in terms of r, the number of times they had to add G to the temporary public key Q to get to the vanity address.

Another quick question if I may please...

When adding uncompressed public keys together, and also when adding the generator point, which parts do I use?

For example:

A full uncompressed public key looks like this:

04F11D0ECD3686E66695A3B28555264F9EF60EFEDF905BE79E2937F7FA1BA3317E9002C25FB8236 2A4EDCA54A6DE49C78448F5DA2264B5E944D116A9D8A7769F59

but I know that it is made up of the x and y axis and it also has the 04 on the front.

So when I want to calculate P = Q + R, what does that actually look like in terms of which parts of the public keys to use?

Similarly,  I know that the generator point is

79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C46 55DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

but it is also made up of the x and y axis.

So when adding it to Q, what would that actually look like in terms of which part or parts of the generator point do I use?

Thanks again for all your generosity in helping me understand these concepts.

[BlackHatCoiner]

Your questions aren't very clear, but I'll give it a try.

So when I want to calculate P = Q + R, what does that actually look like in terms of which parts of the public keys to use?

Let's take your public key which is Q:

Code:

x: F11D0ECD3686E66695A3B28555264F9EF60EFEDF905BE79E2937F7FA1BA3317E
y: 9002C25FB82362A4EDCA54A6DE49C78448F5DA2264B5E944D116A9D8A7769F59

And another public key R. In this case, I'll just take the point G to simplify:

Code:

x: 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
y: 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

Now, you'll have to perform ECC addition of those two points (Q + R) which will give you this P:

Code:

x: 89B9A2CC85F56A5B29E72711D95159CF4C80C2787F1716C38762C7DEACC29D8A
y: 64B2D208EFA41213F4924542ABFD245AA7228754FDDDC9006AEA3BCC75F2C6F6

This new point's private key is the private key of Q plus the private key of R or in this case, it'll be the private key of Q plus 1.


If you're asking what are the maths behind ECC addition, take a look in here: Adding Points in Elliptic Curve Cryptography

[apvl]

Number of CPU thread: 32
GPU: GPU #0 NVIDIA GeForce RTX 3050 Ti Laptop GPU (20x0 cores) Grid(160x128)
[952.00 Mkey/s][GPU 910.98 Mkey/s][Total 2^39.19][Prob 50.7%][60% in 00:03:15]
VanityGen stats just got more into this once i found this forum with the whole finding the keys and all that good shit was good yall

[willi9974]

what can i do to get a faster result?
I get on my RTX 3070 only 162.36 Mkey/s

Code:

D:\Vanitygen>oclvanitygen.exe -iv -D 0:1  1xxxxxxxx
Prefix difficulty:       11720527050400 1xxxxxxxx
Difficulty: 11720527050400
Device: GeForce RTX 3070
Vendor: NVIDIA Corporation (10de)
Driver: 461.09
Profile: FULL_PROFILE
Version: OpenCL 1.2 CUDA
Max compute units: 46
Max workgroup size: 1024
Global memory: 0
Max allocation: -2147483648
OpenCL compiler flags: -DPRAGMA_UNROLL -cl-nv-verbose
Loading kernel binary 29f79abc2dfbdf2a6b365a4ee6dd11c1.oclbin
Grid size: 2944x4096
Modular inverse: 47104 threads, 256 ops each
Using OpenCL prefix matcher
GPU idle: 15.86%
[162.36 Mkey/s][total 3014656000][Prob 0.0%][50% in 13.9h]

[bigvito19]

what can i do to get a faster result?
I get on my RTX 3070 only 162.36 Mkey/s

Code:

D:\Vanitygen>oclvanitygen.exe -iv -D 0:1  1xxxxxxxx
Prefix difficulty:       11720527050400 1xxxxxxxx
Difficulty: 11720527050400
Device: GeForce RTX 3070
Vendor: NVIDIA Corporation (10de)
Driver: 461.09
Profile: FULL_PROFILE
Version: OpenCL 1.2 CUDA
Max compute units: 46
Max workgroup size: 1024
Global memory: 0
Max allocation: -2147483648
OpenCL compiler flags: -DPRAGMA_UNROLL -cl-nv-verbose
Loading kernel binary 29f79abc2dfbdf2a6b365a4ee6dd11c1.oclbin
Grid size: 2944x4096
Modular inverse: 47104 threads, 256 ops each
Using OpenCL prefix matcher
GPU idle: 15.86%
[162.36 Mkey/s][total 3014656000][Prob 0.0%][50% in 13.9h]

This one is faster https://github.com/JeanLucPons/VanitySearch

[rozsada]

Hi guys,
is it possible to generate a btc address using GPU farm (6 x AMD RX480)?

Thanks in advance

[phantastisch]

This is a bit offtopic but did anybody find out a good and safe way to store your generated private keys for your vanity adresses?
Like I get that you could put them into another computer but there has to be a better way without a second rig?
I know that trezor et al cannot store individual private keys.

Did anybody find a safe and convienient system?

[LoyceV]

This is a bit offtopic but did anybody find out a good and safe way to store your generated private keys for your vanity adresses?

You can use BIP38 encryption and print them. A decent password makes it very expensive to crack, so obviously make sure you don't lose the password. And encrypt it using the usual precautions, such as an air-gapped system running from RAM.
Just in case: make sure to verify recovering the private key from the paper before you need it to find back the private key.

[phantastisch]

This is a bit offtopic but did anybody find out a good and safe way to store your generated private keys for your vanity adresses?

You can use BIP38 encryption and print them. A decent password makes it very expensive to crack, so obviously make sure you don't lose the password. And encrypt it using the usual precautions, such as an air-gapped system running from RAM.
Just in case: make sure to verify recovering the private key from the paper before you need it to find back the private key.

That makes perfect sense, thanks for the Input

[nc50lc]

It would be a digital ape fight for the reward and you by depositing on the address will make a number x of apes around the world at maximun excitement.

A fight of whon collect first, are you ready to fight? Are you fast enough?

Most of those "apes" have already set-up a system that can automatically sweep bitcoins sent to famous leaked private keys.
It's not about having fast reactions, it about having the fastest node, code, internet, etc. which IMO isn't exciting at all.

Creating a group that will watch this specific address could attract donators or even member of the group themselves will donate, yes.
But the ones who'll likely win are still the ones who've been collecting the funds, not the ones who are unaware of the info above.

[1337leet]

Hey there,

I'm using the oclvanitygen and want to run 6 RTX 3090.

I first tried one but only get 270 MKey/s... what is wrong here?

This is what I use

C:\Users\Username\Desktop\Adresse> oclvanitygen.exe -v -i -D 0:2,grid=1024x1024 -f comics.txt -o found.txt

[willi9974]

Try it without the -D and -grid parameter

And send me a PM i mean i have a faster software but talking in our home Language is better

Nest regards,
Willi

[Diplester6666]

This is very cool, I downloaded and tried creating a bunch of vanity addresses. As long as the prefix is short, it creates an address in a matter of seconds on a regular computer.

However since this is an old program, it creates non-segwit addresses. Does anyone know if there's a newer version or a similar program that creates a segwit address (that starts with bc1)?

[Diplester6666]

However since this is an old program, it creates non-segwit addresses. Does anyone know if there's a newer version or a similar program that creates a segwit address (that starts with bc1)?

Check these thread,
segvan: Segwit vanity address & bulk address generator.
narcissist - easy peasy vanity addresses - bech32 - split key

Thank you very much, that is exactly what I was looking for. narcissist program looks cool.

[nc50lc]

-snip- Does anyone know if there's a newer version or a similar program that creates a segwit address (that starts with bc1)?

VanitySearch can.
And it's relatively faster than Vanitygen/Oclvanitygen and has Nvidia GPU support.

Vanitysearch thread: http://bitcointalk.org/index.php?topic=5112311.0
Github Repository: github.com/JeanLucPons/VanitySearch

[Diplester6666]

-snip- Does anyone know if there's a newer version or a similar program that creates a segwit address (that starts with bc1)?

VanitySearch can.
And it's relatively faster than Vanitygen/Oclvanitygen and has Nvidia GPU support.

Vanitysearch thread: http://bitcointalk.org/index.php?topic=5112311.0
Github Repository: github.com/JeanLucPons/VanitySearch

Thank you so much! The fact that this program uses GPU makes a lot of difference. It created a lot more addresses in significantly less time!

[antichert]

Tell please, what patterns format in -f parameter?
I specify the desired addresses for which I want to pick up the key, and the application does not work without giving an error.
Even if my file -f addres_list.txt has only one specific address, I tried it in different ways, but it doesn't work, why?