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

Etblvu1, no offense, but Galaxy coin is a really shitty example for a number of reasons:

1. It has a 30 second block time, we're at 10 minutes, that's outright apples to oranges.
2. They used average of previous 10 blocks only, meaning their coin loses its "memory" too quickly. Their coin forgets its history hash rate after just 5 minutes. Ours adapts over the course of 6 hours, but much quicker with drastic spikes in either direction because the average will be affected greatly, and block times will be much shorter or longer than anticipated.

Comparing this solution in galaxy and cat is two completely different kitties. They could have fixed it by taking previous 150 or 200 block average. Or using 5 block retarget with 50 block average, or something similar. THey just don't take enough history into account, which I guarantee causes the crazy oscillations in their coin.

I'm also for the sliding window by my both hands.

And give me link to how calculators count probability
of finding block in solo, please. I try to modell it with
matlab to get graphs.

@hozer:
Man do you know how it named?
Takeower. I'm worry about this compleatly kill this coin.
I have all my CATs in first days, so it will be on your chain
too(if you don't restart it).

Can you cancel your Takeower and wait community response?
Write to the kr105. Sliding window realy better. I have not much time
because of my exams, but want purpose IIR diff algorithm (late unfortunately).

What you doing it's simple stupid revolt on the ship.
That how not should the work to be done. Currency
is currency, because people belive in it. We should unite
around one solution. It's only way above.

If you want kittycoin and prove to everyone, that you are best
go lunch your kittycoin with blank blockchain on another net id.

If you want to help CATcoin, wait community response and get support
(not by "vote you hashrate we'll have distributed exchange in near future")
If you can coordinate your changes and majority (peoples, kr105 and
cryptsy/coinedup and others) will be organised for fork as in previous case,
It will be good. No doubt sliding window better than present diff recalc
mechanism and people will accept it.

But not do it in such cuneass 2ch'ers manner.

I would not be opposed to some kind of a short-term fix pending implementing a longer-term solution, but my main concerns would be 1) using a formula that looks too similar to something that was already tried in another coin and has resulted in the coin spending a lot of time at top and bottom of the profitability charts (see GalaxyCoin, which has a continuous readjustments in difficulty), and having hard forks come too many times too quickly, which can cause exchanges headaches which in turn can lead to getting de-listed.

If what we are looking for is reasonable difficulty stability, we might consider looking at the entire field of cryptocoins that have a similar market cap to Catcoins, and of those, which has the most stability in difficulty, and copy parameters off that coin. Since I did not make a study of this, I will not even speculate what those parameters may be, but I do know continuously variable difficulty was employed by GalaxyCoin and without understanding why they spend so much time at the top and bottom of profitability charts, we should not employ the same or similar algorithm in Catcoin.


There may be some merit to this argument, of why continuous difficulty adjustment combined with slow block target times, may moderate the erratic movements in difficulty, in some sense. I think it is very difficult to model incentives and behaviors with this formula, it's almost like trying to model the exact shape of the sound waves that would come by creating an intentional feedback loop with a microphone and speaker. I think feedback loops are inherently unstable. I think the changes may happen less often than with GalaxyCoin (because of the 10 minutes vs. 30 second target time), but I don't know that extending the difficulty curve and stretching it out, is that much of an improvement, if it spends longer durations at the top of and bottom of profitability charts.

Our top priority for patchwork should be to keep the coin at a moderate place on profitability charts, somewhere close to LTC, and I have no idea what would accomplish that in an elegant way. If we are tossing around inelegant and risky ideas, how about pulling price data from exchanges via API from the QT wallet (LTC price, CAT price, LTC difficulty), then simply setting the CAT difficulty continuously to force profitability to equal LTC, but with some constraints thrown just in case exchange goes crazy or there is no connection available to the exchange API (in that case, as backup, go to the 36 block average based on past difficulty)? I say inelegant and risky, because it is clearly a bad idea to put exchange API into a coin source code and highly risky. in some sense. But if we are being experimental and willing to take big risks to temporarily patch things up, that sounds like as appealing an idea as any I have seen so far, and at least it will fix the issue of the coin profitability being unpredictable. Or better yet, we can avoid exchange API's by randomly popping up a dialog box asking the user to input the current LTC:BTC market price, CAT:BTC market price, and LTC difficulty, and let the users input those, and the network can look at the consensus/median of user inputs to calculate the adjustment. The wallets can pop up the dialog box with about the amount of of frequency that it doesn't bother the user too much, yet provides enough samples to be reasonably reliable.

Etblvu1

Galaxycoin does a new diff every block, over the last 10 blocks, which are *targeted* to come every 30 seconds.

The difference is we have an order of magnitude or more longer period over which these changes occur.

With galaxy coin, a coinhopper mines for no more than 10 blocks and skyrockets the difficulty and leaves everyone else to clean up his mess. That's a few minutes.

Right now, we have a 10 minute block target, and we go through 36 blocks with a hopper in half an hour to an hour, and we clean up the mess for 10 to 20 hours.

With the change up for vote-with-your-hash, the coinhoppers will push things up, and they will lose profitability as the difficulty comes up every block, but it will all occur over timescales where us humans with other things to do in our lives can actually react.

I'd also propose that we set up a profit-switching pool that pays out in CAT if we still have problems and use the oscillations to make money for the CAT community instead of us making money for anonymous coinhoppers.

First off, this "live server" is as close to a test net as we can currently get, unless these changes get over 100 Mhash (or essentially a vote by hash by the community), there is absolutely ZERO way this is going to "take over". Remember only the longest block-chain is legit, unless a majority of users were to move over to hozers code, it's not and will not be the official code. Calling this Knee-jerk is a little bit incorrect, as these changes are far from official or being "THE" catcoin blockchain.

Secondly, we're looking for these changes to be adopted into KR105's fork and pushed out as an actual hard fork to the code. We're looking for the community's input on the potential 1 block retarget, 36 block average method. I've repeatedly tried to get comment on this system, and repeatedly the conversation has been derailed by unrelated conversation. Elbvu1's method has promise and so does hozer's stake mining, as long term solutions. In the short term, I personally think the 1 block retarget, using the previous 36 blocks average diff will allow it to step up and down. The diff will almost look as if it is going up and down a flight of stairs. I'll give you an example to demonstrate.

Here's an EXTREMELY rough paint diagram to illustrate how I envision this working.

(Forgive my paint noobishness, I just banged this out real quick. Put down the pitchforks people! )

http://imgur.com/9Q6coVg

Take a look at that, this is the behavior we want to see implemented, and due to the 1 block retarget the jumps are LIMITED by the average of the previous 36 blocks, it will limit the extreme spikes to this "stepping" action. We may need another fork down the road to add more functionality and to look at loyalty credits or stake-mining. But in the short term this should fix the brutal jumps and make this coin more attractive both in reliability and profitability. Comments?

I'm finding community reaction by watching the hashrate. Vote with your hashes. The coin is easily attackable with less than say $150,000 worth of GPU hardware when everyone leaves because difficulty is high, AND p2pool is effectively unusable, leaving you up to the whims of pool operators. Look at http://catcoins.biz/charts/ .. in 18 blocks (20988) jumper(s) will show up, and halfway through (20999) I fork. What happens next is up to you.

I'm not going to call it CATcoin anymore if nobody hashes on my fork, I'm going to learn a little, clean up the code, and launch Kittycoin. But I figured I'd do the CAT community a favor first and tell them exactly what's going on and what I'm planning.

If you are worried about de-listing, don't. Exchanges are also a single centralized choke point, and stuff like https://github.com/PhantomPhreak/counterpartyd will allow fully distributed exchanges, which is why I included it my release. So if an exchange de-lists, then we just make it so we can all do distributed trades with CAT/LTC/BTC/DOGE directly from our catcoin-qt front-ends.

Fork?

Yes it's more effective to have sliding window than fixed point recalc.
We have historical milestone moving average doing what satoshi want,
but not done for some reason. It goes to 100% digital discreae filter(it use
sliding window with weights for each value), named FIR (finite impulse
response), it can't be cause of not stable oscilations(as fixed point recalc too)
on it's own (take read about FIR) and it is good.

There are IIR as well, but it can cause unstable oscilations(have resonant freqencies)
with wrong parameters those freqencies can be if workind diapasone.
IIR can have very fast response.

And the most futuristic idea will be discreate PID regulator, which can be implemented
as IIR (think so).

But most important now is to get community support and not get 2
CATcoins. If Cryptsy delist it, it will be desaster.

What kr105 think about one more fork?

If you implement it only in pool side(not hard fork) it can be that diff on "forked
wersion will be lower than network (how you deal with it?).

If you not going hard fork, there is not need to scare peoples with this thing.
I can do reserch in matlab (P=1-e^-lambda*t, only need to calc lambda from
hashpower and diff(need simple equation) to do research on hashpower stepping
and filtering).

If you gonna hard fork, leave this idea for now, wait comminity reaction.
Hard forks must be organiszed if we want have CATcoin alive.

I agree with you that potentially revolutionary ideas should not be implemented without full vetting. I have proposed that code be written not to implement the idea in a hard fork, but merely passively log what kind of effects it would have if it were to be implemented. Then people can look at the data and debate based on real data rather than just hypothetical data.

However, I think you may not have got the essence of what I was saying about capping. We want the coin to be "highly reactive" and respond to changes in hash rate, because there are legitimate reasons for hash rates to change, and the difficulty should have little constraint to adjusting when those circumstances occur. However, when a fast downward adjustment happens (more than 50% reduction in one difficulty cycle), we know a lot of miners just left, and all those who left, we can safely surmise, were not high on their commitment level to the coin. Therefore, it is also easy to surmise, that while we should continue to pay miners who remained the full amount of reward, any new miners that show up are not likely to be loyal and can therefore have their pay cut without any significant consequence to the coin network. We can also surmise that if we lost a bunch of miners recently due to lack of belief in the coin, there is probably no real need for the difficulty level to go up in terms of meeting demand for people who want to mine the coin. The only real reason there might be for increasing difficulty is purely economic - we don't want too much inflation in the coin. But by cutting the coin award of those who show up during the exceptionally easy period, we have eliminated the inflation factor (they get paid at the same rate per hash contributed as when it at the difficulty level before the crash in difficulty). So we can afford to have an extended period of easy difficulty combined with penny pinching on the rewards. If the demand to mine continues to increase despite that, then difficulty will recover to pre-crash state sooner or later, and at that point, we can go back to normal operating basis.

You mention something about putting caps on difficulty decrease, but not on increases. With all due respect, this makes no sense. It is true that there is no inherent problem when a bunch of new miners show up - It's a happy thing - we notice blocks are being solved every 30 seconds - and we also don't want hyperinflation - so we want to adjust the difficulty up quickly. Maybe the coin suddenly became popular and is trading for lots of money and adjusting the difficulty up quickly is a good thing as lots of new hashing power shows up. High difficulty is never a problem. The problem is, when the miners contributing the hashes are not stable people. We only know that after they have left. We know they have left, when we notice that block solutions are coming vvvvvveeeeeeeeeeeeeerrrrrrrrrrrrrrry slooooooooooooowly. So we found out that a lot of the hashing power has abandoned us. What do we do now? Put constraints on how quickly we get back to mining a block every 10 minutes??? NO!. We want the blocks to start coming every 10 minutes ASAP. We don't want to hear "20% adjustment constraint" when we are seeing 100 minute block times and increasing. No, we want the block time to return to 10 minutes immediately. Did we already forget what it was like during the difficulty=172 period? However, once we have reached this point, (rising difficulty followed by crash in difficulty), we have a special circumstance. It does make sense to temporarily (and only temporarily) cap increase in difficulty and simultaneously, impose pay cuts on those who show up to mine, until difficulty has recovered to pre-difficulty-crash number.

If you think there is a scenario which can describe with these rules to cause any of the known evils 1) excessively long block times that go on and on, 2) instability/oscillation in difficulty, 3) instability/oscillation of network hashrates, 4) extended periods of hyperinflation of coins, or 5) there being incentives to do anything other than just sit and mine consistently over a long duration to maximize profit - please describe that scenario. The loyalty credit system is specifically designed with these five factors in mind - but it is possible there are scenarios that it does not cover - I may have overlooked something - if you can think of such a scenario please describe it...

Thank you,

Etblvu1

I think your ideas would change the coin too drastically to predict how miners or the market would react to it. You're introducing all different kinds of assumptions and reactions to those assumptions, and I have absolutely no way of knowing what kind of effect that would have on the coin.

We don't want the difficulty to explode. That's what happened with the original catcoin. It climbed so high that we couldn't get over the next difficulty level, and as profitability dropped so did the hashrate.

Now, if you wanted to simplify your idea, you could allow the difficulty to increase quickly when the difficulty goes up, but slowly when the difficulty comes down. To do that all you need to do is put a small percentage cap on difficulty decreases, but allow the difficulty to increase without any imposed limit.

You can't both make the coin difficulty stable and also highly reactive. It's a contradiction in terms. You can find a compromise somewhere in the middle, but trying to impose both makes the coin wildly unpredictable.

The real challenge with putting too much constraint on the difficulty adjustment, is that sometimes there is value in having a rapid rate of increase or decrease in the difficulty. For example, if the coin receives a huge amount of attention from the press or a big investor comes along and wants to sink millions into it, we can easily see a 100x increase in the value of the coins on the exchanges. At that point, it is proper and desirable for the difficulty to increase rapidly. If there is a cap on the rate of increase, it just means that we will have lots and lots of coins being generated in an extended hyperinflationary period of 30-second blocks and being at the very top of profitability charts everywhere, which is not good for the coin.

Likewise, if we discover that there are a bunch of coin hoppers mining the coin for temporary profitability, and we found out because the normal increase in difficulty responding to high hashrate, resulted in a bunch of miners leaving. Under this circumstance, we actually want the difficulty crash quickly as soon as they leave with no unnecessary delay or constraints. Otherwise, the coin may enter an extended period of slow block reward times (we are supposed to be 10 minutes between blocks; if 90% of the miners are coin hoppers and they leave - then the block time would jump to 100 minutes. At this point, we would regret any extreme caps we put in place that only allow 20%-30% changes - that may not keep up with the rate of additional miners getting frustrated and leaving - this was what happened before the last hard fork - and introducing this constraint would re-introduce this issue). This would then have to lead to another perceived need for an emergency hard fork and/or coin death.)

I have proposed that under normal circumstances, .25x - 4x difficulty constraint (the original constraint we had, and we still have) - is just fine. Personally, I think increasing flexibility to .125x - 8x could be a good thing to make the network more agile. I also proposed that during exceptionally easy mining periods (defined as when the difficulty just dropped more than 50%, or any successive period after that, until full recovery of the difficulty level to where it was before it crashed), we should still allow high adjustabilty down (in case there are more coin hoppers wanting to leave), but put a severe constraint on increasing the difficulty, i.e., .25x - 1.25x. The idea being, if a bunch of hoppers just left, they should not be allowed to play with the coin difficulty by coming back. But a further necessary component to this system is that those who do come back despite the difficulty being stuck on easy, should have their pay be cut. These components together take away all incentives to coin hop, and reserve profitability to those who stick with the coin over a long period of time regardless of fluctuating difficulty. Coin hoppers who show up will still receive rewards, but not that much in the way of high profit (they would be compensated at a Catcoin-per-hash rate equal to what loyal miners were getting right before the difficulty crashed). They (the coin hoppers) are free to stay and contribute to the security of the network, but not free to walk away with a killing. But if they stay awhile, they can begin to earn the full rewards of participating in the network. Thus, the habits of coin hoppers can be rehabilitated with incentives. Or they will just go bother other coins, and leave Catcoin in peace. Either way, we win.

Sure - I get the profit-seeking behavior - no worries there.  But I'm seeing the hash spikes happen at the end of our painfully short low-diff periods - which appear to push the diff up and make the coin less profitable to mine.  The confirm rate for the long almost-dead periods is painfully slow.  I'm mining, though only control about 2M hash, and when I want to take advantage of the low-diff points, I come in a few blocks early and then get out before the low-diff period ends - but that seems to be when the 'attackers' come in with a drastic spike.  Either the automated pools have slow reactions or someone's playing games.  I don't know which.
[/quote]

The proposed loyalty credit system will also defeat this type of manipulation too (i.e., spiking the difficulty artificially at end of a particularly easy block, by temporarily putting a limit of 25% to the increase in difficulty, i.e. 1.25x, until the difficulty has recovered to the difficulty level from which it originally took a dive. So the only way to recover difficult level pre-dive is if a large number of miners join to mine the coin despite receiving a reduced number of coins - which far all practical purposes will only happen if there is a large increase in the coin markets for the value of the coin, or there is otherwise a huge increase in the faith in the long-term success of the coin.

Etblvu1

At this stage, I wouldn't even consider a fork unless something new was proposed to tackle the multipools and switchers. Several suggestions have been made. Lowering or increasing the difficulty retarget isn't going to solve it on its own. We both want the difficulty to slowly go up, but also want the coin not to crash back down. We also don't want the difficulty to go so high than if we lose miners we end up in a difficulty spiral we can never escape.

It's not the retarget time that's the problem. The retarget is fine. It's the rate at which it DROPS is the problem. Leo suggested a maximum cap on the drop rate, and also the increase rate. 30% min 20% max caps would prevent the difficulty crashing too much, and 20% cap from increasing too much if any miners hop.

That's it. It's not a hugely difficult problem. We don't need a complex solution or yet another adjustment of the retarget time. We keep going from one extreme to the other.

I didn't realize it was live and in the world - and a potential 51% diversion for CAT.  As much as I admire the work of all that have been involved in this coin from the beginning, I'm not happy about either another knee-jerk decision to change the coin.  I think that no code should go 'live' unless/until at least the new 'board' is, well, on board with the changes.

Sure - I get the profit-seeking behavior - no worries there.  But I'm seeing the hash spikes happen at the end of our painfully short low-diff periods - which appear to push the diff up and make the coin less profitable to mine.  The confirm rate for the long almost-dead periods is painfully slow.  I'm mining, though only control about 2M hash, and when I want to take advantage of the low-diff points, I come in a few blocks early and then get out before the low-diff period ends - but that seems to be when the 'attackers' come in with a drastic spike.  Either the automated pools have slow reactions or someone's playing games.  I don't know which.

Hi Kuroman,

I agree that implementing at the pool side is easier and better in that it avoids a hard fork. It would not cover 100% of the mining, but it will at least reduce the intensity of the oscillation coming from casual miners who jump into and out of cat pool based on placement on profitability index. A pool can implement a simplified version by simply taking notice at each difficulty change whether or not the change was a drastic reduction (i.e., more than 50% reduction in difficulty), and if so, and only for that difficulty cycle, cut the shares contributed by any miners that log on and start mining during that cycle (while continuing to grant full shares for those that had been mining before the change in difficulty). This should not be very hard to code, and will give pools that implement the logic a competitive advantage over those that do not, because it will give miners who leave their rigs pointed to them extra profitability (i.e., for each non-loyal miner granted only half share, it means the other miners are getting the other half share split among them, as extra bonus).

Of course, this "bonus" would disappear over time, at which time the pool can show hash contribution to the cat network is remarkably flat and consistent over time, which means its contribution to the quality of the network is better than pools that contribute more during easy times. That would be a good marketing angle - join the pool that supports Catcoin by contributing the most consistent amount of hashes. In addition, by this time, it will become common knowledge and uncontroversial that if the same logic applied to the coin as a whole, the flatness would translate onto coin as a whole rather than just the particular pool's contribution. Once this idea catches on, the whole coin hopping as a means to maximize profit paradigm is on its last legs - fewer and fewer coins will allow that, and mining will be about long-term evaluations of the potentials and quality of coins, and choosing to invest rigs weeks or months at a time, mining a coin one has determined to have the best future. Then, we will have more people mining and holding coins, and exchanges will stop being clearing houses of coin hoppers, but of mostly people who are adjusting their portfolios, making new investments, and cashing in profits after holding onto their mined coins for a while and watching it rise.

As for your question about implementing in the coin - no, there is no need to add anything to the blockchain - the wallet address to which rewards are paid out, is already part of the blockchain, and this is the same information that is being used by the loyalty credit mechanism. The blockchain design, going all the way back to the beginning of BTC, was to have the wallet address associated with creating a new block be public. It inherently has to be, else how would there be consensus on who should receive the payment for the block? The only thing we are changing is the quantity of that reward, based on status data that can be derived by studying the same blockchain (and in my latest proposed addition - having variable limits on difficulty adjustment depending on whether or not we are in an 'exceptionally easy' state or not - difficulty adjustment at .25x to 4x during normal times, .25x to 1.25x during exceptionally easy times) . There is only change in the flow of logic, not in the blockchain itself (except quantity of reward, and effect on the difficulty). If all the nodes agree on the flow of logic, there is network consensus, and nothing more complicated than that.

Etblvu1

Hey Etblvu1,

Appreciate the effort, and the work you've been doing on this, here is my feedback on it : (

I think the concept in it self is simple the way you present it, and i believe on it own can be translated to a code.

But here is my take on it, this can be implemented pool side, if in the code there is a way to ballance it so that when the it kicks in, the coins that the hopper won't get goes to loyal miner, and this can be done easly

But where I think it will creat an issue, is adding to the blockchain. at what level you want to implement it ? how? what are the possible effect on the code, blockchain and stuff like that, the issue here, is that we are in a decentralized system, the system it self is not supposed to know that kind of informations about the miner in it self, or it would be tracking a miner in the long term and then add function + or - reward according to diff x time loged in..........

regards


Thanks for your hardwork, I'll try it when I have some time and give you a feedback on it, although before I do, I think one of the coins used this before (diff changing each block) and I think it created some issues, so I believe we should be carefull and try to mesure the drawbacks for such a change.

Also do you think it's possible to instead of changing the diff retarget, to change the factor maximum factor of diff change, if I'm not mistaking it is x4 right now, how about setting to something like x1.5 with this the coin won't have big jumps, but instead a smooth and serious diff change, so once the profitability is high, and the coin get more miners, once the diff, the coin will remain profitable and interessting, some might leave but some will remain and vice versa, till the coin find on it own an interessting equilibrium

Indexing to a commodity is actually a great idea!  Not sure how you'd go about implementing that though.  Graincoin stood out to me because its random rewards feature (something also seen in Earthcoin btw) seems to be one possible solution to miners jumping ship.  That and I believe that PoS is the future.  These features (AND a good dev with an incentive to succeed (the premine)) make Grain one of the strongest alts to come along in awhile.

Hedging my bets.  Buying CAT, GRN, LTC and of course BTC.  

Really though…who knows?  The better question is:  How much GRN did you farm before you started raising CAT?

I still support Catcoin, but a fork with absolutely no consensus from the community is just going to harm the coin and confuse things even further.

I had no option but to sell my coins at a substantial loss, because quite frankly, if this coin dies my total BTC would have been near zero. I invested too much into this. I thought it was going to recover.

When I get some BTC back I will buy back in, once the dust has settled. For now I just don't know what's going on anymore. The fork doesn't even address the problem.

What fork? is there going to be another hard fork? or is it just your pool which is making their own hard fork? I am confused, I can feel another heart attack coming on from this coin XD

I've tested it as much as I really can without a working -testnet.

It's live, see http://kittyco.in/p2pool , and it's up to you all to vote with your hashes on which side of the fork at block 20999 you want.

And yes, I suppose you could say 'under attack', but it's really just a product of rational profit-seeking behavior, which is an easily programmable fix. The first step is get everyone used to hardforks every Caturday until we get more user-friendly behavior.