Woah, I swear I just thought of this same thing today! I think it is secure.
For the issue you mentioned, a possible solution: Require the private keys to be revealed and replaced at random intervals even if an address is not found. That way, it is impossible for somebody to maliciously withhold addresses, because they don't know if this time is "real" or not -- it may be the pool randomly asking to renew the private keys, or it may be that an address was found. An additional measure that could be taken is requiring people to put in payment before their address is mined, and if they withhold then you stop mining their address without refund, so they are incentivized to reveal their keys.
One big problem I see is how do you make it easy to handle private key revealing/generation? Most people don't have a personal server at home they can use. So, you can send an email whenever an action needs to be taken, then they can run the application to reveal and regen keys. But this requires them to frequently do it, which is a pain, and also means that whenever they don't do it their mining stops.
A partial solution is to generate many keypairs at once, and host many public keys on the pool servers. So, when an address is found, next round can begin immediately. Then, you only have to run the special application to give out the private keys once every few days. It just means that, if your address was generated, that you don't get access immediately. I think this is acceptable. EDIT: You could actually just use a deterministic HD wallet and give the xpub to the server to let it generate an arbitrary number of public keys.
Overall, it's a great idea, with tons of potential. When I'm done with my current project, I may begin work on a pool server and client application that creates and reveals keys. I think it can be backwards-compatible with oclvanityminer because all the miners actually need to do is mine againts an ECDSA public key, which is already what they do. If you are interested in building part of it, that would be great!
Topic: Merge mining vanity addresses? (Read 360 times)
The scheme:
Let multiple users create a private-public key pair, submit the public keys, and request a vanity pattern.
Let the vanity miners create key-pairs, combine the public key with all the submitted public keys, and check address against all patterns.
When a pattern is found for a user, all other users submit their private keys, the lucky user can combine them with his/her own to create a full private key, and the rest create a new pair.
Advantage:
Vanity miners can mine for multiple users simultaneously, cutting the computational cost.
Disadvantage:
Troublemakers can refuse to reveal keys, causing the whole computation to go to waste.
Discussion:
Has this been suggested before?
Is this practical?
Is this secure?
Let multiple users create a private-public key pair, submit the public keys, and request a vanity pattern.
Let the vanity miners create key-pairs, combine the public key with all the submitted public keys, and check address against all patterns.
When a pattern is found for a user, all other users submit their private keys, the lucky user can combine them with his/her own to create a full private key, and the rest create a new pair.
Advantage:
Vanity miners can mine for multiple users simultaneously, cutting the computational cost.
Disadvantage:
Troublemakers can refuse to reveal keys, causing the whole computation to go to waste.
Discussion:
Has this been suggested before?
Is this practical?
Is this secure?
Jump to: