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)
Sr. Member
Offline Offline

Activity: 477
Merit: 500

View Profile
March 07, 2014, 10:16:31 AM
Last 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

FilterAttenuation = 8
Walkingblock = (block@heightof(currentblock-(FilterAttenuation*2))
TimeAverage = Walkingblock.time
while Walkingblock.heigth < currentblock.height
   Walkingblock =;
   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.
Hero Member
Offline Offline

Activity: 728
Merit: 500

View Profile
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.

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.
Offline Offline

Activity: 14
Merit: 0

View Profile
March 07, 2014, 02:55:54 PM

Pretty much anything is simpler than KGW with silly analogies and magic numbers Smiley 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.
Offline Offline

Activity: 3416
Merit: 5125

View Profile
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]
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!