The scale and speed of the multipools is simply too large relative to our dedicated miners.
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.
The target for the block time is 2.5 min
Reject blocks of lets say less than 30 sec or 1 min block time (could even be by same IP). That would take away a reasonable part of the advantage for very high hash power jumping in at low diff.
Adjustment between blocks
... The diff is halved when 10 minutes have past without a block. ...
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.
... The diff is halved when 10 minutes have past without a block. ...
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.
Dividing it by 4 to bring it back closer to the default block time sounds better.
Anyway, here is what I was thinking about to modify our DGW3 for faster adaption to hash rate changes:
Either take the actual hash rate reading into account (was reading weeks back that a coin did this but can't find it again) or try to predict it by giving the blocks in the interval different weight for the calculation.
The first (oldest) block in the interval gets the lowest weight and increase it to the last (newest) block with the highest weight. Maybe double or triple the weight from one block to the next, so the latest blocks are getting far more important for the next diff.
This way it would react much faster to heavy hash rate changes and would not have a big impact on smaller variations.
I still think the very short blocks should get rejected too; less than 40% of the default time is too short.