Got so many ideas ;-)
Maybe we could add an alternative verification method.
Currently we have to limit the program complexity so that the supernodes can run the code in a fairly short amount of time in order to verify if the user actually found a bounty. So basically, the supernode takes the user's input, runs the entire code, and sees if the result is what meets the bounty criteria.
What if we (optionally) allow to check bounties differently? Meaning we allow checking just the result. So it does not matter if the user actually ran the program, or asked some tooth ferry, as long as the value, that the user submitted meets the criteria, it's all right. (Example: sha256d(x) hat 10 leading zeros).
Since we would allow the "calculation" to be disconnected entirely from the "verification", the actual program can be much longer and a lot more complex. Since the verification routine that the supernodes must run is short enough, it's fine.
For this type of work verification, we would have to disable POW payments since it may happen that the program runs 10 minutes or so.
What do you think? These are little things that open up entirely new use cases!
This sounds appropriate EK and could eliminate a potential bottleneck around the verification process.
If I am understanding this correctly, you are essentially allowing the calculation queue to be decoupled from the verification queue. So jobs start in order (x,y,z) and the job lengths of L(x=3sec,y=2sec,z=1sec), the first calculations verified would be the first job done with calculations (verification order: z, y, x), not necessarily the first calculation job that went into the queue.
Kind of a first come first serve approach to both the calculation queue and the verification queue?
A follow up question. Will a user be able to terminate an order if they do not like the approximated lengths of the job? Or will the users be able to dynamically adjust the processing power allocated/purchased for their jobs? Best term i could come up with is something like dynamic processing power allocation(after initial job submission)?
Wondering if there is a possibility people start continuously starting/cancelling jobs which could potentially bog down the network.
