Diff retarget strategy.

wrapper

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.

pyxis

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

Radacoin

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

ghostlander

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.

svennand

[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

groll

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

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

robep00

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

sl1982

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.

chrisj

[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?

tuneman1980

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?

justabitoftime

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.

tuneman1980

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

ghostlander

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

wrapper

I think this has been a great discusion, I vote we move ahead. The changes I have sugested will swooth any difficulty changes automatically whilst also keeping to the long term block production rate.

Based on the recent higher levels of Hash rate variation on Feathercoin Block production I have further refined the optimum difficulty adjustment algorithm and adjusted the required sampling / Difficulty adjustment frequency.

Based on the short term variation we are now, saved from an out right 51% attack (of say evil 3 GHash/sec) by an additional change over of 4 GHash/sec of other miners coin hoping.

Feathercoin has varied from average 2 GHash/sec to ~ 9 GHash/sec over the last 48 Hours.

Because the change happens very rapidly I have reduced the proposed Difficulty adjustment frequency requires to be 50 Blocks.

I have adjusted the historical Average sample to ( 50 Blocks, 504 Blocks and 10,000 Blocks.)

Therefore: Instead of the current Difficulty re-calculation being based on the time to do 504 blocks it will be based on time since 50, 504 and 10,000

(Average time per last 50 Blocks + Average time for last 504 Blocks + average time last 10,000 Blocks.) / 3

Combined average time per block * 504 > Gives the new values to calculate the difficulty.

If we though it useful we could allow some short term flexibility in which case we Multiply time for 50 blocks by 2 , and divide the average by 4.

I am also now suggesting an addition feature, to stabilise the Difficulty, the difficulty is only recalculated if the Difficulty change greater than 15% (to be agreed)

I’ve just been looking at the coding in FeathercoinQT /src main.cpp, CTxMemPool::accept etc. and it doesn’t look like it would be a hard change to make - like the Auto Check Points code (ACP) looked really hard…

[attachment deleted by admin]

tuneman1980

[quote name=“wrapper0feather” post=“26390” timestamp=“1377615204”]
I am also now suggesting an addition feature, to stabilise the Difficulty, the difficulty is only recalculated if the Difficulty change greater than 15% (to be agreed)
[/quote]

Could you provide your rationale for that suggestion.

Nutnut

[quote name=“wrapper0feather” post=“26390” timestamp=“1377615204”]
I think this has been a great discusion, I vote we move ahead. The changes I have sugested will swooth any difficulty changes automatically whilst also keeping to the long term block production rate.