Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 172. (Read 1153655 times)

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

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.

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?

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.

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

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.

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?

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.

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.

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

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

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?

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

^ I see. Could you describe the discrepancy below?

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?

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

Correct.

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?

First, I like the "adding keys" solution better than my "muliplying keys" solution so I suggest we go that route.

It seems to me there is a workable solution here all we need to do is solve a few logistical issues!  Fun.  Going off line is kind of a nasty issue in that from the time one participant goes off line to the time this is detected and the common starting point is recalculated the efforts of the entire network of participants is wasted.  I think there are two separate "going off line" use cases.

1) a participant decides to shut down for whatever reason - in this case an "I am going to stop participating" message could be broadcast.
2) a participant goes offline without a message (power failure, etc.) - in this case we want a mechanism to detect this as soon as possible and get back on track

In a peer-to-peer implementation could't we have each node monitor just it's connected nodes and then broadcast a "node X went offline" to the entire network as soon as it detects one of it's peers has gone offline?

In an obvious extension of the method you quoted and also the slightly more general but essentially identical method I posted, no exchanges are required (apart from a keep-alive signal if desired) until a successful match has been found. Once all but the new vanity address owner's private keys have been revealed, new public keys must be distributed to securely search for new vanity addresses.

Pooled vanity address generation seems completely feasible.

ByteCoin

^ I blatantly admit to knowing very little about EC cryptography, so I was going off BTCurious' explanation which I took to mean that the search for a vanity address can be offloaded entirely to a untrusted third party, and the result needed to generate the private key for the vanity address can be made public without revealing the resulting private key.

Now I apparently didn't read the second paragraph very well, but if this means that an exchange must take place after each unsuccessful generation of a private/public key pair in search for a vanity address, it will obviously make this method unfeasible.

So the goal is to be able to buy a vanity address by crafting a transaction. It's easy enough to reward someone for finding a certain vanity address as explained by runeks but the act of claiming the reward should enable the person offering the reward to generate the private key associated with the vanity address.

To do this, 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. Firstly, it seems hard to have a point multiplication routine in a script without looping constructs. I can see how it's possible to do in space roughly log₂ of the vanity difficulty. Secondly, implementing EC arithmetic in scripts would also be verbose. Thirdly, you'd have to that appropriate precautions to stop relayers from stripping your solution out of your transaction and claiming it for themselves.  

Finally, there is a way of generating time-limited transactions without nLockTime or a third party but it requires a couple of rounds of interaction and is extremely wasteful of computer time when used over long durations.


Yes that works better.

ByteCoin