Re: [NLG] Guldencoin.com/pay-here — Meet our awesome community
DGW3 was developed at a time and for a network that had far smaller spikes than we see today.
I still think what we need is a faster reaction to the hash rate spikes and drops we see.
The more time it takes to settle in to the desired diff for the actual hash rate the more time we give pools to take advantage of it and normal miners will suffer after a drop and the time it takes to bring the diff back down.
The idea I wrote about a few pages back and some others picked up too is to give the newer blocks in the interval a higher weight than the older ones.
Lets say we split the 24 blocks into 4 parts when calculating nActualTimespan.
older ---> newer
part1, part2, part3, part4 (each part 6 blocks)
a more conservative approach:
part1: block times * 1 (counted like 06)
part2: block times * 2 (counted like 12)
part3: block times * 3 (counted like 18)
part4: block times * 4 (counted like 24)
sum / 60 = weighted average
weighted average * 24 = nActualTimespanWeighted
a more agressive approach:
part1: block times * 2^0 (=block times * 1) (counted like 06)
part2: block times * 2^1 (=block times * 2) (counted like 12)
part3: block times * 2^2 (=block times * 4) (counted like 24)
part4: block times * 2^3 (=block times *
(counted like 48)
sum / 90 = weighted average
weighted average * 24 = nActualTimespanWeighted
Splitting it into more parts would make it react even faster, both on the way up and on the way down.
Giving the newest i.e 1 or 2 blocks additional weight can even speed it up more; giving the very latest blocks too much weight could lead to an exploit for an attack.
It should be an easy mod to our DGW3 diff algo with lower risk than a completely new algo.
I still think what we need is a faster reaction to the hash rate spikes and drops we see.
The more time it takes to settle in to the desired diff for the actual hash rate the more time we give pools to take advantage of it and normal miners will suffer after a drop and the time it takes to bring the diff back down.
The idea I wrote about a few pages back and some others picked up too is to give the newer blocks in the interval a higher weight than the older ones.
Lets say we split the 24 blocks into 4 parts when calculating nActualTimespan.
older ---> newer
part1, part2, part3, part4 (each part 6 blocks)
a more conservative approach:
part1: block times * 1 (counted like 06)
part2: block times * 2 (counted like 12)
part3: block times * 3 (counted like 18)
part4: block times * 4 (counted like 24)
sum / 60 = weighted average
weighted average * 24 = nActualTimespanWeighted
a more agressive approach:
part1: block times * 2^0 (=block times * 1) (counted like 06)
part2: block times * 2^1 (=block times * 2) (counted like 12)
part3: block times * 2^2 (=block times * 4) (counted like 24)
part4: block times * 2^3 (=block times *
(counted like 48)sum / 90 = weighted average
weighted average * 24 = nActualTimespanWeighted
Splitting it into more parts would make it react even faster, both on the way up and on the way down.
Giving the newest i.e 1 or 2 blocks additional weight can even speed it up more; giving the very latest blocks too much weight could lead to an exploit for an attack.
It should be an easy mod to our DGW3 diff algo with lower risk than a completely new algo.
I think this is getting more complicated than it needs to be. If we're looking at a weighted average, like I suggested, take the first 6 blocks and then the next 18 counted as one block. I don't see how additional weight on the latest blocks would allow for an exploit. Care to elaborate?
I do agree though that the changes need to happen faster, much like I originally pointed out here: https://bitcointalk.org/index.php?topic=554412.msg8992812;topicseen#msg8992812. The POT chart there is a solid representation of what we should be trying to achieve.
-Fuse