Topic: Vanity address mining - How to pool work? - page 2. (Read 2902 times)
Just a minor plea: Please don't build more address generators that don't use compressed keys. Compressed keys are faster to generate and uncompressed ones bloat the network.
Thanks, fpgaminer, for the great ideas! Generating a Q_b' is certainly an interesting idea, and yes, it does seem like I can simply use one of the already established methods for dividing up the bounty. An important point, though, we need to remember that miners can search for all the patterns simultaneously that belong to the same base public key. Just means passing a list of patterns back to the miner, though, and checking the returned Q_b' and offset against the entire list when they submit.
As for the bounty issue, my site allows submitters to click a "cancel bounty" button to have the bounty they submitted returned back to the address they sent from. This button is only accessible from a special link they receive after submitting the work, so anyone can't just go in and click cancel and wreak havoc.
To kontakt, yes, I have considered proxying work from other pools to allow miners to work on the best available work on any website at once. The drawback to this idea is that it requires a level of trust from the miner with my pool, because I could simply replace the payout address in the "solved work" with my own before sending the solution to the "proxied" pool, effectively stealing the bounty. Of course I wouldn't do this, but in cases of problems with the proxied pool, the miners would come knocking on my door. Not sure if it's worth the trouble to open that can of worms.
That said, replacing the payout address with my own could be the way to proxy the work AND turn it into an actual pooled implementation. That is, I want the entire bounty to be sent to my pool, then I will send out proportional bounty fractions to the miners that submitted proof-of-work. In that case, though, I would be left out in the cold if someone found the solution and submitted it directly to the proxied pool bypassing me. The Q_b' idea mostly avoids this, so still something to consider.
Thanks to both of you!
As for the bounty issue, my site allows submitters to click a "cancel bounty" button to have the bounty they submitted returned back to the address they sent from. This button is only accessible from a special link they receive after submitting the work, so anyone can't just go in and click cancel and wreak havoc.
To kontakt, yes, I have considered proxying work from other pools to allow miners to work on the best available work on any website at once. The drawback to this idea is that it requires a level of trust from the miner with my pool, because I could simply replace the payout address in the "solved work" with my own before sending the solution to the "proxied" pool, effectively stealing the bounty. Of course I wouldn't do this, but in cases of problems with the proxied pool, the miners would come knocking on my door. Not sure if it's worth the trouble to open that can of worms.
That said, replacing the payout address with my own could be the way to proxy the work AND turn it into an actual pooled implementation. That is, I want the entire bounty to be sent to my pool, then I will send out proportional bounty fractions to the miners that submitted proof-of-work. In that case, though, I would be left out in the cold if someone found the solution and submitted it directly to the proxied pool bypassing me. The Q_b' idea mostly avoids this, so still something to consider.
Thanks to both of you!
I believe a pool should hook all of the already available boards; vanitypool.appspot and all the spinoffs.
As for preventing withholding and proof of work, I've been working on learning the base of the algorithm for generating addresses. I've actually written a program over the last 2 days that converts a public key to a 25 bit standard key. Nothing new or special, just a research project.
I need to examine the double key method for the split key mining to see if this is feasible, but if a third key were added to the mix with the private key being held by the pool, you could ensure generated addresses were presented to the pool.
Since mining for addresses only requires SHA256 of RIPEMD-160 of, you can just make proof of work compatible hashes with a set amount of prefix zeroes, just as the bitcoin miners use.
As for the payment up front, I believe the best solution is to have a timeframe element associated with the job request. You pay a flat registration fee and place the bounty as a deposit. If the address is not found within the specified timeframe, the bounty deposit is returned to your account. The fee can be kept by the operator or shared among the miners. Or a little of both.
As for preventing withholding and proof of work, I've been working on learning the base of the algorithm for generating addresses. I've actually written a program over the last 2 days that converts a public key to a 25 bit standard key. Nothing new or special, just a research project.
I need to examine the double key method for the split key mining to see if this is feasible, but if a third key were added to the mix with the private key being held by the pool, you could ensure generated addresses were presented to the pool.
Since mining for addresses only requires SHA256 of RIPEMD-160 of
As for the payment up front, I believe the best solution is to have a timeframe element associated with the job request. You pay a flat registration fee and place the bounty as a deposit. If the address is not found within the specified timeframe, the bounty deposit is returned to your account. The fee can be kept by the operator or shared among the miners. Or a little of both.
Buyer (person who wants the vanity address generated) submits the following information to the pool: prefix, Q_b, bounty
Where Q_b is the Base Public Key.
Miners request work from the pool. The pool returns: prefix, Q_b'
Where:
Miners can now do the usual vanity mining. i.e.
Miners should return partial or full matches, returning only the offset from the Q_b' that they found. Miners should listen to the pool, in case the job they are working on expires (someone else found a full match).
When a full match is found, the pool can payout using any of the existing reward schemes (proportional, PPS, DGM, etc). The pool can then return the winning offset and r to the Buyer. The buyer can use these to reconstruct the final private key:
Having the pool give out Q_b' instead of Q_b allows the miners to all work on "unique" jobs. The pool can easily verify that any offsets returned by the miners are real (by adding and hashing them), and are not duplicates. I can't think of any way for a miner to fake results, so each share returned is a proof-of-work.
As for preventing withholding, I'm not sure if this is solvable, or if it's already solved in some existing payout scheme. Regardless, it's the same problem any other mining pool would face, so there should be plenty of existing literature on it.
The only real caveat here is that Buyers would need to give the bounty to the pool when they submit the job. If the Buyer were to hold on to the bounty until the full match was found, it would be possible for a Buyer to back out of the deal and stiff all of the miners. So the pool needs to hold on to the Bounty until a solution is found ... which may be never! (Buyer beware)
NOTE: This is all off the top of my head. I didn't spent any significant time checking this system for vulnerabilities.
NOTE2: The pool will need to be a mighty bit beefier than a Bitcoin mining pool, since ECDSA is a more expensive algorithm.
Where Q_b is the Base Public Key.
Miners request work from the pool. The pool returns: prefix, Q_b'
Where:
Code:
r = random 256-bit integer
Q_b' = Q_b + r * G
if Q_b' is infinity, select a new r and repeat
Miners can now do the usual vanity mining. i.e.
Code:
public_key = Q_b'
for i in range (forever):
public_key += 1
hash = hash (public_key)
if hash is partial or full match:
submit i to pool (along with some job identifier)
Miners should return partial or full matches, returning only the offset from the Q_b' that they found. Miners should listen to the pool, in case the job they are working on expires (someone else found a full match).
When a full match is found, the pool can payout using any of the existing reward schemes (proportional, PPS, DGM, etc). The pool can then return the winning offset and r to the Buyer. The buyer can use these to reconstruct the final private key:
Code:
private_key = base_private_key + r + i
Having the pool give out Q_b' instead of Q_b allows the miners to all work on "unique" jobs. The pool can easily verify that any offsets returned by the miners are real (by adding and hashing them), and are not duplicates. I can't think of any way for a miner to fake results, so each share returned is a proof-of-work.
As for preventing withholding, I'm not sure if this is solvable, or if it's already solved in some existing payout scheme. Regardless, it's the same problem any other mining pool would face, so there should be plenty of existing literature on it.
The only real caveat here is that Buyers would need to give the bounty to the pool when they submit the job. If the Buyer were to hold on to the bounty until the full match was found, it would be possible for a Buyer to back out of the deal and stiff all of the miners. So the pool needs to hold on to the Bounty until a solution is found ... which may be never! (Buyer beware)
NOTE: This is all off the top of my head. I didn't spent any significant time checking this system for vulnerabilities.
NOTE2: The pool will need to be a mighty bit beefier than a Bitcoin mining pool, since ECDSA is a more expensive algorithm.
I've been working on a project to create a vanity address mining pool, mostly as a side project to gain some experience developing a web app, but also because I felt the need to improve on vanitypool.appspot.com.
It is currently close to being ready to announce, but only as a simple "market place" for vanity address generation. That is, the concept of pooled work is not really implemented (it's not implemented in vanitypool, either).
I'm hoping to tap on the bitcointalk hive-mind to come up with good ideas for how to create proof-of-work and reward miners for partial matches. At this point, I don't see how to do this in a fair and reasonable way.
My first idea is to allow miners to submit partial matches, and those serve as a proof-of-work. After the vanity address is found (full match), the miners that submitted partial matches should receive some percentage of the total bounty. But, how to divide it up?
Bonus points for ideas that minimize risk for the pool operator, protect against miners from withholding full matches, and are simple to implement without user registration.
Thanks in advance for any input!
It is currently close to being ready to announce, but only as a simple "market place" for vanity address generation. That is, the concept of pooled work is not really implemented (it's not implemented in vanitypool, either).
I'm hoping to tap on the bitcointalk hive-mind to come up with good ideas for how to create proof-of-work and reward miners for partial matches. At this point, I don't see how to do this in a fair and reasonable way.
My first idea is to allow miners to submit partial matches, and those serve as a proof-of-work. After the vanity address is found (full match), the miners that submitted partial matches should receive some percentage of the total bounty. But, how to divide it up?
Bonus points for ideas that minimize risk for the pool operator, protect against miners from withholding full matches, and are simple to implement without user registration.
Thanks in advance for any input!
Jump to: