Pages:
Author

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

full member
Activity: 213
Merit: 100
January 18, 2014, 03:35:20 PM
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 problem with setting a "fixing" a difficulty level and not allowing it to float with the market, is that if the coin prices go up, it will make the coin rise to the very top of the profitability charts very quickly, tons and tons of hashing power will show up. Then we have a block being generated every 30 seconds, and hyperinflation takes hold, dumping the coins into the exchanges, until the coin price crashes to the level where equilibrium is reached.

If we want the coin to be successful, the difficulty number should largely be free to float with the market, so it intermediates current coin market price, and current cost to perform megahashes of work. It should not be significantly constrained or shaped. Let it do its job. And we should avoid overinflating the coin (e.g., produce coins faster than 7.5 coins per minute average), or under pay miners (e.g., produce coins slower than  3.75 coins per minute average). This is not an easy or obvious problem to solve, but a proposal has been put forth designed specifically to accomplish all of these things.

Etblvu1
member
Activity: 86
Merit: 10
January 18, 2014, 01:46:11 PM
i can't mine this coin i registerd in a few pools and on all of ther i cgminer stops and can't mine
can you tel me a pool that is working or do i have to use a special version of cgminer
member
Activity: 70
Merit: 10
January 18, 2014, 12:38:25 PM
Skimmed through the last 2 pages.. ANOTHER FORK? You're kidding right?

You better read the last 10 pages and you'll see why, this is the second fork.
hero member
Activity: 532
Merit: 500
January 18, 2014, 11:22:10 AM
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.

full member
Activity: 378
Merit: 100
January 18, 2014, 10:55:53 AM
Skimmed through the last 2 pages.. ANOTHER FORK? You're kidding right?
hero member
Activity: 1666
Merit: 565
January 18, 2014, 10:21:44 AM
price is getting higher!
full member
Activity: 213
Merit: 100
January 18, 2014, 03:34:43 AM


An Issue with Overall Rate of Coin Production

This posting will cover a slightly different issue we have been having. We are suffering from anemic hashing in the coin overall, even if we were to consider the contribution of Coin Hoppers (green bars) jumping in for easy coins, to be a legitimate contribution (something of a dubious proposition).

Please observe that I have marked off six-hour periods on the X-Axis with dotted lines. These represent how often block difficulty adjustment periods should occur, if the coin operated according to current specifications. The math is as follows - 36 blocks per adjustment period, 10 minutes per block = 360 minutes = 6 hours.

Over the course of one week, we should see a total of 7 (days) x 4 (6 hour periods per day) = 28 adjustment periods. But if you count the stairsteps in the illustration above, there are only 14 adjustment periods that took place. This means for that entire week, the average coin production rate was only 50% of what it should have been. Instead of producing 50,400 coins that week, we only produced 25,200 coins. This means that miners were underpaid by 50% compared to the production rate promised, to correspond to this 50% underproduction.

I believe this fully explains the anemic hashing on the Catcoin network. If we had the Catcoin software simply produce the number of coins it promised to produce (50 coins every 10 minutes, on average), I believe we will see a substantial increase in the hashing activity on the Catcoin network.

Sentiments Expressed

There have been sentiments expressed by some, about looking at the rate of coin production (should average 5 per minute), and block timing (should average 10 minutes per block), as being faulty. Among the arguments made:

1. There is no such thing as "minutes" in the cryptocurrency world, and if 50 coins get paid per block, there has not been underproduction regardless of how long these blocks take to solve, and nobody was underpaid.

2. "Difficulty" is all about changes in the blockchain timing and is only incidentally related to things like cost of performing hashing work or the price of coins on the exchanges, so focus should be on smoothing out the shape of the curve only.

3. It will all even out through averages, because the formulas are designed to compensate and spend some time in high difficulty, and other times in low difficulty so there is "no problem."

4. The graphs are fallacious, because they manipulate data to support a desired argument.

I believe in light of the massive underproduction of coins illustrated above, and massive underpayment of miners in relation to what is promised in the code, #1 and #3 do not require further arguments. #2 and #4 do deserve a bit more attention.

Answer to #2 - This may make more sense to some of you with experience in investing and finances than to those who are primarily coders. It goes like this: In the real world, where people make decisions about where to put money, whether or not to borrow money, where electricity costs money per kilowatt-hour, and computers and video cards cost definite sums of money, it is all about putting in the least amount of investment, to get out as much returns as possible measured in time (return on investment), with as little risk as possible. There are two independent values which can be expressed in terms of cost per unit - a) The current value of a coin in the exchanges, and b) The current cost (taking into account hardware, labor, space utilized, electricity, etc.) of delivering megahash-hours to a coin network. These two values cannot be controlled by the programmer - they are external facts which must be accepted and respected by the coder. The "difficulty" parameter is a technical parameter hidden deep inside the coin, and its primary function is to act as the ratio or intermediation between #a and #b above. Given any price of the coin (whether it is 5 cents or $500), and any cost of performing a megahash-hour of mining (whether it is a penny, or $2.50), this "difficulty" variable alone can bring the two into equilibrium. Since this is the only variable that can keep the relationship between market price of coins, and cost of producing them, in proper ratio, it should be respected for this function. Any theory about the difficulty variable as being something that can be coerced into some shape without considering this important function can do nothing but wreak havoc and create opportunities for arbitrage for the coin hoppers (some variation of the green and tall rectangles in the box above, representing easy coin production for very brief periods of time). I suggest every stakeholder in Catcoins digest this idea and really consider the ramifications, when various proposals are put forth for "fixing the difficulty problem."

Answer to #4 - I selected a one week period which at the time was the one week immediately preceeding when I started working on the charts, without knowing exactly what they will end up looking like. As I have covered, there are even some things which surprised me, so I definitely went into it with a scientific spirit rather than with my mind made up about exactly what lessons are to be drawn. Also, I submit that the graphs cover a one week period with 14 difficulty adjustment periods - and it would be very difficult to select 14 consecutive cycles of wildly varying difficulty cycles and durations which would support one viewpoint, where any other 14 consecutive cycles would not. I challenge anyone who believes I have cherry picked my dataset to select a different 7-day period (or longer period) that you consider a fairer sampling of the data, that suggests or supports a different viewpoint.

A Note to Supporters

Some of you have sent me private messages expressing support for what I am doing even if it does upset some of the established people who prefer to lead by taking initiative without getting consensus. I believe consensus building is an essential part of keeping a healthy coin, and will endeavor to continue posting informative articles to keep the community up to date.

On a somewhat unrelated note, some individuals who I will not name, have threatened to kick me from the development team, because they did not appreciate my posting information and graphs with which they did not agree. Although I suggested they are free to post any information they would like to show a better way forward, they felt that I should simply cease to participate in this coin and in this forum, on their say-so, and go create a new coin - to leave them in peace to implement a new fork I would consider sub-optimal, and without getting community consensus first. I respect the community consensus, and if I receive indication that there is community consensus that my postings and graphs and explanations here have been "disruptive" and "only muddying the waters for the primarily trader audience," vs. my intention, which is to be informative, educational, and maybe a bit entertaining, then I will respect the consensus and stop posting.

Thank you for your time and consideration,

Etblvu1
full member
Activity: 213
Merit: 100
January 18, 2014, 02:51:29 AM
why the transactions in CAT are taking so long now?

A less technical answer - the network has a bug in it - not too serious - but sometimes makes transactions super slow and sometimes super fast. It will get fixed soon.

More technical answer - transaction blocks are taking longer than intended because the difficulty value got set too high to be able to meet the goal of one block per 10 minutes given the hashrate we have on the network right now. It got set too high because the coin software measured the network hashrate when the difficulty value was lower during a time when we had a lot more miners on the network. Unfortunately, most of those miners were there only temporarily, taking advantage of the availability of easy coins. This estimation was inaccurate, because it does not take into account that people leave the network when the difficulty adjusts away from circumstances where easy coins are available. This flaw is actually inherited from the original Bitcoin source, because Bitcoin never anticipated the phenomenon of miners shopping where they mine based on minute-by-minute changes in coin difficulty. However, this can be fixed, so this is only a problem for now. Work is being done to implement a fix to address the underlying issues.  

Stay tuned for further news on that - and for your specific transaction right now - please be patient - it will eventually come through.

Etblvu1
legendary
Activity: 854
Merit: 1000
January 18, 2014, 02:10:24 AM
why the transactions in CAT are taking so long now?
full member
Activity: 138
Merit: 100
January 18, 2014, 12:53:13 AM
Introducing TheLotusPods Original High Payout Dice Game!

WIN UP TO 15X YOUR WAGER

Dice Rolls will be made on http://rolz.org/group

1d6;1d6;1d6;1d6;1d6;1d6;1d6;1d6;1d6;1d6 (Code to roll)

Play:

The player chooses a number from 1 to 6 as his point number. He then throws TEN dice 13 times. His score is the number of times that his point number is thrown.

MIN BET : 1 CAT
MAX BET:    20 CAT
I will update min and max eventually

Payoffs are as followed

        Score Pay-off
10 or less win 15X bet
13 win 2.5X bet
27 win 2X bet
28 win 3X bet
29 win 4X bet
30 or more win 7X bet
Any other score loses.

YOU WILL NEED TO ROLL THE DICE 13 TIMES CONSECUTIVELY

after you roll all 13 times please be paitent to give me time to add up your score

ENJOY I dont know how long i will be hosting this game with such high payoffs we'll see

1d6;1d6;1d6;1d6;1d6;1d6;1d6;1d6;1d6;1d6 This is the code you use to roll Ten 6 sided dice. You will enter this code 13 times for a total of 130 rolls
 you will copy the code and past it 13 times
PM me to play

If you have any questions on how to play or payoffs pm me and I will address any questions

You may roll after I have received the CAT and say "ROLL"


ALL CATS WON WILL BE DONATED BACK TO THE COMMUNITY TO HELP SUPPORT CATCOIN

Hosting more games. PM me to play
hero member
Activity: 657
Merit: 500
January 17, 2014, 11:16:48 PM
Semantics.

It's semantics because it was clear from CONTEXT what the meaning "investor" was.

Yawn. I'm bored of myself for even replying.
Yes, it was clear from the CONTEXT how YOU were using the word.  I, however, provided an alternate and finer-grained view than your dictionary definition and a professional and very, very wealthy source that can provide you with more detail should you so desire.

The fact remains that you consider yourself to be an investor when you're not, and you blamed the devs for your choice to buy high and sell low.  Sorry, incorrect and both counts - and absolutely not a useful addition to the conversation on fixing CAT.

I recommend you start with "rich dad, poor dad" as it provides real-world context and content.
Best,
Andy

edit...   Here's a real-world example of why your dictionary definition is not sufficient.  By that definition, when a person takes out a mortgage they are 'investing' in a house as they often hope it will be worth more later when they resell.  This notion is reinforced - accurately by 'your' definition  - by the banker that processes the mortgage and takes the monthly payments.

With me so far?  Good.  Now...the rest of the story...

The house IS an investment because it provides monthly cash flow - but it's an investment only for the banker, not the home owner.  For the homeowner the building is and always will be a liability.  It's constantly being used, is wearing out, needing maintenance, systems replacement, new windows.  Even after the mortgage is paid off, even after they've paid 2 or 3 times the value of the building in interest to the banker, they can lose the home in an instant if they don't pay taxes.  It's likely not insured for at least replacement value to a fire or flood (got flood insurance?).  And to add insult to injury, they've paid more than the value of the mortgage in utility bills because of the 'investment'.  The banker's gotten rich while the homeowner keeps paying every month.  And as we've recently seen, building values are not guaranteed to increase over time.
hero member
Activity: 742
Merit: 500
hero member
Activity: 574
Merit: 523
January 17, 2014, 10:56:55 PM

p.s. To address specifically your example of a dramatic market drop in the value of the coin, and what this would do. In this case, the coins generated per a given amount of hash power for a time would remain the same in the short run (instead of immediately going up to match the market). This is how it would unfold: At first, the block solution time would lengthen to more than 10 minutes due to less hash power being available. This is more or less the same in all the proposals I am aware of, the differences are in what happens next. Under the proposed code, when people leave from mining the coin, the solution time would lengthen, until at the next difficulty adjustment comes along (maximum of 35 blocks away). At this point, difficulty adjustment would either bring us fully back to 1 block solved per 10 minutes (or with constraints, up to 400% adjustment in that direction). What does NOT change, though, (and this is the innovative part) is that the reward amount in coins per hashes put in. This amount does not follow the extreme adjustment, right away. That part remains constant (for example, instead of 50 coins per block that requires 10,000,000 units of work, right after a violent difficulty adjustment, we may temporarily get only 12.5 coins per block that requires 2,500,000 units of work, which means the same amount of coins per unit of work). But if the market conditions really are such that the coin is worth less over an extended period if time, then after a few more difficulty adjustments, the reference difficulty goes down, and the block subsidy goes back up to the normal 50 gradually over a few difficulty adjustment cycles.  What this accomplishes is that we can get the block production rate back to a rational level quickly, without in the process inherently creating hyperinflation and the incentive for coin hoppers to come and exploit the hyperinflation. Also, consistent miners who found it worth mining the coin at 50 coins per 10,000,000 units of work, will find it equally compelling to continue mining at 12.5 coins per 2,500,000 units of work. If the coins really did take a sustained dip in the market, very soon, the difficulty has fully adjusted to the new market rate, and he finds he is getting more coins for amount of hashing work he is putting in. So the "profitability" remains pretty much constant, although there is a bit of an unavoidable lag which in the long run should even out and not matter. More importantly, the mechanism for making the adjustment can work without in the process introducing opportunities for the coin hopper to cherry pick temporary reduction in difficulty that occur for technical reasons, and not related to market price.


Well, it might be you are right and I am not. It will be much better than now anyway. All these coins (including bitcoin, ha-ha) are experimental. So let's make one more experiment Smiley
newbie
Activity: 9
Merit: 0
January 17, 2014, 10:54:38 PM
It's a little smaller than I intended because of the size of the upload (igmur must shrink them) but you should get the idea. I thought my last try was going in the right direction, but I this one is closer. I'm hoping to make something cool looking, symbolic, and easily adaptable in other images to help market CATs. I am definitely open to suggestions but I do still have more adjustments in mind. Hopefully there'll be something useful to go out with a code update.

(and thanks to whoever had sent me some CAT before, it's definitely a motivator to keep working on stuff since it increases my stake in the coin!)

http://i.imgur.com/RmLJnD5.gif
________________________________________
CAT: 9fQxowosPZMX3ZFGGtSZmr2Z5ZJF8pXq75
hero member
Activity: 742
Merit: 500
January 17, 2014, 10:50:26 PM
Semantics.

It's semantics because it was clear from CONTEXT what the meaning "investor" was.

Yawn. I'm bored of myself for even replying.

[compulsive edit]

Also, the dictionary agrees with my usage:

invest |inˈvest|
verb
1 [ no obj. ] expend money with the expectation of achieving a profit or material result by putting it into financial schemes, shares, or property, or by using it to develop a commercial venture
hero member
Activity: 657
Merit: 500
January 17, 2014, 10:17:54 PM
Where would I post a site that would allow CAT payments for a new TOR site that is being launched soon as one of the cryptocurrency options? Only 5 total.... I guess the acronym  for the coin stood out i was told..
Right here!  Spill it please! Smiley
hero member
Activity: 657
Merit: 500
January 17, 2014, 10:15:40 PM
An investor is one who makes a purchase with cash or a loan in order to generate regular income (in other words, cash flow).
A trader buys and sells something.
A speculator trades or 'buys/holds/prays' in hopes of profiting by selling later.

Semantics.
Actually not semantics.

As an investor, I'm looking at cash flow from my equipment and balancing it with liquidity in the markets to decide which coin is best to mine for my goals.  It's not always the one with the highest yield.  There are other business tools or other types of investing that can guarantee continued cashflow.  Consider rental property - the principal is insured, so the 'money machine' continues to pay out even after a fire.

A trader - esp a currency trader - might focus on technical analysis and arbitrage to hopefully grow their account balance. They're not working every day to generate cashflow, and there is no guarantee that they'll grow their account.

I bring it up only so that we're all on the same piece of music and better able to understand which bellybutton to poke should something go wrong.  No dev made you buy high/sell low and thus lock-in a loss - that's on you - for one example.
full member
Activity: 168
Merit: 100
January 17, 2014, 10:14:32 PM
   float refDiff = ( getDifficulty(nHeight - 36 ) +
        getDifficulty( nHeight - 36*2 ) +    
        getDifficulty( nHeight - 36*3 ) +    
        getDifficulty( nHeight - 36*4 ) +    
        getDifficulty( nHeight - 36*5 ) +    
        getDifficulty( nHeight - 36*6 ) +    
        getDifficulty( nHeight - 36*7 ) +    
        getDifficulty( nHeight - 36*8 ) ) / 8;
    float currDiff = getDifficulty( nHeight );
    if( currDiff < refDiff ) nSubsidy *= currDiff / refDiff;
    return nSubsidy + nFees;


Although I understand the reasons to implement some anti-hopper protection, one thing makes me doubt that this solution will work.

Let's say that the difficulty stabilized by some means. Then due to the market situation the coin price drops significantly enough to make cats mining less profitable than other coins. So people would switch to another coins. Eventually the diff goes down and these who stay mine cats will get decreased rewards for quite while. Then, when the correcting factor will be close to 1, the coin could become attractive again, so miners come back and mine at rate 50 coins a block at low, but growing difficulty until it becomes unprofitable again. And the story repeats.

The market reacts much much slower than difficulty change. Those oscillating wont be as obvious.   
full member
Activity: 213
Merit: 100
January 17, 2014, 09:30:53 PM
   float refDiff = ( getDifficulty(nHeight - 36 ) +
        getDifficulty( nHeight - 36*2 ) +    
        getDifficulty( nHeight - 36*3 ) +    
        getDifficulty( nHeight - 36*4 ) +    
        getDifficulty( nHeight - 36*5 ) +    
        getDifficulty( nHeight - 36*6 ) +    
        getDifficulty( nHeight - 36*7 ) +    
        getDifficulty( nHeight - 36*8 ) ) / 8;
    float currDiff = getDifficulty( nHeight );
    if( currDiff < refDiff ) nSubsidy *= currDiff / refDiff;
    return nSubsidy + nFees;


Although I understand the reasons to implement some anti-hopper protection, one thing makes me doubt that this solution will work.

Let's say that the difficulty stabilized by some means. Then due to the market situation the coin price drops significantly enough to make cats mining less profitable than other coins. So people would switch to another coins. Eventually the diff goes down and these who stay mine cats will get decreased rewards for quite while. Then, when the correcting factor will be close to 1, the coin could become attractive again, so miners come back and mine at rate 50 coins a block at low, but growing difficulty until it becomes unprofitable again. And the story repeats.


As for the implementation of getDifficulty: each block has its target kept encoded as 'bits'. To find these blocks you just need walk through the linked list of blocks (that are already in memory) and pick every 36th one. The whole formula should be changed from finding average difficulty to finding average target and consequent computation of avgTarget/currTarget as it requires less computations while outcome is numerically the same.

Hi Bee7,

Thank you for your thoughtful reply. I agree with you that using a ratio of variables which would produce the exact same ratio as the ratio of difficulties as shown, if it is more efficient or direct, would be superior. Thank you for suggesting that such a shortcut may be available.

I also agree with you that if there is a change in the market price of the coins, it will create incentives for people to put hashing power into the coin, or take hashing power away from the coin. This is like a fact of nature, of economic law - and not anything we can or should try to fundamentally "fix." If you look at the difficulty level of litecoins versus other scrypt coins, you find it is at a very high level, and this is as it should be. In my understanding, the difficulty level inherently will adjust itself to reflect the market value of the coin, and this is really the most fundamental reason why we need difficulty level adjustments at all - to act as the compensating ratio between market price of the coins produced, to the cost of hardware and electricity invested, to perform hashes of work. Furthermore, since difficulty serves this critical function of inter-mediating these key independent facts which cannot themselves be controlled, loading it up with extra work or monkeying with complicated statistical functions can only make it perform this critical function less effectively.

So if this is true, then it makes sense to keep the focus on keeping the average rate of coin production as constant as possible (in our case, 50 coins per 10 minutes, or 5 coins per minute), keep the rate of block production as constant as possible (in our case, 1 block per 10 minutes), and only as a third priority, keep the block subsidy at the defined level as often as possible (in our case, 50 coins per block), and importantly - let the difficulty level float freely with the market and not get mixed up or linked up to the coin production rate (should be 5 per minute average) or block production rate (should be 1 block per 10 minutes). But keep in mind, this approach represents a fundamental shift in paradigms in the entire cryptocurrency world, not just Catcoins. It is therefore meeting with extreme resistance and prejudice. People have responded to this proposal in a manner not so far from religious fanatics accusing religious reformers of heresy. But when a new paradigm addresses the needs of the people better than the old paradigm, people will slowly buy into the new paradigm, and then it is up to the historians to write about how it all unfolded. And there is no fundamental reason why this paradigm shifting code cannot be back-ported to Bitcoin itself, thereby restoring "Bitcoin in Scrypt" status in totality, except it could just as well be said Bitcoin becomes "Catcoin in SHA256."

Maybe people will find upon contemplating the wide implications of this, they can't help get excited at the prospects for a true paradigm-breaking innovation being implemented in our coin first, stock up on the cheap coins, and ride it all the way to the top. And this kind of excitement has the power to overcome paradigm shift resistance.

Etblvu1

p.s. To address specifically your example of a dramatic market drop in the value of the coin, and what this would do. In this case, the coins generated per a given amount of hash power for a time would remain the same in the short run (instead of immediately going up to match the market). This is how it would unfold: At first, the block solution time would lengthen to more than 10 minutes due to less hash power being available. This is more or less the same in all the proposals I am aware of, the differences are in what happens next. Under the proposed code, when people leave from mining the coin, the solution time would lengthen, until at the next difficulty adjustment comes along (maximum of 35 blocks away). At this point, difficulty adjustment would either bring us fully back to 1 block solved per 10 minutes (or with constraints, up to 400% adjustment in that direction). What does NOT change, though, (and this is the innovative part) is that the reward amount in coins per hashes put in. This amount does not follow the extreme adjustment, right away. That part remains constant (for example, instead of 50 coins per block that requires 10,000,000 units of work, right after a violent difficulty adjustment, we may temporarily get only 12.5 coins per block that requires 2,500,000 units of work, which means the same amount of coins per unit of work). But if the market conditions really are such that the coin is worth less over an extended period if time, then after a few more difficulty adjustments, the reference difficulty goes down, and the block subsidy goes back up to the normal 50. What this accomplishes is that we can get the block production rate back to a rational level quickly, without in the process inherently creating hyperinflation and the incentive for coin hoppers to come and exploit the hyperinflation. Also, consistent miners who found it worth mining the coin at 50 coins per 10,000,000 units of work, will find it equally compelling to continue mining at 12.5 coins per 2,500,000 units of work. If the coins really did take a sustained dip in the market, very soon, the difficulty has fully adjusted to the new market rate, and he finds he is getting more coins for amount of hashing work he is putting in. So the "profitability" remains pretty much constant, although there is a bit of an unavoidable lag which in the long run should even out and not matter. More importantly, the mechanism for making the adjustment can work without in the process introducing opportunities for the coin hopper to cherry pick temporary reduction in difficulty that occur for technical reasons, and not related to market price.
Pages:
Jump to: