double remain = fmod(block, diff) + rnd(networkhashps)
??
edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)
This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.
Its not tested, but in theory, you randomize a value from the nethash, rand(diff) or rand(networkhash).
There would be no way to just run the cmd fmod(block, diff) to calculate if it would be an anomaly or not - It would be almost impossible to guess. in theory,
edit: true something that deviates from what is standard, normal, or expected. It randomness is what make it an anomaly.
edit 2: you cant calculate a anomalies - you can only calculate probability
This can't work - what would prevent a miner from simply SAYING they got a random number number that causes a remainer resulting in an anomaly? You can't have a truely random function in the getBlockValue function, or else there is no way to determine if the reward listed in a given block is actually valid.
This is why the "random" coins like Doge all use a pseudo-random function with a known seed value - the result is reproducible (side effect: predictable).
The only way around this that I have envisioned is a massive protocol change where block rewards are granted in the NEXT block to the miner of the previous block. But again, this is a massive protocol change and unlikely to get implemented in any already existent coin.
--
Changing the algorithm is a decent solution that prevents large pools and multi-pools from abusing predictable block rewards, and allows KGW to be dropped (KGW, while useful for small coins in smoothing out difficulty, actually enables other attack vectors like time-warp "51%" re-org attacks that require significantly less then 51% of the network hashrate).