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

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.

A timestamp and difficulty look to be embedded in the chain for each block. So, if the block explorer can extract this information, then getDifficulty() should be able to as well.

http://catchain.info/block/1908c6546f822d3c743ed38ef8c79fc3d4ee1b21cd5f1f96f5d732c6ee6b0f5f

I only ask about the contents of getDifficulty() to know if it will return sensible values for the full domain of nHeight.

This is an interesting proposal. Once you get getDifficulty() coded, you should run a broad range of nHeights through it and see if the reDiff() gives you what you expect. I sense a hole in this approach, but I can't put my finger on it.

Semantics.

I want to highly recommend that you pick up some books by Robert Kiyosaki on the differences between 'investing' and 'trading' and 'speculating'.  Comparing/contrasting realized VS unrealized gains/losses would be useful as well.

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.

As I see it, miners are the only investors here.  The rest - including the time we volunteers spend tweaking the coin - are traders or speculators.

Considering the above definitions, nobody was 'burned' by anything outside their control, and certainly not any investors.  None of the 'devs' asked anyone to buy anything or sell anything.  None of the 'devs' guaranteed that the last fork would do anything except what it did - to get us from certain death to where we are now - prepped for a long-term fix.  Therefore, no traders or speculators were 'burned' by actions of devs, either.

Clearly you're upset - sorry about that - but that's not something anyone else can affect.

This is a fair question. That function is not yet implemented. But does code exist out there to look at the blockchain data to reliably produce what the difficulty was at any given block number? Given how many graphs and blockchain websites are out there that shows exactly this data, the answer has to be yes.

So the code I am showing is the only new code which can introduce unexpected bugs. Incidentally, I am actively looking at the easiest, most efficient way to obtain the difficulty number given a block number and am offering a 2,500 CAT bounty* for the first person who can provide me with elegant code that works within the confines of Main.cpp to look up difficulty in effect given nHeight as parameter.

Etblvu1

I'd better put in small print here... I will pay this bounty regardless of whether or not my overall proposal is implemented, because this is a useful for me to have for other potential projects. HOWEVER, to qualify as elegant and bug-free, it would need to 1) be run through a battery of tests to detect potential bugs, and 2) be something that can be posted to this group and gain general consensus that the function does not have, or is extremely unlikely to have, any bugs. I will not burden the bounty-claimant with the risk that my overall proposal will not be accepted, but the function has to be accepted to the standard of general consensus that it does what it purports to do.

Don't buy any until the devs announce the fix and answer any questions pertaining to it.

Many investors were already burned badly by the last fix that didn't really seem to address the underlying issue with this coin.

What does getDifficulty() look like?

Not all of us mine, some of us have to buy. Will cat ever go up, I may  buy some more.

Worldcoin, 2016 block retarget, and the true spirit of Bitcoin. Worldcoin has done some good things and contributed something innovative to the cryptocurrency world, and has (for now) earned a relatively high market capitalization. Copying their difficulty adjustment formula would not be the end of the world. At the same time, it wouldn't be true to say copying them is either innovative or keeping the true character of Bitcoin. We would be selectively keeping some parts of the Bitcoin personality, and copying and modifying other parts. This is what all altcoins are doing and have been doing. Nothing wrong with that, but it is not "Bitcoin in Scrypt" any more than other altcoins. If anyone really wants to be true to the original recipe of Bitcoin, let them propose how we can re-implement the 2016 block retarget. I promise to keep an open mind as to how this can be done practically. Believe me, the slow, 2016 block retarget is an essential part of the "true spirit" of mining Bitcoins. For a time, I mined Bitcoins with about 130 GH/S worth of ASICs and I can speak from first hand experience, seeing a pretty consistent production rate for about 2 weeks, and the dread of anticipating this be cut by 30% at the next retarget. If the production rate was eroded continually instead of every 2 weeks, the experience would have been completely different.

Legitimate Desire for 50-Coin Subsidy vs. Subsidy Dogma. Setting aside the idea of bringing back the 2016 block retarget for now - let's examine the idea that the block subsidy must be always be exactly 50 coins per block regardless of how hard or easy the block was to solve. There is actually merit to the intention behind this idea - the block reward structure is definitely a recognizable part of Bitcoins (and of Catcoins) and drastically changing it around would not be wise. Doing such a thing is not in the proposal I have presented. In simulations and projections, in general, about 67.5% - 87.5% of the blocks*, the block reward would be exactly 50. The other 12.5% - 37.5% of the blocks*, the block reward would be slightly less, but can be considered essentially 50 (e.g., something in the order of 47.2 or 42.8, depending on what was necessary to keep coin production from exceeding 5 coins per minute - call it a necessary evil to put a tiny bit of bitter taste in the otherwise sweet subsidy to make it unappealing to coin hoppers). If the coin is under extreme attack (as in, if someone suddenly dumps 10x the hashing onto the coin, suddenly withdraws, then tries to come back to take advantage of extreme easy difficulty), the block reward may drop for just a few minutes to 5 coins per block, before quickly returning to the normal level of 50 coins per block. It is more accurate to describe this technique as dampening the standard block subsidy only in response to systemic shocks, with the subsidy remaining at 50 for the most part apart from shocks. It would be inaccurate (and unfair) to characterize this as changing the subsidy amount or making the subsidy amount continuously variable. The technique assumes that keeping a more consistent 10 minute block time is better for the coin long-term and is more innovative, than using the "50 coins per block" as a dogmatic constant, and letting hash attacks result in hyperinflation (see the height of the green parts of the graphs) and hours-long block time (see the width of the red parts of the graphs) with extended severely diminished time-reward for miners (see the height of the blue parts of the graphs), which result from refusing to seriously consider coin production rates (per minute, not "per block" which is meaningless in the real world where electric bills come every month).

Do We Want to Keep Coin Hoppers? Let's consider Worldcoin and DOGE in relation to coin hoppers. If a coin is routinely mined by pools like multipool, then we know the coin is a target for coin hoppers. Both Worldcoin and DOGE are in this category. When those coins, due to flaws in their design, produce coins faster than the intended rate, coin hoppers come to take the easy coins. If Catcoin copies formulas of coins that coin hoppers frequent, Catcoin will also inherently in this group. Catcoins will continue to land in the pockets of coin hoppers whenever production rate gets unrealistically high (again, see the height of green bars). People who want to mine Catcoins consistently will have to do essentially bathroom cleaning duties at low pay (see height of blue bars), for the benefit of the coinhoppers who periodically show up to claim the easy money. The degree of this may decrease, but the principle will remain. In the meantime, say what bad things you will about the 2016 block retarget employed by both Bitcoins and Litecoins, at least they stay out of coin hopping madness for the most part, and are stable. The only reason Catcoin stopped using the 2016 block retarget, was because coin production rate dropped from 5 coins per minute, to something in the order of 0.5 coins per minute, which is why miners found it intolerable. The 36 block retarget did not really address this problem (see the long stretches of very wide blue bars above).

Alternative to Capping Coin Production. If the 50-coin subsidy is going to be held as a dogmatic constant for the next change, I believe this will show up in the form of Catcoins showing up at or near the top of profitability charts and getting included in coin hopping pools, just as DOGE and Worldcoin are seeing. I submit that if we really are going that route, we should at least keep a close eye on the coins-produced-per-minute metric as an indicator of whether the formula deployed was successful in bringing coin production rate into reasonable range. If we have significant periods of hyperinflation (say, more than 7.5 coins per minute) or low pay bathroom duties for long-term miners (say, less than 3.75 coins being produced per minute), we should agree in advance that is a big red flag that the formula is broken, and we need to revisit directly addressing coin production rates. Coin production rate is a key issue which address both why coin hoppers show up (many coins! easy profit!), and also why miners leave (big electric bill! meager coins!). I believe a consensus will emerge sooner or later (maybe not right now; this is a fundamental paradigm shift; and most people will instinctively resist paradigm shifts as if their lives depended on it), that we need to pay more attention to coin production rate, and less to a technical parameter like "difficulty level" - which should be allowed to float with little restriction, with the market**.

Avoiding Complicated Code. It has been expressed that the proposed capping on coin production rates would be complicated to code, and we should keep things simple, so we avoid inadvertently introducing bugs. This is true in part. Yes, we should code that is as simple as possible, to avoid introducing bugs. But no, the capping of the production rate does not need to be complicated. Reproduced below is code in principle (not yet working because of a missing function), of what capping coin production rate looks like for consideration (something that looks like this would be added to the end of the GetBlockValue() function:

   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;


I would encourage anyone interested in this subject to compare the complexity of this code (including what kind of advanced math degree you may or may not need to understand), to the complexity of what it would take to implement any other proposal floating around.

Thank you,

Etblvu1


* If holding 50 coins constant for 67.5% - 87.5% of the blocks is not enough, this is very easy to tweak upwards to something > 95% of the time while losing very little effectiveness, just by changing the second-to-last line in the code to something like "if (currDiff < refDiff * 0.8 ) nSubsidy *= currDiff / refDiff;". This would still retain the full capability of counteracting extreme attacks as described, while putting more bias towards trying to keep the block subsidy at exactly 50 whenever possible.

** The proposed method can be combined with some sort of capping of the rate at which difficulty levels can change, but capping really is unnecessary when we have addressed the underlying coin production rate - which is really the bottom line of why coins become profitable to mine or not, which attracts coin hoppers or causes miners to leave for greener pastures.

Etblvu1,  I'm very concerned about your chart and assumptions.  You start by suggesting that difficulty isn't really important, and suggest what people want is coins per minute.

There are no 'lost' coins because each solved block pays 50 coins regardless of the RATE those blocks are solved.  The coinhoppers only receive more coins per minute because they are coming in with orders of magnitude more hash power than we have on the network.  By the basic design of cryptocoin, the gal that finds the most blocks gets the most coins.

As a miner of a whopping 1.6MH/s, I can assure you that while the network slows considerably during our high difficulty periods, I still receive  approximately as many coins per week as expected relative to my work unit per minute rate.

The coin is designed from the start to adjust difficulty to the hash rate.  If one changes how coins are paid they are fundamentally changing the coin.  If we choose an option that does that, we are no longer CAT and are no longer on the same level as BTC - we're just another experimental and untested clonecoin.



The CAT design is sound and the difficulty system is a proven way to allow the block solving rate to adjust to the hash rate.  All CAT needs is a tweak in how the difficulty changes to better react to a mining market that didn't exist when the original code was written.  In other words, we're only seen as a target for hoppers because they only see us as 'profitable' to mine when our diff is too low.  Fix the flaw and we are no longer seen as soft targets - and thus our hopper problem goes away.

We've all done things with simulations, tx42, that's why we're volunteering our time and experience, not just posting on a forum.  As I've already stated, we are miners AND investors (time and money and experience) AND speculators - and we're still holding our CATs.

We'll see you on IRC, or not.  That's just as 'up to you' as choosing to sell your CATs.

cheers.

I'm itching to buy back in, but I can't. All my BTC is tied up in other coins which look on the up in the very near future. I have some altcoins I can sell if they hit Cryptsy, but for now I'll have to wait.

I'm just trying to help. I bought thousands of cat when it was worth many times what it is today. I had to sell because the future was entirely unclear after it tanked from the last fork. I'm all out now. I'm looking to get back in because I think it will could be a good coin. My BTC are on the sidelines at this point.

I offer my expertise in simulations, which is extensive, I assure you, and I get either a short answer or a rant. I don't think that bodes well for the future of this coin.

I and others have already told you that we're running testnets, testing and simulating.  That hasn't changed.
'The devs' are not proposing varying the payout - the devs have brainstormed options that might stabilize CAT for the long term.  You've already heard from Maverickthenoob that he is not in favor of fundamentally changing the coin in this way, and I'm now on the record as opposing it as well.  I believe one of our main selling points is our 'bitcoin in scrypt' position.

It's very clear from both simulations and from real-world performance of other coins that have been exactly where we are today that we need only a slight modification - a simple tuning - of our difficulty mechanism.  Everything else - hash rates, payout performance, difficulty levels, and stability - stabilizes once we stop the mood-swings imposed by fast-switch pools.  I am in favor of adapting a dual moving average, akin to a trailing 100 and trailing 500 block average.  This has been found to work much better than a single SMA alone in the real world.  I outlined the plan here:
https://bitcointalksearch.org/topic/m.4548636

While your requirement for simulation is laudable, it's already been addressed multiple times.  Yes - we're simulating.  But more importantly, we're looking both backward and forward with real-world data because at the end of the day we are not working on CAT so that it looks great on a spreadsheet - we're working on CAT so it performs in the real world.  Your insinuation that we're simply throwing things at a wall and going with what sticks is insulting and off the mark at best.

Let me make this clear to many of you:  If you are a pump and dump miner you will not be happy with CAT.  This is not some flash in the pan coin.  If you expect us to simply drop the diff while busting our butts to increase the value so you can sell your stash and buy an island somewhere, please find another home.  If, on the other hand that you are interested in long-term stability, fair compensation for work performed, and a growing user-base and value, then there's a place here for you.

And finally - this coin is not yet ONE MONTH OLD!  This is NOT the end of the process, and we are not here to present options for consensus yet - this is important!  Let's hold on another day or two.  While it would have been better for all of us if the original dev had chosen to stay with his creation, we don't have that option.  We're working as hard and as quickly as possible to get up to speed on the guts of this coin, the guts of the environment, and the guts of the market so that we ensure our CAT has a very long and happy life.  I think those of you that choose to stay in the community will be happy you did.

And hopefully that would be the last fix. 

It's not stuck. The difficulty is high. There is however a fix for this whole situation coming.

me either!

Will the fork beat the next dump by the coin jumpers?

That would be the point of the simulation. You find the most robust parameters for coin generation.

Anyway, I'm not the one proposing to vary the payouts like the devs, which seems drastic. The idea behind a simulator is that you find the most conservative set of coin generation parameters to still maintain robustness of the coin.

You have a bunch of ideas floating around. You could either fork the coin every time an idea fails (which seems to be the current paradigm for catcoin), or make intelligent decisions based on simulations.

I'd explain why simulation is preferable to try-and-fail, but Nate Silver has already beat me to it. Read The Signal and The Noise.

My wallet is stuck @ block 21102 and it won't budge. Fix?