Can Miner Generate Vanity Address?

[Bitcoin++]

Since the ASIC solves double-SHA256 and this is used in generating bitcoin addresses, may mining hardware be used to generate vanity addresses?

[DrG]

Yes it is available here:
https://bitcointalk.org/index.php?topic=25804.0

No longer advised to use vanity addresses other than to receive funds and the quickly transfer them to another address due to security issues.

[RoadStress]

Yes it is available here:
https://bitcointalk.org/index.php?topic=25804.0

No longer advised to use vanity addresses other than to receive funds and the quickly transfer them to another address due to security issues.

Why? What's the risk?

[Vortex20000]

Indeed, what's the risk?

In reply to OP, you're looking for Oclvanityminer.

[jonnybravo0311]

I don't think the OP is looking for vanitygen, unless it can be adapted to work with your ASIC hardware.  Vanitygen works on your CPU and oclvanitygen works with your GPU.  I don't think there's an ASICvanitygen.

Also, DrG, I'm curious to know what the security risks are for using vanity addresses.  If I've compiled and run the program on my own box, I don't see the issue here.  I mean, I suppose somebody could try the brute force method of reverse engineering my private key using my public address... but that's an inherent risk in general and not specific to vanity addresses.

[BurtW]

Receiving multiple transactions into a vanity address (or any address) does not pose a security risk but does pose a privacy risk.

Multiple sends from the vanity address (or any address) does reduce security since the first send from any address publishes the public key.

Address reuse of any kind poses a significant privacy risk not only to the address owner but to everyone doing transactions with the address owner.

Vanity addresses are very bad because they encourage address reuse, which reduces the overall privacy for the entire Bitcoin system.  Very few people, if any, create a vanity address in order to just use it one time.

Finally, address reuse poses a significant threat to the long term viability of Bitcoin because it poses a threat to the fungibility of Bitcoin.

[BurtW]

Since the ASIC solves double-SHA256 and this is used in generating bitcoin addresses, may mining hardware be used to generate vanity addresses?

First, vanity addresses are a bad idea since they encourage address reuse, see my previous post.

Second, the hashing operation for mining is different than the hashing operation for generating vanity addresses.

Third, the hashing of the public key is only part of the time consuming operations needed to generate a vanity address.  Generation of a vanity address also involves: random private key generation, calculating the public key from the private key, base conversion, and finally regular expression matching.

None of this can be done by an ASIC designed specifically for Bitcoin mining.

So the answered is no.

Given a couple million dollars an ASIC could be designed and produced specifically for vanity address generation.  However this would be a huge loss as the market for long vanity addresses generation does not support the large NRE investment.

And to answer your next question, no, even with millions of state of the art ASICs all running 24/7 you could not generate a vanity address that was a full match to a known address so you could steal someone's BTC.

[jonnybravo0311]

BurtW, thanks for the informative replies!  You state that using any address (be it a vanity address or a randomly generated one) multiple times poses privacy risks.  What's your stance on mining in pools?  Some pools (Eligius, p2pool, etc) use a BTC address as your worker name, and pay directly to that address as part of the generation transaction.  Other pools (GHash, BTCGuild, etc) use a wallet address that you provide to send you payouts.

I mean, I suppose if I were entirely paranoid, every time a block was found or a payment was made I could reset my miners/pools to use different addresses, but that seems a bit like setting up a faraday cage in my basement and wearing a tin foil hat

[RoadStress]

Since the ASIC solves double-SHA256 and this is used in generating bitcoin addresses, may mining hardware be used to generate vanity addresses?

So the answered is no.

Thank you for clearing this up and for the rest of the information.

[DrG]

BurtW said pretty much everything I wanted to say.  Since each Bitcoin transaction follows from another leading back to block generation, any known traceable ID via a vanity address decreases the anonymity of all transactions with that address.

Since payment address for pools are generally not associated with any specific person or entity they remain somewhat anonymous.

[BurtW]

BurtW, thanks for the informative replies!  You state that using any address (be it a vanity address or a randomly generated one) multiple times poses privacy risks.  What's your stance on mining in pools?  Some pools (Eligius, p2pool, etc) use a BTC address as your worker name, and pay directly to that address as part of the generation transaction.  Other pools (GHash, BTCGuild, etc) use a wallet address that you provide to send you payouts.

I mean, I suppose if I were entirely paranoid, every time a block was found or a payment was made I could reset my miners/pools to use different addresses, but that seems a bit like setting up a faraday cage in my basement and wearing a tin foil hat

OK you have hit on a pet issue of mine so sorry in advance for the long post.

My position is that every periodic payment should be done using deterministic key pair generation.  Of course this includes all mining payouts.  The way this would work is that instead of generating a normal private/public key pair and giving the Bitcoin address of the public key to your mining pool for payout you would generate an extended private/public key pair and give the extended public key to the mining pool.

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key.  So the mining pool would send your first payment to the first public key, your second payment to your second public key, your third payment to your third public key, etc.

Meanwhile your client can generate the first private key that corresponds to the first public key, the second private key that corresponds to the second public key, etc. so you can claim/spend the BTC when you are ready.

This way every single periodic payment can be sent to a unique public address.  Cool, right?

However, I do not know of a single pool that supports this payment mechanism.  I do not keep up with all the various mining pools having given up mining at the end of the GPU mining era myself.  So, if there is a pool that supports this please let me know.

All miners should demand this from every pool they use and only use pools that support this mechanism.

In the mean time, while waiting for this to be implemented system wide, the next best thing you can do is create an address that you only use for your mining income and nothing else.  Never spend these coins directly.  Instead always send them through a mixer before you use them or at least send them through a few rounds of coinjoin transactions (called shared send on the blockchain.info wallet) before you use them.

[jonnybravo0311]

BurtW, thanks for the informative replies!  You state that using any address (be it a vanity address or a randomly generated one) multiple times poses privacy risks.  What's your stance on mining in pools?  Some pools (Eligius, p2pool, etc) use a BTC address as your worker name, and pay directly to that address as part of the generation transaction.  Other pools (GHash, BTCGuild, etc) use a wallet address that you provide to send you payouts.

I mean, I suppose if I were entirely paranoid, every time a block was found or a payment was made I could reset my miners/pools to use different addresses, but that seems a bit like setting up a faraday cage in my basement and wearing a tin foil hat

OK you have hit on a pet issue of mine so sorry in advance for the long post.

My position is that every periodic payment should be done using deterministic key pair generation.  Of course this includes all mining payouts.  The way this would work is that instead of generating a normal private/public key pair and giving the Bitcoin address of the public key to your mining pool for payout you would generate an extended private/public key pair and give the extended public key to the mining pool.

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key.  So the mining pool would send your first payment to the first public key, your second payment to your second public key, your third payment to your third public key, etc.

Meanwhile your client can generate the first private key that corresponds to the first public key, the second private key that corresponds to the second public key, etc. so you can claim/spend the BTC when you are ready.

This way every single periodic payment can be sent to a unique public address.  Cool, right?

However, I do not know of a single pool that supports this payment mechanism.  I do not keep up with all the various mining pools having given up mining at the end of the GPU mining era myself.  So, if there is a pool that supports this please let me know.

All miners should demand this from every pool they use and only use pools that support this mechanism.

In the mean time, while waiting for this to be implemented system wide, the next best thing you can do is create an address that you only use for your mining income and nothing else.  Never spend these coins directly.  Instead always send them through a mixer before you use them or at least send them through a few rounds of coinjoin transactions (called shared send on the blockchain.info wallet) before you use them.

Certainly no need to apologize.  I'm always interested in learning more about ways to improve this thing called Bitcoin .  Truth be told, I'm one of those vanity address guys - mostly because I thought they would be cool to have.  I've generated a few and have used them here and there (for example, my forum profile has one attached to it).

To answer your question, I don't know of any pool that offers the type of functionality you're describing.  I know p2pool certainly doesn't (I've spent quite a bit of time with that code).

I like the idea of this extended key you proposed.  Where I'm a bit confused is in the execution of your mechanism, specifically here:

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key.

Both you, as the owner of the private keys, and the pool, as the one who would have to generate public keys based upon the extended key, need to be synchronized.  I get how you can create this and say, "Here's an extended key with n public keys" and you've created that "n" of private keys corresponding to them.  What I don't get is how you'd make that "n" dynamic.  I'd appreciate if you'd educate me a bit.  Thanks!

[BurtW]

There is no n.  The xpub key desribes a starting point on the eliptic curve and how to get to the next point from any point.  So you start by sending a payment to point P₀, the starting point, and then you can calculate P₁ as a function of P₀.  Once you send to P₁ you calculate P₂ as a function of P₁ and so on "forever".  An xpub key describes an endless (for all practical puposes) sequence of public keys.

The two parties involved just have the agreement that the sender will use each key only once and use them in sequence.  Therefore the receiver just looks through the sequence of keys until they find the last one that has gotten used and then the next one in the sequence is the one the sender will be using next.  All this will be done automatically by your client and the client will just keep all the previously used private keys just in case someone accidently sends BTC to one of the previously used addresses.

I hope that clarifies things.

This is all covered in one of the Bitcoin Improvement Proposals (BIPs) I just don't recall off the top of my head which one.  BIPs are listed here:

https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

I think it is probably described somewhere in #32, if I get a chance I will dig it up for you.

[jonnybravo0311]

There is no n.  The xpub key desribes a starting point on the eliptic curve and how to get to the next point from any point.  So you start by sending a payment to point P₀, the starting point, and then you can calculate P₁ as a function of P₀.  Once you send to P₁ you calculate P₂ as a function of P₁ and so on "forever".  An xpub key describes an endless (for all practical puposes) sequence of public keys.

The two parties involved just have the agreement that the sender will use each key only once and use them in sequence.  Therefore the receiver just looks through the sequence of keys until they find the last one that has gotten used and then the next one in the sequence is the one the sender will be using next.  All this will be done automatically by your client and the client will just keep all the previously used private keys just in case someone accidently sends BTC to one of the previously used addresses.

I hope that clarifies things.

This is all covered in one of the Bitcoin Improvement Proposals (BIPs) I just don't recall off the top of my head which one.  BIPs are listed here:

https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

I think it is probably described somewhere in #32, if I get a chance I will dig it up for you.

Clarifies it perfectly.  I was just missing the fact that the keys were sequentially generated as part of the P₀, P₁, ..., P_n curve.  Thanks for filling in the missing pieces, and for the link to the BIP list .