Quote from: Haku99 on January 14, 2014, 05:20:28 AM

ajochems: I very much agree with your assessment. Network hash rate drops too far when multipools switch out. Seems there's even a risk of being forked during these phases. At times it drops to ~50MH/s or lower. Multipools also hurt the stability of the value as many probably hash directly to cryptsy with auto-sell active, so the market gets flooded with unwanted and undervalued coins.

Quote from: illodin on January 14, 2014, 08:38:17 AM

Isn't it possible to adjust difficulty according to time interval? Once per hour or once per x amount of blocks, which ever is reached sooner..?

Exactly, ... it is the combination of the drop in networkhashrate and still high difficulty. Since we retarget after 720 blocks and the average time per block rises from the target 30 seconds (6 hours) to about 100 or more (about 20 hours or more) we get into trouble. Because of the average block time that does not get adjusten we see blocks found slower, confirmations take longer, transaction speed drops. This is not good for what the coin was meant for, a fast coin for fast casino transactions.

I think illodin has a very good point!!! We should include time as a parameter into the retarget formula but i would also lower the amount of blocks to retarget anyway. If you cut it in half and retarget every 360 blocks that would be normally every 180 hours. If we take whatever is sooner, time or blocks for a retarget it would be like this:

- profitability rises, network hashrate increases
- average block time drops below target 30 sec, e.g. to 20 sec, retarget based on time would be in 180 minutes, retarget based on blocks would be in 120 minutes
- as soon as the 360 blocks are reached difficulty should be recalculated and will rise
- profitability drops, network hashrate decreases
- average block time rises above target 30 sec e.g. to 45 sec, retarget based on time would be in 180 minutes, retarget based on blocks would be in 270 minutes
- as soon as 180 minutes are reached difficulty should be recalculated and will drop

My proposal would be:
- default retarget in 360 blocks or 180 minutes, whatever is reached first

@transcoder: if you do not want to change the retarget block count, at least include the time for 720 blocks which is 360 minutes into the retarget conditions as min/max setting. Although i think that the erratic behavior justifies a lower retarget block count as well. Do you have the knowledge to make such adjustments to the casinocoin source code?