[Dev] Kimoto gravity well integration - Feathercoind 0.8.5.1
-
Kimoto’s Gravity well was introduced in Megacoin October 2013, after it gained tradable value. It was specifically to discourage Multipool difficulty manipulation.
Since then it has been taken up by a growing number of small coins, cumulating with Chris Franko recently introducing it to Frankocoin.
I’ve now looked into the Gravity Well quite a bit. It is very much fulfilling our requirement to produce difficulty re-targets based on the rate of change between the short and long block time averages. I actually think it is very brilliant.
A number of other coins are employing it specifically against multipool leaching, and don’t seem to have, forking or other validation issues which may have concerned us more (with a larger network and more miners to update).
The only point against is it is effectively retargeting at each block, so it might be worth trying that (easy solution) first. It effectively damps the block difficulty changes, so our current granulated difficulty change may become superfluous.
It only protects against extreme hash change, I am proposing a mild gravity well and Feathercoins normal averaging periods for block re-target.
Here are my proposed Feathercoin settings. I’ve set the slope to the lower end.
[quote]
Coin EventHorizonDeviation
Feathercoin 1 + (0.7084 * pow((double(PastBlocksMass)/double(28.2)), -1.228));BlocksTargetSpacing * 2.5 * 60; (= 2.5 mins)
PastSecondsMin TimeDaySeconds * 0.20; (short average = 4 hrs)
PastSecondsMax TimeDaySeconds 14; (= 2 weeks)
[/quote]1. Are there any other disadvantages we should test for apart from already identified, extra processing at next block difficulty processing?
2. Any other settings that might be tested, and why?
3. Any other inconsistencies in code or mathematics?
4. Any volunteers to assist patching/ testing.[Quote]
unsigned int static KimotoGravityWell(const CBlockIndex* pindexLast, const CBlockHeader *pblock, uint64 TargetBlocksSpacingSeconds, uint64 PastBlocksMin, uint64 PastBlocksMax) {
/* current difficulty formula, megacoin - kimoto gravity well */
const CBlockIndex *BlockLastSolved = pindexLast;
const CBlockIndex *BlockReading = pindexLast;
const CBlockHeader *BlockCreating = pblock;
BlockCreating = BlockCreating;
uint64 PastBlocksMass = 0;
int64 PastRateActualSeconds = 0;
int64 PastRateTargetSeconds = 0;
double PastRateAdjustmentRatio = double(1);
CBigNum PastDifficultyAverage;
CBigNum PastDifficultyAveragePrev;
double EventHorizonDeviation;
double EventHorizonDeviationFast;
double EventHorizonDeviationSlow;if (BlockLastSolved == NULL || BlockLastSolved->nHeight == 0 || (uint64)BlockLastSolved->nHeight < PastBlocksMin) { return bnProofOfWorkLimit.GetCompact(); }
for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
PastBlocksMass++;if (i == 1) { PastDifficultyAverage.SetCompact(BlockReading->nBits); }
else { PastDifficultyAverage = ((CBigNum().SetCompact(BlockReading->nBits) - PastDifficultyAveragePrev) / i) + PastDifficultyAveragePrev; }
PastDifficultyAveragePrev = PastDifficultyAverage;PastRateActualSeconds = BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();
PastRateTargetSeconds = TargetBlocksSpacingSeconds * PastBlocksMass;
PastRateAdjustmentRatio = double(1);
if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0) {
PastRateAdjustmentRatio = double(PastRateTargetSeconds) / double(PastRateActualSeconds);
}
EventHorizonDeviation = 1 + (0.7084 * pow((double(PastBlocksMass)/double(144)), -1.228));
EventHorizonDeviationFast = EventHorizonDeviation;
EventHorizonDeviationSlow = 1 / EventHorizonDeviation;if (PastBlocksMass >= PastBlocksMin) {
if ((PastRateAdjustmentRatio -
Maxcoin also uses Kimoto gravity well.
It seems the Maxcoin devs did at least one thing right ;) -
Is there any argument to make against?
-
This method gives protection from multi pools fast “attack”. But does this method protects the loyal miners from longer attack?
Scenario:
- Huge scrypt farm come to the FTC network and stays for a period of time
- diff. will go insane fast
- loyal small miners would be there unprotected no chances to mine a block
My toughs:
1. multi pools could be defeated if we play their game by their rules
2. We need unique PoW -
If its a long term move to mining FTC is it really a multicoin hopping attack? (unless you mean 51%)
-
Multi pools issue isn’t tech. issue but it’s financial issue ( Doesn’t harm the network but mines a coins and then convert them into another currency ). Multi pools would mine a coin until mining is most profitable ( there is tight connections with it’s price ) no matter how big/low is difficulty or block reward.
I’m not pointing out to 51% attack ( we have protection from it ) but I’m pointing out to situation where miner with 30% of hash power could cause 10% loyal miners to abandon the currency. ( We need to check the numbers and make correct simulation about all of the possible scenarios )
-
Other than the difficulty retarget issue I’m not sure if anything needs to be done.
If difficulty does up and price does not follow profit miners will disperse as its just a market but loyal members would likely stay and maintain the network resilience.
There has been talk already on this forum on people mining coins other than FTC and selling them for FTC to help increase the buy market for FTC.
So even if people did leave then this would be ok. The difficulty would adjust anyway if miners left possibly making the coin profitable to mine again. lolits a vicious circle but a healthy one.
If we could make the multipool attack last only one block before a difficulty adjustment then loyal miners would be affected far less and I think this would solve the problem.
-
If we have a situation where all of multi pools are connected to the FTC network for a long time then we can expect multi pools for sha256 that will pay off the miners with FTC :)))
-
[quote name=“kris_davison” post=“58692” timestamp=“1392213272”]
If we could make the multipool attack last only one block before a difficulty adjustment then loyal miners would be affected far less and I think this would solve the problem.
[/quote]I agree, even the single block Difficulty adjustment isn’t the full answer, could be a problem. We already have some protection against difficulty drive up, single block might negate that.
-
Heres a really good explaination of whats goin on in the Kimoto algorythm…
-
Maxcoin has Kimoto, Dogecoin consider it.
http://www.benzinga.com/news/14/02/4283374/the-next-altcoin-to-hit-20-million
-
Yeah… I’m gonna follow this topic.
I’ll have a solid read when I get back from work.
-
Orbits.
I am now starting to get a different picture of how the Kimoto Gravity well is suposed to work, and be understand weither the code actually does that.
The block time can be seen as an orbit around its required 2.5 min timeing for Feathercoin. If all is well, a block will appear at -1.25 and +1.25 mins.
The algorythm then loops back through a number of historical blocks to find the deviation of the orbit. The more deviation, the more gravity is applied.
The main action of the gravity well will be to adjust the Retarget more often, and take acount of “sudden variations” in Hash rate.
-
Mooncoin has added it. FWIW.
-
Orbits.
I am now starting to get a different picture of how the Kimoto Gravity well is suposed to work, and be understand weither the code actually does that.
The block time can be seen as an orbit around its required 2.5 min timeing for Feathercoin. If all is well, a block will appear at -1.25 and +1.25 mins.
The algorythm then loops back through a number of historical blocks to find the deviation of the orbit. The more deviation, the more gravity is applied.
The main action of the gravity well will be to adgust the Retarget more often, and take acount of “sudden variations” in Hash rate.
Thanks, that makes much more sense.
-
Just out of curiosity, aside from KGW (which is really popular right now, almost every new coin seems to be implementing it at the moment), what other ways could we protect against crazy difficulty traps?
In regards to KGW, I echo chrisj’s thoughts.
Is there any argument to make against?
Keeping ftc ahead of the game is always a +1.
So, are there any arguments against KGW?
I don’t understand it thoroughly enough to try find anything wrong with it.
-
At least it needs to be tuned and applied carefully.
The blockchain is a control loop (I hope the term is correct, got it from leo.org)
Basically it works like
Measure block spacing-> blockspacing lower 2.5 mins?-> if yes increase difficulty
-> if no decrease difficultyThe KGW represents a fast reacting algorithm to adjust difficulty.
Fast reacting control loop tend to oscillate and this could lead to unnecessary jumps in difficulty and make things worse.It may take some time to find the best parameter to be applied to KGW to get it working even with extreme jumps in hashrate.
Also it will need more calculations to get the new difficulty as it recursively looks back to recent blocks.
With a max block lookback of 10 it’s already 2939328000 calculations ( 1*2*3*4*5*6*7*8*9*10 ).
-
+1 Wellenreiter
I understand KGW a lot better when you put it like that.
-
Thanks for this discussion. I believe a change is needed, and you’re all the ones to make it happen. I’m trying to understand the tech part, but I do understand the results, and I believe a change is needed. I really appreciate this discussion, and will pop back in.
Bona Fortuna
-
The theme is interesting, I will take part in discussion.
