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

[Rassah]

^ What he said

[1714077757]

1714077757

[1714077757]

1714077757

[1714077757]

1714077757

[1714077757]

1714077757

[1714077757]

1714077757

[1714077757]

1714077757

[Phinnaeus Gage]

deepceleron and Rassh, you have been both very helpful. Let me quote the exact point at which I get lost, then let me know if there is any hope for me.

If GPU acceleration is desired, install ATI Drivers v11.11 or newer for ATI video cards or latest Nvidia driver, test that OpenCL is working with GPU miner software.

I need my clients to easily hash their own vanity address without having to purchase, let alone, install hardware and complex programs. Is this even possible?

[deepceleron]

deepceleron and Rassh, you have been both very helpful. Let me quote the exact point at which I get lost, then let me know if there is any hope for me.

If GPU acceleration is desired, install ATI Drivers v11.11 or newer for ATI video cards or latest Nvidia driver, test that OpenCL is working with GPU miner software.

I need my clients to easily hash their own vanity address without having to purchase, let alone, install hardware and complex programs. Is this even possible?

Generating anything beyond a trivially short vanity phrase takes significant time. It would only be practical in a "vanitygen for hire", "check back later and see if we found one" fashion.

Your clients would need to trust you also having the private keys that can be used to spend their bitcoins (dangerous), and you would need a dedicated web server that can run executable non-script binaries on-demand (dangerous), and have security and audited code to ensure that no client can hack the front-end software to get another person's key (dangerous).

The way I would see a "generation" service working would be to have a vanitygen always running, and when a client wants to have a new address searched for, the address they want is validated as workable, has never been used for anyone else, and is added to vanitygen's PrefixList.txt as I used it above only if the list is not too long already, and the vanitygen process is restarted. Software would have to parse the output regularly to find if an address was found and add it to a user's "found addresses" database. All this should not be attempted by someone who even has a hard time running vanitygen, you are liable to f*#k something up by putting such a system online for hackers smarter than you to mess with.

[Rassah]

deepceleron and Rassh, you have been both very helpful. Let me quote the exact point at which I get lost, then let me know if there is any hope for me.

If GPU acceleration is desired, install ATI Drivers v11.11 or newer for ATI video cards or latest Nvidia driver, test that OpenCL is working with GPU miner software.

I need my clients to easily hash their own vanity address without having to purchase, let alone, install hardware and complex programs. Is this even possible?

My mining rig does 530Mhash/s, consisting of two ATI 5830s, each costing $130 or so. With that, to generate an address like 1MemDea1r would take me about a month of running vanitygen non-stop, burning 430 Watts per hour. It's not cheap.

[Phinnaeus Gage]

WOW! But I'm not done with. I'm sure that if ask the right questions, the answer will manifest itself.

What would be the average price point for generating the longest possible vanity address in the least amount of time? Giving a couple hypothetical examples would be nice.

Also, is there a way to just pen an address, partially or a complete one, have it checked to make sure it's not already in use, then have a private key made for that? e.g. 1TurkeyBob1siHHu8...etc...

[deepceleron]

WOW! But I'm not done with. I'm sure that if ask the right questions, the answer will manifest itself.

What would be the average price point for generating the longest possible vanity address in the least amount of time? Giving a couple hypothetical examples would be nice.

Also, is there a way to just pen an address, partially or a complete one, have it checked to make sure it's not already in use, then have a private key made for that? e.g. 1TurkeyBob1siHHu8...etc...

I would have a 50% chance of finding a case-insensitive "1phinnaeus" address in twelve days on my video card. In that same time I could have mined a guaranteed 2 BTC PPS. Each additional character in length makes it 59 times harder. A case-sensitive "1TurkeyBob" would have a 50% chance in 214 years.

If you want to see if an address prefix was previously used on the Bitcoin network, you can go to http://firstbits.com and type in 1phinnaeus or whatever. It would be possible to do a check yourself on your own website if you have the skills to make a site that integrates Bitcoin blockchain lookups like firstbits or blockexplorer. I mention checking that no other user is simultaneously searching for the same or a similar address on a "generator" web site in my post above, because that is just one obvious way you could mess up and give two users the same private key.

[Rassah]

Also, is there a way to just pen an address, partially or a complete one, have it checked to make sure it's not already in use, then have a private key made for that? e.g. 1TurkeyBob1siHHu8...etc...

Regarding your second question, no, encryption is one way only. It is VERY quick and easy to make a public key from a private key, but almost impossible to make a private key out of a public key. If what you ask was possible, it would be fairly easy to take an address, such as 1BTC1oo1J3MEt5SFj74ZBcF2Mk97Aah4ac, and make a private key out of that. Obviously we wouldn't want that. So what vanitygen essentially does is pick random numbers, makes private keys out of them, and then checks what kind of public address is made from that private key. If the address is what you are looking for, you're good. If (most likely) it's just gibberish, it tries again with a different random number. The process is pretty much just like mining, where you are throwing dice millions of times a second, and instead of looking for a hash that starts with 000000000000... you are looking for a "hash" that starts with 1TurkeyBob1siHHu8...

[BurtW]

Distributed vanity address generation (distributed vanity address mining) has been discussed several times in several threads.  Someone just needs to get off their butt and do it.  Using the additive or multiplicative properties of the elliptical curve cryptography used for Bitcoin it can be done securely but there is one sticking point to the scheme - all the miners have to cooperate.  There are several threads related to this including back up a few pages in this thread.

I have shelved the idea personally until the new type 3 addresses since they will make vanity address generation much easier and allow for much longer vanity names.  For example 3BurtWagner.....

Dug up one of the better threads on this subject here:  https://bitcointalk.org/index.php?topic=56839.0

If you are interested you should revive that thread!

[Phinnaeus Gage]

Distributed vanity address generation (distributed vanity address mining) has been discussed several times in several threads.  Someone just needs to get off their butt and do it.  Using the additive or multiplicative properties of the elliptical curve cryptography used for Bitcoin it can be done securely but there is one sticking point to the scheme - all the miners have to cooperate.  There are several threads related to this including back up a few pages in this thread.

I have shelved the idea personally until the new type 3 addresses since they will make vanity address generation much easier and allow for much longer vanity names.  For example 3BurtWagner.....

Dug up one of the better threads on this subject here:  https://bitcointalk.org/index.php?topic=56839.0

If you are interested you should revive that thread!

That's what I was looking for! Thanks, Burt. There's nuggets out the ass on that short thread. What I wanted to see and read is the following in bold, until Gavin almost burst my bubble.

From a glance-through read, it would appear that one would only be able to generate addresses for a single client at a time. Am a wrong, that the hashing and checking will find an address that would work for just one client. Currently, you hash once and see if the public address has any matches from an arbitrary list.

This is a challenge. One possible approach (and again I hope I'm not reinventing the wheel) is to have a body of n arbiters which are assumed do not all collude. Each will generate a private key bi and public key Bi. The Bi's will be distributed among miners. The miner generates a pair d, D and tries different nonces C in the transaction script (B1 & B2 & ... & Bn) & (C | D) . If the resulting address matches a pattern, he informs the arbiters who the client is. He sends C to the client and each arbiter send his bi to the client. Each arbiter then deletes the key and generates a new pair to be used for the next completed address and broadcasts the public key to all miners. Then the only way to steal the funds is if all arbiters collude and share the client's keys.

Without the benefit of mining vanity addresses for multiple clients while looking for your own too, with minimal performance penalty, it doesn't seem an endeavour worth pursuing.

This endeavor is worth what its purchaser will pay for it. I can think of two main reasons to use vanity addresses:

1. Well, vanity - to show the world you have an intensional address with a harder pattern than other people. Then it doesn't matter at all how hard or easy it is, there will be a market of those who want harder than average.

2. To have a simple firstbits address - then generally you want the vanity pattern as short as possible while being unique. The length it takes to be unique is fixed, so if generating addresses is too easy there will be no market for generation since anyone can generate the required address.

So, harder generation is better for generators and for businesses wanting to protect their brand, indifferent for most other people.

I've was kind of aware of what deepceleron pointed out in the current last post of that thread:

However, I don't think anything like this should be included in Bitcoin. Although not any more dangerous than "firstbits", it would make it too easy to spoof people into sending money to an "amazon.com" that goes to a malicious squatter instead. It also hinders anonymity and the sender identification that comes with one-time-use addresses.

The first line of defense should be doing due diligence, an example of when Matthew once changed one letter in a domain name, making us believe there was an update to an infamous letter.

Thanks, all, for helping me with this. I'll be back!

~Bruno~

[mcorlett]

Also, is there a way to just pen an address, partially or a complete one, have it checked to make sure it's not already in use, then have a private key made for that? e.g. 1TurkeyBob1siHHu8...etc...

Regarding your second question, no, encryption is one way only. It is VERY quick and easy to make a public key from a private key, but almost impossible to make a private key out of a public key.

To correct, encryption isn't one-way only. Hashing is.

[bitpop]

I started 4 copies of vanitygen but they all use the same rng seed file. Will they all be starting from the same spot? Or is there added entropy even if I use a seed file? Thanks.

[deepceleron]

I started 4 copies of vanitygen but they all use the same rng seed file. Will they all be starting from the same spot? Or is there added entropy even if I use a seed file? Thanks.

Use them all to find the same simple phrase, like 1234, you should find that they each find a different one.

[bitpop]

I will try restarting one and see if it gets the same ones in order.

I started 4 copies of vanitygen but they all use the same rng seed file. Will they all be starting from the same spot? Or is there added entropy even if I use a seed file? Thanks.

Use them all to find the same simple phrase, like 1234, you should find that they each find a different one.

[cypherdoc]

anyone run into the error:  CL out of resources?

using app sdk 2.5, win 7 64 bit, 2 x 6970 gpu's usually used for mining via cgminer. 

turned them off and restarted so they aren't running, i think.

[deepceleron]

anyone run into the error:  CL out of resources?

using app sdk 2.5, win 7 64 bit, 2 x 6970 gpu's usually used for mining via cgminer. 

turned them off and restarted so they aren't running, i think.

You mean like the error you get if you try to search for 50,000+ addresses at once?

[cypherdoc]

anyone run into the error:  CL out of resources?

using app sdk 2.5, win 7 64 bit, 2 x 6970 gpu's usually used for mining via cgminer. 

turned them off and restarted so they aren't running, i think.

You mean like the error you get if you try to search for 50,000+ addresses at once?

no just one.

[Rassah]

I an guessing that vanity names will explode in usage after the reward block halves, since Bitcoin mining will be very unprofitable at that point, and there will be a lot of hashing hardware sitting idle. I recently decided to focus on mining while I can, and put my vanity name generation off until next year.

[malevolent]

I an guessing that vanity names will explode in usage after the reward block halves, since Bitcoin mining will be very unprofitable at that point, and there will be a lot of hashing hardware sitting idle. I recently decided to focus on mining while I can, and put my vanity name generation off until next year.

The difficulty:price ratio will also change and only that's important (apart from maybe liquidity on exchanges).

[Rassah]

There will be two weeks for the difficulty change, and many more weeks for those mining at a loss to finally quit. I don't expect the price to change almost at all from that, since miners have little if any effect on the market. So, for a few weeks mining will be very unprofitable, and likely getting blocks to confirm your transactions will take way longer than normal. Just in time for the holiday shopping season, too 

[Red Emerald]

Has anyone worked on getting secure zero-trust generation of vanity addresses by a third party?

Something like the user generates a private key and a public key and then gives the public key to someone with a bunch of hashing power.  They take the given public key and multiple it by a private key generated by vanitygen2.0. If that gives an address that matches the search pattern, the private key is sent securely back to the user.

I think this could be a great service.

I can't think of a way for the third party to prove they have generated the address without giving the key to the user.  I was trying to figure out how to monetize this.


EDIT: It looks like Armory has the math for this built in.

(1)Emulated 2-of-2 multisig  Note:  this is only for the case that one party will be redeeming the full amount of the encumbered funds:  there is no trust-free way to split the funds with this method (which makes it useful for Casascius+OtherParty physical bitcoins).

• Each party produces a new address (which should not be in their wallet [explained later])
• From the wallet properties dialog, or the "Keys" tab in the calculator, fetch public keys and exchange with the other party.
• Fetch your own private key for the public key you just sent
• Use the middle entry in the calculator dialog, to multiply the other person's public key (enter x,y pair) by your private key
• Both parties get the same answer!  This is because party A has private key a and public key a*G and party B has private key b and public key b*G.  Both parties then end up producing a*b*G which is a new public key.  However, neither party can calculate a*b (which is the private key for the public key both parties calculated).
• Calculate the address for the public key, and fund it with the amount of money agreed upon.

This is called an "Elliptic-Curve Diffie-Hellman" exchange (ECDH).  It is usually for creating a shared secret with your public keys (such as an encryption key).  In this case, it lets you produce an address that only someone with both private keys can access.  At the end of this process, one person must send the other person their private key, so that they can calculate the shared private key and redeem the funds!  This is why the private key you generate should not be part of any wallet, because it will eventually be shared and you never want to share a private key in one of your wallets!  

This could be used by Casascius and another party:  Casascius and other party execute the process above, and fund the address with 1000 BTC (for a 1000 BTC gold bar).  Casascius gets his hand on the gold bar, and puts his tamper-proof private key on it.  He sends it to the other party, and they put their tamper-proof private key sticker on the other side.  Now, the user with the gold bar is the only person that will ever see both private keys (once he peels them off) and thus, the only person that can ever spend them!  Just plug one into the 'a' field of the calculator and the other one into the 'b' field of the calculator  (if Casascius wanted to do this, I would add a simpler, reduced interface for multiplying private keys, but it is technically do-able as-is).

EDIT: I am so rusty when it comes to C.  I don't think this would be too complex to write, though.  It would definitely slow down address generation since you have to do some key multiplication.  A public key would be need to be passed as an additional argument.