Bitcoin Forum
May 08, 2021, 10:04:23 PM
 News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 Home Help Search Login Register More
 Pages: [1]
 Author Topic: Kimoto Gravity Well alternative  (Read 1167 times)
Nite69
Sr. Member

Offline

Activity: 477
Merit: 500

 March 07, 2014, 10:16:31 AMLast edit: March 07, 2014, 12:03:48 PM by Nite69

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

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.

What do you think? I think it is a lot simpler and more effective that KGW.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Rannasha
Hero Member

Offline

Activity: 728
Merit: 500

 March 07, 2014, 01:16:45 PM

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.

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)

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.
mkz
Newbie

Offline

Activity: 14
Merit: 0

 March 07, 2014, 02:55:54 PM

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.
gmaxwell
Moderator
Legendary

Offline

Activity: 3416
Merit: 5125

 March 07, 2014, 08:17:12 PM

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.
 Pages: [1]