Quote from: c_e_d on September 28, 2014, 05:21:41 PM

BTM is recalculating the diff every 720 blocks, with an steady hashrate that translates to 1 day.
Imaging clever jumping in for exactly 1 interval of 720 blocks and than leave normal miners with the skyrocketed hashrate for the next interval for the following 720 blocks. Scary to me. It could take many days to solve those 720 high diff blocks.
That although opens the gates to malicious hashrate attacks.

DGW3 is adjusting every new block based on the last 24 blocks with a max increase to 3 times of the previous or max decrease to 1/3 of the previous. Reducing the interval of 24 blocks can make it adapt quicker (less smoother change), but on a jump you are still left with 1 block calculated based on the hashrate before the jump (called 'bad block' by me).
If we have a chance to see a bigger hashrate chance already during a block, we could take that into the calculation and the 'bad block' is gone. We should still set bounds of min and max block times and with some thinking we should even be able to translate that into a diff based on the actual hashrate.
Rejecting blocks sounds bad, resending blocks with a corrected diff sounds far better if possible. This could help at the beginning of a spike but sadly not at the end.

At first your right about the possible high diff after 720 blocks but if someone would induce such spike they have to wait for several days before they get their money because it also takes 720 blocks to mature. This will make jumppools think twice.

There is no way in the current setup to calculate the hashrate of the current block because this is done outside the network in the machines of the miners. Sure you can write some software added to the coins core to periodicaly send some status but if I was a pool I would tweak that info an tell the ouside world the hashing is very low.

You are amongst many people who say "rejecting blocks seems a bad idea" At first I got a little tired but thats not in the interest of the coin so I will explain why its not so strange...
I will refer to pooled mining. When you join a pool and start hashing on the current block, you get a diff from the pool that's less as the network diff. So you start hashing and find a matching block. You submit it to the pool and because it's hashed at a lower diff, good chance it does not comply with the network diff. And then comes the fun... your block gets rejected by the pool!
So your machine starts again and again and again, until you or another pooled miner finds a block that matches the network diff. At that moment the block is send onto the network and is accepted by the network.
So when you enter a pool you are hashing for John Doe most of the time and you get reject on reject. Your work however is recorded because the pool has to calculate how much effort you put in finding the block. The latter is the reason pools work this way otherwise they don't know how much effort you put in hashing.