Quote from: Cor2 on March 20, 2014, 12:32:51 AM

- take the last 1.5*N block interval values (the difference between the time stamps of adjacent blocks)
- store the interval values in a double linked list

- go through this list and remove the highest 0.25*N and the lowest 0.25*N interval values (including negative values) which will remove noise and correct time travel intervals (both the before and after intervals).

I think this is the most important point in this algorithm. Bad timestamps provide no information about the block-rate and should be ignored. This doesnt solve the problem completely, but hopefully the difficulty is less wrong because we dont make big changes based on bad data. Ideal solution would be a system where timestamps can be trusted.

In general we should be more clear to divide the problem in two parts: estimating the current block-rate and calculating the difficulty adjustment based on estimated rate. Control part is not that difficult and simple proportional controller seems to be good enough for lot of cases. The difficulty comes from the fact that block timestamps that cannot be trusted are used as input its garbage-in-garbage-out. I usually work with embedded systems and detecting broken sensors there is pretty straightforward. Here the problem is more difficult because the miners have incentive to lie about the timestamps.

There is some outlier rejection in AcceptBlock() (timestamp has to be between median of last 11 blocks and 2h in the future) and it could be made stronger. I dont understand why the limit is at 2h even for Bitcoin, never mind for the faster altcoins. Extra rejection and smoothing can be done by pre-prosessing the block timestamps before feeding the blocks to difficulty controller (like in Cor2's algorithm before), so that we can still accept blocks even though we dont trust their timestamps enough to base the difficulty adjustment on them.

mkz

Posts

Merits