Diff retarget strategy.
-
[quote name=“SixGun” post=“26151” timestamp=“1377293566”]
Although, I am [i]still[/i] waiting for someone more in the know to tell me why the increase rate has to be the same as the decrease rate. I would appreciate at this point at least for someone to tell me that’s the stupidest thing they’ve ever heard. :o Acknowledgment is better than indifference or just being ignored.
[/quote]
It doesn’t.
If you look at the current state of play, 137 to 193 is a 41% increase yet 193 to 137 is a 29% decrease. ;)
-
9% over 126 blocks doesn’t solve the problem. Makes it less serious, but doesn’t really work around coin hoppers like Multipool. Phenixcoin is about to have such settings implemented. I hope we can figure out something better.
I have studied PPCoin and found it interesting. Retargets every PoW block while keeping a very large window to look back for difficulty calculations: 1 week. Although exponential, not linear. It works very well in most cases. In fact, it eliminates coin hopping nearly completely. However, PPCoin employs 10 minute block target for both PoW and PoS blocks. We have 2.5 minute block target and no PoS. I have come to conclusion that 12 block retarget strategy (0.5 hour) may work very well, though 24 block retargets (1 hour) can be also tested. To match our current difficulty limiter, 1% (12 blocks) or 2% (24 blocks) max. difficulty change per retarget suggested. Either way is very smooth and nearly kills coin hopping.
Now about retarget window (nTargetTimespan). We had 3.5 days (~2016 blocks) initially, and it was too large. It brought us to a dead end in May together with difficulty limiter of 4, so there was our 1st hard fork. Now we have 21 hour (~504 blocks), and it seems to work very well. I suggest to keep it. Although there are some ideas to make it more advanced with weighting or non linear curve, I’m inclined to think they are not worth necessary complications at this time.
I can prepare the patch to make a run on the testnet against any other retarget model offered.
-
[quote name=“Nutnut” post=“26154” timestamp=“1377307387”]
[quote author=SixGun link=topic=3403.msg26151#msg26151 date=1377293566]Although, I am [i]still[/i] waiting for someone more in the know to tell me why the increase rate has to be the same as the decrease rate. I would appreciate at this point at least for someone to tell me that’s the stupidest thing they’ve ever heard. :o Acknowledgment is better than indifference or just being ignored.
[/quote]
It doesn’t.
If you look at the current state of play, 137 to 193 is a 41% increase yet 193 to 137 is a 29% decrease. ;)
[/quote]ach! facepalm
thanks for clearing that up. forgot my basic maths.
-
I’d add my two feathercoins but I’m completely retarded when it comes to this sort of thing so just take the path of least resistance. Feathers are supposed to fall from the sky gently and evenly unless dumped from a giant source where they all will likely clump together. I have no idea why I wrote this, just going by pure intuition here.
-
[quote name=“corather” post=“26160” timestamp=“1377320569”]
I’d add my two feathercoins but I’m completely retarded when it comes to this sort of thing so just take the path of least resistance. Feathers are supposed to fall from the sky gently and evenly unless dumped from a giant source where they all will likely clump together. I have no idea why I wrote this, just going by pure intuition here.
[/quote]Congrats!! That’s probably the most random post I’ve ever seen! ;D ;D
-
I’m all for change if it works better for us all, so count me in.
Its a pity we can’t modify the client in a way that you cant mine feathercoins if you jump on and off every 2 days, or some way to attack the issue in that way.
-
[quote name=“Pyxis” post=“26166” timestamp=“1377331856”]
I’m all for change if it works better for us all, so count me in.Its a pity we can’t modify the client in a way that you cant mine feathercoins if you jump on and off every 2 days, or some way to attack the issue in that way.
[/quote]Thats really not fair even if we could.
Not all are able to mine 24/7.
Some may only be able to mine during night. Or maybe just weekends.
Doesnt make em coinhoppers, just less fortunate than us 24/7 ;D -
I think its a good idea, it is the same idea as my idea, but with the “rough” banging on the sizes damping, not as good as the smooth damping implementation of averaging I proposed.
It does not add the long term component, so the short fall over the month is not being addressed. Which we should do if we take the trouble to change the code, otherwise it is a waste of programming and testing time.
It is a “crude implementation” for adding the average block time for ~100 blocks, as part of the difficulty calculation, thus damping high frequency changes.
However, its plus points are, we have already done this and although crude we have shown it works.
-
[quote name=“svennand” post=“26167” timestamp=“1377332273”]
[quote author=Pyxis link=topic=3403.msg26166#msg26166 date=1377331856]
I’m all for change if it works better for us all, so count me in.Its a pity we can’t modify the client in a way that you cant mine feathercoins if you jump on and off every 2 days, or some way to attack the issue in that way.
[/quote]Thats really not fair even if we could.
Not all are able to mine 24/7.
Some may only be able to mine during night. Or maybe just weekends.
Doesnt make em coinhoppers, just less fortunate than us 24/7 ;D
[/quote]I understand the moral issues and the problems part time miners would face, and miners in general especially if you have a power loss or overheating issues, but I would say generally speaking coinhoppers use a lot of hash, so could we modify the client that stops people jumping if they’re using more than a certain amount of hash like lets say 25Mhash? Again I say this, without knowing if this is possible either on moral or technical grounds, just throwing ideas out there.
-
[quote name=“Nutnut” post=“26147” timestamp=“1377288237”]
I am starting the bidding at 9% every 126 blocks.
[/quote]+1 for Nutnut.
I agree that the difficulty algorithm should be changed in the next client update.
This would be a short term fix.
Long term I think coinchoose & multipools will always find ways to “exploit” a coins weaknesses - as long ass all those coins share the same hashing algorithm.
Therefore I propose to change Feathercoins hashing algorithm. A minimal modification of the scrypt code will do. E.g. a scrypt2 where only a “*2” or a “/4” is added in one place in the code.
ckolivas (cgminer developer) could easily adjust his miner (maybe for a small donation) - or we would do it ourselves (it’s public source, so just create a fork).
Benefit: Multipools won’t be able to redirect hashing power any more. Loyal miners would stay and continue mining Feathercoin. Difficulty would stabilize.
-
9%/126 may work for now when there are 2GH/s of loyal miners and 8GH/s of coin hoppers. Look into the future. What if hash rate of coin hoppers doubles or triples? Because it’s going to happen anyway and you’ll be asking for another hard fork again. Multipool alone has doubled its hash power this month and there are others, too. Hard forks are for permanent solutions, not for temporary fixes.
-
[quote name=“handyrandyrc” post=“26181” timestamp=“1377350009”]
While it is frustrating to watch, I realize this is simply how a free market is supposed to work. In the exchanges of the world, there are guys with real-time computers that do millions of teensy trades to take advantage of any bit of difference in currencies. I say let it be. They have just found a way to take advantage of a low difficulty.I have no problem smoothing it down as Nutnut suggests, as it isn’t really changing the overall slope, just making updates more frequent. Anything more radical I would be opposed to.
Just because someone can make a change, doesn’t mean they should. Let the currency be free and let the market sort it out. Those big multipools are full of miners, and they have feather coins, lite coins, all types in their wallets. The more feather coins there are, the better.
Making a change that will only benefit a subset (eg. the dedicated miners) is a slippery slope.
[/quote]I 100% agree with this, was gonna write my own post but this explained it pretty well.
Lets have a tighter target time/diff adjust so that loyal miners wont be punished all the time.Lets not think negative about multipool. They are an important part of the mining society. The problem today is that FTC miners are getting the bad end out of the bargain.
Lower time/adjust will make the diff more consistent and do not contribute toso high differences for those that want to mine ftc 24/7 :D -
I tgink that not only miner will profit from a more stable time between blocks. but the use of the coin also as the time for x confirm will be more stable so more predictable. yes usual person use time ;)
first lets see the potential problem of shorter retarget(without longer sampling then the retarget itself):
- time manipulation for the retarget block will affect the difficulty (the 2h in future with 504 block is a 9.4% change, in the past is actually 6 block interval in theory 15 minutes, reality 5 to 45 minutes)
- bigger variation can be exploit to lower or higher the diff to extreme level. (seems everyone agree the max of 1.414 over 504 block should be respected, so no issue if we do so )
- low number of block
Some profit switching pool have big hash power switch so we should try to not over react with the difficulty.
I think that a 1.207 factor would serve us better then the actual 1.414.
The actual model is based on we have x mining power we want 2.5 minutes what we should have as difficulty to have that(that was fine for Bitcoin as it was adjusting to new comer). For FTC the reality is that change in difficulty also result in significant change in hash power.
So a damping factor should be include so we retarget to a portion of the difficult adjustment calculated.(in fact small change should be ok as is big change should be reduce a lot… logarithmic?). for simplicity it could stay linear and add a factor of 3 or 4. But i thing 1+log is nearly simpler for example(i simplify the calculation from the real one but the result is the same) : a retarget from 6 minutes would be actually *1.414 as 6/2.5=2.4, 1+log(2.4)=1.38so my opinion on the >100 blocks proposal. they should be ok as long as it stay below the range of the actual 504. shorter then that should probably add a longer sampling or sampling combination (like (last x + last 504)/2) or possibly a slower change.
in all case I would add the damping factor as we actually it the *1.4141 and /1.414 for mostly every retarget and this what is causing the miner issues and transaction issue of block every 8 minutes. smoothing the diff change will smooth the hashrate and the time between block all at the same time. I have seen few weeks ago that LTC vs FTC profitability is a big switch for hoppers usually with FTC needing to be 3-10% more profitable and then we get 1.5Gh/s, now with midlecoin probably more the that 1.5Gh/s
9% every 126 with a 1+log damping factor is my vote
1% every 12 with 504 back sampling seems promising also, need to be weighted for newer as more significant else past bump will make a re-bump. but this need more study and test. -
For my 2 FTC, I support these 2 options:
[quote]9% every 126 with a 1+log damping factor is my vote
1% every 12 with 504 back sampling seems promising also, need to be weighted for newer as more significant else past bump will make a re-bump. but this need more study and test.[/quote]cheers,
robep00 -
1% every 12 blocks makes the most sense to me. If hash rate Jumps massively the difficulty will ramp up fairly quick. But on the other side it will also come back down faster.
-
[quote name=“ghostlander” post=“26179” timestamp=“1377346105”]
9%/126 may work for now when there are 2GH/s of loyal miners and 8GH/s of coin hoppers. Look into the future. What if hash rate of coin hoppers doubles or triples? Because it’s going to happen anyway and you’ll be asking for another hard fork again. Multipool alone has doubled its hash power this month and there are others, too. Hard forks are for permanent solutions, not for temporary fixes.
[/quote]If I have understood you right, [b]ghostlander[/b], you’re saying that the collective hashrate of ‘pool hoppers’ is increasing over time and you believe this trend will continue.
Could you say why you believe it will continue? What can we say about these pool hoppers? What is their intention, are they free loaders? Is there anyway we can turn their behaviour to our advantage?
It seems to be that in some way this is about the short termists stealing from the future by brute force. Throwing hashing power in to a narrow span of time to extract as many coins as possible and thus depriving those who are more committed over the long time. Would this be accurate?
-
Countering the coin hopping pools shouldn’t be too hard. We just need to create a massive pool that always mines the least profitable coins. Any volunteers?
-
The pool hoppers are being giving false information. While xcoin might show a 300% profitability, the market depth is so shallow, it’s not realistic.
-
[quote name=“erk” post=“26344” timestamp=“1377550048”]
[quote author=tuneman1980 link=topic=3403.msg26322#msg26322 date=1377526692]
Countering the coin hopping pools shouldn’t be too hard. We just need to create a massive pool that always mines the least profitable coins. Any volunteers?
[/quote] I couldn’t think of a harder way to solve the problem. The easy way is to change the diff calc formula to be responsive and smooth. “Small steps Ellie, Small Step” - Contact.
[/quote]Sorry, I was being 100% sarcastic. I should have wrapped it in tags.
-
[quote name=“chrisj” post=“26317” timestamp=“1377520177”]
[quote author=ghostlander link=topic=3403.msg26179#msg26179 date=1377346105]
9%/126 may work for now when there are 2GH/s of loyal miners and 8GH/s of coin hoppers. Look into the future. What if hash rate of coin hoppers doubles or triples? Because it’s going to happen anyway and you’ll be asking for another hard fork again. Multipool alone has doubled its hash power this month and there are others, too. Hard forks are for permanent solutions, not for temporary fixes.
[/quote]If I have understood you right, [b]ghostlander[/b], you’re saying that the collective hashrate of ‘pool hoppers’ is increasing over time and you believe this trend will continue.
Could you say why you believe it will continue? What can we say about these pool hoppers? What is their intention, are they free loaders? Is there anyway we can turn their behaviour to our advantage?
[/quote]Many if not most miners don’t care much about particular coins. They want money fast. That’s why they’re hopping. Professional miners are different somewhat. They have invested a lot into their hardware, spent a lot of time and they also pay a lot for electricity. They want decent predictable ROI and they mine Litecoin usually with their GPU farms. Although some of them also try luck by hopping. I expect this trend to accelerate and more coin hopping pools to appear in the near future.
[quote]It seems to be that in some way this is about the short termists stealing from the future by brute force. Throwing hashing power in to a narrow span of time to extract as many coins as possible and thus depriving those who are more committed over the long time. Would this be accurate?[/quote]
Well, it is in fact. They destroy emerging coins while hunting for profits.
