[ANN] Catcoin - 0.9.1.1 - Old thread. Locked. Please use 0.9.2 thread.

[dotnetmin]

Cool got them solo 

Looks like normal. Put your mouse on the watch and you´ll se how many conformations needed to confirm.
120 are needed for the CAT, this can take some days. On the overview side they should be listed as immature.
I havent´t seen that on my CAT wallet but on other coins

[kuroman]

You really give yourself a hard time.

Don't you think it's finnaly time to check Kmotos Gravity Well code?

Just open the main.cpp of any Coin that have it (KDC, Vent, Mega) and study it. Just reading it will give you some good ideas I am sure. Also about how to do the averaging better/more correctly.

We are a community coin. We don't add features that most people can't relate to. If we add black magic, fewer people will contribute to the vitality of the coin. Then we die.

We are going to restructure the coin so that this stuff is easier to deal with.

Correct me if I'm wrong, but from your comment I get the feeling that you didn't make the effort to look it up and understand how it work, and I think it's fair to make a judgement about it after you do those things. and btw it is a simpler solution than SMA36LIM12

For those who didn't bother looking at it or who aren't tech savies let me explain to you how kimoto gravity works (from my understanding) :
1-Diff retarget is made every single block
2-The function for diff retarget depends on hashrate or rather the time to solve a block
It uses this function KGW = 1 + (0.7084 * pow((double(PastBlocksMass)/double(144)), -1.228))
So if fast rate is high the function above is applied if/when it's the opposite 1/KGW is applied
Here is the whole code behind it, there is nothing magical about it just a simple math formula applied dynamicly :

Code:

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 <= EventHorizonDeviationSlow) || (PastRateAdjustmentRatio >= EventHorizonDeviationFast)) { assert(BlockReading); break; }
                }
                if (BlockReading->pprev == NULL) { assert(BlockReading); break; }
                BlockReading = BlockReading->pprev;
        }
        
        CBigNum bnNew(PastDifficultyAverage);
        if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0) {
                bnNew *= PastRateActualSeconds;
                bnNew /= PastRateTargetSeconds;
        }
    if (bnNew > bnProofOfWorkLimit) { bnNew = bnProofOfWorkLimit; }
        
    /// debug print
    printf("Difficulty Retarget - Kimoto Gravity Well\n");
    printf("PastRateAdjustmentRatio = %g\n", PastRateAdjustmentRatio);
    printf("Before: %08x  %s\n", BlockLastSolved->nBits, CBigNum().SetCompact(BlockLastSolved->nBits).getuint256().ToString().c_str());
    printf("After:  %08x  %s\n", bnNew.GetCompact(), bnNew.getuint256().ToString().c_str());
        
        return bnNew.GetCompact();
}


The above is the code for the Gravity Well, just for reference's sake.

[goldgreen]

I discovered if I close my wallet, and start it up again, the problem returns.  The wallet stalls endlessly and will not sync.  I can keep up using the delete and rebuild method, but there is a bug in the wallet system that would be nice to be fixed.  Developers please take note.  Thanks.

https://i.imgur.com/98oO739.png

I think you're fine, it's just an hour behind because no block has been found since, which is a problem, but not with the wallet. If you want to make sure, check http://catchain.info/chain/Catcoin and see if your wallet has the same block. It shows 2 hours behind for me too, which is true, we're not even close to 10 minute blocks.

You were correct.  Thanks.

[fredeq]

Any word when cryptsy will be on the correct chain?

[captainfuture]

Diff went down to 1
that ridiculous
and if someone says the fork works cause on average we have a normal block time, then i want you to try to send coin when diff is high and stuck.

[dotnetmin]

Diff went down to 1
that ridiculous
and if someone says the fork works cause on average we have a normal block time, then i want you to try to send coin when diff is high and stuck.

CAT needs to be changed -  Reward 5 CAT /  Blocktime 1 minute / Difficultadjustment KWD

CAT has soo much potential, nobody would care about these changes and left to support this coin - think about that

Too see how it works everybody should kave a short look to the blockchainexplorer - http://catchain.info/chain/Catcoin to see it doesn´t work.
You don´t have to be a expert.
 
At well working coins the loop regulates the designed Blocktime - we are far far far away from this.
Regulate a coin with such a long blocktime it´s nearly impossible, so change the parameters around the coin to get the blocktimetarget working.

[skillface]

Any word when cryptsy will be on the correct chain?

No idea, they're apparently aware of it but I submitted a ticket myself just now to keep the pressure up.

Also for anyone using NVIDIA cards, there's a new version of cudaMiner out, check it out here. I went from ~280KH/s to ~330KH/s myself with my GTX 670, and this version also adds support for Scrypt-Jane.

Every little bit of extra hash will help with stabilizing CAT's difficulty fluctuations.

[dotnetmin]

Miners go out earlier this time and hash wasn´t as high as on the last rounds. Would not expect diff now goes higher than 100.
This round was while US was sleeping

[envy2010]

Diff went down to 1
that ridiculous
and if someone says the fork works cause on average we have a normal block time, then i want you to try to send coin when diff is high and stuck.

The current oscillations are entirely due to the days we spent at a 108+ diff and 10+ hour block time. The fork basically walked the coin off a difficulty cliff, and it needs some time to settle down.

Is the current version ideal? No. Does it work much much better than either of the last two? Absolutely it does. There are occasional waits of a few hours for 6 confirms, but it's still usable.

I would like an update with a couple more tweaks, but this is close to a coin that can survive and thrive despite high hashpower attacks.

[envy2010]

No. It chases the hashrape away. It never gets to 60x. Don't worry about that. It needs to be 12%.
If it's less the swings will be worse because the hashrape will last longer and the difficulty will be higher at the peak. If it's more they will also be worse, because it will allow the difficulty to jump TOO fast.

Envy - I know it's Superbowl weekend, but we need folks working together, not being armchair quarterbacks.  Where where you the past month when we were actually testing this?

Keep in mind, everybody, that we are 35 days old, the original dev basically dropped everything on the community, and we had to pick-up the dev process from scratch while building a new team in the middle of a crisis.  CAT's in very good hands, the community is stronger than ever, the PR folks are kicking ass, and we've been recognized by an Oprah reality show.

Yes, we still have the seat belt sign fastened - we're not in smooth air yet - but we're alive, we're growing, and we're standing up to hopping pools - and we no longer need to extend our claws to hang-on.  Life's good and getting better, Catfolks!

Andy

I was watching here with interest as the dev process unfolded, but not about to jump into the drama that discussion turned into. The current system is certainly working, and should be run for a while to see just how stable it can get, but could be tweaked just a bit for stability.

I'm an engineer with some dynamic systems modeling experience, and I'm willing to do some predictive modeling of difficulty response for future tweaks, if you are interested.

Getting a fast response to spikes, while keeping the difficulty reasonably stable, is a difficult proposition. I think there are a few non-conventional solutions (such as lowering the difficulty BETWEEN blocks if blocktime exeeds an hour or so). There are also simple solutions that would tweak the current response, such as weighting the 36-block average so that recent blocktimes have more weight than older ones.

[TheTribesman]

Regarding the Catcoin logo, I much prefer the new one. The old one looked like a kitten sticking its tongue out for a facial (you know what I mean), and I know I wasn't the only one that saw that.

Frankly it didn't look even remotely professional. Even DOGE's logo looks better that the old CAT logo.

I took the liberty of throwing together a few new full logos with the updated artwork that might come in useful. I went for a look that emulated the Bitcoin logo, since Catcoin is meant to be the Scrypt Bitcoin.



I might upload new artwork to my Catcoin Art album on Imgur now and then if I get bored.

I like this one

[Maverickthenoob]

Diff went down to 1
that ridiculous
and if someone says the fork works cause on average we have a normal block time, then i want you to try to send coin when diff is high and stuck.

The current oscillations are entirely due to the days we spent at a 108+ diff and 10+ hour block time. The fork basically walked the coin off a difficulty cliff, and it needs some time to settle down.

Is the current version ideal? No. Does it work much much better than either of the last two? Absolutely it does. There are occasional waits of a few hours for 6 confirms, but it's still usable.

I would like an update with a couple more tweaks, but this is close to a coin that can survive and thrive despite high hashpower attacks.

Finally some logical, level-headed input.

Alright, so my intial reaction to the results is two-fold:

1. THis still needs to level out some, but the extreme diff drops are empowering the pools to hit us and cause a slingshot effect. THis current method is indeed much more functional than it was before.

2. I think 36 Block SMA might be too long, and I raised those concerns with my team before the fork. The coin is reacting to what happened 6 hours previous, to be blunt, that's dumb, we need to react to what's happening now, but with a smoother to prevent unnecessary spikes or drops from lucky or unlucky blocks. I also agree with what you said previously that 12% might be too much, as that allows 600% per 6 hours, where as before it was only 400%. I think overall this algo can be functional with some more tweaking. Perhaps 12 or 18 blocks would provide enough smoothing without slowing down the reaction time so much. Right now it takes 18 blocks for the averaging to really start kicking in, that's a lot IMO, especially for a 10 minute coin. I think reasonably that we could almost half the 12% to 6% and still get the desired effect, without causing crippling hyper-inflation.

I have suggested the gravity well idea to the team, but hozer suggested there was a flaw with the algorithm, I'll let him elaborate on that.

[kuroman]

Diff went down to 1
that ridiculous
and if someone says the fork works cause on average we have a normal block time, then i want you to try to send coin when diff is high and stuck.

The current oscillations are entirely due to the days we spent at a 108+ diff and 10+ hour block time. The fork basically walked the coin off a difficulty cliff, and it needs some time to settle down.

Is the current version ideal? No. Does it work much much better than either of the last two? Absolutely it does. There are occasional waits of a few hours for 6 confirms, but it's still usable.

I would like an update with a couple more tweaks, but this is close to a coin that can survive and thrive despite high hashpower attacks.

Finally some logical, level-headed input.

Alright, so my intial reaction to the results is two-fold:

1. THis still needs to level out some, but the extreme diff drops are empowering the pools to hit us and cause a slingshot effect. THis current method is indeed much more functional than it was before.

2. I think 36 Block SMA might be too long, and I raised those concerns with my team before the fork. The coin is reacting to what happened 6 hours previous, to be blunt, that's dumb, we need to react to what's happening now, but with a smoother to prevent unnecessary spikes or drops from lucky or unlucky blocks. I also agree with what you said previously that 12% might be too much, as that allows 600% per 6 hours, where as before it was only 400%. I think overall this algo can be functional with some more tweaking. Perhaps 12 or 18 blocks would provide enough smoothing without slowing down the reaction time so much. Right now it takes 18 blocks for the averaging to really start kicking in, that's a lot IMO, especially for a 10 minute coin. I think reasonably that we could almost half the 12% to 6% and still get the desired effect, without causing crippling hyper-inflation.

I have suggested the gravity well idea to the team, but hozer suggested there was a flaw with the algorithm, I'll let him elaborate on that.

I'm sorry but this is totally wrong!, while at diff 108 we spent much "time" it was only a cycle of 36 blocks!and with the next cycle it should have been fixed and we started 21346 and we are right now at 21680 which is 334 blocks which is 9 cycles + , the solution doesn't work properly, as I've shown before. it will always be the same story, a symetrical solution (diff rise and decrease) won't work it will keep reacting the same way over and over again, 12% 6% 2% 20% won't do anything other than, making the cycle longer (flatter) or shorter / per 36 blocks, in fact and in worst case scenario, due to a lower number the diff will just keep decreasing in a much longer periode of time (if in the 36 blocks we don't reach block target time that is)

I proposed a solution to force the diff to an equilibrium, which is to have whatever limiting function for diff increase SMA36 6% or 12% or whatever, but for diff decrease leave it without any limite, which means that each time profitability pools will leave the coin, on a block the next block diff will drop to the value it should be on this will force those pools to mine the coin again, and over time it will find an equilibrium.

As for KGW, the reason why I prefere this solution is : the solution is simple and more importantly proven to work! of course this doesn't mean it is flawless, but so far no issues has been reported and I'm curious to what hoser has to say about it

[envy2010]

... it will always be the same story, a symetrical solution (diff rise and decrease) won't work it will keep reacting the same way over and over again, 12% 6% 2% 20% won't do anything other than, making the cycle longer (flatter) or shorter / per 36 blocks, in fact and in worst case scenario, due to a lower number the diff will just keep decreasing in a much longer periode of time (if in the 36 blocks we don't reach block target time that is)

I proposed a solution to force the diff to an equilibrium, which is to have whatever limiting function for diff increase SMA36 6% or 12% or whatever, but for diff decrease leave it without any limited, which means that each time profitability pools will leave the coin, on a block the next block diff will drop to the value it should be on this will force those pools to mine the coin again, and over time it will find an equilibrium.

You are right in stating that having a simple moving average is not a ideal way to reach equilibrium after spike hashrate changes. However, the problem currently is not symmetry -- the current solution is asymmetric at 12% up and 10.7% down. The problem is that the change is ALWAYS pressed to the limit (because of the initial cliff it fell off from 108+ to under 1). The difficulty spends little time in the narrow 24% band around 10 minute blocktime where there is usable feedback, and instead races through until it hits a harder stop near 1 or over 100 difficulty.

An EXTREMELY simple solution to this is to start to back the change away from the limit as blocktime approaches 10. This can be implemented by changing the current diff change factor from:

MIN(MAX(10/<SMA36_blocktime>),100/112),112/100)

to:

MIN(MAX(1-((1-(10/<SMA36_blocktime>))*0.02),100/112),112/100)

Where 0.02 is a damping factor that changes the band of usable difficulty feedback. This change has no effect on any other specs of the coin: the max change is still 12% up and down every block based on the simple average of the last 36 blocks, and targets a 10-minute blocktime. I modeled the current system and the proposed system with these results:



As you can see, the prediction for the current mechanism is consistent with what we have seen over the last few days. Also, I simulated a 1500 MH/s spike for 36 blocks (on Feb. 8th in the plot), and the damped system responded with a quick uptick, then drop back to equilibrium.

Edit: The 0.02 damping factor comes from a maximum change of 2% when the difficulty is off by a factor of 2 (e.g. a 5-minute blocktime with yield a 2% per block increase, and a 20-minute blocktime will yield a 2% per block decrease). This changes proportionally to the damping factor, so a factor of 0.01 will yield a 1% increase for 5-minute blocktimes, and 0.03 a 3% increase. Anything over 5% is unstable in my model, while anything under 0.5% is very slow.

[serje]

Anyone want's to buy CatCoins?

[kuroman]

... it will always be the same story, a symetrical solution (diff rise and decrease) won't work it will keep reacting the same way over and over again, 12% 6% 2% 20% won't do anything other than, making the cycle longer (flatter) or shorter / per 36 blocks, in fact and in worst case scenario, due to a lower number the diff will just keep decreasing in a much longer periode of time (if in the 36 blocks we don't reach block target time that is)

I proposed a solution to force the diff to an equilibrium, which is to have whatever limiting function for diff increase SMA36 6% or 12% or whatever, but for diff decrease leave it without any limited, which means that each time profitability pools will leave the coin, on a block the next block diff will drop to the value it should be on this will force those pools to mine the coin again, and over time it will find an equilibrium.

You are right in stating that having a simple moving average is not a ideal way to reach equilibrium after spike hashrate changes. However, the problem currently is not symmetry -- the current solution is asymmetric at 12% up and 10.7% down. The problem is that the change is ALWAYS pressed to the limit (because of the initial cliff it fell off from 108+ to under 1). The difficulty spends little time in the narrow 24% band around 10 minute blocktime where there is usable feedback, and instead races through until it hits a harder stop near 1 or over 100 difficulty.

An EXTREMELY simple solution to this is to start to back the change away from the limit as blocktime approaches 10. This can be implemented by changing the current diff change factor from:

This is also wrong for several reasons and the fact that diff exceeded the initial 108 and by a huge margings proves that the algo is not solving this issue at all. Also I'll let you answer this on your own, what would be the difference if the initial diff was 50 instead of 108 or even 25 for that matter? What you need to take into consideration and I feel this is one of the model flaws is that profitability pools, don't switch after a SET block they keep mining as long as the coin is profitable so if the 36 average makes the increase of the diff slower (due to the lower average) they'll keep mining longer, intel they'll reach the same point of non profitability and leave and the same story with start over again. (You are bound to have a diff peak higher than 100+)

Also 10.7% down did I miss something? and this is even worse, it means that the diff takes longer to go down than to go up.

As for your graph with your poposed solution, I don't get how diff doesn't go below 50 it will never be the case with the current "loyal" hashrate unless you set a diff hard limite (which is a huge risk! and can kill the coin and it's not the case from your equation), let's just be clear the point of the 12% limite value, is to make the coin reach the profitability and orbits around it aka the profitabilty pools join the diff goes up progresively without peaking up and reaching the potentiel maximum value, profitabilty pools leave, and diff drops again till an equilibrium is found, but what I don't get is the 36 average value what does it do here this value for me not needed

KGW? Is a proven solution,so why do we need to invent the wheel all over again?, heck some don't want anything to do with the wheel, and we are going backwards, it's like using antic egyptians (Pharaoh era) techinics to move heavy stuff and trying stuff. we are better off taking the solution that works as a starting point and try to improve it and build on it (isn't this how we humains managed to advance this much)

[envy2010]

... it will always be the same story, a symetrical solution (diff rise and decrease) won't work it will keep reacting the same way over and over again, 12% 6% 2% 20% won't do anything other than, making the cycle longer (flatter) or shorter / per 36 blocks, in fact and in worst case scenario, due to a lower number the diff will just keep decreasing in a much longer periode of time (if in the 36 blocks we don't reach block target time that is)

I proposed a solution to force the diff to an equilibrium, which is to have whatever limiting function for diff increase SMA36 6% or 12% or whatever, but for diff decrease leave it without any limited, which means that each time profitability pools will leave the coin, on a block the next block diff will drop to the value it should be on this will force those pools to mine the coin again, and over time it will find an equilibrium.

You are right in stating that having a simple moving average is not a ideal way to reach equilibrium after spike hashrate changes. However, the problem currently is not symmetry -- the current solution is asymmetric at 12% up and 10.7% down. The problem is that the change is ALWAYS pressed to the limit (because of the initial cliff it fell off from 108+ to under 1). The difficulty spends little time in the narrow 24% band around 10 minute blocktime where there is usable feedback, and instead races through until it hits a harder stop near 1 or over 100 difficulty.

An EXTREMELY simple solution to this is to start to back the change away from the limit as blocktime approaches 10. This can be implemented by changing the current diff change factor from:

This is also wrong for several reasons and the fact that diff exceeded the initial 108 and by a huge margings proves that the algo is not solving this issue at all. Also I'll let you answer this on your own, what would be the difference if the initial diff was 50 instead of 108 or even 25 for that matter? What you need to take into consideration and I feel this is one of the model flaws is that profitability pools, don't switch after a SET block they keep mining as long as the coin is profitable so if the 36 average makes the increase of the diff slower (due to the lower average) they'll keep mining longer, intel they'll reach the same point of non profitability and leave and the same story with start over again.

Also 10.7% down did I miss something? and this is even worse, it means that the diff takes longer to go down than to go up.

112/100 = 12% change up, 100/112 = 10.7% change down. This has been noted on previous pages.

The difficulty dropped below 1 because even if 35 blocks were solved INSTANTLY after the fork, the 36 block average time would still have been over 10 minutes -- and so even after 35 drops of 12% the algo "thought" the diff was still too high. Though it wasn't instant, once a couple blocks were found the next 30 or so came very fast. Then, very suddenly, those long blocks were far enough back to be left out of the average, and the average time dropped to below a minute.

The 36SMA12LMT system is intended to react fast to lots of hash entering and leaving the network (which it does well) but a side effect of that is that it overreacted to what it perceived as a lot of hash having "just left" a the time of the fork. If the difficulty had started at 50, block times would have been more reasonable for the 36 before the fork, and this oscillation would never have started.

Also, having the hashrate rise faster than it drops is good in that it prevents hyperinflation. As long as the drop back down  is fast enough to keep block times reasonable (at least under an hour), that's more suitable for reaching an equilibrium state.

[SlimePuppy]

I'm sorry but this is totally wrong!, while at diff 108 we spent much "time" it was only a cycle of 36 blocks!and with the next cycle it should have been fixed and we started 21346 and we are right now at 21680 which is 334 blocks which is 9 cycles + , the solution doesn't work properly, as I've shown before. it will always be the same story, a symetrical solution (diff rise and decrease) won't work it will keep reacting the same way over and over again, 12% 6% 2% 20% won't do anything other than, making the cycle longer (flatter) or shorter / per 36 blocks, in fact and in worst case scenario, due to a lower number the diff will just keep decreasing in a much longer periode of time (if in the 36 blocks we don't reach block target time that is)

Kuroman, I like the analysis you've provided in the past.  I understand what you're saying about our cycles here and think I can help build a bridge between you and Mav.  It's important, first, to remember that this fork was not intended to be a 100% solution.  It could have been with a bit more time (or less wasted time dealing with trolls) but we didn't have the time available.  This is designed to get us moving and to make sure we never got stuck too high or too low again.  As Mav has said multiple times in various venues, this is at best an 80% solution.  We CAN stay here for months and ride the waves - we'll be alive, we'll be attracting enough miners, and end-users can actually start using the coin.  This gives us a working platform the PR team can work from - and they're kicking ass!

Yes - we can and will do better!  And now, because of this fork, we have plenty of time to create a 100% solution without having a gun to our heads.

A quick additional comment - we know from our testnet work that this algo WILL converge and stabilize.  We didn't have that before.   Also - keep in mind that in conjunction with this fork we also got a significant endorsement from the Oprah Winfrey empire - I'll guarantee you that we didn't see that coming.

I hope you and envy will continue to work towards the long-term goal of getting CAT to Mars. 

Andy

[zerodrama]

We are a community coin. We don't add features that most people can't relate to. If we add black magic, fewer people will contribute to the vitality of the coin. Then we die.

We are going to restructure the coin so that this stuff is easier to deal with.

Correct me if I'm wrong, but from your comment I get the feeling that you didn't make the effort to look it up and understand how it work, and I think it's fair to make a judgement about it after you do those things. and btw it is a simpler solution than SMA36LIM12

You are even wronger. SMA36LIM12 is simpler than the ArbitrarySciFiVariableName spaghetti you posted.

It's not whether it works. Maybe it's perfect (except for WTF broken FPU!), but it matters if the average person understands it. If they don't, then they have no voice.

It uses this function KGW = 1 + (0.7084 * pow((double(PastBlocksMass)/double(144)), -1.228))
So if fast rate is high the function above is applied if/when it's the opposite 1/KGW is applied
Here is the whole code behind it, there is nothing magical about it just a simple math formula applied dynamicly :

No explanation of the function. Not magical. Magical. I don't think it means what you think it means. So, at this point it is magical.

I have looked at it. I think I know what it does. I also think it can be done a lot better. Without magic.

[gadado]

I can't believe what I read here. You are still thinking a little tuening here and a little there and your averageing function with limits produces a satisfying solution!?

You already did 2 changes which aren't cheap. You have to fork and everyone has to update. And you really want to continue that path? Another change attempt and fork and another likely failure? And then... another one?

If this charts and data that you see aren't conlusive enough for you to see your base is off and you are going the wrong way than I guess I wasted my time with my gently hints.

You go a painful length in just to avoid an already existing SIMPLE and elegant solution at all cost.

For what?

I lost the hope. You don't know what you do.