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

[zerodrama]

Check out the rest of my comment, You've answered me before I wrotte the second part, also thank you for 10.7 information not alot of us had this piece of information as we all got the 36SMA12LMT as 12% goes both ways.

It is 12%. The thing is it's symmetrical. It's a multiplication. Not an addition. To go up 5/4 you multiply by 1.25x. You don't add 25%. To go back down you multiply by 4/5 or 0.8x. 0.8 * 1.25 = 1. 112/100 * 100/112 = 1.

I over-estimated your understanding capabilities it seems, if you can't figure out as much that you have KGM applied when hashrate increase drastically and 1/KGW applied when it deacrease dramatically while KGW is a clear formula and the code it self is clear than writing the SMA36LIM12.

It's not a clear formula. It's a copy pasted formula. SMA36LIM12 is specific. Why 0.7? Why 144? Why -1.228? Why power function?

NEVERMIND the possibility of a broken Floating Point Unit!

If you say it's hard then explane to me why every single new scrypt altcoin use this solution? You are just being overprotective for a solution that doesn't work properly.

COPIED AND PASTED. No thinking used. No one knows WHY it works.

-And what the problem if it having competition (why don't give some example while we are at it) and competition is good, it means that the best solution will prevail, and will push developers to innovate more,

I don't CARE if developers innovate. Developers are creating a ton of coins already. You seem to think, like A LOT of COIN coders, that ONLY developers should contribute, the rest of the COMMUNITY should just debate, hype, freak out, and vote on polls. How DARE they contribute code! I want the code to be easy enough for even a freshman in college to understand HOW TO IMPROVE IT. That is the strength of the coin. That everyone knows what it does.

[SlimePuppy]

This may be obvious to you, kuroman, but how many people on this forum do you think are at least marginal C programmers?

Let's all use words, examples, and conversations that are available to the entire community.  Limiting the conversation to a few, either through expediency or hubris, doesn't help the greater good.

No solutions are off the table right now - not all possible solutions are ON the table yet. LOL  We're not yet at the stage where we need to fight over options.  Thankfully, we now have time to propose and more importantly TEST the solutions on the testnet, not just on an Excel spreadsheet or in a Matlab pageprint.

Everyone - put your 'thinking caps' on and get those ideas on the table!

Thank you!

I don't understand your point here? I posted the KGW code to people that are concerned about it and were claiming it is overly complicated which is not the case as proven is explaned several times.

Kuroman - I'm sorry you don't understand my point here.  Please permit me to restate it in a way that might be easier to understand.  First - the programming language with which I'm most familiar is Fortran.  How comfortable would you feel debating the guts of the KGW in Fortran 77?

Now expand that to the entire community: How many people here - miners, speculators, retailers, charities - do you think know ANY programming language?

Simply put:  You did post code.  It might make sense to the 7 or 8 people here that are fans of Kernighan and Ritchie (the authors/creators of the C programming language) - but that means you're not communicating meaningfully to >97% of the community.  I'm fairly sure that's not the result you're hoping for.  I'm trying to help you get your excellent analysis into the hands of a greater portion of the community.  I hope you will do just that.

[SlimePuppy]

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

Andy thank you for your comment, the fact is the 12% limite is supposed to make the diff converge indeed, but that is under some strict conditions such as, fix hashrate jumps, the jump of hash rate is made when the block time is 600s ....ect which is definitly not the case not to mention that the SMA36 makes everything goes beserk and due to other variables it is countering the convergence from the 12% limite.

I agree with you - and I think you can see from Maverick's post that he does as well.  That is why we are beginning another phase of improvement - and we are very thankful that we have the time available to us - time we would not have without this fork.  This is a real-world reminder that the outside world does not always mirror a simulation.

NB: this is why I didn't want to join the catcoin-dev channel discussion despite being present and folowing what happening there, people are blankly dismissing other people ideas, I saw some heated discussions, where no one want to make compromises. Also calling people math geek/nerds and discrediting them on that same channel doesn't help really because and let me remind you however you break the discussion the basic level of all this will be math and code.

I'll answer this directly as I'm a person identified in the earlier thread for stopping some of the later term 'debate'.  I hope I can do it in a way that eliminates any communication barriers due to language differences.  The dev team was working on saving the coin since before I arrived.  One thing that is clear from the last thread is that at least Maverick and Hozer were calling for, begging for, and even threatening for help FROM THE COMMUNITY.  That was the point where we needed more input from everyone - when we had time to put more options on the table, debate them, test them, and choose the best.

I did some research and put an option on the table.  Others put options on the table as well.  When my option was found to be not up to the task, I dropped it and worked with the group to hunt for a better option.  Others, however, could not let go of their pet hypothesis and instead of working together were intent on splitting the dev team on IRC and the community in this forum.  Neither of those behavior choices was useful.  We simply did not have the luxury of the six months it would have taken for a 'corporate-style' centrally-controlled process that would have made one potential contributor happy at the expense of everyone else on the team.  At some point in a process, we have to make a choice, test it more fully, and deploy it.  And yes - I stood up to support the people working FOR the community and for fixing the problems - and I will do it again in future if necessary.

Unfortunately, it appears you arrived late in the process - when we had to code, not debate.  We are not in this same position today - we have the luxury of time now.  We have the luxury of calling for everyone in the community to step forward and put ideas on the table.  I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

[envy2010]

Envy - will you please tell us the assumptions you're using and/or give an example of what you're 'feeding' your model?  I'd like to understand what environment you're working in.  Thanks in advance!

Absolutely. I'm just running in Excel with a row per block, since I don't have any loops or complex logic; I can move the model to Matlab if it gets any more complex, but haven't seen any need so far.

I'm using past block times, hashrates and difficulties from catchain.info to calculate the last 36 block average time, and the  current hashrate and difficulty (all of which are known values). I then adjust the difficulty based on a retarget formula (I started with the current Catcoin formula, and tried a few modifications) to get the next block difficulty.

That's where I need to start making assumptions. I can't predict the exact next blocktime, so I use the expected blocktime based on current hashrate and difficulty, with a random multiplier (normal distribution, centered on 1) to approximate the next blocktime. That gives me the next average blocktime and thus the next difficulty adjustment, but not a hashrate (back-calculating hashrate from a random blocktime doesn't seem like a satisfactory solution).

To get the next block hashrate I pulled past difficulty and hashrate info from catchain.info into Excel and fit an inverse exponential function where as difficulty goes down, hashrate goes up. It fits past data well and as predicted the past couple days fluctuations reasonably well, although there is some time lag. There isn't as much difference in stability between assuming a static hashrate and a time-variant one as I thought there would be.

[zerodrama]

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.
but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

[kuroman]

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

So Zerodrama you are quoting that message because you relate to it right? so you don't understand C or the code behind KGW, you don't understand the math behind it, then why the hell are you complaining about it and how complex it is if you don't know the basics that will allow you to judge it? I remind that in my previous comments i had simple explainations, simple graphs, analysing data, and giving my opinion in simple terms without even using math, I'm not even pushing for the solution I proposed (I proposed 2 in my previous posts if you bothered to read them and I explained why they might work and fix the current issue but they need alot of testing and might introduce problems on their own...ect) and this is the exact reason why I'm rooting for a solution that is proven to work, with the code available and so far you didn't a bring a single argument against it.

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

Andy thank you for your comment, the fact is the 12% limite is supposed to make the diff converge indeed, but that is under some strict conditions such as, fix hashrate jumps, the jump of hash rate is made when the block time is 600s ....ect which is definitly not the case not to mention that the SMA36 makes everything goes beserk and due to other variables it is countering the convergence from the 12% limite.

I agree with you - and I think you can see from Maverick's post that he does as well.  That is why we are beginning another phase of improvement - and we are very thankful that we have the time available to us - time we would not have without this fork.  This is a real-world reminder that the outside world does not always mirror a simulation.

NB: this is why I didn't want to join the catcoin-dev channel discussion despite being present and folowing what happening there, people are blankly dismissing other people ideas, I saw some heated discussions, where no one want to make compromises. Also calling people math geek/nerds and discrediting them on that same channel doesn't help really because and let me remind you however you break the discussion the basic level of all this will be math and code.

I'll answer this directly as I'm a person identified in the earlier thread for stopping some of the later term 'debate'.  I hope I can do it in a way that eliminates any communication barriers due to language differences.  The dev team was working on saving the coin since before I arrived.  One thing that is clear from the last thread is that at least Maverick and Hozer were calling for, begging for, and even threatening for help FROM THE COMMUNITY.  That was the point where we needed more input from everyone - when we had time to put more options on the table, debate them, test them, and choose the best.

I did some research and put an option on the table.  Others put options on the table as well.  When my option was found to be not up to the task, I dropped it and worked with the group to hunt for a better option.  Others, however, could not let go of their pet hypothesis and instead of working together were intent on splitting the dev team on IRC and the community in this forum.  Neither of those behavior choices was useful.  We simply did not have the luxury of the six months it would have taken for a 'corporate-style' centrally-controlled process that would have make one potential contributor happy at the expense of everyone else on the team.  At some point in a process, we have to make a choice, test it more fully, and deploy it.  And yes - I stood up to support the people working FOR the community and for fixing the problems - and I will do it again in future if necessary.

Unfortunately, it appears you arrived late in the process - when we had to code, not debate.  We are not in this same position today - we have the luxury of time now.  We have the luxury of calling for everyone in the community to step forward and put ideas on the table.  I promise you, kuroman, that I understand and agree with you 100% that the end result must be code -- but we also feel very strongly that this process should not be limited to only the few here that are fluent in C - everyone should have a voice if they want one.

I can not force anyone to participate in this community or the dev process, but I also cannot and will not accept an environment where anyone that wants to participate is excluded.  That doesn't mean we won't again arrive at a time when we have to close the door and start coding - but until that point all comers are welcome.

Andy, I invite you to check the original thread, I was with catcoin before it was launched, during the first fork (with suggestions), I've been susggesting and debating about the second fork (and if we needed a second fork) before even it was decided to be so, and there were unilateral opinions from people that were involved in other project and just joined catcoin after their own thing failed a few days before fork but this is not the point anyway. As for code, please read the second part of my answer to Zerodrama. Our goal is the success of catcoin and on this we all agree, heck I own almost nothing compared to others but being involved since the begining being part of this community it is what makes me analyse and work out models and spend hours for this coin, but what I don't understand is the Ego of some and the entitlement of others, and this isclearly not towards you or Marverick and if i was against you I would state it directly and from the begining, some discussions are like deaf yelling at each other

[zerodrama]

So Zerodrama you are quoting that message because you relate to it right? so you don't understand C...

Nope. I've edited linux modules to allow servers to be hidden behind invisible routers. I can do C/C++, PHP, Javascript, Lisp, and a few others.
This is about the rest of the community not understanding the code. You keep thinking only coders should understand the code.
Not on my watch.

As for examples and graphs, I've been in the trenches trying to help pull this code out of obscurity and into the light. All I've seen as far as Kimoto is the code snippet you posted. I haven't seen anything that talks about what EventHorizon and PastMass mean. If the COMMUNITY has no idea what they mean, that's no good. It doesn't matter if you or I know what it means. If the users don't know, they can't contribute. It separates them from the developers. That's no good for a coin's survival.

[zerodrama]

kuroman, I'm not trying to be nasty, but I feel as if some people see this project as a piece of software with peculiar switches and knobs and they think that's where it ends.

Unfortunately, it's not. The poorly structured code is inhibiting evolution and innovation. We need something that doesn't smell like 1995.

[SlimePuppy]

You know, everyone, as much as I admire open source, distributed, global teams working together for the betterment of all, what we really need right now is to sit around a huge table with pints all around, and bets on the outcome of a programmers VS non-programmers dart match.  LOL

Enjoy your evening!

[madoka]

limiting improvements to what we can all understand as to code is stupid. All contribute what we can, a undermine, others promote currency and other program the code.

Excuse my English is not my native language.

[Maverickthenoob]

limiting improvements to what we can all understand as to code is stupid. All contribute what we can, a undermine, others promote currency and other program the code.

Excuse my English is not my native language.

Translation:

Limiting our code development to the weakest link (aka those who do not understand code) is akin to dumbing ourselves down. We all contribute, let's not limit our potential by making it understandable (at least in code format) for anyone. The layperson can still understand code if it is explained properly.


Code is nothing more than the expression of an idea, a talented coder can turn any idea into a function. So whether it is understandable in code is irrelevant, we must take the best idea and transform it into code, assuming that is possible. If it isn't we should be able to explain why.

[SlimePuppy]

Envy - will you please tell us the assumptions you're using and/or give an example of what you're 'feeding' your model?  I'd like to understand what environment you're working in.  Thanks in advance!

Absolutely. I'm just running in Excel with a row per block, since I don't have any loops or complex logic; I can move the model to Matlab if it gets any more complex, but haven't seen any need so far.
<snip>

Thank you very much!

[SlimePuppy]

Just for grins, here are a couple of scattered thoughts in no apparent order.  Hopefully the pictures will make up for the lack of organization.

A number of folks here as well as a number of coin devs are enamored with the Kimoto Gravity Well (KGW).  So far, the coins I've found that use this have fairly fast block times.  The longest is Anoncoin's 3.42 minutes.  Others, from Megacoin through Franco, have block times from 30 seconds through 2.5 minutes.    Here's Megacoin with its 2.5 minute block time:

https://coinplorer.com/Charts/Difficulty/MEC



It's pretty clear that this method allows difficulty to track the hash rate fairly well.  Let's look at another coin with a 2.5 minute block time - Phoenixcoin:



Let's skip forward in time for Phoenixcoin - here's a look at performance after the Oct, 2013 fork:




This fork is when the team there moved to an average of 100 and 500 block SMA, 10% damper, 20% limit, a 1 block retarget.  I don't know if this can be adjusted to work for CAT, but I hope it shows that KGW is not the only way to.

So - all you smart folks in CATlandia - thinking caps people - we need you!

[Percy520]

catcoin, up up up!

[zerodrama]

limiting improvements to what we can all understand as to code is stupid. All contribute what we can, a undermine, others promote currency and other program the code.

Excuse my English is not my native language.

Translation:

Limiting our code development to the weakest link (aka those who do not understand code) is akin to dumbing ourselves down. We all contribute, let's not limit our potential by making it understandable (at least in code format) for anyone. The layperson can still understand code if it is explained properly.


Code is nothing more than the expression of an idea, a talented coder can turn any idea into a function. So whether it is understandable in code is irrelevant, we must take the best idea and transform it into code, assuming that is possible. If it isn't we should be able to explain why.

The problem is the limited amount of time that coins have to make changes due to the consensus based design and the trainwreck structuring of the code. This slowly distances the vision that coders have from the vision that the users have. Soon as the vision dies, the coin becomes exchange dust. That's where it lives instead of being used and improved. Finally, there ends up so little evolution, that parasites in Congress think they understand it enough to hijack it. Not on my watch.

[madoka]

 

[karololszak]

https://i.imgur.com/Z8tw1VB.png

So... a new fork coming? They clearly have >51%.
Network hashrate is ~300Mh/s and theirs is almost 200Mh/s so they have almost 2/3 of the entire network (~ 65%) which is A LOT.

And also Team CatCoin pool (has around 80Mh/s so ~ 25% of network) is somewhat stuck with stats like this:
PPLNS Target: 195812
Est. Shares: 156687 (done: 302.82%)
Pool Valid: 474480

This is even worse than Bitcoin at the moment with cex.io having almost half of the network...

[envy2010]

The only remaining problem with the difficulty adjustment is that it doesn't "know" the difference between being off by 2000% and being off by 20%. It serves up the same 12% change for both scenarios, when they should really be treated much differently.

KGW and the double-moving-average are both solutions which would probably work well, but both are complex (and as far as I can tell have not been applied to a long blocktime coin like CAT).

I would like to throw another possible solution out there which is extremely simple (one line of code), readily understandable, and responds well to hash attacks in my simulations. It doesn't change anything about the coin except how it approaches the 12% limit. Block time, max change, etc. all remain the same.

That solution is an exponentially weighted average, which instead of simply dividing the target blocktime by the average blocktime to get the change amount, takes the logarithm of that division. In pseudocode:

Modified_Actual_36_Block_Time = Target_36_Block_Time + Target_Blocktime*NaturalLog(Target_36_Block_Time/Actual_36_Block_Time)

When the actual blocktime is 5 minutes (50% of target), the retarget only goes up 1.93%. More examples are shown in the table here:



The modeled system response to 1 GH/s attacks every time the difficulty drops below 45 is shown in the plot:



The actual code implementation is to add one line:

Code:

 if(pindexLast->nHeight >= fork2Block){
        numerator = 112;
        denominator = 100;
    }
    int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
    int64 lowLimit = nTargetTimespanLocal*denominator/numerator;
    int64 highLimit = nTargetTimespanLocal*numerator/denominator;
    printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);
    if (nActualTimespan < lowLimit)
        nActualTimespan = lowLimit;
    if (nActualTimespan > highLimit)
        nActualTimespan = highLimit;

to:

Code:

 if(pindexLast->nHeight >= fork2Block){
        numerator = 112;
        denominator = 100;
    }
    int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
    nActualTimespan = nTargetTimespanLocal+nTargetSpacing*log(nTargetTimespanLocal/nActualTimespan)
    int64 lowLimit = nTargetTimespanLocal*denominator/numerator;
    int64 highLimit = nTargetTimespanLocal*numerator/denominator;
    printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);
    if (nActualTimespan < lowLimit)
        nActualTimespan = lowLimit;
    if (nActualTimespan > highLimit)
        nActualTimespan = highLimit;

The limits would still kick in at 12%, which would happen when the actual time is around 100x or 0.01x the target time.

[kuroman]

It is 12%. The thing is it's symmetrical. It's a multiplication. Not an addition. To go up 5/4 you multiply by 1.25x. You don't add 25%. To go back down you multiply by 4/5 or 0.8x. 0.8 * 1.25 = 1. 112/100 * 100/112 = 1.

That's my understanding of this but someone told me it is not and he presented different numbers.

It's not a clear formula. It's a copy pasted formula. SMA36LIM12 is specific. Why 0.7? Why 144? Why -1.228? Why power function?

NEVERMIND the possibility of a broken Floating Point Unit!

The number works? ever heard of testing process with different numbers? you are the one that's been promoting this from the begining, testnet, different numbers 12% (why 12% why not 6% why not 20% it's the same process) same goes for 36

COPIED AND PASTED. No thinking used. No one knows WHY it works.

Why do they bother copying and pasting it? Because it WORKS

I don't CARE if developers innovate. Developers are creating a ton of coins already. You seem to think, like A LOT of COIN coders, that ONLY developers should contribute, the rest of the COMMUNITY should just debate, hype, freak out, and vote on polls. How DARE they contribute code! I want the code to be easy enough for even a freshman in college to understand HOW TO IMPROVE IT. That is the strength of the coin. That everyone knows what it does.

Aren't contradicting your self? Am I a developper? no NO and NO it's the total opposite I can writte you a white paper of only math code, but do you see me doing that here? no so.

Simply put:  You did post code.  It might make sense to the 7 or 8 people here that are fans of Kernighan and Ritchie (the authors/creators of the C programming language) - but that means you're not communicating meaningfully to >97% of the community.  I'm fairly sure that's not the result you're hoping for.  I'm trying to help you get your excellent analysis into the hands of a greater portion of the community.  I hope you will do just that.

You are not putting into context the reason why I posted the code, I posted the code to answer the person who claimed it was overly complicated and impossible to implement hence claiming he already read the code and understand it, which is not the case, You don't see me posting code in every single comment do you ?

Nope. I've edited linux modules to allow servers to be hidden behind invisible routers. I can do C/C++, PHP, Javascript, Lisp, and a few others.
This is about the rest of the community not understanding the code. You keep thinking only coders should understand the code.
Not on my watch.

As for examples and graphs, I've been in the trenches trying to help pull this code out of obscurity and into the light. All I've seen as far as Kimoto is the code snippet you posted. I haven't seen anything that talks about what EventHorizon and PastMass mean. If the COMMUNITY has no idea what they mean, that's no good. It doesn't matter if you or I know what it means. If the users don't know, they can't contribute. It separates them from the developers. That's no good for a coin's survival.

You've edited and can't understand a simple lines of code like that, I don't code C, I only used C / C++ and Fortran to solve, Mechanical problems, And I only use alghorithms for Mechanical and CFD Simulation on software like Ansys or Fluent ect. So to resume I have a basic level, but with my basic level of knowledge, I can just go to the Gethub of any coin that uses YGW, open the main.cpp and see the parameters used and search for the definition instance like blockmass or evenhorizon (and btw this word are used as kimito seems to be interessted with general relativity, and Mass, Gravity well and evenhorizon are just the basics of spacetime fabric warp and stuff like that and the number used are inspired from some of general relativity constantes and obviously I'm not asking you to know this )

kuroman, I'm not trying to be nasty, but I feel as if some people see this project as a piece of software with peculiar switches and knobs and they think that's where it ends.

Unfortunately, it's not. The poorly structured code is inhibiting evolution and innovation. We need something that doesn't smell like 1995.

Bad code? you just claim it's poorly structured and bad code while it is just simple C commands ! how can this be bad code, you are just in self denial here, the solution is proven to work end very well, it you have some factual evidence that the solution doesn't work perfectly please put them on the table, also I'm not saying we should apply the code as it is, we can adapt to our coin, it would be stupid to just apply like that.
we can change:
-BlocksTargetSpacing  
-PastSecondsMin            
-PastSecondsMax    
And this something other coins did to adapt the code to their coin (you claim they just stupidly copied YGW, that's an insult to other dev, that know more than you and me about cryptocurrencies and coding in general)

Just for grins, here are a couple of scattered thoughts in no apparent order.  Hopefully the pictures will make up for the lack of organization.

A number of folks here as well as a number of coin devs are enamored with the Kimoto Gravity Well (KGW).  So far, the coins I've found that use this have fairly fast block times.  The longest is Anoncoin's 3.42 minutes.  Others, from Megacoin through Franco, have block times from 30 seconds through 2.5 minutes.    Here's Megacoin with its 2.5 minute block time:

https://coinplorer.com/Charts/Difficulty/MEC



It's pretty clear that this method allows difficulty to track the hash rate fairly well.  Let's look at another coin with a 2.5 minute block time - Phoenixcoin:



Let's skip forward in time for Phoenixcoin - here's a look at performance after the Oct, 2013 fork:




This fork is when the team there moved to a 2-tail simple moving average with 100 and 500 block SMA, a 1 block retarget and a limit.  I don't know if this can be adjusted to work for CAT, but I hope it shows that KGW is not the only way to.

So - all you smart folks in CATlandia - thinking caps people - we need you!

Pheonixcoin is a bad example, as it was only hited Once the top charts of profitability and it was hit only once or twice with profitability pool since fork, Also during december the coin was not tradable during several days on cryptsy.

I'm not saying there can't be other solutions, of course there are, but the process to get one that will work well for out case will take a huge amount of time, between having an idea/white paper, translating the idea into code, simulating the code, testing the code (and as proven with current code testing does not represent real life conditions sadly as it disregard some parameters ....) ect ect, it takes time and energy.

I'm all for innovating our own solution and let other coins copying our solution like they are doing with kimitos, but I think for now and in the meantime to get all this process done, we can use KGW adapted to our coins (it does not take much copy/paste to main.ccp adapt values and tada! (well might not be this simple as I've never coded a coin and I'm not an expert but I think it's not far from it) and we can have our sweat time testing the values choosen and tweaken, then release a version that solve this problem.

Almost every new scrypt altcoin, and previous coin that had issues with profitabilty pools uses KGW and it has solved their problem and this is for reason

[SlimePuppy]

Everyone - Coinium has more than 51% of the hash - please move miners to avoid a fork.