[ANN] Catcoin - Scrypt meow!

[SlimePuppy]

<snip>
Etblvu1

Ladies and gentlemen of CAT,  since this passive-aggressive post was pointed directly at me, I will take a few minutes to respond and clear the air.

I started mining coins in very early December.  I stumbled on CAT Christmas afternoon and read every post in this thread to that point.  I was amazed at the community that had risen around this coin!  As a cat person in a family of cat people, as a computer geek, and as a huge fan of local currency and distributed progress, I thought and still feel that this coin and this community can do more and become more than any pump and dump clone coin, or than many of the more established coins that are basically just coins.

I also noticed another thing in these posts:  That there were some here that didn't seem to be working to strengthen the coin and the community but were rather working, intentionally or not, in ways that were fracturing the community.  I didn't know who to trust as I was new, and hadn't yet done my own research into the various characters active here, so I didn't say anything or take the time to even join the forum.  I instead, kept reading, but only after I turned all of my mining equipment at the coin.

Now that I've had an opportunity to be a bit more involved, talk to some of you here, in PMs, and especially in IRC, I feel more confident about outlining where we are and where we're headed:

We all know that CAT is basically a clone of LTC with BTC parameters - it's BTC with scrypt.  We're also well aware that the 'founder' didn't quite finish his baby before she was born, and then he got pulled back into 'the real world' after a robbery and new job.  Unfortunately, that's left some of us to pick up the dev pieces - and we've had to do it quickly because the environment - mining power, pools, hopping pools - is very different today than it was years ago when BTC was released.  The assumptions used to tune the way the difficulty responds to sudden changes in hash rate are not up to the task.  We learned this very quickly when the first hits from a switching pool pushed our difficulty into the stratosphere and almost brought CAT to a halt.  Some brave souls dug into the code, made a quick change to get things moving again, made wallets, coordinated with pools and exchanges, and we had a hard fork.  This was emergency surgery - it wasn't designed or tested to be a 100% fix or to be the one and only code change - it was designed only to stop an emergency.  It did that perfectly!  That we're all still here is proof of that!

We are working on what should be a final fork - a long-term fix to the difficulty 'stuckness' that we're in.  The good news is that we have four options, two are coded, two are under test on our new testnet and when we finish simulating a 'hopper attack' we'll present the results.  Yes, at this point, no news is good news here.

The bad news from the 'back room' is that one of the four proposals would essentially gut the coin and reprogram it in ways not intended for CAT or LTC or BTC.  It would change the entire character of the coin in ways that have never been tested in the real world.  What's worse is that the gent that passionately believes in his plan believes that miners are bad, that hoppers are evil creatures, and that the only way to keep CAT alive is to implement FIAT-like manipulation that would make the FED proud.  This gent has proven to not understand how the coin was designed, or why crypto exists in the market to begin with.

To the point of etblvu1's post:  I am the person that finally asked him to leave the dev channel last night.  I did so because me, hozer, blaksmith, and zerodrama were trying to compile more wallets so we can finish testing a code change on the testnet.  Unfortunately, etblvu chose to continue to pull all of us off track because he's still trying to sell his proposal to gut the coin.  After wasting most of the four hours I had available, I asked him to either help with the dev efforts or leave.  I wasn't the only one asking...  I have no 'kick' or 'ban' authority on the IRC channel, so all I could do was to press 'ignore' - and I did that only so that we could use the available time for cat, not to massage someone's ego or get into off-topic debates on 'arbitrage'.  Yes, etblvue1 writes well and makes some cool graphs - and he's almost got a machine on the testnet.  Unfortunately, the signal to noise ratio is so bad that it's not helping us move forward.

That's the tech and that's the soap opera.

Back to the fix:  As I've outlined already, other scrypt coins have launched between BTC and CAT (man, that's an understatement!).  I've not looked at all of them yet, but the six I have examined have all needed forks to tune the difficulty code - every one.  Some are on fork FIVE.  What we've been doing is learning from those experiences - finding the difficulty adjustments that WORK so that CAT's 2nd fork (one we knew from the start that she needed) would be the last.  There is nothing knee-jerk about this work!  

Some things about me that maybe 1 or 2 of you will care about:  I'm not a politician and I don't have a poker face.  I don't enjoy drama or soap operas.  I'm retired military and prefer to cut through the crap and just plain get the job done.  I've learned the hard way that bad data is worse than no data - so I don't spin or lie and won't work with anyone that does.  I have found some people that I can trust in the community that are also working their butts off to fix the CAT.  They are active in the dev channel in between their work and family illness schedules.  They are:  Maverickthenoob, hozer, skillface, zerodrama, raistlinthewiz, upd, and ThePeePs.

The three fixes we're testing are simply adjustments to the way the difficulty responds to dramatic changes in hash rates.  Diff must be allowed to move up and down in response to the number of miners servicing our CAT.  The problem - and the ONLY problem with the structure - is that the original code was tweaked for a much, much slower network - a much slower-changing mining base.  That's it!  Every fix we're working on WILL be better than today - of that we're certain.  We're testing not so we can be sure we can improve the coin, but so that we can select the solution that works best.  Frankly, we could implement any of the three and have maybe a 60% chance of being done.  We're working to get that into the 90% range.

We're putting our time, money, and miners into CAT and are working to get past this one last hurdle.  The work's almost done and we look forward to giving you the rest of the details once we've proven that the code works.  We expect this to be the absolute last time we will have to slog through a period of 'too high difficulty' and we really look forward to announcing to all of you that we're finished!

Thanks everyone.
Andy



Ada the QC cat approves.

[SlimePuppy]

Could we not just have a predefined difficulty curve set as a baseline until the coin halves? The difficulty can also be capped 20% either direction from the baseline difficulty, so it can still adjust, but based on the difficulty curve. After the coin halving the difficulty curve would slowly taper off, allowing normal difficulty to resume.

The difficulty has to start high to dissuade coin hoppers, then it slowly declines, we'll lose some coin hoppers, but in that time also some dedicated miners. After this, the difficulty slowly rises, but now as fast as the difficulty fell. Once we reach the block halving, the difficulty declines again slowly until the baseline is zero and normal difficulty retargeting resumes.

The good news Nullu is that we're well beyond that.  We could simply reset the difficulty and add a movement limiter.  It would require a hard fork, and would require more code work and a third fork, however.

The plan is to do everything we need in one last fork.  We'll start with the difficulty high (not quite as high as today, but higher than one would expect for our current hash rate) so that we are not a target for switching pools.  This will allow the diff to slowly move down to match the miners we have in place when the fork happens.  Additionally - and this is the really good part! - the tweaked difficulty will move quickly with the hash rate.

The problem we have today is that the code was originally designed for a much slower-moving mining environment without pools and without switching-pools.  If I remember it correctly, it checked the hash rate, adjusted the difficulty level, then went to sleep for something like 1016 or so blocks.  Then the program 'woke up', checked the hash rate, adjusted the difficulty to match, and went back to sleep.  This was just fine before GPUs and pools - but as we know it doesn't work today - it's not fast enough.  The first hard fork reset the difficulty down, and reduced the number of blocks between hash rate checks - but it's still not fast enough.

The fixes we're testing will adjust the difficulty every single block.  This will allow a fast response to both high and low hash rates - no more stuck/dead times with the diff too high, and no more difficulty 6 periods where switching pools can scoop out coins after we've chipped away at the side of the mountain for days.  To keep difficulty swings in check, we're testing some different moving averages - the goal is that if we ever get hit with a huge hash rate, the difficulty will quickly adjust up as the coin is designed to allow - this will cause the hopper to move on as now another coin's more profitable to mine in that instant.  As soon as the superhash leaves, diff quickly drops to match the rest of us and we carry on - all within a matter of a few blocks.  It's already working in other scrypt coins so we know there's no risk to this method - we know it will do 100% of what we need it to do.  Specifically, we're testing a 32 block simple moving average (SMA) with a 12% up/down limit.  Other options include a single longer SMA period, and using the same 100 and 500 block SMA combination used by Phoenixcoin.  Again - all of these are known to work and they've been evaluated by an outside mathematician/statistician to boot.

I hope that helps,
Andy

[etblvu1]

<snip>
Etblvu1

Thanks everyone.
Andy

Thank you, Andy, for joining on this topic. I do not believe we need to have any drama on getting a proper fix implemented, but opening up to the community so we can build a consensus is important. The last time we had a fork almost forced on us we practically had a rebellion, until it was canceled.

Some background on me, in case this is helpful for anyone. I am an entrepreneur who has been operating an I.T. consulting business for the past 19 years, and have a knack for creative problem solving which I apply in behalf of my clients, to help their businesses grow. I have also applied my creative capability to publish a commercial software product in the enterprise software space, and have in the past partnered with healthcare software publishing and designed and put into production several healthcare applications. I have acquired a patent for an invention. I am working on a book about the I.T. industry and I.T. consultants. I have been programming since age 13, and have learned about 20 different programming languages. I have been involved in precursors to the cryptocurrency movement since high school, studying Ayn Rand, Ludwig von Mises, Napleon Hill, participating in and becoming one of the 5000 founders of the Laissez-Faire City project. I started CPU-mining Bitcoins in 2010, and got 50 Bitcoins from CPU mining in early 2011. I could go on. I am not new to this realm. I have committed significant time and money away from my primary business, to obtain more Catcoins, and do everything I can to help it succeed. I am sorry to say I have obtained most of my Catcoins not from mining, but from buying on the exchanges. But this was not due to any lack of my trying - I had my mining equipment pointed at the Catcoin network since the network was launched. Unfortunately, it appears I got onto the wrong fork, and I did not see my first mined coin until difficulty had hit 64, and after mining a few blocks, have only intermittently mined Catcoins. My contribution has been in the area of investigating why Catcoin is not shooting to the top of the charts with success, because the initial concept was very good  "Bitcoin in Scrypt." I am definitely a cat person - having grown up with my parents keeping no fewer than 20 cats around - I will continue to participate in any way I can to promote the coin perhaps as an "activist investor" if the current crop of developers do not wish to work with me or consider my code contribution.

Andy - although you have said things about me, and about my proposal which I consider untrue and unfair, I will limit my response to pointing out two things you neglected to mention in your post.

Contributing to development and testing I have been in the development IRC channel, doing everything I can to help with the development and testing since invited to do so, including installing Debian linux, setting up a testnet node, setting up my mining rig to participate in the testnet, and even writing code to implement what I believe is the best way forward for the Coin. You have explicitly excluded me from the list of people who are working on this coin, which suggests that I was somehow an unwelcome non-producer popping in to bother the actual developers.

Hours of Wasted Time, etc. The event you are describing, which makes it sound like I just randomly dropped in on the channel and started typing for hours and hours for no reason. In fact, I came into the channel to continue development work, but you sent a message into the public development channel accusing me of causing discord and confusion among investor types and that in essence I was as ignoramus with no knowledge of economics, etc. I was not expecting this sort of communication in a development channel, but I had just spent the better part of about two days, setting my business responsibilities aside, to research the blockchain, condense information, and create a chart from scratch to put light on the problems we are experiencing, in an effort to gather community consensus. You made it clear you did not appreciate that, and that the Catcoin community would be better off I would refrain from participating in it. I believe the best way forward to do the best thing for Catcoin is to communicate in the clearest possible way the nature of the problems we are having, and the various proposed methods of solving the problem, and go forward with consensus and mutual general informed assent. Maybe it was wrong of me to respond to your statement in the development channel, but at the time it seemed that it deserved a response. This in turn led to further messages, to which both sides contributed. My part in this was to participate in the messaging back and forth, and I am truly sorry that I do not have the strength of character to let essentially being called stupid and malicious roll off of me and ignore it and continue working on the task at hand.

I believe it is a healthy thing for some of the members of the developer community to open up and share their ideas and air out their grievances they have with me - and let's get back to posting useful informative things and proposed approaches so a consensus can emerge, and we can change the coin for the better in this fashion.

Thank you,

Etblvu1

[sakkosekk]

good of you to reach out

[zerodrama]

At this point the real bottleneck is the Windows wallet. Both the Mac and Linux wallets compile. Getting a unix environment compatible with Windows and Qt is a pain. It's also hard to find accurate information on what works and what does not. The Windows code will have to be changed so we can have a unified deployment, which hopefully other coins can benefit from.

[etblvu1]

Benchmarking the Success of the Next Fork

I have proposed that both block timing and average coin production are important measurements by which to judge if code implementing a fix was successful in achieving what the coin has promised to do. I submit for your consideration these benchmarks to incorporate into a possible community consensus:

Block Timing. The average time between blocks should be at or slightly below 10 minutes. Bitcoin has a lower than 10 minute average, because they have been adding hashing power pretty much continually, and the time is often down to 6-7 minutes at each retarget. If the coin spends significant amounts of time averaging more than 15 minutes, then something is not right.

Coin Production. The network should be generating an average of 5 coins per minute, with reasonable allowance to allow buffering for sudden changes. If the network is generating less than 3.75 coins per minute for any significant period of time, miners are being underpaid, and something is not right. If it generates more than 7.5 coins per minute for an extended period of time, we have hyperinflation, and something is not right.

I believe these are reasonable expectations to hold for any change that is implemented into the next coin software update, as part of any fix, and I invite any code contributor in the development team to commit to these benchmarks (or propose alternative benchmarks).

As the contributor of the proposed LLACCA logic, I hereby commit to these benchmarks.

Etblvu1

[SlimePuppy]

At this point the real bottleneck is the Windows wallet. Both the Mac and Linux wallets compile. Getting a unix environment compatible with Windows and Qt is a pain. It's also hard to find accurate information on what works and what does not. The Windows code will have to be changed so we can have a unified deployment, which hopefully other coins can benefit from.

Exactly.  That's what I was in the middle of last nite - building a windows install environment - when we were pulled off track.  I hope to have a successful compile later today, though by that time I may look like Bill the Cat for a bit afterward.

[SlimePuppy]

Benchmarking the Success of the Next Fork

I have proposed that both block timing and average coin production are important measurements by which to judge if code implementing a fix was successful in achieving what the coin has promised to do. I submit for your consideration these benchmarks to incorporate into a possible community consensus:
<snip>
As the contributor of the proposed LLACCA logic, I hereby commit to these benchmarks.

Etblvu1

Great - bring the dick-waving to the forum - that'll be good for investor confidence. Bloody hell.

Look, as has been pointed out to you here and on IRC, your LLACCA scheme is dead on arrival and best tried ONLY at the pool level, not in a coin, and CERTAINLY NOT in CAT.  Our number one selling point in the coin structure (there are plenty of other points that the community is ready to run with - not ignoring those!) is that we're essentially Bitcoin in scrypt.  Anyone - ANYONE! - that tries to lobby to change that is not working 'for' this community but only for their own ego.

Your 'block timing BS' is also misguided.  Again, you didn't get it last nite so let's try again:  The difficulty adjustment is HARD CODED into the coin.  The 50-coin per block payout is HARD CODED into the coin.  The other factors for the coin are HARD CODED and are there by design.  The 10 minute block rate is a TARGET and is NOT 'hard coded' into the coin - and it SHOULD NOT BE because it is an indicator of properly functioning hash/difficulty tuning.  That's why it's a target and not a hard coded number.

Everything about your 'LLACCA' system and your absolutely incorrect sales pitch that somehow miners are 'missing coins' is incorrect because you continue to focus on time above all else, instead of understanding how the coin is supposed to work.

For pete's sake, there are no missing coins during slow periods because the coin like most others pays by the BLOCK not by the hour.  Time depends on network hashrate and difficulty level.  Period.  Full stop.  It is really as simple as that.  My 11 year old understand that - I have no idea why some others don't.

The code changes are being tested on the testnet as we type.  They will be proven there first and that will be presented to the community.  The first and only priority is to adjust the hashrate/difficulty interaction so that it properly responds to the network.  Once that is accomplished, we will all see that the 10 minute block target will fall into line.

I'm calling on all other's with a clue to weigh-in on this - please make your voices heard.  Thanks in advance.

[etblvu1]

Benchmarking the Success of the Next Fork

I have proposed that both block timing and average coin production are important measurements by which to judge if code implementing a fix was successful in achieving what the coin has promised to do. I submit for your consideration these benchmarks to incorporate into a possible community consensus:
<snip>
As the contributor of the proposed LLACCA logic, I hereby commit to these benchmarks.

Etblvu1

Great - bring the dick-waving to the forum - that'll be good for investor confidence. Bloody hell.

Look, as has been pointed out to you here and on IRC, your LLACCA scheme is dead on arrival and best tried ONLY at the pool level, not in a coin, and CERTAINLY NOT in CAT.  Our number one selling point in the coin structure (there are plenty of other points that the community is ready to run with - not ignoring those!) is that we're essentially Bitcoin in scrypt.  Anyone - ANYONE! - that tries to lobby to change that is not working 'for' this community but only for their own ego.

Your 'block timing BS' is also misguided.  Again, you didn't get it last nite so let's try again:  The difficulty adjustment is HARD CODED into the coin.  The 50-coin per block payout is HARD CODED into the coin.  The other factors for the coin are HARD CODED and are there by design.  The 10 minute block rate is a TARGET and is NOT 'hard coded' into the coin - and it SHOULD NOT BE because it is an indicator of properly functioning hash/difficulty tuning.  That's why it's a target and not a hard coded number.

Everything about your 'LLACCA' system and your absolutely incorrect sales pitch that somehow miners are 'missing coins' is incorrect because you continue to focus on time above all else, instead of understanding how the coin is supposed to work.

For pete's sake, there are no missing coins during slow periods because the coin like most others pays by the BLOCK not by the hour.  Time depends on network hashrate and difficulty level.  Period.  Full stop.  It is really as simple as that.  My 11 year old understand that - I have no idea why some others don't.

The code changes are being tested on the testnet as we type.  They will be proven there first and that will be presented to the community.  The first and only priority is to adjust the hashrate/difficulty interaction so that it properly responds to the network.  Once that is accomplished, we will all see that the 10 minute block target will fall into line.

I'm calling on all other's with a clue to weigh-in on this - please make your voices heard.  Thanks in advance.

Thank you.

[tmp68]

Here's two gifs I made for amusement and procrastination and hopefully to help with coin interest.

The first one wouldn't show inline... https://i.imgur.com/f9N0lDT.gif

https://i.imgur.com/zIJ2SWV.gif

__________________________________________

CAT: 9fQxowosPZMX3ZFGGtSZmr2Z5ZJF8pXq75

[etblvu1]

Understanding Missed Production vs. Missing Coins

The Catcoin code, being a descendant of Bitcoin, is limited by code to a maximum of 21,000,000 coins produced over its lifetime. The actual maximum will be less than this, due to coin destruction through lost wallets, etc. The final coin produced would happen sometime about 140 years in the future. About every four years, the block subsidy is divided in two. So for now, you receive 50 coins if you solve a block. In about four years, this will become 25. Then four years after that 12.5, and so on.

Nobody has seriously suggested any substantial change to this sequence, or limits.

I have previously posted that by producing coins at a rate that is half of what is promised by the code, we have missed production. By this, of course we are talking manufacturing language. Missed production does not mean that production will not eventually happen - it means we have missed producing what we promised to produce, in the time frame we promised to produce them. Worse, when production catches up, the people who reasonably expected to be paid what was put off being produce, do not get paid from out of the delayed production. Imagine signing up to buy mining rigs, paying the asking price for it, then finding out that they are running slow on production, so they are going to just send you half the rigs you expected, discard the rest of your order, keep all of your money, and next week when they produce rigs, they will just send it to people who placed new orders. When you complain, they explain it's just the way things work, and encourage you to just send another order if you want more rigs. This would not fly in the real world, yet this is analogous to what miners are suffering when coin production rate is below the promised amount over an extended period of time.

However, this does not mean coins are missing - not exactly - except in the sense of they didn't show up as expected in the pockets of miners. It is not missing in the sense that the network recognized some coins to have come into existence, and then mysteriously due to some bug or something, they disappeared. No, that is absurd - no such bug has ever been discovered, or hopefully should ever be discovered. Nobody has suggested such a thing. The coins produced are exactly as many coins as the software instructed the computer to produce. We are all in agreement about that. The issue is whether or not the software has delivered what it promised to deliver.

When we take an average for an entire week, encompassing 14 difficulty adjustment cycles up and down (more than enough for "averaging out" to take place), and discover only half as many coins had been produced during this timeframe to pay the miners - in the real world - for people who have bills to pay, it is not an exaggeration to say that we have missed production schedule - and miners were undercompensated in relation to the compensation schedule promised by the coin. It means half of the coins that should have been produced and paid to miners that week, were put off being produced until later. And the coins that get put off being produced until later, are paid to future miners, not miners who reasonably expected to be compensated for their mining.

So let us all agree that there are no missing coins. Hopefully, we can also agree that coin production missed its target production rate that was promised, and in the future, we should have regular production of coins averaging the promised rate of 5 coins per minute, so miners can pay their electric bill and are not forced by economic circumstance to stay away from the Catcoin network.

The more we get developer and community buy-in for this concept, the more likely the coin will receive the correct fix, to make sure miners receive what was promised to them in the future, which will lead to increased miner participation (increased hashing) in our Coin network. The proposed benchmark is intended for this purpose. It is actually a good sign if it causes angry reactions by developer(s) who perhaps did not have this priority in mind.

[etblvu1]

Here's two gifs I made for amusement and procrastination and hopefully to help with coin interest.

The first one wouldn't show inline... https://i.imgur.com/f9N0lDT.gif



__________________________________________

CAT: 9fQxowosPZMX3ZFGGtSZmr2Z5ZJF8pXq75

Nice!

[kisa2005]

@slimepuppy
@etblvu1

for the sake of CAT, guys, please stop posting your lengthy argument with ego and resume competition to the bewildered community that still appreciates your continous efforts. some of us are not nearly as tech as you guys, but it looks that each of you has their credentials and is working their asses off for this coin. There could be errors or unknown consequences in any the approaches suggested, given that social processes can't be perfectly modelled, but hopefully there is benefit of taking different view angles at current issues. If only your discussion remained constructive and inoffensive, reading through your posts gives the rest of us steep learning curve and confidence that any proposals get tested hard before being released. however, the argument has now been off that constructive track (perhaps the reason being that everyone is by now exhausted and needs a decent rest) - so please get over it and arrange for the best possible united effort and some peace now. Thank you!!!

Show that cats can smile also

[SlimePuppy]

@slimepuppy
@etblvu1

for the sake of CAT, guys, please stop posting your lengthy argument with ego and resume competition to the bewildered community that still appreciates your continous efforts. some of us are not nearly as tech as you guys, but it looks that each of you has their credentials and working their asses off for this coin. There could be errors or unknown consequences in any the approaches suggested, for the simple reason that you can't perfectly predict or test social processes, but hopefully there is benefit of taking different viewangles at current issues. If only your discussion remained constructive and inoffensive, reading through your posts gives the rest of us steep learning curve and confidence that any proposals get tested hard before being released. however, the argument has now been off that constructive track for some reasons (maybe everyone is by now exhausted and needs a decent rest) - so please get over it and arrange for the best possible united effort and some peace now. Thank you!!!

Thank you Kisa and I agree completely.  Unfortunately when it comes to groups of people, especially busy people that want sound answers and don't necessarily have the time to dig through the 'sausage making' part of the process, it's all too easy for some shyster to step in with a good story and shiny shoes and appear to know what's best.  This is exactly the type of behavior I saw causing confusion around the first fork - most of the community - ME INCLUDED - was in here on the forum thinking this was where all the important work was being done.  And frankly I was confused and finally cornered Maverickthenoob to 'put up or shut up' and let us know what's happening.

This led to plenty of discussions, entry into the dev room, and an intro to the folks that were making the sausage.  And yes - it confirmed for me who was NOT helping - either here or there.

I'll leave it at that.  Please - everyone in the community - I can assure you that the folks that are still in the room working right now are miners, hold CAT, and are working to grow not only the coin's stability but also her value AND the social aspects of CAT.  I won't steal any thunder here, but I'm aware that work is happening that involves CAT people and attorneys.

For reliable information on the progress to date, visit on IRC Freenode #catcoin-dev, or PM Maverickthenoob, hozer, skillface, or zerodrama.  Most everything I know is already posted here.

For the CAT above any person - including myself,
Andy

[etblvu1]

Summary of what is on the table. Information will be adjusted as people point out any aspects I may have missed, or if there are any inaccuracies that need to be corrected. Any of the proposed improvements will be better than what we have now. Thank you.

For those of you who are not familiar with the LLACCA algorithm, see: https://bitbucket.org/dahozer/catcoin/issue/11/the-llacca-algorithm

Etblvu1

[Nullu]

I have absolutely no idea what's going on anymore. Could explain in simple terms what's happening? TL:DR.

[etblvu1]

I have absolutely no idea what's going on anymore. Could explain in simple terms what's happening? TL:DR.

Developers do not all agree on the best approach to fix the coin. Some developers want to implement and push for a new hard fork without public discussion. Other(s) want to keep the community informed on the alternatives and form a consensus, so we do not have another badly executed fork. I believe all are doing what they think best for the coin.

[Nullu]

I have absolutely no idea what's going on anymore. Could explain in simple terms what's happening? TL:DR.

Developers do not all agree on the best approach to fix the coin. Some developers want to implement and push for a new hard fork without public discussion. Other(s) want to keep the community informed on the alternatives and form a consensus, so we do not have another badly executed fork. All are trying to do what they believe is best for the coin.

So basically we have everyone doing their own thing? The exact same problem we had with the last fork.

Why can't we just use the Kimoto Gravity Well? It wards off multipools, and most importantly it is code that already exists and works. We do not need to reinvent the wheel. The Catcoin brand sells the coin. Any new code may make things worse.

This has become a debate about the inherent flaws in cryptocurrency, rather than a debate on how to fix Catcoin.

[etblvu1]

Why can't we just use the Kimoto Gravity Well? It wards off multipools, and most importantly it is code that already exists and works. We do not need to reinvent the wheel. The Catcoin brand sells the coin. Any new code may make things worse.

This has become a debate about the inherent flaws in cryptocurrency, rather than a debate on how to fix Catcoin.

Would you like me to add your proposal to the list of proposals on the table?

[Nullu]

Why can't we just use the Kimoto Gravity Well? It wards off multipools, and most importantly it is code that already exists and works. We do not need to reinvent the wheel. The Catcoin brand sells the coin. Any new code may make things worse.

This has become a debate about the inherent flaws in cryptocurrency, rather than a debate on how to fix Catcoin.

Would you like me to add your proposal to the list of proposals on the table?

Sure. From what I've seen it'd be the quickest fix, that's been proven to work. We could spend another few weeks debating what the problem with the coin is, or just use a solution someone else has already come up with. The Kimoto Gravity Well will instantly spike the difficulty the moment a multipool so much as touches it, causing the multipool to switch. For the same reason it stops coin hoppers as well. The moment they mine it, diff jumps. The coin's difficulty will reflect the hashrate. The coin will then have to survive by its name and branding, which was always the point and the appeal of this coin to begin with. Problem solved. Essentially it's a difficulty recalculation per block.

That's my two cents. I don't want to join the debate. I just want to see a solution that works. I don't care whose. Perhaps we should just put all the proposals in one thread and put up a poll.