Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 3. (Read 1153691 times)

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)?

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

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

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.

That makes perfect sense, thanks for the Input

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.

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?

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

Thanks in advance

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

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

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

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

Let's take your public key which is Q:

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

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

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

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.

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.

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.

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.

With regards to combining keys there is nothing more to it then can be found on the website.
The Vanitygen c-code itself just makes use of library functions to work with the generated keys.
The calls are all based on EC (Eliptic Curve) mathematics, where bitcoin just uses the specs according to SECP256k1.
https:en.wikipedia.org/wiki/Elliptic_curve.

Transforming a public key to a bitcoin address can be found here:
https:en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses.

But I guess I probably do not understand your questions.
Are you looking for more information on how Vanitygen 'searches' for the BitcoinPrefix?

Thanks.

I still don't think it's any clearer in my head.

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

Thanks so much.

I have used this site and it's really helpful, but unfortunately doesn't answer my questions around exactly how Vanitygen calculates the address and the PrivkeyPart. The actual nuts and bolts of it.

With simple math. If upper case letters (P, Q and R) are points on the curve (aka public keys) and lower case letters (p, q and r) are integers in [1,N] range and G is the generator point we have:
User has q (the initial number they generated) and receives r (the number pool gives them) from the third party and computes q+r or his private key for that final address.

P.S. p needs to be reduced to be valid. p = (q+r) % N