Chiznitz said:
Not sure why we would not go with digishield, its being used in almost all coins that are moving from KGW, I'm sure it has issues but the issues of not using it are much greater.
There is a lot of copycatting happening and not a lot of original thought put into the math. One solution catches on (Digishield because Doge adopted it) and other cryptos blindly copy it. Just because other cryptos are doing it doesn't mean the solution is any good! Digishield is better than nothing, but the question is: What works best? Or, can another approach work better than DigiShield?
If you look at the link a few posts above, which describes the DigiShield algorithm, the problem I see is that the difficulty rises quickly, and lowers slowly. The problem is spikes, which are by nature short-lived and bring a sudden increase in total net hash power. This causes TWO problems for the coin:
Problem #1: If the algorithm doesn't adjust difficulty up quickly, whoever is bringing the huge hash power gets away with an insane amount of coin in a few hours, because the difficulty remains low for a long time (because it adjusts too slowly). These coins are then dumped on the market, hurting the value of the coin. When coins are defined, a key characteristic is how often they are generated: "X blocks every Y minutes." RPC was defined as 1 block = 1 coin = every 2 minutes. When spikers can snatch 1 coin every 12 seconds, as they did a few times lately, that screws everyone else, who has invested work and earned returns at the normal rate of work of 1 coin every 120 seconds, or thereabouts. In 10 minutes, spikers can grab 2 hours worth of coins, leave, and return and do it again.
Problem #2: If the algorithm doesn't adjust difficulty down quickly, after the spike is over, the smaller, regular miners are left with a very high difficulty. This means:
(A) a very long time to solve blocks,
(B) long confirmation times, and
(C) miners lose interest, because it takes forever to get a coin. Their labor & electicity is better spent elsewhere.
Moreover, (C) makes (A) and (B)
even worse because
blocks have to be solved before the 48-blocks per re-adjustment threshold is reached.
DigiShield solves Problem #1; it doesn't address Problem #2, because by design it lowers values slowly.
Colin's solution addresses Problem #1 AND Problem #2, and is thus better.The spike yesterday is a good example (I saw 1.54 GH/s, compared to normal values around 0.4 GH/s). Difficulty jacked up from 3 - 4 to 16, and now is slooowly falling off. Why? Difficulty adjusts every X blocks (48 right now), but when the difficulty goes high from a spike, and then the big hashers leave, it takes FOREVER for smaller miners to get through those next 48 blocks. Difficulty right now is still 13, and the total net hash rate is 0.04 GH/s. Chunky's Pool was virtually empty after the last spike. Thus we see Problem 2 (C) above: miners lose interest. As a result, it will take
days for the difficulty to get back down to 4 where it was. And anyone waiting on a transaction will have to wait days or hours -- because of (B).
Lastly, regarding 11% max swing for both increase and decrease...is there any reason why 11% is still the magic number? Evaluated per block, it's still a good improvement, but wouldn't higher be better?
To take the last spike, the difficulty jumped from 4 (it was briefly 3.8 before that) to 16. Waiting 48 blocks to adjust, that means a max of 48 blocks to plunder. Waiting 1 block to adjust, it would take just 14 blocks to adjust from diff 4 to diff 16. (1.11 ^ 14 = 4.3) If we chose a max swing of 20%, it would take only 8 blocks to adjust from diff 4 to diff 16 (1.2 ^ 8 = 4.3).
Colin's solution will still mean a slower return to normal difficulty, however. Why? Because when the big hasher leave, blocks still have to be processed before the difficulty readjusts. Adjusting every block is MUCH better than every 48 blocks in this regard. BUT, because max swing is capped at 11%, all the 11% steps downward will still take a time.
Take the last spike again as an example. When the difficulty hit 16, and total net hash returned to normal (0.04 GH/s), it now takes 15 - 20 minutes to solve EACH block. So 14 blocks to readjust downward is going to mean about 3.5 hours (14 blocks x 15 mins per block). It will actually be less, more like 2.5 hours, because the difficulty is slowly adjusting down, but you get my point? When the spike is on, blocks fly by, so difficulty adjusts in
a few minutes. Plunder is thus stopped. But when the spike is gone, blocks still crawl, and thus the return to low difficulty
still takes hours.
My quartile approach, which no one seems to like but me
tries to solve this by ignoring the spike hashrate values when they are gone, and getting the difficulty back down more quickly to baseline, as defined by the lower 75% of block hash rates. I think it would solve Problem #2 even better than Colin's solution. But if Colin increased the max swing to a value greater than 11%, then problem #2 would not be as big. People can ride out a few slow hours. But a few slow days is horrible!
That's my $0.02. I'd love to see more argument, not just "other people use KGW / DigiShield."
