Diff retarget strategy.
-
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.
-
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]
-
[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.
-
[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.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…
[/quote]This is all very well but you forgot to charge the Flux Capacitor! ;D
-
[quote name=“Pyxis” post=“26173” timestamp=“1377336095”]
[quote author=svennand link=topic=3403.msg26167#msg26167 date=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]Nothings stopping them from using several clients targeting a pool. Also that would make it real difficult for pools to work. given that they hash the same way. if you customize it so it would affect pools. then your back at square one since the coin hoppers could just create their own pool.
Also its not that easy for pools to controll this, a “miner” with botnet usage could for instance just create several accounts in a pool an just modifie his botnet controll exploit to target different accounts.Dont underestimate the power of money, theres alot of smart people out there.
Crypto currency is the new way for criminal networks to gain money from you. Either by hacking/stealing your wallet. Or exploit your computer for their mining profit. -
[quote name=“erk” post=“26420” timestamp=“1377634885”]
Zetacoin (ZET) adjusts it’s diff every 4 blocks based on a 90block average, and it gets jumped by ASIC farms coin hoping.
[/quote]But thats Sha256 crypto, thats an entire other ballpark as regarding fluctuation in hashrate.
-
[quote name=“svennand” post=“26423” timestamp=“1377635745”]
[quote author=erk link=topic=3403.msg26420#msg26420 date=1377634885]
Zetacoin (ZET) adjusts it’s diff every 4 blocks based on a 90block average, and it gets jumped by ASIC farms coin hoping.
[/quote]But thats Sha256 crypto, thats an entire other ballpark as regarding fluctuation in hashrate.
[/quote]
they have +1% and -20% for 4 blocks for sure this will move a lot. that is exactly why we say should not go over the 41.4% for 504 blocks. but should be looked at a bit more closely to see the sampling longer then retarget effects. -
[quote name=“erk” post=“26430” timestamp=“1377639240”]
[quote author=svennand link=topic=3403.msg26423#msg26423 date=1377635745]
[quote author=erk link=topic=3403.msg26420#msg26420 date=1377634885]
Zetacoin (ZET) adjusts it’s diff every 4 blocks based on a 90block average, and it gets jumped by ASIC farms coin hoping.
[/quote]But thats Sha256 crypto, thats an entire other ballpark as regarding fluctuation in hashrate.
[/quote] Why? The diff adjustment code for Bitcoin vs Feathercoin looks quite similar.[quote author=svennand link=topic=3403.msg26423#msg26423 date=1377635745]
they have +1% and -20% for 4 blocks for sure this will move a lot. that is exactly why we say should not go over the 41.4% for 504 blocks. but should be looked at a bit more closely to see the sampling longer then retarget effects.
[/quote] Which sounds smart to me, they want to respond smoothly to diff rate increases, but quickly to a sudden removal of hash rate to avoid being stuck at high diff for prolonged periods like FTC, CNC, and other coins have often experienced.
[/quote]Theres just so many asics out there, and its easy if the hashrate isnt at bitcoin level do experience hashrate swings.
Shouldnt we look at pxc and wdc as regarding what happend when they changed the target time to much (due note they have faster block find time). Alot of pools got orphans.
-
asymmetric can be good in linear change, but with longer sampling average it’s used with an amplifier. So they put too much in the same basket.
the 90 block amplify the drop and they get >10 times 20% decrease in a row, then a lot of 1% to go back to high diff where it begin to pass over the 30seconds between block so they let the time between block becomes a bit long for some times(probably with some hash power remove from the network to help as it pass from ~30 sec to around 1 minutes at similar diff. of 14K). so longer time between block begins to accumulate in the 90 block until it get out the fast block found during the ramp up at 1% that where every 10-20 seconds. so short time between block that are 90 old are replace by 1 minutes blocks so several blocks with longer time between block enter the 90 blocks sample and 20% begins to be applied every 4 block until the average 30 seconds is pass over to get new block at 10-20 seconds to compensate for older one. but many -20% are done until they balance the 90 blocks (ex: 30 X 1 minute + 60 X15 sec. = 45 minutes = 30 sec average) to 30 sec average. so they go to 14000 diff back to 1000 and then ramp up 1% at a time back to 14K over a pretty long time with full hash power to maximize block.
the 90 block sampling are a FIFO(first in first out) so older time get out to make place for new blocks, but blocks are used ~22 times in the calculation.
note: this is possibly also amplified by someone playing with block 10 minutes in the future that get 10-20% of the blocks.
