I'm sure you have your reasons but Elastic is not something special in this regard. Almost every single modern tech can be used to help bad guys achieve their goals. What really matters is how much good this particular tech can do in comparison. Bitcoin itself is a good example of such controversy.

What a pity, looks like POS only, nothing for the miners here 

@EK mainnet?

I have noticed a strong correlation between website beautifulness and the speed of progress, so I am very confident here ;-)

I have almost finished the only matured idea for the retargeting mechanism so far for the next testnet iteration.

I will summarize the other ideas which we discussed here soon. So far I have posted the current description here:
http://elastic-project.com/retargeting. Discussions, detected flaws and criticism and totally different approaches are always welcome. I am not meant to do this alone  

I have termed the retargeting mechanism the ...

Retaining Inverse Slow-Start

Preliminaries

Work authors push work to the Elastic network which they want to have solved by the “miners”. It is important to clarify that at the same time, there maybe 0 or more works active in parallel. To ensure “workers” who work on the work packages are paid out continuously, they are eligible (even if they do not solve the actual task) to submit PoW packages on a regular basis. This principle is similar to what traditional Bitcoin mining pools use, to ensure constant payouts to their miners. Ultimately, those PoW packages are solutions of which the “hash” (that is formed through the execution of the actual program) meets a certain target value. When we say it “meets” a target value we actually mean that it is lower than a constantly adjusted target value. The target value is meant to be adjusted in a way, that per work there are no more than 10 PoW packages submitted in each block.

At this point it is worth to note that the blockchain grows by PoS only. That is, PoW submissions are just normal transactions that are included in the blocks just as any other transaction is.

Problems with Traditional Retargeting Methods

Traditionally, blockchains use PoW submissions to extend the blockchain and the required effort to find a solution that matches a specific target value is always the same (e.g. it take on average always the same amount of hash calculations until a certain target value is met). On the contrary, in Elastic we have many different work packages which may differ significantly in the required computational effort: there may be very simple programs as well as programs that require a significantly higher amount of processing power. If all work packages work on one global target value, several problems may arise.

Very fast executing jobs may lower the target value (i.e. increase the difficulty) more significantly than jobs which need more computational effort. At the same time, the switch from a fast job to a complex job may result in a heave drop in the PoW submission rate until the target value readjusts and vice versa. This may cause heavy oscillations both in the target value and in the rate at which PoW submissions are submitted.

Furthermore, the target value tries to find a good measure of “computational investment”. That means, that one PoW submission should be worth the same amount of computational effort across all open works. This cannot be guaranteed if different jobs (with different computational footprints) are working towards the same target value. As a matter of fact, those differences make it hard to estimate a good “per PoW submission price” for a work author, as it (in the traditional scheme) highly depends on the other work live work packages in the network.

Another problem is also latent in these traditional approaches: usually, the target value is measured by a sliding window of the last x blocks and the required time to find them so that-on average-one PoW is found in a preconfigured amount of time. In approaches where the blockchain is extended by the PoW submissions itself, this scheme may be valid. In the case of Elastic, however, it may happen that there are no works live but the blockchain is still extended by the PoS miners. No matter how precise the target value has converged, after long times without work it may happen, that the target value approaches the least possible value: it is impossible for such approach to distinguish between “no PoW miners are active” and “no PoW are submitted because there is no work to do”. This effect may cause immense bursts of PoW submissions, when a new work is created after such long period without work and wakes up a huge number of miners which were on stand-by before.

The Solution

The solution to this problem is a retargeting mechanism, which we termed “Retaining Inverse Slow-Start”. Retaining, because we aim for “remembering” the average computational power of the miners as a whole across multiple work packages and across “time gaps” with no work live in the network. Inverse Slow-Start, because we use a mechanism similar to an “inverted” version of TCP's Slow-Start mechanism to quickly adapt the retained target value both to the computational processing power of all miners in case it changed unnoticed (when there is no work, no computational power measurement can be carried out) and to the varying computational effort required for different work packages.

In detail, the retargeting mechanism works as follows:

• Every work has its own target value.
• Once a work is created, the target value gets initialized with the average final target value of the last 10 finished jobs.
• There can be only 20 unconfirmed PoW submissions in the memory pool (and in each block) at most per work.
• As long as no PoW submission is made, the difficulty drops exponentially so that in at most 3 blocks it reaches the “least possible difficulty”. This is the “Inverse Slow-Start” to help bootstrapping in case of significant changes in the total computational power of the network. Otherwise, the difficulty is adjusted by means of DGW. Hence, If the number of miners decreased significantly (due to potent miners abandoning the ship), work packages do not end up with no PoW submitions at all due to the difficulty being too high for the rest of the miners: it takes at most 3 blocks to “heal” the problem.
• That is, if we have too many miners suddenly, or if potent miners joined in the meantime, they can only clutter the blockchain at a rate of max. 20 tx / block and work until the retarget mechanism fixes things. If we suddenly have only a few miners left, the target value “exponentially” heals itself.
• Due to the usage of DGW (again, in case of constant submissions of PoWs regardless of the rate) the retargeting mechanism reacts quickly, per block, to adapt each work's target value so that the work receives, on average, 10 PoW submissions per block.
• The above scheme inherently mitigates the attack when a potent miner “waits” until the difficulty drops to burst his precomputed PoW submissions. He, if he is the only miner live, in this case, can only get through at most 20 PoW submissions until the difficulty readjusts in the following block.

I think we could be ready to hard-fork the testnet tomorrow (the protocol with the bounty announcement deposit fees, see current development branch on GitHub), what do you think?