Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement BIP13 (P2SH) address support #10

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

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