Rejecting blocks
This sounds like a good idea, but I'm afraid it can be bypassed fairly easy. A multi-pool could implement some software to premine blocks with future timestamps, and broadcast those future blocks when the time is right (while the actual mining machines are working on different blocks on a different coin). So in the end, it will still result in multi-pools getting a lot of blocks.
Right now a jumpool gets 80+% of the coins in a couple of minutes. Even if such pool mines in advance and drops the block after the timeout expires and we asume a timeout of 75 seconds he could not mine more than 1 block every 75 seconds and thus his gains lower dramaticaly. He would have to adjust his software to act as you described but always have 10 fold less profitaility as other coins. The premining of blocks can be further prevented by randomising the timeout. If he mines in advance he can drop the block till it's accepted but cannot mine the next because he does not know in advance if he's at the right time, if another miner was lucky to be the first, hashing in advance is useless because the next block would not match.So thats not a problem the real problem can be higher vulnerability to timewarp and a proper calculation has to be done for that
How would you randomise the timeout? The consensus algorithm for bitcoin/guldencoin is that the miner creates the blocks, and the data is confirmed by all other nodes. So the miner would decide the 'random', and no-one could check if it is truly random. One could use the block hash as input for the timeout time calculation, that would make it pseudo-random I guess.. But in both cases: the miner knows the new timeout, and can directly start mining the next block, he doesn't even have to broadcast the first block yet (giving other miners a huge disadvantage). In the end, a multi-GH/s pool can mine a 'perfect' row of blocks in advance, while the dedicated miners have just a few blocks, and will lose in a chainsplit.
Time based block reward
When the block reward is based on the seconds that have past since the previous block, it will discourage multi pools to mine a lot of blocks at once, as it won't be profitable since the reward will be low.
For example: 150 seconds since last block would reward 1000 NLG and 15 seconds would reward 100 NLG.
As pointed out by ny2cafuse: the downside is that "lucky" blocks will have a smaller reward. On the other side, we could change the max block reward to 2000 NLG (rewarded at a block being 300 seconds after the previous block). This means that in the end exactly 1000 NLG per 150 seconds would be generated, regardless of "lucky" or "bad-luck" blocks or jumping pools. To me it's still unclear if there are exploits with this approach (for instance: invalid block times to receive more coins).
Like I said before NO limits. If there is a very tough block it is a huge incentive to gain thousands of NLG to mine it. Limiting does affect the coin supply. Here again the small miners benefit because they also can have the jackpot when their pool finds a tough block. Okay the luck factor changed from lucky to find a NLG 1000 block in three seconds to finding a NLG 10000 block in 15 minutes, but it's still there. There maybe a drawback however, right now clever stops at high diff but in this case he can wait till the blocktime is over 150+ seconds and wham mines that block fast, waits, leaves the easy low value for the small miners and hits again when the blocktime goes over 150some secs.
I think there should be a limit but it should be higher, maybe 10.000 NLG for a block that is 1500 seconds after previous block. The reason I want a limit at some point is because otherwise a huge pool could exploit the system by creating a huge diff (getting small miners stuck), waiting a few hours, then mining that one huge-diff block worth 100.000 NLG.
Beside all these solutions I still think the problem is the way DGW3 is implemented. It just does not react the way it should and that has nothing to do with being designed for... Because its a counting algo based on the last 24 blocks. One thing that also keeps me busy is the fact that KGW did not work properly either so maybe the solution is at some totally other place in the code. You sometimes see the same strange behaviour when variables are used outside the memory space and overwritten by some other procedureDGW3 was not modified, except for some code comments and alignment. It looks like DGW3 is calculating correctly, the problem is that it was not created for jump pools at this scale. I have been thinking about increasing the number of blocks into calculation (currently 24). But I'm affraid that it will only result in multipools getting more blocks before the diff spikes. What do you think?