How would you structure a proof of work? My only idea is to accept partial matches to the pattern as proof if work, and pay earn a share percentage for that proportional to how "close" it is to the desired pattern. This seems complicated, but probably possible. I need to spend some time thinking about how the math would work out.
Standard pool software just has a constant target for a "share". I don't think you really need to change that.
You want that to be sufficiently difficult so that miners aren't spamming the server, but not so difficult that they have very high variance.
You could specify a maximum distance from a valid target as your share difficulty. That would give better resolution than number of letters matching (which would step in multiples of 58).
The pool would work on 1 address at a time. There would be a list on pool site sorted in terms of(bounty) / (complexity of target).
It would always pick the most profitable target. If you want the pool to work on your address, you have to out bid the address that is currently active. Otherwise, you get added to the queue.
You could also do it ebay style. The buyer submits the max they will pay and the top slot is auctioned. You pay what the 2nd highest person bids.
However, there could be a rule that it won't work on hashes that would have an expected duration of more than 1 hour, given the pool's current hash rate.
If using PPLNS, then you ideally want the range to normally cover at least a few wins. The value of a share would be proportional to (share difficulty) * (bounty) / (complexity) for the target. The share difficulty could be adjusted to keep it so that N shares = 2 hours on average. Combined with a 1 hour limit of expected search time, that keeps variance low.
The buyer- Generates key pair (A, a)
- sends target string to the pool
- sends public key (A) to the pool
- sends payment (in advance)
The buyer can cancel but there is a 1 hour delay if some miners were working on the target. A miner might find the hash in that time, so they would still have to pay the bounty. That is unlikely though, since the pool would automatically update to the new "best" target. Miners could be updated by something like the "longpoll" system to move to the new hash.
Also, it would be a good idea to have software that handle's the buyer's side. This would be open source and do the calculations required for the buyer. That aren't that complex, but it would increase
The pool- Adds address + bounty to the pending work page on the website
- Generates key pair (B, b)
- sends target string, public key (A + B) and bounty to miners
Miners runs this in a loop
- pick c (private key)
- compute C (public key)
- add (C + (A + B))
- compute base58-encode(C + (A + B))
- check if it meets the difficulty requirements for a share
-- send c to pool and receive 1 share
Note: Miners don't have A or B, they just have (A + B)
The pool
- receives c
- checks c is valid for a share
-- adds a share to miner's total
- checks if the address matches the full target
-- publishes (c + b) and the address on the pool's website
-- sends (c + b) to the customer
-- Adds payouts to the miner's accounts
The advantage of that is that it is all safe for each group. There is a rule with keys that if a and b are private keys with public keys of A and B, then (a + b) will be a private key matching (A + B).
It prevents miners from sending the winning share directly to the customer. You need to know three pieces of info to actually use the address; a (customer knows), b (pool knows) and c (miner knows).
The miner which actually hits the winning value for c should probably get an extra reward (say 1% of the bounty goes to that miner).
