It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.
This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)
Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.
Actually, I am not yet sure what would be the best way to go. There are currently three schemes on the table:
- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin.
I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.
This is an issue of computational profitabillity, that must be considered very carefully because it has immediate systemic effects.
First has thepositive that you can buy time, the negative is that non-profit research directly competes with profitable computation and is either more expensive than it would be or never gets done, or less profitable computation loses to more profitable (so Elastic becomes just an ether pool)
Second makes XEL representative money, and its value tied to the value of a gflop, this would in time decrease the value as technology improves, but it makes it cheaper to get jobs done.
Third would be computational demand difficulty, this would increase payments with more jobs, so the more successful Elastic is, the more it would cost to use it, but it would attract miners until the price would be too high for jobs. (this has similar effects as the first option)
I think that the first and third aren't viable for Elastic, the second isn't optimal as well.
I have two ideas, but not really thought them through first a correction to the third option, adjustable algo based on two difficulties one determined by # of jobs one by # of computation, (small ammount of jobs = lower payouts (less competition cost), small ammount of computation = bigger payouts (to attract miners), so you get the market flexibility but don't increase costs as much. And second, perhaps some combination could be made, you compute on the higher-pay with higher frequency, but still compute the lesser (randomly so you can't switch it off at the times you're computing for lower pay, if thats possible at all to prevent). In any case, if it is done as generalized payout, a minimum should always be determined (or people will just tag along for free).
