Difficulty Spike?
-
I see that difficulty jumped up to ~200 today, while it was hovering around 30 in the past weeks. This is a huge 700% jump!The network hash rate is somewhat higher than usual, but not out of the ordinary. What’s going on?
-
We had an even higher spike some days ago.
See http://forum.feathercoin.com/topic/9153/ftc-block-difficulty-analysis-500-difficulty-mhash-attack
We are analyzing the behavior and the devs take countermeasures, if they think it is an attack or a flaw in the code.
-
True, but that event was triggered by the hash rate spike from 1.6 GH/s to 14 GH/s (>800%). Right now the hash rate is around 3 GH/s.
-
@taurus @Wellenreiter I also agree, this time it’s odd – I don’t see a similar spike in hashrate to force diff to 200.
Only place I can see a detailed graph of difficulty is on a mining site like zpool (http://www.zpool.ca/explorer/FTC), but it only holds 12 hours worth (so go look now to see what the “spike” really looks like!). “eHRC” in action… for better or worse.
Coinwarz’ hash chart is screwed up when zoomed into less that a couple weeks (is there a better one somewhere else?), but still doesn’t show a spike to correlate to this diff rise like the last time - it only looks like 1GH was put on this time.
-
Interestingly, block #1889029 took more than 41 minutes (!) to create. This just shows that the difficulty was way too high for the going hash rate at a time. Coincidentally, this block has by far the highest Tx value: 226,757. Smells fishy to me.
-
@taurus said in Difficulty Spike?:
Interestingly, block #1889029 took more than 41 minutes (!) to create. This just shows that the difficulty was way too high for the going hash rate at a time. Coincidentally, this block has by far the highest Tx value: 226,757. Smells fishy to me.
It merely shows, that the hashrate dropped dramatically before b1block #1889029 was mined.
-
@Wellenreiter
You’re correct, of course. It’s a common problem with all blockchain algo’s. It’s has fast response time to the hash rate increase, but slow response time to the hash rate decrease because the difficulty can only be adjusted on the block boundaries. So, a rapid decrease in hash rate can cause network starvation, i.e. no new blocks created for a long time. -
that is correct, but we decided against a faster downward adjustment, as this may create other problems.
In theory we could adjust eHRC to dampen the difficulty decrease calculation less than the increase calculation. Then the BC would need less blocks to adjust the difficulty down.
