Skip to content

Conversation

@luke-jr
Copy link

@luke-jr luke-jr commented Jun 6, 2012

No description provided.

@samr7
Copy link
Owner

samr7 commented Jun 7, 2012

Thanks Luke!
Nice job, very clean code.
I'm still reading BIP13 but have two questions about this change.

  1. How are the private keys for this address format are handled by the clients?
  2. Which clients are able to produce the same vanity address given the private key? Presumably somebody hardcoded the same wrapper script around a single public key into a client?

@luke-jr
Copy link
Author

luke-jr commented Jun 7, 2012

To turn the 1-address into the 3-address (which is a 1-of-1 multisig), use:

bitcoind addmultisigaddress 1 '["1address"]'

Note that it doesn't work correctly in Bitcoin-Qt for receiving yet, only sending to them. bitcoind seems to be fine.

@samr7
Copy link
Owner

samr7 commented Jun 9, 2012

That makes sense. I'll accept this, and try to get it to work in oclvanitygen too.

If it's possible to embed a nonce in the script hash, it might take a lot less time to generate this type of vanity address. Guessing that's probably too hard to do in the client right now?

@luke-jr
Copy link
Author

luke-jr commented Jun 9, 2012

It's not supported by any client AFAIK, and I'd rather not see blockchain bloat purely for vanity addresses.

@samr7
Copy link
Owner

samr7 commented Jun 9, 2012

Says the guy who puts scripture into coinbase transactions.

Seriously, removing EC operations will increase the key search rate by 5x-10x, and add maybe 8 bytes of nonce.

@luke-jr
Copy link
Author

luke-jr commented Jun 9, 2012

Coinbase inputs were intentionally designed for including arbitrary data. Putting it in transactions is an abuse of the system ;)

Also, that's 8 bytes of nonce per transaction. 5-10x speedup isn't worth it, IMO. It's not like people can't just get more CPUs to throw at solving it.

@samr7
Copy link
Owner

samr7 commented Jun 9, 2012

I think we both know that coinbase transactions were not designed to hold arbitrary data any more than regular transactions or scripts for P2SH addresses, and the use of nonces was introduced to solve problems related to mining.

When the tools get more mature, it may end up being the choice of the users to decide whether to search for a nonce-including P2SH address in 1 day, or a non-nonce address in 5-10 days.

@luke-jr
Copy link
Author

luke-jr commented Jun 9, 2012

You obviously missed out on the example coinbase input Satoshi used for the Genesis block (political propaganda). :p

User choice may be unavoidable, but hiding it in an advanced option and making them difficult to use can discourage it. ;)

@samr7
Copy link
Owner

samr7 commented Jun 9, 2012

Okay then.

Thank you for your contribution to this project.

@BlinkyStitt
Copy link

Samr7 hasn't been active with this repo. I would like to support this with my fork at https://github.com/WyseNynja/vanitygen. It's easy to install with my brew tap at https://github.com/WyseNynja/homebrew-bitcoin and has various other fixes. Would you mind rebasing and submitting a PR there, @luke-jr ?

ulrichard pushed a commit to ulrichard/vanitygen that referenced this pull request Feb 18, 2014
utdrmac's fixes for oclvanitygen warnings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants