The proposed solution is to make the final step of the POW dependent upon block id.

@bytemaster pushed a commit that referenced this issue an hour ago
https://github.com/steemit/steem/issues/256

following is the  full story.. @arhag found   the solution 

@arhag 10:11 PM 
The fix is pretty simple. The dependence on the latest block_id needs to be reintroduced in a later stage of the mining algorithm so that this kind of solving backwards during signature steps cannot be done.

@arhag 10:05 PM 
But that's in hindsight by taking advantage of the fact that it could be done and that it depends on solving the active key. I've analyzed the mining algorithm before and wasn't able to come up with that hack. So I'm impressed with this hack.
It became very apparent what was happening if you know how ECDSA works and when you look at his blockchain history and why he changes his active key so much.
From now until when the next hardfork fixes the mining algorithm (hopefully soonish).
Until the vulnerability is fixed in a hardfork, it does however mean that mining is pointless right now (unless you know the trick supercomputing knows and are willing to code the hack).

RedRockMining 8:41 PM 
Hmm, if someone were to commandeer that many VPS cores I doubt it could be done profitably at standard rack rates I've seen, so either it's someone with access to many CPUs at below market rates OR someone has developed a GPU miner. I gather from what I've heard here that it would take some work but is not impossible so my guess is someone's done it.

@liondani 8:37 PM 


https://steemit.com/mining/@anonimau5/miner-witness-queue-weirdness-2-0

@steemchatter123 3:58 PM 
https://steemit.com/mining/@anonimau5/miner-witness-queue-weirdness-2-0
 
steemit.com
Miner-witness queue weirdness 2.0 — Steemit
Moments ago a new army of @supercomputin