Topic: [ANN] Catcoin - Scrypt meow! - page 5. (Read 470759 times)

EXCITED!

That's excellent news.

Within the next ~17 blocks.

Probably been asked before, but is there an eta for when the fork will occur?

Great, I agree that it's not perfect. So what's your suggestion then?

Everybody has been super quick to say the idea isn't perfect. Of course it's not! None of the solutions are! What' I'm not seeing is people lining up out the door with solutions that are fairly straightforward to implement and actually address the problem. I realize an SMA is delayed, but that beats the alternative of having the diff jumpy as shit if we didn't average it out. We arguably could reduce the SMA to 18 or 12 blocks to make the coin more reactive, and the 12% would still provide the smoothing necessary, but for the most part, it's been a small core group of us working on this, and very few ideas that are short-term friendly (ie. not llacca or gravity wells or loyalty credits) and don't fundamentally alter the coin that everybody signed up for! I'm not sure else how to get the community involved in this process rather than simply telling us our ideas suck and not providing anything reasonable as an alternative. It's fucking frustrating.

If you guys have a better suggestion then by all means we're all ears, I'd much rather implement a permanent fix. But I have to say this: This coin does not currently have the life left in it to survive what would likely be a several month development/deployment process to properly test some of the more complex solutions. Please for the sake of CAT, either put up some ideas, or support one of the already proposed solutions.

Oh, and Etbluv1, I wouldn't even suggest calling what I said baseless, because I can show you 20 or so term length papers you wrote about how your idea was better than everyone else's. To the point that it made a lot of us red in the face to read YET ANOTHER insanely long post. If you want different representation for this coin, be my guest, but I will not stand here and be called a liar in front of everybody, when the majority of the community has supported my position on you in various ways over the past several weeks. I'm aware you hold 40K CAT, which means your motivation in this is almost entirely financial. If you wanna dev this fucking coin, be my guest, but I guarantee you you'll kill it with the ideas you've presented. They are impractical, and more importantly will take too long to implement. Time we don't have currently. Good day, sir.

Note that Mav's comment was 'simpler' not 'simplest' and that's important.  I'm happy to report that my proposal, the 100 and 500 block SMA with limit as developed by the Feathercoin devs and used in Phoenixcoin, was not selected as it is more complicated, designed for a coin much faster than ours, and would likely only move us 10-20% closer to long-term stability.  Likewise, we did not choose to completely replace the guts of the retarget process as has been heavily promoted by one large cat speculator.  Mav and Hozer found that we can get the performance we need - today and tomorrow - with the 1/36/12% process we've been testing.

The 1 block retarget, 36 block SMA, with a 12% up/down limit has been tested on the testnet and has reacted very smoothly and quickly to rapid increases in hash rate (we started with instantly adding 20 times more hash than base, then increased that last night.  This fairly closely simulates the current low hash rate and the injection of computer power by switching pools we've seen to date.  The difficulty and block times are responding very well.  Most importantly, this eliminates the massive difficulty swings that have brought coinhopping pools to us in the first place.

Rest assured that the number one goal is to fix it right and stabilize the coin for the very long term - for miners, investors, speculators, and retailers.

Here's a look at the diff response from last night's 30x hash rate 'attack':  http://waywardlife.net/blak/catcoin/

Thanks,
Andy

Baseless?  Let the community decide.  On Saturday, 25th Jan, this individual was informed - and acknowledged his understanding - that the build process for the Windows wallet would be published, validated by other devs (and anyone else that desired), and confirmed.  Others communicated the same thing to him the following day.



Since that time, the build process has been published in both dev channels and here and is fully open for scrutiny and comment.  The build process was based on the processes used for Bitcoin, Litcoin, and Feathercoin.  Our code was forked from the former, and we're in the same 'generation' as Feathercoin - we've incorporated some process 'lessons learned' since BTC and LTC.

Let's also take a look at how we view 'security'.  The gentleman stirring the pot here seems to believe that if we follow his chosen method that we will build a wallet free of malware.  Unfortunately he's incorrect.  Any build environment or tool can be manipulated by someone with ill intent.  Comparing a hash only confirms the two binaries are identical - it does not 'verify' the binary to be free of malware.  Both packages can contain the same virus or backdoor or root kit.  In other words, anyone demanding to see a hash must understand what that does and does not communicate.

My view of security is different and frankly more involved and intense than a simple virus scanner or a hash.  I'm a retired communications analyst that worked in highly secure environments for more than 21 years.  During that time, I was a systems administrator, network administrator, and secure communications administrator in a mixed Windows/Unix environment for a national agency.  Later in my career, I ran a computer lab that tested network protection tools.  We compiled everything we used from source, and compiled most of the *nix kernels we ran.  Since retiring, I've started two businesses and run one from home.  While my 'daily driver' is a Win 7/64 box, other machines in the house are running XP, Ubuntu, and whatever's on the Raspberry Pi today.  Software and network security goes well beyond 'just' a possible virus.  I've been building my own computers since 1983 and haven't had a virus or other malware on a machine under my control since the mid-1990s.  I have no intention of starting now.

The machine I'll use to build the production wallet will be a freshly installed Windows 7 64 bit machine.  It will be built - as are all of my 'production' machines - on a freshly formatted disk, using official MS distribution media,  while not connected to a network.  Windows is installed, then an updated anti-virus tool (I use Kaspersky).  Then the machine is connected to the 'net and all updates are run.  The initial dev environment tools include binaries (MinGW, Pearl, Python) from trusted sources.  The wallet dependencies including QT5, and then the wallets, are built from source retrieved directly from the respective developers.

My build process will affect exactly one section of the community:  Windows wallet users.  It does not affect pool operators or exchanges as they will build directly from source (Blaksmith read in the transcript above is one such pool operator).  I don't know of any pool or exchange running any flavor of Windows.

I'm not asking anyone to trust me and I will not.  I have already published the build process and links to all required packages - anyone that desires to build their own wallet should do just that in whichever environment they're comfortable working in.  While binaries will be available for Windows and Mac users that desire them, they are not required.

As communicated earlier, if you have questions for the dev team or the board, please visit on irc freenode #catcoin-dev, or contact Maverickthenoob, hozer, skillface, zerodrama, johnny_non or myself.  Anyone else providing updates is doing so for their own purposes and does not represent the board, the devs, or the community.

I hope that's useful for the community.
Andy

Windows wallet build instructions:
MS Word DOC format:  http://www.absoluteefficiency.com/images/cat/catcoin_wallet_build_windows.doc
PDF:  http://www.absoluteefficiency.com/images/cat/catcoin_wallet_build_windows.pdf

You shouldn't take the simplest. You should take the best one which already proved to work in other coins.
Times for alt coins won't become simpler once the scrypt asics get into this game.

A moveing average is something that is always delayed. With or without limit you will pay in difficulty everytime a pool-hope jumps in.

I rather liked if you considered to fix it right once and for all.

Certainly retargeting after each block and averaging is already a lot better than what it is now. But will that hold for the future?
I have my doubts.

Dear Maverickthenoob,

While I appreciate your substantial investment of time and energy to help the coin, I do not appreciate your posting and/or repeating multiple baseless defamatory allegations about my character. I believe any detailed rebuttals I might post to defend myself would unfortunately contribute to a circus atmosphere around this coin, which it most definitely does not need. So at the risk of appearing to acquiesce to the unjust allegations, I will leave it at that for now.

You said in your post "We will verify these builds with two or more developers, and check hashes to ensure everyone is on the same page." If this is true, then this is different from what was emphatically explained to me in the #catcoin-dev channel yesterday. May I take your statement to be an official or semi-official commitment from you and/or the development team that any links to Windows or Macintosh wallet executable files officially posted from any team member will have had its hash checked against another developer compiling to the same platform, and confirmed matching? Some people may think I am making a big deal about some obscure hyper-technical issue. But if you think about it, the last thing this coin needs right now is even hint of a suggestion from anybody right after the fork that bitcoins or litecoins local to the system where they downloaded a catcoin wallet executable mysteriously got spent and if anyone were to say such a thing (true or made up or misattributed - maybe they had a virus infestation that did this to them totally unrelated to Catcoins, but they don't know and post here their suspicions), being able to say that two independent developers verified the hash will immediately remove/allay any fears that a compromised wallet executable is circulating - where such fears would otherwise be almost impossible to disprove/shake. So it really is a bigger deal than it may seem on the surface.

If we are getting verified hashes before posting executables, that is really great news, and that is all I ask for and really all anyone can reasonably ask for under the circumstances. It means no Windows or Macintosh user is being asked to put total trust in any single developer, that the executable they are downloading has been compiled from the trusted Catcoin source code. As a minor aside, with respect to Linux users, my posting does not suggest anywhere that secure build issues affect Linux users - I am aware that Linux users customarily build their own executables from source, and I apologize if my posting was not sufficiently clear on that point.

Thank you,

Etblvu1

The linked wallet is for the current network - version 0.8.7.0-beta.

Once the fork code is finalized and announced, we'll update the wallet and announce the new version number.  We'll let you know via a readme on sourceforge as well.

Not just hoping, but actively working for the long-term success of CAT and her entire community. 

Andy

Difficulty retarget block by block is a good thing. It should've been done first time around.

I'm looking forward to it.

And with all the disagreements, I'm sure everyone here is hoping for the best, no matter what their opinion.

Making some new pools so figured CAT is a sweet coin to compete with DOGE

http://cat.thec0de.com

Stratum Mining - Port: 3334

Proportional Payout System

VARDIFF Enabled for CatCoin difficulty

1% Pool Fee - Donations Appreciated Wink

DDoS Mitigating Host

other pools

SexCoin: http://sxc.thec0de.com (First Production SXC Pool)
PotCoin: http://pot.thec0de.com (New!)

Hope it helps boost the MEOW out there 

Been waiting nearly 24 hours for 5cats to go to Cryptsty from my wallet.

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.


I definitely have to agree with you here.


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.


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.


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.

Lol this coin. Can't wait for it to go up so I can dump it.

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.

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.

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.

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.

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

5. Secure build. To the best of my knowledge and research, it is customary in coin development for executable wallet programs to be compiled from source by two or three separate developers to verify the hashes match up before posting a link for the coin community to download it. This is a security measure to make sure a coin community is not being asked to personally trust a single developer's build environment and the developer personally, in order to download and run the program.

6. Hard Fork with Secure Build. A couple of days ago, I expressed a strong concern in the #catcoin-dev channel that verifying the hash by two developers is a good security practice yet seemed to be missing from the plan, and what is being proposed to be released would be regarded as an insecure build. At the time, I received assurance from multiple developers that of course we should release a secure build, and nobody objected to the idea at the time.

7. Hard Fork without Secure Build. It was recently explained to me that the decision to release a secure wallet for Windows and Mac OSX has been "moved to the back of the line" and a hard fork is proceeding immediately without a securely built wallet. Everyone would instead be asked to download their own source code and build the wallet for themselves. I do not quite understand why this change in plan, but frustration was expressed to me, in effect that the difficulty level situation was severe and required immediate fix, and that it could not wait for a time-consuming build verification process. One developer expressed the opinion to me that my suggested secure build procedure was too stringent a requirement - and this is probably the majority opinion among developers, although I have not taken a poll.

8. Options for Catcoin Wallet Users. Building a wallet from source in Linux for use in Linux is a fairly straight-forward process. Linux users routinely do this for most programs they use. But it is not so straight-forward for Windows and Mac OSX users. If you are a Linux user, this hard fork will be no different from any other. If you are a Windows or a Mac OSX user, with this hard fork, you will have to choose between: 1) failing to upgrade the wallet on time and potentially be on an obsolete fork or the wallet stops connecting to the network, 2) scramble to figure out how to compile a wallet program for yourself from the trusted source code, or 3) download the wallet executable from a single developer who has compiled it, and whom you must personally trust, since the compiling was not reproduced by another developer from the same source and programs verified to match up.

My Recommendation. As the release of this hard fork appears to be moving ahead, my recommendation for Linux users is to build from source and deploy as usual. For Macintosh and Windows users - either choose to trust the developer who will be compiling the executable and who will be making it available for download for your convenience, but perhaps install it on a computer separate from where you may have other coin wallets (a good security precaution to use anyway for all wallet executables of any coin type) - or find someone you know and trust personally who can build the wallet for you from source - or transfer balances to an exchange you trust (to retain the ability to spend) and not run the outdated wallet on your local computer, and later obtain a copy of an updated wallet executable you feel comfortable trusting, and transfer the balance back in.

I apologize in advance if there are any omissions or mistakes in the above list, or if I failed to be sufficiently unbiased in presenting the facts.

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.

Thank you,

Etblvu1

looks like my maths in the morning isn´t very good - sorry

that would be 16 blocks

only 6 more blocks to go ? The wallet in your link is still the old version or does it only has the same name ?

(holding a sealed envelope to my head) I'm seeing...2 or 3...and a 1...is that a 6?  Yes - it looks like 21346... But what does it mean?



---
Cat wallet for windows:
https://sourceforge.net/projects/catcoinwalletarchive/files/