Seems that you can now view Catcoin overall stats (e.g. Net Hashrate, current value in USD, etc.) on the CAT Information page on Cryptsy. Unfortunately almost all of that information is wrong. |
|
|
|
60 blocks mined in 10 minutes, from multipool
We believe that either the CoinEx switchpool, MDC or some unknown large farm/private switchpool has been dropping in. |
|
|
|
Just seems a little strange to me that we are asked to sign up at reddit to give up our loses, then we get an update that a portion has been send to coinium, and then reading on the forum after asking that they use it to cover their own losses.
Right, because that's still in process. It is a lengthy and labor intensive process to verify the losses, with as many forked chains as we're dealing with. Coinium was compensated by me personally, not from the insurance fund directly. I did this because Raistlin's pool balance hit zero, and it was going to affect further mining. The rest he covered out of his own personal supply. Raistlin was able to verify his loses more simply because he has access to the back end software for his pool. Work is still being done on the insurance fund, but I can assure you my coins, although listed there, do not represent any of the funds that were committed by other people. |
|
|
|
To bad if ur lost coins at coinium, the reimbursting coins they got go into their own wallets...
They refund 0, they just keep the coins.
No offense, but are you fucking kidding me? I personally put out 500 coins to cover coiniums losses. The pool op, Raistlinthewiz, put up THREE THOUSAND FIVE HUNDRED CAT of his own personal stash to cover overpaid coins. What does that mean? It means he paid out legitimate coins on mining that was done on invalid coins. Those coins never existed, but were paid out anyways. So, other invalid coins were caught before they were paid out, so yes, you didn't get paid out, but those coins never existed to begin with. Try to consider that everybody got screwed by these forks, ESPECIALLY Coinium. |
|
|
|
|
define unable to update your wallet? make sure when you extract it you're running the new version of Catcoin-QT
|
|
|
|
|
Alright guys, I promised a few people I'd make a post about the status of the project, and to clear some concerns a few people have brought forward.
First off, to our users and pool operators, than you for your patience during this trying time, I know it's not easy to deal with forks, constant upgrades, and lost coins. For that you have my teams' sincere thanks.
With that being said, I am troubled by the sheer number of accusations that have been made against our pool owners, especially Coinium. Raistlinthewiz (the pool op) has been one of our closest supporters since the launch of this coin. He's worked tirelessly to bring a high quality pool with a custom front end offering many statistical advantages that have been a huge advantage to the team, and the community. I have spoken with him directly and he has confirmed losses in excess of 4000 CAT due to overpayment for invalid blocks that we're not caught before they were paid out. In the interest of disclosure, I have compensated him 500 CAT from my personal reserves in order to offset at least some of these loses. He has agreed to cover the rest with his own personal funds. I take accusations against him and our other pool ops very seriously , because (and I can't stress this enough) they were not at fault for these losses. This was something that was a network issue, start-to-finish, and was both unpredictable and unavoidable. I know it's frustrating that many of you may have lost coins, but the pools were not responsible for that. Also, as much as I'd like to say otherwise so you could have someone to blame, neither was my team. We've been working around the clock to resolve these issues, and we're finally to a place we're we believe we've resolved this issue for the immediate future.
To clarify what happened, I'll explain a couple of key issues that caused this whole incident:
1. KR105, the original dev, hard-coded the master seed nodes into the source code of catcoin. These nodes pointed to a domain that hasn't existed in over 2 months, this resulted in the catcoin wallets going into a P2P mode, and caused some people who were freshly syncing to download bad blockchains from old ancient nodes. We still are seeing some people running the original catcoin daemon and this was causing havoc within the network. We've tried to combat this a few ways, most importantly, the team and some of the pool owners have deployed a number of new super-nodes, that are both fast and stable. We've corrected the master seednodes in the new source code and this was applied with the maintenance patch. As we see more new wallets and pools come online, we will have less and less network issues, and we've already received positive feedback from users and one of our exchanges at how much faster the network syncs now, so for now we'll take that as a very nice step in the right direction.
2. ComputeMinWork: This was the root of the issue. Because of the new periods of low diff, followed by huge hash rate influxes, we saw a dramatic increase in the work submitted to the network, unfortunately due to another oversight by the original dev, this caused a protection system within the bitcoin code to activate and ban any nodes that were submitting work too quickly, and we were effectively DDoSing ourselves. This resulted in our primary nodes not talking to each other and as a result all the forks happened because none of the nodes were synced up because they were banned from each other. We've relaxed this protection slightly to accommodate this issue, and this has caused a dramatic improvement within the network.
Hope this helps, it was kind of the quick and dirty explanation, and some of my team could explain some of the changes in more detail, because I was not here while they were being built.
|
|
|
|
|
Pool Owners: Please update your pools and post here or PM me when this is complete so I can update your status in OP. Thanks.
|
|
|
|
Check your pools and compare it with block explorer, some pools has fork...
I think block explorer is still on fork. Edit: Or maybe I'm wrong. But my updated client has less blocks than the explorer. If block explorer in fork, then devs anytime can start solo mining with minimal dif, and after say that all pools and block explorer was on fork... Block explorer must be real mining indicators. And block explorer shows correct all mining block after update until some time, while some pool don't start fork... if devs will say what block explorer on fork then CAT can be buried... We are aware that the chain explorer may be on the wrong fork, I've had one of the guys message dogeles to see if he can verify his blockchain for the daemon. Edit: I am not super crazy about you accusation that the devs would do such a thing, we wouldn't. We're mining the same chain you guys are, because any other chain is useless. |
|
|
|
|
Alright Guys,
I've logged in when I said I wouldn't because this is getting out of hand. OUT. OF. HAND. I am getting married on Sunday....No offense, but I don't really have a ton of time to be logging in to break up cat fights, I have other priorities at the moment.
To clarify a few quick things, so maybe you guys might actually trust what my team is saying:
- There were two hard forks since the beginning of the coin, the first reduced the diff retarget from 2016 blocks to 36 and manually set the diff to 16, this occurred at block 20290. The second implemented the 1 Block retarget, using 36 SMA, 12% Minmax. This was implemented at 21436.
-The gravity well. We get it. Some of you guys really have a hard-on to see this algorithm deployed ASAP. Before I left, I instructed Etbluv1 to use his new simulator to model the gravity well. This is not a simple task because the code must be ported from C to C#. He said he will do this at his earliest possible convenience. This tool is going to be how we establish consensus, because from what I have seen of it so far, it is EXTREMELY accurate, and very realistic to a real world environment. This is going to take time. After this past debacle, I REFUSE to deploy another fork that MAY OR MAY NOT solve the problem. There will be no more fucking maybes. It's either going to fix the problem and we're going to be able to prove that, or it's not going live. Period. No more half-assed garbage. Be patient, my guys are spending a ridiculous amount of time on this as it is.
I can appreciate that many of you want to see this coin profitable ASAP, believe me, we are all at the top of this list on this team, we are doing our best, and I wish that some of you would be a little more realistic with the fact that this is not what ANY of us do for a living. We do this in our spare time and expecting us to be working on this 24/7 is going to end up with us burnt out, and a lot of people excessively angry. Calm down, I promise you we will develop something that will work.
Hopefully that sorts some things out.
KM
|
|
|
|
 Cryptsy is now in sync. |
|
|
|
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. |
|
|
|
|
ENOUGH. Everybody take a step back for a second. Dev team included.
A little (blatantly obvious) honesty: The current algorithm didn't work as well as we planned, but to those of us tearing us apart for it, I didn't exactly see any of you lining up at the door with any of the simulations I'm seeing now. I would have put a stop to this before we even released it if we had, or at least tweaked it some more to make it less (over)reactive.
I need you guys to all stop and take a breath and open your minds to solutions, and by all of you I mean ALL OF YOU, my team included.
This is the situation we can't control now, we released the fork, it's done, the coin arguably functions better than it did before, because at least now the confirmations don't full stop for 4+ days at a time. This is critical to the survival of this coin, and buys us time. I'm not happy this didn't solve the problem, and releasing a band-aid wasn't really the goal, and guys honestly, that is somewhat on me. I'm sorry I let you as a community down. I really am. I have a lot going on in my life, I'm getting married next week and I've been ill for the majority of this week. It's not an excuse, but merely an explanation. Please remember that I'm human and my team is human, and we had to pick this coin up quickly in less than ideal circumstances. We've established roles, and everybody is aware of what they contribute. Lessons were learned during all of this, so please, it was all part of the process. I'd like to think that we have one of the most active dev teams of any of the coins out there, that's got to be worth something. We also have one of the most active and vocal communities out there, and that is definitely worth something.
Now is not the time to tear each other apart over mistakes that were made though, I can't do any more but apologize for what happened. I can promise you I will do better and my team will do better in the future. But, we need your support, and we need some of the expertise that has shown up in the past 24 hours. It's just a fact of life, I said when we built this team we were always looking for more talent. We still are, and always will be. As an example of this I recently added Johnny_non to our team, who I don't think anybody can argue with has done an UNBELIEVABLE job turning around our PR front and websites. I'd like to take a moment to recognize that dedication, because it's been extremely important. He's got some cool shit brewing in the wings too that will be discussed here soon. The Oprah thing is absolutely huge for us. I can't stress that enough.
As for our coins future, enough bickering, bickering and name calling is not productive, one thing is for certain: this coin's community certainly does not lack in color and contrast. We have several options in front of us, and we're looking for more.
Yes, the Gravity Well is one of them, hozer's concern revolves around the floating point numbers that the algorithm uses to calculate difficulty. He can get into his concerns if he wishes. That algorithm is by no means off the table, however.
envy2010 and kuroman, and strelok have provided very detailed feedback which I've been looking through at length. I think the solution is in front of us, we just need to AS A COMMUNITY decide what direction to take this coin and what we feel the best approach will be to resolve this once and for all. We have bought ourselves significantly more time with this last fork, obviously it's not ideal, but it still functions as a coin.
I hope that perhaps everybody can take a step back and breathe and stop fighting like cats, and that a calm level head will provide us with a permanent solution that takes this coin to the next level.
Thanks for your time.
Kevin McCurdy
|
|
|
|
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. |
|
|
|
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. А если ты здесь из 2ch'ерской банды крутых хацкевов-програмистов-финансистов и прочего сброда "офигенных российскех школотеев и проходимцев", которые тут, чтоб "выдавить биток с хомяка", убейся об стену. 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. |
|
|
|
 My wallet has been like this for daysss. Any idea what is wrong? I copied the conf. file to roaming, so now it is in both places, right? Thanks for the help. Try deleting you blockchain and redownloading it. You can do this by deleting most all the dat files in %appdata%\CatCoin. DO NOT DELETE WALLET.DAT MAKE A BACKUP OF IT WHILE YOU'RE IN THE FOLDER AND KEEP IT SOMEWHERE SAFE. |
|
|
|
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. |
|
|
|
|
by updating to the new wallet.....you're two wallets behind.
What OS are you running?
|
|
|
|
On the coinium frontend i can now see:
Net Hashrate: 0.22 GH
Pool Hashrate: 146.93 MH
Why are you guys still promoting your pool, when you are obviously holding more then 50% of hashrate? I dont get it.
they're not promoting. people need to move on their own. To where? We don't even know what is the correct block and the developers haven't said anything. I'm dumping this. Lol, you've bean threatening to pump and dump this since before the fork. Get rid of it already so I don't have to listen to you, you're pissing me off. It's not forked fromw aht we can tell, we've been watching it pretty closesly and noticed the coinium discrepancy some time ago. From raistlinthewiz directly at coinium: (3:55:24 PM) raistlinthewiz: { (3:55:24 PM) raistlinthewiz: "blocks" : 21506,(3:55:24 PM) raistlinthewiz: "currentblocksize" : 3031, (3:55:24 PM) raistlinthewiz: "currentblocktx" : 9, (3:55:24 PM) raistlinthewiz: "difficulty" : 63.12087317, (3:55:24 PM) raistlinthewiz: "errors" : "", (3:55:25 PM) raistlinthewiz: "generate" : false, (3:55:25 PM) raistlinthewiz: "genproclimit" : -1, (3:55:26 PM) raistlinthewiz: "hashespersec" : 0, (3:55:26 PM) raistlinthewiz: "networkhashps" : 223754655, (3:55:27 PM) raistlinthewiz: "pooledtx" : 9, (3:55:27 PM) raistlinthewiz: "testnet" : false (3:55:28 PM) raistlinthewiz: } His front end lagged a bit. Calm down. |
|
|
|
look at coinwarz.com.. this coin will not survive. it needs to defeat big pools.
look at that list. its sad. they suck a coin dry until it barely becomes a $15/day proffit for a 1mh/s miner.
is this difficulty going to stop this?
you need one block retarget. so if they jump in then the next block it would be pointless for them to stay.
What exactly do you think we implemented? |
|
|
|
Difficulty going up despite network hash rate going down? You're kidding..
It's a side effect of the new algo. Relax it's coming back down, it should be much more gradual this time . |
|
|
|
|
Show Posts
