Quote from: etblvu1 on January 27, 2014, 09:47:09 AM

Catcoin Fork Status from Etblvu1

Since at least one member of the development team has declared me off of the team for failing to agree with what amounts to the party line, I post here strictly as myself as an interested investor with some knowledge of development processes, but necessarily on behalf of the development team. I do not want to be inflammatory or controversial, and that is not my intent here. I believe Catcoin community members deserve an alternative perspective report on the fork that has been announced or is about to be announced. I will try to present this report in as unbiased a way as I can, so you can make up your own mind what it all means - and hopefully it can proceed in an orderly way.

No offense, but you're really starting to get on my nerves. For the record of the community, Andy (AKA SlimePuppy) has Etbluv1 on ignore in IRC, because he can't seem to understand that his opinion isn't the only one, and repeatedly frustrated Andy to the point that there was no compromise on outcomes.

You've demonstrated repeatedly that you are only really interested in implementing your own ideas, and to hell with everyone else. The continuing (REPETITIOUS) discussion (especially re: LLACCA) and time it took to either discredit or disprove your theories has absorbed a TREMENDOUS amount of development time that easily could have been better used elsewhere. This fork would have been done two weeks ago if it wasn't for the constant struggle we've had establishing the fact that there are no perfect solutions, there are only solutions that are complicated or simple. You seem driven to implement the former, and the rest of the team is concerned with the increased risk of gaming the system with more complicated algorithms. Innovative is good, complex is bad. I've had a couple of RL developers look at your ideas and their immediate reaction was (and I quote) "That's bullshit." So take that for what it's worth.

Quote

1. Issues. We have been experiencing severe fluctuations in the rate at which new blocks have been generated - most noticeably in hours between confirmations of transactions. This has been a legitimate concern that is behind the current laudable efforts to implement a fix.

I definitely have to agree with you here.

Quote

2. Team. The original developer has not been available due to circumstances beyond his control. In the meantime, several individuals have volunteered to take on various development roles, and this work has proceeded without any formal organization to coordinate the efforts - the coordination has been informal and organic.

I disagree with this, though the organization has been someone chaotic at times due to various RL obligations of our team, there are most certainly people filling all of the critical roles. We are not professional developers, and we do this with our free time, holding us to a professional project management standard is both idiotic and inappropriate. We've clearly established who is doing what, and to say otherwise means you've been listening to yourself talk for too long.

Quote

3. Algorithm. There have been multiple algorithms proposed for implementing a solution (gravity well, loyalty credit, llacca, and simple moving average with limit). Through a particular decision-making method, a decision was reached to implement the simple moving average with 12% limit as the solution in behalf of the Catcoin community.

This is true, the majority of the group wished to compromise on a relatively simple but ultimately safe and likely effective solution. We develop it easily and test it just as easily, while the other algorithms were far more demanding both time and skill wise.

Quote

4. Hard fork. Through the same decision-making method, it has now been decided that a hard fork is imminently being released.

I want to emphasize also, that it is very dangerous for a coin to have a hard fork if the people are not unanimous in their accepting the hard fork, so the best thing to do despite any feelings you may have about the way this fork is being conducted, to accept it anyway for now, use good security steps to protect yourself (always a good idea anyway), and keep the fork unified. We can always work on improving the quality of the build process and if needed, the difficulty adjustment algorithms later. But for the health of the coin, we must remain united and agree on what fork to be on, and do everything possible to avoid the chaos of multiple forks being out there. To this end, I will try to keep my opinions to myself about this entire situation so the fork has the chance to be successful. I may post more robust commentaries once things appear to have stabilized after the fork.

We're well aware you have issues with how the project is being run. Let me clarify a few things from the remaining items on your list, as I do not have all day to comment on them individually.

As with previous forks and other coins, the majority of linux users prefer to compile their own nodes and wallets directly, as it is both simple and secure for the user. Saying this is an uncommon practice is an outright fallacy, and you know it.

We are planning to have multiple developers (specifically me and Andy for sure) compile the wallet and compare the hashes generated. We don't need extra software or an extra development process just to satisfy your need to make things as complicated as possible. I assure you, I've signed my real name to this project, the last thing I'm going to do is put my reputation in jeopardy with some shady practices. People are welcome to segregate the wallet from others, but you are severely over-blowing the risk here. None of us are here to see catcoin fail, so why would we go out of our way to fuck that up?

Now that all of that is out of the way:

Development is in its final stages. I personally threw 2MH on the testnet for about 18H last night to see what would happen. Results are available for everyone to see. In the next 48H we will be unifying all our repos and distributing that information to the community for verification. Once that is done we will pick a block number and notify the exchanges and the pools. We will also build the wallets based on this final vetted code. We will verify these builds with two or more developers, and check hashes to ensure everyone is on the same page. Once this is done we will begin the process uf updating the nodes and pools, so when the fork block does come, there are no surprises. We will do our best to assemble the pool operators at fork time to ensure that in the event of a runaway pool, things are controlled as quickly as possible. We will monitor the network for any unintended consequences. We will also begin a PR campaign to bring hash back to the network to try and reduce a possibility of a 51% as much as possible.

Further, the fork block will be selected so that it has a already high diff, and the preceding 36 blocks will be high. This was a mistake that was made at the last fork where the diff was set artificially low, and ultimately caused a fork. This high diff method will allow the network to settle out and adapt on it's own, while reducing the risk of a switching pool or high hash user causing issues. We're aware of the mistakes that were made last time, and we've specifically addressed those concerns as best we can. Hopefully I've demonstrated that this process is far more involved and thought out for us than etblvu1 has let on. I'm getting tired of this argument, and equally tired of having to spend an hour writing a post every time he disagrees with something. I am open to further suggestions and ideas from the remainder of the community.