Generally all the continual update stuff comes with some messy costs: It greatly reduces the cost of isolation attacks, and it ends up making weird non-linear incentives likely (e.g. more profitable to mine in bursts) because the clamps become more significant.
For some fringe altcoin with no real usage perhaps it's necessary to prevent abandoning the chain— though to be honest I think merged mining is generally better— but I don't really see any applicability to Bitcoin.
Topic: Kimoto Gravity Well alternative (Read 1229 times)
Pretty much anything is simpler than KGW with silly analogies and magic numbers 
These alternatives are easier to tune and debug and I bet they are at least as effective as KGW. Effectiveness of course depends on what we want to optimize for; if the hash power can suddenly change a lot and we are left with too fast or too slow block-rate, we need to react faster and use something like these. I guess this is not very likely scenario for Bitcoin, so slow response time is fine for it.
I think PID-controller or EMA would be good options altcoins.
These alternatives are easier to tune and debug and I bet they are at least as effective as KGW. Effectiveness of course depends on what we want to optimize for; if the hash power can suddenly change a lot and we are left with too fast or too slow block-rate, we need to react faster and use something like these. I guess this is not very likely scenario for Bitcoin, so slow response time is fine for it.I think PID-controller or EMA would be good options altcoins.
Alternatively you just use an exponential moving average, which means you don't have to keep any historical data other than the value at the last block. Since difficulty is stored in the block header, you already have the relevant data available. The difficulty is proportional to the inverse of the time between blocks in the past.
edit: Obviously this applies to alt-coins primarily, as an algorithm like this isn't really needed for Bitcoin and would require a hard-fork to be implemented.
Code:
prevAvgTime = k / prevDiff;
newAvgTime = a * timeSinceLastBlock + (1 - a) * prevAvgTime;
newDiff = k / newAvgTime;
(k is the scaling factor between block time and difficulty, a is the decay-parameter that determines the weight of the most recent data and how quickly old data is reduced in weight)newAvgTime = a * timeSinceLastBlock + (1 - a) * prevAvgTime;
newDiff = k / newAvgTime;
edit: Obviously this applies to alt-coins primarily, as an algorithm like this isn't really needed for Bitcoin and would require a hard-fork to be implemented.
Basicly KGW is just calculating running average, min x hours, up to y days. Then, it limits the max change with the horizon.
This is the alternative:
The average should be weighted so the latest block times affects more than the older block times.
In the simplest theorethical implementation:
Count from the block 0: TimeAverage = (TimeAverage + LastBlockTime)/2
Cannot do that in practise; it would weigth the latest block time too much (50%), and also we cannot walk throught the blockchain everytime we start over, so
What do you think? I think it is a lot simpler and more effective that KGW.
This is the alternative:
The average should be weighted so the latest block times affects more than the older block times.
In the simplest theorethical implementation:
Count from the block 0: TimeAverage = (TimeAverage + LastBlockTime)/2
Cannot do that in practise; it would weigth the latest block time too much (50%), and also we cannot walk throught the blockchain everytime we start over, so
Code:
FilterAttenuation = 8
Walkingblock = (block@heightof(currentblock-(FilterAttenuation*2))
TimeAverage = Walkingblock.time
while Walkingblock.heigth < currentblock.height
{
Walkingblock = Walkingblock.next;
TimeAverage = (TimeAverage*(FilterAttenuation-1) + WalkingblockTime)/FilterAttenuation;
}
Actually this simulates quite well RC circuits commonly used on electorics to filter signals.Walkingblock = (block@heightof(currentblock-(FilterAttenuation*2))
TimeAverage = Walkingblock.time
while Walkingblock.heigth < currentblock.height
{
Walkingblock = Walkingblock.next;
TimeAverage = (TimeAverage*(FilterAttenuation-1) + WalkingblockTime)/FilterAttenuation;
}
What do you think? I think it is a lot simpler and more effective that KGW.
Jump to: