Quote from: Evil-Knievel on June 23, 2016, 09:16:56 AM

This is the current work flow / payment flow. What do you think, does that make sense?
Also, I need some input on the red line ;-) Thanks

1. User creates a job and attaches a certain amount of money M.
2. This money M is split into two piles, 60% go to the pow fund P and 40% go to the bounty fund B.
3. Users periodically send proof of work packets which are themselves rate limited by an automatically adjusted difficulty. Based on that difficulty, users are credited a variable amount V from the pow fund P.
4. Users periodically send bounties (that is, no proof of works but rather those results that the author of the job is looking for), these are included in the blockchain but do not yet pay anything.
5. To avoid DOS with a huge amount of bounty submissions which are not rate limited, we have to limit the number of allowed bounties. (here I need the community's opinion ... should we go for a hard limit or a variable limit which can be increased by higher fees maybe?)
6. Once the pow fund P runs out of money, the job is cancelled or timed out or the job has received the maximum number of bounties these two things happen:
- The author of the job gets credited the remaining funds in the pow fund P
- The bounty fund B gets evenly distributed among all bounty submissions - so if there were 10 submission, each one of them gets 1/10 of the bounty fund B.

Note: This means that the total money (P+B) is only refundable as long as no bounty has been submitted. If one has been submitted a job the refund after a cancellation or timeout is at most what was in pow fund P.

A variable limit , and can be increased by higher fees.