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

[Maverickthenoob]

Great! Finally data to visualize.

(http://catcoins.biz/charts/)



I used your data to plot a bit more:


I am gone surfing those waves up right!

I'm worry about those waves on diff vs block number graph. I think there is a problem.

A ecли ты здecь из 2ch'epcкoй бaнды кpyтыx xaцкeвoв-пpoгpaмиcтoв-финaнcиcтoв
и пpoчeгo cбpoдa "oфигeнныx poccийcкex шкoлoтeeв и пpoxoдимцeв", кoтopыe тyт,
чтoб "выдaвить битoк c xoмякa", yбeйcя oб cтeнy.

My post in old CATcoin thread. It's matlab model of diff recalc.

Code(matlab):

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clear
clc

N = 36*10+1;
hashrate   = zeros(1, N);
difficulty =  ones(1, N);
blocktime  = zeros(1, N);

lastchange = 1;
hashrate(1,1) = 1000;

%imaging floating hashrate somehow (i'm not a wizard of probability theory)
for i=2:N
   change = rand(1,1)/4*sqrt(i-lastchange);
   if change>1
      hashrate(1, i) = rand(1,1)*1000*2+100;
      lastchange = i;
   else
      hashrate(1, i) = hashrate(1, i-1);
   end
end

%hashrate   = [ones(1, (N-1)/3)*100 ones(1,(N-1)/3).*1000 ones(1, (N-1)/3+1)*100];
%single stepup stepdown
%end imaging floating hashrate somehow

%diff and approximate blocktimes with sliding window
for i=1:37
    blocktime(1,i) = (difficulty(1,i)*2^32/(hashrate(1, i)*1e6)/60);
end

for i=(37+1):N
    average  = sum(blocktime (1, (i-36):(i-1)))/36; %average of blocktimes
    averdiff = sum(difficulty(1, (i-36):(i-1)))/36; %very important, otherwise unstable
    difficulty(1,i) = averdiff/(average/10); %10 is target, such recalc have astatism
    blocktime(1,i) = (difficulty(1,i)*2^32/(hashrate(1, i)*1e6)/60);
end
%end diff and approximate blocktimes with sliding window

%show results for window
fig1 = figure(1);
stairs(hashrate./100, 'color' , 'red');
hold on
stairs(difficulty./10, 'color' , 'green');
stairs(blocktime, 'color' , 'blue');
hold off
%end show results for window

difficulty =  ones(1, N);
blocktime  = zeros(1, N);

%diff and approximate blocktimes with classic recalc
lastrecalc = 1;
for i=2:N
   if i-lastrecalc > 36
       average  = sum(blocktime (1, (i-36):(i-1)))/36;
       difficulty(1,i) = difficulty(1,i-1)/(average/10); %10 is target, such recalc have astatism
       lastrecalc = i;
   else
       difficulty(1,i) = difficulty(1,i-1);
   end
   blocktime(1,i) = (difficulty(1,i)*2^32/(hashrate(1, i)*1e6)/60);
end
%end diff and approximate blocktimes with classic recalc

fig2 = figure(2);
%show results for classic
stairs(hashrate./100, 'color' , 'red');
hold on
stairs(difficulty./10, 'color' , 'green');
stairs(blocktime, 'color' , 'blue');
hold off
%end show results for classic
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Matlab arrays starts from 1 not 0;

Warning: if sliding window then in next difficulty must take part average
difficulty on window, not previous difficulty, othervise system unstable.

Is actual algorithm use average diff as good as blocktime?
If it use average without construction such as red_line_in_code_above
it will have diff spikes and hollows.
Correct it immediately if it's so. We will be anough with sliding window,
no need to invent bicycles with 12% and other excesses to diff recalc
algorithm and imagine yourself gods of cryptoworld.

And where is old logo? It was much better than actual.
Actual one have lack of one thing (it can be called idea byt in is not fully correct).
I don't know how to say about it, try to ask artists. Those thing, which make you
recognise product in mass. Like doge on dogecoin sign, like BTC on bitcoin logo,
Like double front grille in BMW.

Strelok, your math work on this has been fantastic since day 1, I really really wish you would join our dev team. Your insight could be invaluable to correcting these issues.

Also that log was never the logo of CAT, and is essentially false advertising as nothing about this currency is currently anonymous. Until such time as it is, I don't feel comfortable saying it is.

[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

[kuroman]

THE FORK WORKS

First difficulty oscillation: BOTTOM 1, TOP 139
Second diff oscillation: BOTTOM 1.19, TOP 79

GOING DOWN

Diff 196 now.

What do you say now?

I say the network hash is almost 600 Mhash, it should have long since slowed down if it wasn't the fact that it's still rocketing upwards can only mean there is a lot more net-hash here than we realized. I'll re-evaluate tomorrow when the blockchain explorer gets repaired.

As for the diff, I've been monitoring it this couple of days, and been switching pools and trying to understand what's the matter, I've done some simulations under matlab, I understand more or less, the jerky reaction of the network despite the new parameters, so here is my analysis :

1-Profitibility pools don't switch to the most profitable coin instantly, they keep mining coin, as long as it has a decent profitibality, and I think this allows this pools to mine for a certain amount of time

2-Despite the 1 Block diff change, the value that wasn't taken in consideration is the 10min target time, (this value cannot be changed is a core value of the coin) but I think the importance of this, is that unlike other coins with very quick block target time, our value gives the time to huge brandwidt to join in and keep mining, while the 12% limite was supposed to limite the inflantion both ways, the delayed reaction of profitability pool, cause them to join once the diff is really low and leave once it is considerably high and leaving the coin with block time in hours.

So tl,dr the new fork parameters doesn't work as perfectly because profitabilty pools don't just switch in the exact instant the coin becomes the most profitible and leave the instant it is the most profitable but keep mining for a while. This doesn't mean the fork failled, it is not the case, the situation is better than what it was a few days ago when were stuck with high diff for a long periode of time, it's just that it doesn't work perfectly and nothing is perfect.

What I suggest, is too keep the dev work on going and lets think about solutions to keep the coin healthy, I'm still thinking gravity well is a good solution, but we should study before hand if it possible to implement it, and how it can interact with our long block target time

Great! Finally data to visualize.

(http://catcoins.biz/charts/)



I used your data to plot a bit more:


I am gone surfing those waves up right!

I'm worry about those waves on diff vs block number graph. I think there is a problem.

A ecли ты здecь из 2ch'epcкoй бaнды кpyтыx xaцкeвoв-пpoгpaмиcтoв-финaнcиcтoв
и пpoчeгo cбpoдa "oфигeнныx poccийcкex шкoлoтeeв и пpoxoдимцeв", кoтopыe тyт,
чтoб "выдaвить битoк c xoмякa", yбeйcя oб cтeнy.

My post in old CATcoin thread. It's matlab model of diff recalc.

Code(matlab):

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clear
clc

N = 36*10+1;
hashrate   = zeros(1, N);
difficulty =  ones(1, N);
blocktime  = zeros(1, N);

lastchange = 1;
hashrate(1,1) = 1000;

%imaging floating hashrate somehow (i'm not a wizard of probability theory)
for i=2:N
   change = rand(1,1)/4*sqrt(i-lastchange);
   if change>1
      hashrate(1, i) = rand(1,1)*1000*2+100;
      lastchange = i;
   else
      hashrate(1, i) = hashrate(1, i-1);
   end
end

%hashrate   = [ones(1, (N-1)/3)*100 ones(1,(N-1)/3).*1000 ones(1, (N-1)/3+1)*100];
%single stepup stepdown
%end imaging floating hashrate somehow

%diff and approximate blocktimes with sliding window
for i=1:37
    blocktime(1,i) = (difficulty(1,i)*2^32/(hashrate(1, i)*1e6)/60);
end

for i=(37+1):N
    average  = sum(blocktime (1, (i-36):(i-1)))/36; %average of blocktimes
    averdiff = sum(difficulty(1, (i-36):(i-1)))/36; %very important, otherwise unstable
    difficulty(1,i) = averdiff/(average/10); %10 is target, such recalc have astatism
    blocktime(1,i) = (difficulty(1,i)*2^32/(hashrate(1, i)*1e6)/60);
end
%end diff and approximate blocktimes with sliding window

%show results for window
fig1 = figure(1);
stairs(hashrate./100, 'color' , 'red');
hold on
stairs(difficulty./10, 'color' , 'green');
stairs(blocktime, 'color' , 'blue');
hold off
%end show results for window

difficulty =  ones(1, N);
blocktime  = zeros(1, N);

%diff and approximate blocktimes with classic recalc
lastrecalc = 1;
for i=2:N
   if i-lastrecalc > 36
       average  = sum(blocktime (1, (i-36):(i-1)))/36;
       difficulty(1,i) = difficulty(1,i-1)/(average/10); %10 is target, such recalc have astatism
       lastrecalc = i;
   else
       difficulty(1,i) = difficulty(1,i-1);
   end
   blocktime(1,i) = (difficulty(1,i)*2^32/(hashrate(1, i)*1e6)/60);
end
%end diff and approximate blocktimes with classic recalc

fig2 = figure(2);
%show results for classic
stairs(hashrate./100, 'color' , 'red');
hold on
stairs(difficulty./10, 'color' , 'green');
stairs(blocktime, 'color' , 'blue');
hold off
%end show results for classic
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Matlab arrays starts from 1 not 0;

Warning: if sliding window then in next difficulty must take part average
difficulty on window, not previous difficulty, othervise system unstable.

Is actual algorithm use average diff as good as blocktime?
If it use average without construction such as red_line_in_code_above
it will have diff spikes and hollows.
Correct it immediately if it's so. We will be anough with sliding window,
no need to invent bicycles with 12% and other excesses to diff recalc
algorithm and imagine yourself gods of cryptoworld.

And where is old logo? It was much better than actual.
Actual one have lack of one thing (it can be called idea byt in is not fully correct).
I don't know how to say about it, try to ask artists. Those thing, which make you
recognise product in mass. Like doge on dogecoin sign, like BTC on bitcoin logo,
Like double front grille in BMW.

I agree with the averdiff sum, also you choose N=36*10+1 can you explain to me why *10? did you try to plot the diff function?

[ubermoose]

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.

[strelok369]

N = 36*10+1;
It's "signals" arrays length (don't like any dynamical memory allocation anywhere).
Those code representing 36 blocks sliding window and i simply want to see period as long as 10 windows.
N can be any value (not 36 dividible may cause some problems in this code, but it's only quick overwiev)

You should mention about astatism of diff recalc.
It's relative, so algorithm don't know what difficulty need to set for hashrate, it even don't know exactly hashrate.
Algorithm operates on how need to multiply current difficulty to get target block time with assumption(maybe aprove through probability theory),
that block time reverse proportional to hashrate with same difficulty and most important - that blocktime proportional to
difficulty with same hashrate. And all of coefficients of proportions is unknown and more, random (with distribution law
depending on the hash distribution law). And i use very symplified model of most probable average time (think it's "Expected value" in english terms).
Take it from LTC calculator as i remember.

If you take in account astatism, and tests show that blocktime stabilise on 10 mins after hashrate change and hold both ways, i'm calm.

And yes, catcoin never been anonimous, but i'm about logo design. My "serious cat" not a cake too.
I'm explain. Actual logo on my opinion has expected standart advertisment design. If you think about
food or traveling company logo it's what first come to mind - light offce mainstream style. And "old" anime-style
(not fan of anime, only like "ghost in the shell" for it's cyberpunk setting and not very simple plot) kitten was what you
never expect from currency, somehow original(in this place) and rememberable. It was cute and not serious,
it was attracting, something which "CATcoin" name can be accosiated. Posche - you imagine porsche 911 design. Bmw - you remember
double front grill and sign. Microsoft - you remember windows logo. Bitcoin - BTC. It's about associations.
If those gray kitten has no name and story behind it it's the best logo. Still offer gray kitten on mars surface.

[zerodrama]

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.

The difficulty prevents blocks. The wallet assumes it missed something. That's why. This is not an error.

[Bitye West]

Anyone else's wallet stuck synchronizing at 21 hours behind?  It's been stuck here for about 30 minutes.

It says I have 10 active connections to the Catcoin network.

[etblvu1]

N = 36*10+1;
It's "signals" arrays length (don't like any dynamical memory allocation anywhere).
Those code representing 36 blocks sliding window and i simply want to see period as long as 10 windows.
N can be any value (not 36 dividible may cause some problems in this code, but it's only quick overwiev)

You should mention about astatism of diff recalc.
It's relative, so algorithm don't know what difficulty need to set for hashrate, it even don't know exactly hashrate.
Algorithm operates on how need to multiply current difficulty to get target block time with assumption(maybe aprove through probability theory),
that block time reverse proportional to hashrate with same difficulty and most important - that blocktime proportional to
difficulty with same hashrate. And all of coefficients of proportions is unknown and more, random (with distribution law
depending on the hash distribution law). And i use very symplified model of most probable average time (think it's "Expected value" in english terms).
Take it from LTC calculator as i remember.

If you take in account astatism, and tests show that blocktime stabilise on 10 mins after hashrate change and hold both ways, i'm calm.

And yes, catcoin never been anonimous, but i'm about logo design. My "serious cat" not a cake too.
I'm explain. Actual logo on my opinion has expected standart advertisment design. If you think about
food or traveling company logo it's what first come to mind - light offce mainstream style. And "old" anime-style
(not fan of anime, only like "ghost in the shell" for it's cyberpunk setting and not very simple plot) kitten was what you
never expect from currency, somehow original(in this place) and rememberable. It was cute and not serious,
it was attracting, something which "CATcoin" name can be accosiated. Posche - you imagine porsche 911 design. Bmw - you remember
double front grill and sign. Microsoft - you remember windows logo. Bitcoin - BTC. It's about associations.
If those gray kitten has no name and story behind it it's the best logo. Still offer gray kitten on mars surface.

Hi strelok369,

From a mathematical perspective, what do you think about the idea of breaking up the tendency for harmonics to develop, by replacing just the "36" portion of "SMA36LIM12" with a prime number pseudo-randomly at each block retarget, to be selected from a table? For example, if we take the least significant 4 bits of the hash of the last block, and used it to look up a table of 16 prime numbers consisting of {7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67}. Why this sequence of prime numbers? It's the closest consecutive list of prime numbers that approaches the average of 36 that we are already using (average of this list of primes is 34.875 and median is 31 or 37, so responsiveness to sudden changes in hash power would roughly match what we have now at 36, actually slightly better). And why prime numbers? By using prime numbers, we eliminate any unintended/unforeseen harmonics that could happen in relation to sampling sizes. Even if there is no danger of harmonics in this sense, it seems good to spread out the numbers a bit, and using prime numbers seems as good a way as any to distribute the numbers, and gives us a nice variability range from 7 to 67.

Thank you for your thoughts.

Etblvu1

p.s. If this approach is discussed it might need a name so, I'll give it the name SMA~36LIM12 to indicate the sample size is approximately 36, instead of exactly 36. And I guess "simple" moving average may not be the accurate name, but I don't know what else to call it.

[Tim Suite]

We could still switch back to the gray kitten logo, it would work with the orange colour scheme.

[Bitye West]

Anyone else's wallet stuck synchronizing at 21 hours behind?  It's been stuck here for about 30 minutes.

It says I have 10 active connections to the Catcoin network.

I think I spoke too soon.  Exited and restarted client and now it's stuck at 3 hours behind.  Hopefully it's synch up eventually.

[zerodrama]

Hi strelok369,

From a mathematical perspective, what do you think about the idea of breaking up the tendency for harmonics to develop, by replacing just the "36" portion of "SMA36LIM12" with a prime number pseudo-randomly at each block retarget, to be selected from a table? For example, if we take the least significant 4 bits of the hash of the last block, and used it to look up a table of 16 prime numbers for example consisting of {7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67}. Why this sequence of prime numbers? It's the closest consecutive list of prime numbers that approaches the average of 36 that we already have in place (average of this list of primes is 34.875 and median is 31 or 37, so responsiveness to sudden changes in hash power would roughly match what we have now at 36, actually slightly better). And why prime numbers? By using prime numbers, we eliminate any unintended/unforeseen harmonics that could happen in relation to sampling sizes. Even if there is no danger of harmonics in this sense, it seems good to spread out the numbers a bit, and using prime numbers seems as good a way as any to distribute the numbers.

Thank you for your thoughts.

Etblvu1

How do you synchronize the RANDOM selection number across all clients? We have already clients that don't agree what block we're on.

That aside +9001 for short READABLE proposal. This could be useful.

[Bitye West]

Anyone else's wallet stuck synchronizing at 21 hours behind?  It's been stuck here for about 30 minutes.

It says I have 10 active connections to the Catcoin network.

I think I spoke too soon.  Exited and restarted client and now it's stuck at 3 hours behind.  Hopefully it's synch up eventually.

It wound up synchronizing.  I just exited the client and reopened it a couple times an hour until it finally synched up.

[gadado]

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.

[etblvu1]

Hi strelok369,

From a mathematical perspective, what do you think about the idea of breaking up the tendency for harmonics to develop, by replacing just the "36" portion of "SMA36LIM12" with a prime number pseudo-randomly at each block retarget, to be selected from a table? For example, if we take the least significant 4 bits of the hash of the last block, and used it to look up a table of 16 prime numbers for example consisting of {7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67}. Why this sequence of prime numbers? It's the closest consecutive list of prime numbers that approaches the average of 36 that we already have in place (average of this list of primes is 34.875 and median is 31 or 37, so responsiveness to sudden changes in hash power would roughly match what we have now at 36, actually slightly better). And why prime numbers? By using prime numbers, we eliminate any unintended/unforeseen harmonics that could happen in relation to sampling sizes. Even if there is no danger of harmonics in this sense, it seems good to spread out the numbers a bit, and using prime numbers seems as good a way as any to distribute the numbers.

Thank you for your thoughts.

Etblvu1

How do you synchronize the RANDOM selection number across all clients? We have already clients that don't agree what block we're on.

That aside +9001 for short READABLE proposal. This could be useful.

Hi zerodrama,

I appreciate your thoughtful question.

All the clients inherently and necessarily agree on what the hash of the last solved block is, or else they could not agree on the next block being valid, either.

So we take the least significant 4 bits of that hash, so all the clients agree on which prime number to use from the list. So it's technically a deterministic pseudorandom number that all the clients inherently already have access to in common.

We inherently can't worry about clients not on the correct fork, so they are not a factor. Clients that aren't caught up are also not a problem, because they inherently will see the same pseudorandom number (last block known) to validate the next block as they catch up, the same exact way they already validate blocks as they catch up.

Etblvu1

[geokilla]

Coinium caused a fork apparently. People need to get off Coinium.

[kuroman]

N = 36*10+1;
It's "signals" arrays length (don't like any dynamical memory allocation anywhere).
Those code representing 36 blocks sliding window and i simply want to see period as long as 10 windows.
N can be any value (not 36 dividible may cause some problems in this code, but it's only quick overwiev)

You should mention about astatism of diff recalc.
It's relative, so algorithm don't know what difficulty need to set for hashrate, it even don't know exactly hashrate.
Algorithm operates on how need to multiply current difficulty to get target block time with assumption(maybe aprove through probability theory),
that block time reverse proportional to hashrate with same difficulty and most important - that blocktime proportional to
difficulty with same hashrate. And all of coefficients of proportions is unknown and more, random (with distribution law
depending on the hash distribution law). And i use very symplified model of most probable average time (think it's "Expected value" in english terms).
Take it from LTC calculator as i remember.

If you take in account astatism, and tests show that blocktime stabilise on 10 mins after hashrate change and hold both ways, i'm calm.

And yes, catcoin never been anonimous, but i'm about logo design. My "serious cat" not a cake too.
I'm explain. Actual logo on my opinion has expected standart advertisment design. If you think about
food or traveling company logo it's what first come to mind - light offce mainstream style. And "old" anime-style
(not fan of anime, only like "ghost in the shell" for it's cyberpunk setting and not very simple plot) kitten was what you
never expect from currency, somehow original(in this place) and rememberable. It was cute and not serious,
it was attracting, something which "CATcoin" name can be accosiated. Posche - you imagine porsche 911 design. Bmw - you remember
double front grill and sign. Microsoft - you remember windows logo. Bitcoin - BTC. It's about associations.
If those gray kitten has no name and story behind it it's the best logo. Still offer gray kitten on mars surface.

Hi strelok369,

From a mathematical perspective, what do you think about the idea of breaking up the tendency for harmonics to develop, by replacing just the "36" portion of "SMA36LIM12" with a prime number pseudo-randomly at each block retarget, to be selected from a table? For example, if we take the least significant 4 bits of the hash of the last block, and used it to look up a table of 16 prime numbers consisting of {7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67}. Why this sequence of prime numbers? It's the closest consecutive list of prime numbers that approaches the average of 36 that we are already using (average of this list of primes is 34.875 and median is 31 or 37, so responsiveness to sudden changes in hash power would roughly match what we have now at 36, actually slightly better). And why prime numbers? By using prime numbers, we eliminate any unintended/unforeseen harmonics that could happen in relation to sampling sizes. Even if there is no danger of harmonics in this sense, it seems good to spread out the numbers a bit, and using prime numbers seems as good a way as any to distribute the numbers, and gives us a nice variability range from 7 to 67.

Thank you for your thoughts.

Etblvu1

p.s. If this approach is discussed it might need a name so, I'll give it the name SMA~36LIM12 to indicate the sample size is approximately 36, instead of exactly 36. And I guess "simple" moving average may not be the accurate name, but I don't know what else to call it.

Ok thought so, I was like that can't be a multiplication since it doesn't make since.


I have a question to everyone, I have my opinion on this but I want to hear yours, does the diff needs to be ruled  symetrically ? how about making SMA36LIM12 when diff is increasing, but in case of decrease have it go down with any limite per block: how will this effect the coin well let me show you :
NB: The value I took are aproximatif and are for the sake of having a concrete example they do not represent reality (as hashrate is variable/s diff adjustement and so on)

Right now :

Explanation : SMA36LIM12 makes the diff change almost sysmetrical per 36 block and the point of sysmetry is the block where the hashrate drops  significaly (or increase drasticaly for that matter) while this is supposed to be good, it is not because if we take in consideration block resolve time we see a huge disparity, because when the hashrate increase instantly, the block resolve time decrease by a huge marging, this makes block time resolve much shorter, the block resolve time increases with diff increase (12% a time) over time (over blocks) and gets closers to the supposed 600s target but once the Hashrate drop we are left with block with HUGE resolve time and due to the 12% limite, the next blocks will have a huge resolve time till we get close to the 600s resolve time again (it will take much longer to get diff down than to get up due to the limite and hashrate disparity, we are talking about an order of magnitude or two here)

So what if SMA36LIM12 is applied only for diff increase and the decrease is left limiteless:

Even if we suppose (absurd supposition) that profitability pools will leave the coin for the one block that the diff drops and comes back right away, we will have the diff retarget time decreasing overtime on each cycle (as these don't leave at the exact second before a new block, but it takes a couple of miliseconds to seconds to do so not to mention people who do this manually) which means with each cycle the chart is getting flat and and cycle it self it's getting shorter and less jerky, which will solve the issue.
But In reality independant miners that switch coins manually and profitability don't have instantnious reaction will make the coin level even faster and reach a sort of equilibrium over time on it own

[zerodrama]

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.

[evilwhynot]

Hey guys, is anyone else having problems mining right now? I have been mining for the past two days and havnt gotten any confirmed CAT or unconfirmed CAT. Right now I am mining with Coinium, and have  15,750 valid shares on this block. I did have a auto payout set at 10 CAT but I disabled that because I was not receiving anything in my wallet yesterday. Today I do not have anything like yesterday but I can see myself hashing in cgminer and on the coinium website.

[skillface]

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.

[etblvu1]

Hey guys, is anyone else having problems mining right now? I have been mining for the past two days and havnt gotten any confirmed CAT or unconfirmed CAT. Right now I am mining with Coinium, and have  15,750 valid shares on this block. I did have a auto payout set at 10 CAT but I disabled that because I was not receiving anything in my wallet yesterday. Today I do not have anything like yesterday but I can see myself hashing in cgminer and on the coinium website.

I've been solo mining and I just found two blocks in a row with my meager 4 megahashes, about 3 hours apart, what are the odds? and I am up to block 21601. I hope I just got lucky and I am on the right fork. Otherwise, maybe I  will lose 100 CATs I thought I mined.

Etblvu1