Bitcoin Forum
January 22, 2019, 07:40:08 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Can Miner Generate Vanity Address?  (Read 1519 times)
Bitcoin++
Full Member
***
Offline Offline

Activity: 180
Merit: 100


View Profile
August 21, 2014, 09:30:49 PM
 #1

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

Posts: 1548142808

View Profile Personal Message (Offline)

Ignore
1548142808
Reply with quote  #2

1548142808
Report to moderator
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DrG
Legendary
*
Offline Offline

Activity: 1694
Merit: 1017



View Profile
August 22, 2014, 03:01:44 AM
 #2

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
Legendary
*
Offline Offline

Activity: 1862
Merit: 1002


View Profile
August 22, 2014, 03:34:40 AM
 #3

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?

H/w Hosting Directory & Reputation - https://bitcointalk.org/index.php?topic=622998.0
Vortex20000
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500

sucker got hacked and screwed --Toad


View Profile WWW
August 22, 2014, 05:03:45 AM
 #4

Indeed, what's the risk?

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


jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1015


Mine at Jonny's Pool


View Profile WWW
August 22, 2014, 11:25:40 AM
 #5

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.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
BurtW
Legendary
*
Offline Offline

Activity: 2366
Merit: 1015

All paid signature campaigns should be banned.


View Profile WWW
August 22, 2014, 11:50:16 AM
 #6

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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
BurtW
Legendary
*
Offline Offline

Activity: 2366
Merit: 1015

All paid signature campaigns should be banned.


View Profile WWW
August 22, 2014, 12:11:05 PM
Last edit: August 22, 2014, 04:03:32 PM by BurtW
 #7

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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1015


Mine at Jonny's Pool


View Profile WWW
August 22, 2014, 12:59:22 PM
 #8

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 Wink

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
RoadStress
Legendary
*
Offline Offline

Activity: 1862
Merit: 1002


View Profile
August 22, 2014, 01:41:26 PM
 #9

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.

H/w Hosting Directory & Reputation - https://bitcointalk.org/index.php?topic=622998.0
DrG
Legendary
*
Offline Offline

Activity: 1694
Merit: 1017



View Profile
August 22, 2014, 02:00:58 PM
 #10

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
Legendary
*
Offline Offline

Activity: 2366
Merit: 1015

All paid signature campaigns should be banned.


View Profile WWW
August 22, 2014, 03:57:24 PM
 #11

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

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1015


Mine at Jonny's Pool


View Profile WWW
August 22, 2014, 04:56:49 PM
 #12

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 Wink
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 Smiley.  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:
Quote
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!

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
BurtW
Legendary
*
Offline Offline

Activity: 2366
Merit: 1015

All paid signature campaigns should be banned.


View Profile WWW
August 22, 2014, 05:11:20 PM
Last edit: August 22, 2014, 05:26:21 PM by BurtW
 #13

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 P0, the starting point, and then you can calculate P1 as a function of P0.  Once you send to P1 you calculate P2 as a function of P1 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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1015


Mine at Jonny's Pool


View Profile WWW
August 22, 2014, 06:25:16 PM
 #14

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 P0, the starting point, and then you can calculate P1 as a function of P0.  Once you send to P1 you calculate P2 as a function of P1 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 P0, P1, ..., Pn curve.  Thanks for filling in the missing pieces, and for the link to the BIP list Smiley.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
Pages: [1]
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!