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

[BTCurious]

So if I got this right:
If person A wants me to search for a vanity address for him, but I would also like to search for vanity addresses for n other people simultaneously, the result that I find, with which person A can generate his desired vanity address, is only usable to person A if he has a certain piece of information from all these n other people?

Correct.

[runeks]

^ I see. Could you describe the discrepancy below?

(The explanation assumes you know something about EC cryptography)
Person 1 makes a private key Priv1, and calculates the public key Pub1. Person 2 gets Pub1, creates a new private key Priv2, and adds (EC source point) * Priv2 to it, creating Pub2. Now, if Pub2 hashes to a nice vanity address Vnice, then Person 2 sends Priv2 to Person 1. Person 1 then adds Priv1 to Priv2, getting Privnice. [emphasis added]

To do this [verify that a VAGT is spendable], the rewarding transaction must be spendable by providing a number which, when used to multiply the generator, yields a point which when added to a specified public key point yields a new public key point which hashes to a value that gives the required vanity address.

As far as I can understand from BTCurious' explanation, verification that Priv2 is useful for Person 1 to generate his desired vanity address can be done, if both Priv2 and Pub2 is included in the spending transaction, by verifying that Pub2 is indeed the accompanying public key to Priv2, hashing Pub2 to see if the desired vanity pattern is present in the resulting address.
Your verification sounds a lot harder (and indeed difficult to implement in Bitcoin script). Is BTCurious' explanation just an over-simplification?

Thirdly, you'd have to that appropriate precautions to stop relayers from stripping your solution out of your transaction and claiming it for themselves.

Good point! I hadn't thought of this. I will have to give that some thought.

[BTCurious]

Well, my "Pub2" in the explanation you quoted, is actually the public key associated with (priv1 + priv2). I don't quite follow all the schemes that are being devised for verification though

[BurtW]

I just wanted to describe my current understanding of the basic claim algorithm here to make sure I am on the same page:

At the time a desired public key is found the node that has just found the desired public key has two pieces to the puzzle: the very "last" piece and their own private key that corresponds to their published key.

Every other node has one additional piece of the puzzle and the requestor has the "first" piece of the puzzle.

Every node has the public keys from every other node and the private key corresponding to their published key.

So the problem is to collect all the pieces together to complete the puzzle.  It makes sense to me to have all the nodes send their pieces to the requesting node.

Let's assume a node finds the desired public key and it broadcasts a message "I found public key 1xxxx... and I am claiming the prize".  In this message it includes the following:

• Its own private key, encrypted by the requestor's public key.
• The private key that found the desired public key, encrypted to the requestor's public key.
• Its new public key to be used for subsequent searching.
• The payment address for the claim.

Every node can then encrypt their current private key with the requestors public key, create a new public key and broadcast a message containing the encrypted private key and the new public key out to the network.

Every node then accepts the new public keys from everyone else, calculates the new starting point, and begins searching for the remaining patterns.

Meanwhile the requestor can assemble all the keys together, verify the claim and then pay the finder.

Is that close to what we are talking about?

[Remember remember the 5th of November]

Is it me, or this program has been stuck at version 0.17 forever?

[ByteCoin]

In this message it includes the following:

• Its own private key, encrypted by the requestor's public key.
• The private key that found the desired public key, encrypted to the requestor's public key.
• ...

I don't believe that there's any additional security to be gained by encrypting the private keys. So long as one party does not release their private key then the resulting vanity address is equally secure. If the revealed private keys are published in plaintext then all parties can verify that the private keys match the public keys. It's probably more important that the revealed private keys are signed with the public key to stop a MITM DOS attack.

The hard part will be ensuring that payment is sent for vanity keys and preventing DOS attacks.

bwagner: From what you write, it appears that you understand the scheme correctly.

ByteCoin

[BurtW]

Since nodes will come and go, workload lists will vary from node to node, and workload subnets will develop I think we need to add the following to the claim message:

Let's assume a node finds the desired public key and it broadcasts a message "I found public key 1xxxx... and I am claiming the prize".  In this message it includes the following:

• Its own private key (maybe encrypted by the requestor's public key - see below).
• The private key that found the desired public key (maybe/maybe not encrypted to the requestor's public key).
• Its new public key to be used for subsequent searching.
• The payment address for the claim.
• The list of all public keys used to make the desired vanity key.
• The entire message signed by the sending node

I forgot to include the signature in my last post.  So if we sign using the OLD private key then we must encypt the private key in the message because it is the key used to sign the message.  If we sign with the NEW private key then I guess the private key in the message can be clear text.  Still thinking on that one.

Then only the nodes on the list need respond with the private key/new public key messages.  And the same thing goes for these messages the private key can be clear if it is not the key used to sign the messages.

[Red Emerald]

This sounds really cool. It would be neat to have a site that sells vanity addresses based on their difficulty that you would not need to trust.

[BurtW]

Just wondering where everyone went.  We were having a great discussion and then everyone just dropped it Is anyone working on this?  Did the discussion move to PM?  I think this is a very cool idea and would like to be involved if anyone else would like to work on it.

It is a pretty broad project so maybe everyone thinks it is too much effort?

Perhaps a white paper is the best place to start.  I could consolidate all the discussions so far into a wiki page if everyone thinks that is the next step.

Have we reached general agreement on the main issues?

[BTCurious]

It's still interesting, but I don't have a lot of time to work on it at the moment.
I'd still keep a close eye on any development though.

[2weiX]

if someone could make a noobs guide to adding those to ones' bitcoin client...?

[BurtW]

Are you asking how to import your vanity address into your client?

Personally, I store all the vanity addresses/accounts I find in my https://strongcoin.com account since it is much easier to import private keys into StrongCoin than into the standard client.  You can also very easily import mini private keys (from physical Bitcoins) into StrongCoin.

[2weiX]

Are you asking how to import your vanity address into your client?

Personally, I store all the vanity addresses/accounts I find in my https://strongcoin.com account since it is much easier to import private keys into StrongCoin than into the standard client.  You can also very easily import mini private keys (from physical Bitcoins) into StrongCoin.

that is swell, thank you!

i am not at all familiar with the different options.
the next question will unveil my utter ignorance of how the bitcoin protocol works.

vgen gives me:
an address
a key

i do import the KEY (base58) and am then able to pass the "address" part around for ppl to pay me?

[btc_artist]

Yes. You can import the key to strongcoin or if you install a tool like pywallet, you can import the key into the regular bitcoin client.

[c_k]

Code:

>oclvanitygen.exe -d 1 -N Mtest
Prefix 'Mtest' not possible
Hint: valid namecoin addresses begin with "M" or "N"

>oclvanitygen.exe -d 1 -N Ntest
Prefix 'Ntest' not possible
Hint: valid namecoin addresses begin with "M" or "N"

Is there something wrong with v0.17 Windows x86+x64 binaries when generating namecoin addresses?

[Red Emerald]

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

[Rassah]

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

It doesn't, but you can create a new unencrypted one, import your address, and move all your money out of the encrypted one, before encrypting the new one. Don't know if there is a way to extract keys out of encrypted wallets though :/

[paraipan]

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

It doesn't, but you can create a new unencrypted one, import your address, and move all your money out of the encrypted one, before encrypting the new one. Don't know if there is a way to extract keys out of encrypted wallets though :/

or you could use the comandline options and unlock your wallet for 10-15 minutes, enough time to import few private keys with pywallet

[Red Emerald]

I got oclvanitygen running on my miner just for fun.

Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8

I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it.  I'd rather make coins with that much time.

I would still love an easy way to import these keys besides with strongcoin.  I don't think pywallet supports the encrypted wallet format yet.

It doesn't, but you can create a new unencrypted one, import your address, and move all your money out of the encrypted one, before encrypting the new one. Don't know if there is a way to extract keys out of encrypted wallets though :/

or you could use the comandline options and unlock your wallet for 10-15 minutes, enough time to import few private keys with pywallet

Oh I didn't realize that it worked like that.  I am going to have to do some experimenting now.

[HostFat]

I tried 1I and it showed this error:
Invalid character 'I' in prefix '1I'

I also tried with a char like "à" but it didn't work well.
Are there some chars that aren't allowed? ( or are them bugs? )