Pages:
Author

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

sr. member
Activity: 271
Merit: 254
January 12, 2014, 01:43:14 AM
Quote
"We reject: kings, presidents and voting.
  We believe in: rough consensus and running code."
http://tools.ietf.org/html/draft-moonesamy-consensus-00

The code is running, the consensus will be obvious in the hashrates.

So you are admiting to want to force a take over here, well at least you are honest about it.

You don't want to make another copycoin, for the simple reason, that despite it issues, catcoin is strong brandname with a strong community behind it, so you want to ride on that potentiel. And again you admit this, and again you are honest about it.

Now my turn to be honest about this, I don't mind you forking the coin, but what I do mind is doing things unilateraly one sided and without discussing things with other (read the above a descibed a well weighted and decent process to do this), If you are going to thing your way, believe me it will only create tension and will fracture the cat community, the first fork was almost a disaster and right now you are about to repeat the same thing but only worse because I don't know if you are going to even get the back of half the community.

Concensus should be made by majority, this is not some sort of imperialism, or the savana, where the strongest rule, As proven by history neither of those system works/worked for humans aka people that thinks for themselves and have their own opinion on things.

I've been trying to get feedback every place I can mostly irc.freenode.com #catcoin-dev (come join us), and still keep moving. Everyone that's still hashing CAT during high difficulty periods is losing revenue and giving it to coinhoppers. I'd like to get some consensus while there's still some community to get a consensus from. How many moved on to coinye? How many p2poolers showed up and left after 3 days of no blocks? The alternative is keep my mouth shut and wait another couple weeks and pick the chain off in the middle of the night with 5Mhash and have the few people left wake up with new rules, or a long-slow death like yacoin, or crazy difficulty oscillations like galaxycoin.

okay, I need to get off the forums. If you think you have a consensus for a block number better than 20999 to implement difficulty changes every 1 block based on the last 36, please file an issue at https://bitbucket.org/dahozer/catcoin/issues, and tell me how you arrived at a consensus.
hero member
Activity: 588
Merit: 501
January 12, 2014, 01:16:26 AM
Fork?

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 have CATcoin alive.

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.

Did I miss something ?  I tought we were only discussing, and testing ideas for a possible fork, not a fork in it self and like this, and I refuse that you fork the coin and I'm sure I'm not the only to do so, this is more or less an hostile takeover, and rushing thing out, we need to dicuss things, if anyone passing by decides to fork whatever coin he wants whenever he wants it's going to be a miss, and just kill the coin.

Please reconsider again what you are doing, No fork for now, we can discuss and test ideas, but I don't want to see another rushed one sided fork.

Great. For now, Hozer's fork is an alternative, if people decide this is the direction they want for catcoin, it's not the official fork, and is unlikely to be unless many people reach consensus and join it. Any coin can have this done to it. Unless it's adopted by the masses, it's irrelevant.

How about we reach a consensus on what we're actually going to do and actually execute it. Hozer's fork is not official, and does not represent the board, but it is an alternative. You guys are arguing about a non-issue. Anybody can clone a git repo for any coin and do exactly what hozer is doing, unless it gets major hash rate it's not happening. For now that gives us a valuable test bed, and an opportunity to actually come to a solution as a community and decide what direction we want this coin to go. Currently only etblvu1 has posted alternatives to my knowledge, and frankly short term I'm not sure they're viable, if I see proof to the contrary it may yet get my vote. My 1 block 36 average is still my first choice personally. That choice does not represent the community or board as a whole. What is the best option? What is simple and relatively safe from abuse that solves our current diff issues? I'm looking for more suggestions, or approval of one of the current options. This coin is dead in 10 days if we do nothing, which seems to be the current course of action, because the nethash is dropping with every diff cycle. Lets get a solution adopted and coded, so we can save this coin. We currently have a measly 44 MHash. Our time is ticking, lets get this done.

In theory I would have agreed  with the first part of your reply, but it isn't the case.

But let me begin with the last part of your reply which is wrong: The current hash rate is 0.17 Gh/s (not 44Mh/s) which has been stable for the last 10 days during the 36 high diff blocks and before the profitability switching pools join in and for that the coin is more than safe as it has managed to find an equilibrium point. (or maybe I missed your point?)

Now back to the first part, does the fork start at a different diff? probably yes due to the non existant hashrate, which means, that with the new fork having non-existant very low diff it will automatically draw miners to it no one wants to miss a launch and easy mining. (might be wrong here, but please feel free to correct me if I missed something again)

Another things is that at 0.17Gh/s, if just 3 to 5 of the biggest catcoin miners decides to switch camp due to an incetivited offer, it will switch the balance from the new fork, I've talked to people who had rigs of 40Mh/s 50 Mhs and even more, so this is another possible scenario, and this can happen despite the majority wanting to remain with the original coin.

This is why I thin the consensus Idea on it self is flawed, especially in our case, and I believe we should be extra carefull about things because right now what would be deadly to the coin is not taking some time (as proven in the first part of my reply) but doing a mistake such as fracturing the catcoin community.

Good night to all or good day depending on your time zone, it's 7:20 am here and I think it's about time to get a small nap Cheesy
full member
Activity: 213
Merit: 100
January 12, 2014, 01:04:12 AM
We currently have a measly 44 MHash. Our time is ticking, lets get this done.

I would like to point out, as a way of illustration, that I happen to have about 4.4 MHashes at my disposal. If the mining rewards were fair and rational, that means if I point my rigs to solo mine catcoins over an extend period of time, I should be seeing a block solution happen an average of every 100 minutes (10 minutes per block, since 4.4 MHashes is 10% of the hash power, I should get one every 10 blocks). But it doesn't work that way right now. Sometimes, the difficulty is such that I'd have to mine 40 minutes for a block to be found (meaning, I'd have to mine an average of 400 minutes to get my 1 block solution). Other times, the difficulty is low, but bunch of coin hoppers come and dilute my contribution, so even though blocks are being found every 2 minutes, I don't have enough hash power to get in on finding a block every 10 blocks, to make up for losses from the slow difficulty times. Maybe during high difficulty times, I am earning 1 block out of 10, but at only 1/4th the potency (so 25% earnings), and this is 75% of the time. The low difficulty times, I am earning maybe 1 block out of 30, but they come every 2 minutes, so my earnings are maybe 160% the expected, but only 25% of the time. .75 x .25 + .25 x 1.6 = .45, meaning I am only getting 45% of my fair reward of 1 block per 100 minutes, i.e., I would be average only 1 block found per 222 minutes. The other 122 minutes' worth of coins are going to some anonymous coin hopper for their "valuable services" to me of showing up when difficulty is easy and diluting my work. The numbers may not be exact, but they demonstrate the principle. And you ask about why the network hashrate is low.

Etblvu1

member
Activity: 70
Merit: 10
January 12, 2014, 12:49:07 AM
Fork?

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 have CATcoin alive.

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.

Did I miss something ?  I tought we were only discussing, and testing ideas for a possible fork, not a fork in it self and like this, and I refuse that you fork the coin and I'm sure I'm not the only to do so, this is more or less an hostile takeover, and rushing thing out, we need to dicuss things, if anyone passing by decides to fork whatever coin he wants whenever he wants it's going to be a miss, and just kill the coin.

Please reconsider again what you are doing, No fork for now, we can discuss and test ideas, but I don't want to see another rushed one sided fork.

Great. For now, Hozer's fork is an alternative, if people decide this is the direction they want for catcoin, it's not the official fork, and is unlikely to be unless many people reach consensus and join it. Any coin can have this done to it. Unless it's adopted by the masses, it's irrelevant.

How about we reach a consensus on what we're actually going to do and actually execute it. Hozer's fork is not official, and does not represent the board, but it is an alternative. You guys are arguing about a non-issue. Anybody can clone a git repo for any coin and do exactly what hozer is doing, unless it gets major hash rate it's not happening. For now that gives us a valuable test bed, and an opportunity to actually come to a solution as a community and decide what direction we want this coin to go. Currently only etblvu1 has posted alternatives to my knowledge, and frankly short term I'm not sure they're viable, if I see proof to the contrary it may yet get my vote. My 1 block 36 average is still my first choice personally. That choice does not represent the community or board as a whole. What is the best option? What is simple and relatively safe from abuse that solves our current diff issues? I'm looking for more suggestions, or approval of one of the current options. This coin is dead in 10 days if we do nothing, which seems to be the current course of action, because the nethash is dropping with every diff cycle. Lets get a solution adopted and coded, so we can save this coin. We currently have a measly 44 MHash. Our time is ticking, lets get this done.
full member
Activity: 213
Merit: 100
January 12, 2014, 12:41:54 AM
You mistake me. I'm not opposed to change. I want that change to not leave unanswered questions for miners. I don't ant it to be guess work as to what the block rewards is going to be. IMHO, variable block rewards are a fundamental change to how this coin operates. I also wish the algorithm to be simple and near impossible to abuse. I'm not sure your solutions satisfies all those conditions currently. If I can see proof that it does, I personally am more likely to be on board. how can we test and verify this?

I agree with you that any new ideas should be fully vetted. I am glad you are asking good questions.

Consider this: If you think of block reward per time invested rather than in terms of per block solved, I think you will find it easier to understand. When difficulty is high, it means the miner is getting relatively less coins per time invested. When the difficulty is easy, it means the miner is getting relatively more coins per time invested. The goal is to equalize things, so the miner is seeing more or less constant coins per time invested. The level of coins produced per time would equalize based on supply and demand, and market price of the coins.

So to prove this algorithm would work in a desired way, we need to prove four separate propositions:
(1) That coin hoppers would largely go away when there is no way to swoop in when convenient, and walk away with big profits;
(2) That if coin hoppers go away, difficulty fluctuations would become more mild;
(3) As long as coins generated per time invested with rigs is knowable, most miners care very little about detailed mechanics of exactly how many coins got generated for creating which specific blocks; and
(4) Given difficulty fluctuations are mild and coins awarded per hashes contributed is knowable, supply and demand and arbitrage will take care of making sure enough hashes are there to back up the coin given any market price, with difficulty going up or down as the value of the coin goes up or down, but block time remaining more or less constant at 10 minutes.

To save space, please let me know if you agree if all four of these are accepted or proven, that would address all of your concerns; and also, which of the four you doubt, and therefore I need to demonstrate.

Also, that would only be proof on the theory side; to prove it on a more practical side, we can do something like run simulations. I am going to use catchain.info data screen scraped off the webpage, and run a simulation of of what would happen using the continuous difficulty + variable reward formula. This simulation cannot take into account that people respond to incentives, so with the varying difficulty and rewards, the time between blocks would have changed. But by studying the output of this simulation, you can at least validate that the incentives are always pushing in the right direction. I plan to post this once I write the simulation, and have something to show.

Thank you,

Etblvu1


hero member
Activity: 588
Merit: 501
January 12, 2014, 12:39:21 AM
I think this is a flaw in the bitcoin design, but It wasn't possible to forsee that in 5 years time there will be hundrends of altcryptocurrencies. This flaw didn't affect BTC because it was the only crypto for a long while, and the notion of maximising profit didn't exist because BTC was all you had, as for the situation today is a bit complicated.

I still believe the solution would be to remove, the diff jumping issue, and that would be by reducing the maximum variance of diff, I think this is the simplist and easiest way to do things. If this done correctly, there won't an issue of reward per block, because the diff will rise smoothly it will prevent people from switch coin every diff retarget and it will balance out the hashrate it might have it own drawbacks which I don't see, but please feel free to point it out

Also keep in mind that with increased diff should result in an increase of the value of coin, (outside the speculation and the fundamental laws of the market aka offre and demande)


Now first of all we should decide what to implement, and what not to implement in the fork as a community, from there we can move on to do a vote and if anyone is against something he should present an argumentation to his opinion which might be legitimate and from there.

Lets take our time, this process should last at least 2 weeks, one week to dicuss and finalise the fork if the majority agrees to this, and the second week would be to fine tune the code, and at the same time inform all the parteners involved in catcoin such the exchanges, and of course in the meantime this will allow us to spread the word efficiently.

Tell me what you want to see. I got into Catcoin because I live with 3 cats, and it seemed like a better long-term-deal than copycatcoin of the week, and better than doing another bogus launch of a new coin. Catcoin is a fork of Litecoin/Bitcoin, and KR105 listened to the community and switched from sha256 to scrypt.

I want to see Catcoins worth approximately what it costs own a cat, or about $10,000 each. I want rough consensus and running code.

Quote
"We reject: kings, presidents and voting.
  We believe in: rough consensus and running code."
http://tools.ietf.org/html/draft-moonesamy-consensus-00

The code is running, the consensus will be obvious in the hashrates.

So you are admiting to want to force a take over here, well at least you are honest about it.

You don't want to make another copycoin, for the simple reason, that despite it issues, catcoin is strong brandname with a strong community behind it, so you want to ride on that potentiel. And again you admit this, and again you are honest about it.

Now my turn to be honest about this, I don't mind you forking the coin, but what I do mind is doing things unilateraly one sided and without discussing things with other (read the above a descibed a well weighted and decent process to do this), If you are going to thing your way, believe me it will only create tension and will fracture the cat community, the first fork was almost a disaster and right now you are about to repeat the same thing but only worse because I don't know if you are going to even get the back of half the community.

Concensus should be made by majority, this is not some sort of imperialism, or the savana, where the strongest rule, As proven by history neither of those system works/worked for humans aka people that thinks for themselves and have their own opinion on things.
sr. member
Activity: 271
Merit: 254
January 12, 2014, 12:30:29 AM
Fork?

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 have CATcoin alive.

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.

Did I miss something ?  I tought we were only discussing, and testing ideas for a possible fork, not a fork in it self and like this, and I refuse that you fork the coin and I'm sure I'm not the only to do so, this is more or less an hostile takeover, and rushing thing out, we need to dicuss things, if anyone passing by decides to fork whatever coin he wants whenever he wants it's going to be a miss, and just kill the coin.

Please reconsider again what you are doing, No fork for now, we can discuss and test ideas, but I don't want to see another rushed one sided fork.

Tell me what you want to see. I got into Catcoin because I live with 3 cats, and it seemed like a better long-term-deal than copycatcoin of the week, and better than doing another bogus launch of a new coin. Catcoin is a fork of Litecoin/Bitcoin, and KR105 listened to the community and switched from sha256 to scrypt.

I want to see Catcoins worth approximately what it costs own a cat, or about $10,000 each. I want rough consensus and running code.

Quote
"We reject: kings, presidents and voting.
  We believe in: rough consensus and running code."
http://tools.ietf.org/html/draft-moonesamy-consensus-00

The code is running, the consensus will be obvious in the hashrates.
hero member
Activity: 657
Merit: 500
January 12, 2014, 12:29:39 AM
So would you consider yourself a rational-self-interest coinhopper? I appreciate very much that you've been willing to say so publicly.
No, I would not consider myself to be a coinhopper, hozer, as I first learned about CAT on 26th Dec and have been mining it since.  Prior to CAT, I focused on Feathercoin. The only time I left one of three CAT pools was to finish building my rig when we were stuck in the "difficulty from Hell" period.
I would also like to understand where the blip of 8Mhash on one of my p2pool nodes came from (address 9cTpXimaMvCKCCNg2CXk3Mz14MsBzuhSQQ) for a few minutes.
As would I!

That really was the point of my comments - that if I was hopping for profit, then I'd want to make sure I catch EVERY block at low difficulty.  If, on the other hand, I wanted to attack a coin, I'd not bring my hashes in until the very end of the low difficulty period so I could push the diff to the moon and try to stall it again.  That's really why I think we're under attack rather than 'just' being abused by a hopper - rational or not.

You all know what I'm doing, and you have the choice where you want to hash.
I won't be mining your chain, hozer, as I see it as a threat to CAT along the lines of a hostile takeover.  Frankly, this is the first time I've been truly concerned for the future of this coin.
member
Activity: 70
Merit: 10
January 12, 2014, 12:28:35 AM
Quote
Idea #2 - Variable Reward Below Reference Difficulty

This is to take a small part of the more complex loyalty reward idea, in a form that may be less controversial and easier to code:

We take the average of the last 144 difficulty levels and call it the reference difficulty. Then, if the current difficulty is less than the reference difficulty, the reward amount is proportionately reduced. For example, if the reference difficulty is 32, and the current difficulty is 16, then we award 25 CATs instead of 50 CATs. If the current difficulty is at or above the reference difficulty, we award the full amount. This would be combined with continuously varying difficulty. This will at least ensure that no matter how easy the difficulty gets, we never have hyperinflation or hit the top of profitability charts due to sudden reduction in difficulty. But at the same time, we also should never have long periods of time between solving blocks.

Etblvu1



I don't believe we can do a "variable reward system" without fundamentally changing the coin, causing us to lose a lot of the support that we have left. I'm personally looking for reliable predictable output from a coin not "it could be anywhere between 25 and 50 coins". That's not predictable, and from what I've learned of the mining community people want simple easy to understand coins.

I still have not yet to see any reason why 1 block 36 avg will NOT work. I also see discussion in the main alt coin forums that "smart devs will choose to have a 1 block retarget". So why is this not going to work? Why make it more complicated then it needs to be? The algorithm is simple and easy to understand. It's also quick to implement. I'm open to alternate suggestions, but I have not seen a simpler one yet.

I don't take issue with your criticism of idea #1 - that one was more tongue in cheek.

With your critique of idea #2 - I think we need to get over holding as sacred the idea that awards should be equal whether a block was difficult or easy to find. The sole purpose of difficulty adjustments is to make the appearance of new blocks happen with targeted intervals of time. This goal does not include, and does not in any way imply that rewards have to be equal between solving blocks. The very fact even BTC has a scheduled halving of rewards from time to time shows that rewards do not have to be fixed. There is no reason why rewards should not be considered fair game when dealing with incentives of coin hoppers.

Think about it in terms of fundamentals. This dogma about equality of hard and easy to solve blocks really is at the bottom of why people choose to coin hop. If you can get paid the same whether it's easy or hard to do the work, why not hop around looking for easy work, to maximize profit? And if people persist in insisting on "equal reward regardless of how hard it was to mine the block" the corollary is that no matter how many mathematical tweaks and tricks you come up with, you will always have some periods where blocks are easier or harder to mine, and coin hoppers will find a way to swoop in when it's easy. And the instability this introduces will inherently create equal and opposite instability in the direction of too much time between blocks. Why insist on keeping this coin hopper paradigm? It's so unnecessary - we are trying to have a stable coin, that finds a block every 10 minutes. People don't need to "understand" why sometimes 50 blocks are awarded, and sometimes, only 7.5 coins are awarded. Those that do, are coin hoppers, and we lose nothing by having them leave.

Etblvu1



You mistake me. I'm not opposed to change. I want that change to not leave unanswered questions for miners. I don't ant it to be guess work as to what the block rewards is going to be. IMHO, variable block rewards are a fundamental change to how this coin operates. I also wish the algorithm to be simple and near impossible to abuse. I'm not sure your solutions satisfies all those conditions currently. If I can see proof that it does, I personally am more likely to be on board. how can we test and verify this?
full member
Activity: 213
Merit: 100
January 12, 2014, 12:16:31 AM
Quote
Idea #2 - Variable Reward Below Reference Difficulty

This is to take a small part of the more complex loyalty reward idea, in a form that may be less controversial and easier to code:

We take the average of the last 144 difficulty levels and call it the reference difficulty. Then, if the current difficulty is less than the reference difficulty, the reward amount is proportionately reduced. For example, if the reference difficulty is 32, and the current difficulty is 16, then we award 25 CATs instead of 50 CATs. If the current difficulty is at or above the reference difficulty, we award the full amount. This would be combined with continuously varying difficulty. This will at least ensure that no matter how easy the difficulty gets, we never have hyperinflation or hit the top of profitability charts due to sudden reduction in difficulty. But at the same time, we also should never have long periods of time between solving blocks.

Etblvu1



I don't believe we can do a "variable reward system" without fundamentally changing the coin, causing us to lose a lot of the support that we have left. I'm personally looking for reliable predictable output from a coin not "it could be anywhere between 25 and 50 coins". That's not predictable, and from what I've learned of the mining community people want simple easy to understand coins.

I still have not yet to see any reason why 1 block 36 avg will NOT work. I also see discussion in the main alt coin forums that "smart devs will choose to have a 1 block retarget". So why is this not going to work? Why make it more complicated then it needs to be? The algorithm is simple and easy to understand. It's also quick to implement. I'm open to alternate suggestions, but I have not seen a simpler one yet.

I don't take issue with your criticism of idea #1 - that one was more tongue in cheek.

With your critique of idea #2 - I think we need to get over holding as sacred the idea that awards should be equal whether a block was difficult or easy to find. The sole purpose of difficulty adjustments is to make the appearance of new blocks happen with targeted intervals of time. This goal does not include, and does not in any way imply that rewards have to be equal between solving blocks. The very fact even BTC has a scheduled halving of rewards from time to time shows that rewards do not have to be fixed. There is no reason why rewards should not be considered fair game when dealing with incentives of coin hoppers.

Think about it in terms of fundamentals. This dogma about equality of hard and easy to solve blocks really is at the bottom of why people choose to coin hop. If you can get paid the same whether it's easy or hard to do the work, why not hop around looking for easy work, to maximize profit? And if people insist on hanging onto this dogma, at least do so understanding that the inherently necessary corollary is that no matter how many mathematical tweaks and tricks you come up with, you will always have some periods where blocks are easier or harder to mine, and coin hoppers will find a way to swoop in when it's easy. And the instability this introduces will inherently create equal and opposite instability in the direction of too much time between blocks. Why insist on keeping this coin hopper, instability-inducing paradigm? It's so unnecessary - we are trying to have a stable coin, that finds a block every 10 minutes. That is the important predictability. If we have to lose consistently giving away 50 coins with every block to get it, there is no reason on earth why not to give it up. The only real objection, is a coin hopper objection - the desire to find opportunities to drop in on an easy profit opportunity. But you have to realize that this comes at the expense of profits for more loyal miners. When you take way this easy profit, it means it becomes easier for all the others mining the coin to finally see stable profits. Without coin-hopping destabilizing the difficulty levels, supply and demand and market forces stop being drowned out, and finally equalize out the difficulty curve, so people receive neither too much or too little profit. Difficulty will go up as coin prices go up, and difficulty will go down as prices go down, but without any quick profit potentials by swooping in at the last minute during momentary quick drops.

Etblvu1

sr. member
Activity: 271
Merit: 254
January 12, 2014, 12:12:07 AM
I'm going to put forth two (2) ideas for a patchwork solution (not necessarily good ideas, may provide some fodders for discussion though):

Idea #1 - Voter Override of Difficulty Adjustment

1. Add a small form section in the QT wallet UI with the following:
  a. List or graph of the last 5 difficulty levels
  b. List or graph of the hashrates during the last 5 difficulty levels
  c. Show current hashrate, current difficulty level, estimated time to next adjustment, and estimated difficulty level at next adjustment.
  d. Label that says "Vote to override next adjustment?" and radio buttons "Yes" and "No" next to it.
  e. Label that says "Make adjustment immediate or at the next scheduled adjustment?" and radio buttons "immediate" and "next scheduled"
  f. Labels that says "Preferred difficulty" and a text box pre-filled with next estimated difficulty but can be edited.
  g. "Vote" button.
2. When the user clicks "Vote" it sends the results signed by the wallet across the network. Coin-days of the wallet is used to give weight to the votes. Voting is optional, weighted by coin-days of the voting wallet, and vote-weight decays with age from full strength to zero in 2016 blocks. The nodes forward the votes around, so everyone should be looking at the same set of votes (the same way everyone looks at the same transactions).
3. The nodes can agree whether the network prefers to leave the difficulty level at default, or has voted to manually intervene. If wallet owners intervened, it takes the weighted median of all the submitted suggested values to derive the consensus of what the difficulty should be adjusted to, instead of the default calculated difficulty, and that is the difficulty that takes effect with the next block solution or next difficulty adjustment (allowing for a small margin, in case the weighted median calculation was slightly off based on the computing node missing a vote or two).

This seems like it could be really hard to code, but I wouldn't know. If it's easy to code, it could provide us with excellent stability for as  long as wallet owners remain engaged and vote often.


I think you just described https://bitbucket.org/dahozer/catcoin/wiki/create/Stake-voting.
I have a line in the code that says:

/** The interval over which we look to calculate the next difficulty **/
static const int RETARGET_INTERVAL = 36; // can we stake-vote on changing this? -- Troy

member
Activity: 70
Merit: 10
January 12, 2014, 12:06:30 AM
I'm going to put forth two (2) ideas for a patchwork solution (not necessarily good ideas, may provide some fodders for discussion though):

Idea #1 - Voter Override of Difficulty Adjustment

1. Add a small form section in the QT wallet UI with the following:
  a. List or graph of the last 5 difficulty levels
  b. List or graph of the hashrates during the last 5 difficulty levels
  c. Show current hashrate, current difficulty level, estimated time to next adjustment, and estimated difficulty level at next adjustment.
  d. Label that says "Vote to override next adjustment?" and radio buttons "Yes" and "No" next to it.
  e. Label that says "Make adjustment immediate or at the next scheduled adjustment?" and radio buttons "immediate" and "next scheduled"
  f. Labels that says "Preferred difficulty" and a text box pre-filled with next estimated difficulty but can be edited.
  g. "Vote" button.
2. When the user clicks "Vote" it sends the results signed by the wallet across the network. Coin-days of the wallet is used to give weight to the votes. Voting is optional, weighted by coin-days of the voting wallet, and vote-weight decays with age from full strength to zero in 2016 blocks. The nodes forward the votes around, so everyone should be looking at the same set of votes (the same way everyone looks at the same transactions).
3. The nodes can agree whether the network prefers to leave the difficulty level at default, or has voted to manually intervene. If wallet owners intervened, it takes the weighted median of all the submitted suggested values to derive the consensus of what the difficulty should be adjusted to, instead of the default calculated difficulty, and that is the difficulty that takes effect with the next block solution or next difficulty adjustment (allowing for a small margin, in case the weighted median calculation was slightly off based on the computing node missing a vote or two).

This seems like it could be really hard to code, but I wouldn't know. If it's easy to code, it could provide us with excellent stability for as  long as wallet owners remain engaged and vote often.

This would be a disaster to code IMO, open to abuse and doesn't really solve the problem. If people don't vote or can't vote for whatever reason, everyone else gets screwed.

Quote
Idea #2 - Variable Reward Below Reference Difficulty

This is to take a small part of the more complex loyalty reward idea, in a form that may be less controversial and easier to code:

We take the average of the last 144 difficulty levels and call it the reference difficulty. Then, if the current difficulty is less than the reference difficulty, the reward amount is proportionately reduced. For example, if the reference difficulty is 32, and the current difficulty is 16, then we award 25 CATs instead of 50 CATs. If the current difficulty is at or above the reference difficulty, we award the full amount. This would be combined with continuously varying difficulty. This will at least ensure that no matter how easy the difficulty gets, we never have hyperinflation or hit the top of profitability charts due to sudden reduction in difficulty. But at the same time, we also should never have long periods of time between solving blocks.

Etblvu1



I don't believe we can do a "variable reward system" without fundamentally changing the coin, causing us to lose a lot of the support that we have left. I'm personally looking for reliable predictable output from a coin not "it could be anywhere between 25 and 50 coins". That's not predictable, and from what I've learned of the mining community people want simple easy to understand coins.

I still have not yet to see any reason why 1 block 36 avg will NOT work. I also see discussion in the main alt coin forums that "smart devs will choose to have a 1 block retarget". So why is this not going to work? Why make it more complicated then it needs to be? The algorithm is simple and easy to understand. It's also quick to implement. I'm open to alternate suggestions, but I have not seen a simpler one yet.
hero member
Activity: 588
Merit: 501
January 11, 2014, 11:59:24 PM
Fork?

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 have CATcoin alive.

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.

Did I miss something ?  I tought we were only discussing, and testing ideas for a possible fork, not a fork in it self and like this, and I refuse that you fork the coin and I'm sure I'm not the only to do so, this is more or less an hostile takeover, and rushing thing out, we need to dicuss things, if anyone passing by decides to fork whatever coin he wants whenever he wants it's going to be a miss, and just kill the coin.

Please reconsider again what you are doing, No fork for now, we can discuss and test ideas, but I don't want to see another rushed one sided fork.
sr. member
Activity: 271
Merit: 254
January 11, 2014, 11:52:01 PM

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.
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.


The only real observable we have are the time between blocks, and the address the generate transactions go to. The pools might have a better idea about hash rate, and p2pool does not have enough hash rate to do anything meaningful.

So would you consider yourself a rational-self-interest coinhopper? I appreciate very much that you've been willing to say so publicly. I would also like to understand where the blip of 8Mhash on one of my p2pool nodes came from (address 9cTpXimaMvCKCCNg2CXk3Mz14MsBzuhSQQ) for a few minutes.

If there are 100 'true believers' with 1Mhash each holding up the value of CAT, and allowing you to complete your generate transactions, and let's say 500 people with rational-self-interest with 2Mhash each that appear for low-diff periods, there's no attacker, just a gigahash of people looking to make some CAT, which are depending on the generosity of 100 others so that their transactions may complete.

My opinion is this is not good for you, for me, the exchanges, or anyone else that wishes for CAT to have value as a functional currency, and the action I can take is ask you all to hash with me on the next low difficulty period, and find out if the dynamics of adjusting every block result in a more profitable and equitable currency for everyone, rather than just those interested in profit.

You all know what I'm doing, and you have the choice where you want to hash.
full member
Activity: 213
Merit: 100
January 11, 2014, 11:42:49 PM
I'm going to put forth two (2) ideas for a patchwork solution (not necessarily good ideas, may provide some fodders for discussion though):

Idea #1 - Voter Override of Difficulty Adjustment

1. Add a small form section in the QT wallet UI with the following:
  a. List or graph of the last 5 difficulty levels
  b. List or graph of the hashrates during the last 5 difficulty levels
  c. Show current hashrate, current difficulty level, estimated time to next adjustment, and estimated difficulty level at next adjustment.
  d. Label that says "Vote to override next adjustment?" and radio buttons "Yes" and "No" next to it.
  e. Label that says "Make adjustment immediate or at the next scheduled adjustment?" and radio buttons "immediate" and "next scheduled"
  f. Labels that says "Preferred difficulty" and a text box pre-filled with next estimated difficulty but can be edited.
  g. "Vote" button.
2. When the user clicks "Vote" it sends the results signed by the wallet across the network. Coin-days of the wallet is used to give weight to the votes. Voting is optional, weighted by coin-days of the voting wallet, and vote-weight decays with age from full strength to zero in 2016 blocks. The nodes forward the votes around, so everyone should be looking at the same set of votes (the same way everyone looks at the same transactions).
3. The nodes can agree whether the network prefers to leave the difficulty level at default, or has voted to manually intervene. If wallet owners intervened, it takes the weighted median of all the submitted suggested values to derive the consensus of what the difficulty should be adjusted to, instead of the default calculated difficulty, and that is the difficulty that takes effect with the next block solution or next difficulty adjustment (allowing for a small margin, in case the weighted median calculation was slightly off based on the computing node missing a vote or two).

This seems like it could be really hard to code, but I wouldn't know. If it's easy to code, it could provide us with excellent stability for as  long as wallet owners remain engaged and vote often.

Idea #2 - Variable Reward Below Reference Difficulty

This is to take a small part of the more complex loyalty reward idea, in a form that may be less controversial and easier to code, and combine it with the continuous difficulty adjustment:

We take the average of the last 144 block difficulty values call it the reference difficulty. Then, if the current difficulty is less than the reference difficulty, the reward amount is proportionately reduced. For example, if the reference difficulty is 32, and the current difficulty is 16, then we award 25 CATs instead of 50 CATs. If the current difficulty is at or above the reference difficulty, we award the full amount for creating a block. This will at least ensure that no matter how easy the difficulty gets, we never have hyperinflation or hit the top of profitability charts due to sudden reduction in difficulty. But at the same time, we also should never have long periods of time between solving blocks. The difficulty would probably stabilize quite a bit because coin hoppers would not find it profitable. This would also inherently make Catcoins more scarce than Bitcoins and give it more upward potential in value, and be self-correcting so the value sits near the middle (or else people would stop mining, or start mining, until it got there) and discourage coin hopping.

Etblvu1

member
Activity: 70
Merit: 10
January 11, 2014, 11:23:39 PM
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.
I'm new, but do understand that the longest chain wins.  From a somewhat conservative sysadmin/netadmin point of view (maybe incorrect in this realm...), I personally wouldn't put ANYTHING live on a network unless I was sure it was ready - because as hozer has acknowledged, all his fork needs is hashes to become 'the' CAT.

I guess the risk is, some DOGE fanboy or pool operator with a grudge and access to lots of hashing power might find it fun to mess with the Catcoin network by taking that client and putting lots of hashing power behind it, just long enough to force that to cause a major fork or maybe become official, and watch with glee as all the finger-pointing and arguing erupt in this thread. It may be advisable to do whatever it takes to get a real testnet operational, maybe we need to find a coin dev who is not currently involved in Catcoins, and pay some BTC's to temporarily loan us some expertise.

Etblvu1


In some ways, our low trade volume runs the risk of us getting de-listed anyways. As hozer said, being de-listed is not a death knell, having no netowrk hash is. We need to either use the presented solution or come up with a better on as soon as reasonably possible, code it, publish it and get the pools and exchanges on board with the fork. Does anyone see any issues with the logic we're talking about here? DOes my graph have any flaws that we should know about?

It would be pretty easy to add a 50% limiter to prevent 400% increases up and down, but using an average of 36 or whatever number we decide on will not likely ever see that drastic of a change. We can implement it just to be sure.  In what way does 1 block 36 Avg not solve the issues we have right now? It's self limiting, accurate, quick and very flexible. I'm open to suggestions otherwise here.
sr. member
Activity: 271
Merit: 254
January 11, 2014, 11:22:38 PM


Izzy says vote by cat.
full member
Activity: 213
Merit: 100
January 11, 2014, 10:26:34 PM
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.
I'm new, but do understand that the longest chain wins.  From a somewhat conservative sysadmin/netadmin point of view (maybe incorrect in this realm...), I personally wouldn't put ANYTHING live on a network unless I was sure it was ready - because as hozer has acknowledged, all his fork needs is hashes to become 'the' CAT.

I guess the risk is, some DOGE fanboy or pool operator with a grudge and access to lots of hashing power might find it fun to mess with the Catcoin network by taking that client and putting lots of hashing power behind it, just long enough to force that to cause a major fork or maybe become official, and watch with glee as all the finger-pointing and arguing erupt in this thread. It may be advisable to do whatever it takes to get a real testnet operational, maybe we need to find a coin dev who is not currently involved in Catcoins, and pay some BTC's to temporarily loan us some expertise.

Etblvu1
hero member
Activity: 657
Merit: 500
January 11, 2014, 10:21:13 PM
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.
I'm new, but do understand that the longest chain wins.  From a somewhat conservative sysadmin/netadmin point of view (maybe incorrect in this realm...), I personally wouldn't put ANYTHING live on a network unless I was sure it was ready - because as hozer has acknowledged, all his fork needs is hashes to become 'the' CAT.  As a holder of CAT (I've converted all my crypto - FTC, DGC, ANC, BTC - into CAT because of the coin and the team) and as a new miner hoping to pay off his equipment before I get too old to care one way or another, I'm concerned about any changes to this coin that do not include full agreement from at LEAST the full 'board'.  Y'all know more about the guts and gears of crypto than I - I just want to make sure all the 'brains' think this is the way to go.

The meme can be about 'herding cats' but the decision-making process does NOT. Wink



(Your 'cave etching' was on graph paper - nothing wrong with that. LOL)
sr. member
Activity: 271
Merit: 254
January 11, 2014, 10:13:40 PM
@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.

Takeover is not my intention, but we, as a community, have to find a better way to express direction and confidence. I can only speak for myself, and observed hashrates, which, right now, at 113 Mhash, tell me between 100-200 people find cat valuable enough to donate long-term hashing power. That's not enough, and my view is we need thousands to have a viable currency.

I do not want to launch yet another copycoin, I would like to find a way to test this properly, and have a system for testing. So the first thing that needs to happen is I need to be able to mine catcoins with p2pool. That's good for you, good for me, good for the community. I don't know if this will work, but it's worth a try as a live test of the dynamics. The alternative for me is go join a coinhopper pool or launch my own coin, both of which do not help Catcoin.

The second thing that needs to happen is we have to come up with a genesis block for catcoin-testnet. I suspect there's some tool I haven't found, or debug code that will do this, so please, try running 'catcoind -testnet', and tell me what happens.

If things are obviously not going very well by say block 21100 or so, I can shut down the p2pool instances, catcoind's, and delete the wallets, and we can plan with wide notice to do this next Caturday, and get a -testnet, and some people who are willing to commit to a test plan for scheduled releases.
Pages:
Jump to: