(…)
I'm not sure this answers your specific question, but the design already allows the job author to set multiple iterations which provide bounties as well as specific criteria for what qualifies as a bounty for each iteration. once all bounties for an iteration is done the miners all move to the next iteration
Well, I didn't have a specific question per se, I was just thinking aloud, especially that e part about memory. A computer consists of a processor and data storage. We are focussing on the processing part, which is cool, but there is the memory part as well, which needs attention.
the simplest solution would be to make it the job authors responsibility to somehow provide the needed data, essentially working as a kind of RAM in which miners can check for relevant data.
However, even with a memory system in place, there may be scenarios, in which miners have little to no incentive to use this memory.
Let's take a look at the bruteforcing a password job. I'm not saying that this is something, Elastic should be used for, and you are welcome to provide a different example, but this specific job shows Elastics shortcomings pretty well:
It is pretty much throwing random input into a function and running it until a single solution is found. There aren't multiple solutions, just one. This greatly affects how miners behave:
Miners have no incentive to share information about which inputs they already tested, because they don't want to give other miners an edge. This means, that in a worst-case scenario, many inputs are tested by multiple miners, effectively lessening Elastics power.
I'm sorry that I'm rambling.
i see what you are saying but that is no different than how all mining works now...also it is not a limitation in elastic but the miner. a pool could easily be setup to ensure the unique work is done by all miners in the pool.
But either way...a lot of this depends on how well the author codes the job.
Edit: please keep in mind that the miner i wrote is just a proof on concept to demo all the functionality. It is expected that is thers will come along and improve on the design, make hardware specific optimizations, etc
), this means that all of them try the same iterations, until the fastest one eventually hits the right solution. This is a giant loss of computing power. Now, in the specific scenario, the solution would be to generate random inputs, instead of following a system, but in other cases, this leads to the network as a whole computing functions, which already have a (negative) solution.
