Move FTC to factor four diff swing over 7 days
-
I like we are now moved to discussing this, fixing the Difficulty equation for our present Hash Rate variability.
-
18%/504 doesn’t seem to be a solution worth a hard fork. Not much advantage over 41%/504 we have now. More frequent small adjusts are better.
Real time difficulty adjustments are performed every block. May look extreme somewhat, but it is a very good idea in general especially with high block targets like 10 minutes. It is not necessary for lower block targets such as our 2.5 minutes. I have considered values between 4 and 24 blocks (10 to 60 minutes respectively) and come up with 12 blocks (30 minutes). I still think it will do the best for Feathercoin.
[quote name=“Bushstar” post=“26464” timestamp=“1377684537”]
Bitcoin moves by a factor of four every 10 days.
Litecoin moves by a factor of four every 2.5 days.
Feathercoin moves by a factor of four every 2.5 days.If we moved half way between the two then we can have a factor of four change every 5 days which would give us the adjust of around 18% every 504 blocks.[/quote]
Every 3.5 days actually. 1.4142^4=4 and 4*21/24=3.5 days. If 1.4142 (41%) difficulty limiter over 504 blocks does well for us in general as proven by numerous attacks and pumps/dumps on exchanges, why to change it? We only need to tune it up a little for more frequent adjustments to make loyal miners happy.
-
Sorry for the late response - up to eyeballs with work. :-[
18% in one jump is still a fairly large swing and would almost certainly trigger all of the multipools simultaneously. If there is anyone on here that is capable of running some models of what the adjusts would mean in terms of surge mining then that would be great.
Wrapper0feather - you spring to mind! ;)
Can you (or anyone with a mental capacity higher than that of a staple gun) produce some models that show what the impact of various retarget blocks / percentages would look like when mixed with the hash surges so we have a graphic view? If we have a swing that is large enough to trigger the mutlipools on every diff change, we’ll still see the same hashrate jumps and therefor block target variance.
The truth is i don’t think anyone knows what will work until we try it but simulations may help.
I like the idea of quick, small retargets based on large sample times but would this potentially lead to diff increases whilst the hashrate drops due to a delayed effect? This could then potentially hit us even harder if we happen to have a price slump at the same time as an increase.
edit: I’m inclined to agree with ghostlander that 41%/504 works overall which is why i suggested 9% every 126blocks. Again though i think we need some models to show what effect the surges and more subtle increase do. for instance it may be that we only trigger one mutlipool not all so that we only have a small hash surge which isn’t enough to bounce the diff off of the limiters.
-
[quote name=“Nutnut” post=“26590” timestamp=“1377785876”]
Sorry for the late response - up to eyeballs with work. :-[18% in one jump is still a fairly large swing and would almost certainly trigger all of the multipools simultaneously. If there is anyone on here that is capable of running some models of what the adjusts would mean in terms of surge mining then that would be great.
Wrapper0feather - you spring to mind! ;)
Can you (or anyone with a mental capacity higher than that of a staple gun) produce some models that show what the impact of various retarget blocks / percentages would look like when mixed with the hash surges so we have a graphic view? If we have a swing that is large enough to trigger the mutlipools on every diff change, we’ll still see the same hashrate jumps and therefor block target variance.
The truth is i don’t think anyone knows what will work until we try it but simulations may help.
I like the idea of quick, small retargets based on large sample times but would this potentially lead to diff increases whilst the hashrate drops due to a delayed effect? This could then potentially hit us even harder if we happen to have a price slump at the same time as an increase.
edit: I’m inclined to agree with ghostlander that 41%/504 works overall which is why i suggested 9% every 126blocks. Again though i think we need some models to show what effect the surges and more subtle increase do. for instance it may be that we only trigger one mutlipool not all so that we only have a small hash surge which isn’t enough to bounce the diff off of the limiters.
[/quote]+10,000
-
Thanks Nutnut for your concern, you said what I thought you would say, that 18% is still too great. I feel this to but perhaps you can see where the last proposal of a quicker diff adjust and a swing by times four over fives days can come in.
Moving to a swing of times four over five days seems agreeable as Litecoin’s swing is very fast and Bitcoins is glacial. The sweet spot is in between the two.
If we move to five days for times four diff swing and simply halve the blocks to a difficulty adjust then we get 9% over 252.
What I want to do is get a more agreeable solution in very soon. I am wary of real time difficulty adjusts because of potential vulnerabilities that could be exploited and the effect that it may have on the market.
-
Moving to really fast adjusts has seen other coins find unexpected problems. I would prefer to see us move to an agile solution slowly rather than find ourselves in hot water. I believe that halving the difficulty adjust time and halving the amount the difficulty can swing is a big step already and will take us much further from the original design of times four difficulty over 2016 blocks.
I’m sure we’ve had this discussion before erk on the last difficulty change. Perhaps we’ll have to disagree very fast difficulty adjust for now but we can agree that we need an improved difficulty solution. The last change proved that there was a better solution and now we can work on getting closer if not find the most suitable difficulty solution.
-
Re. all this bitching about our difficulty swings. The mother of all Scrypt coins, Litecoin, has also huge swings.
[img]http://img580.imageshack.us/img580/9558/rn12.png[/img]
Take away the MtGox bonus and they’d be screwed.
-
[quote name=“Bushstar” post=“26724” timestamp=“1377872176”]
Moving to really fast adjusts has seen other coins find unexpected problems. I would prefer to see us move to an agile solution slowly rather than find ourselves in hot water. I believe that halving the difficulty adjust time and halving the amount the difficulty can swing is a big step already and will take us much further from the original design of times four difficulty over 2016 blocks.
[/quote]Frequent adjusts with large window and appropriate difficulty limiter are harmless theoretically and I see no unexpected problems to address in practice. 1% over 12 blocks may deliver 52% max. difficulty change (1.01^42=1.5188) over 21 hour (~504 blocks) interval in small increments. We keep the same 21 hour window to look back for difficulty calculations, so no bad surprises there.
Moving from 41%/504 to 20%/252 seems a waste of hard fork. Limited short term effect. Better maintain the status quo and get used to it if we cannot agree on an innovative model to make Feathercoin look really different from Litecoin.
-
From a miners perspective moving to a 9% difficulty shift from a 41.4% difficulty shift is essential and it would have prevented from being mined up so high and left where we are now.
We are going to fork but we are not moving to a real time difficulty adjust, not in the next month anyway.
-
[quote name=“Bushstar” post=“26740” timestamp=“1377883350”]
We are going to fork but we are not moving to a real time difficulty adjust, not in the next month anyway.
[/quote]If you have decided already on the fork and the details, what’s the purpose of this debate? Use your powers and do the job. I haven’t received your arguments against my model though.
-
Ghostlander, I am saying that there are real concerns. TRC went from 0.004 to 0.0014TRC/BTC in the markets over their effort for fast adjusts. They had to hard fork a total three times over it in total and got attacked over a flaw in their code. Not only that but Terracoin has lost its profit miners with its new algo. I am not saying that your model has these flaws but I’m very sure that the TRC devs did not see the flaws either.
More than anything else their effort removed the for profit miners from the equation completely and that does not seem fair to me either. I have been both in the past and mining is where my enthusiasm started for crypto.
-
[quote name=“erk” post=“26714” timestamp=“1377863672”]
I vote for frequent small changes. Not overly fussed about the exact formula, as long as it feels smooth, not these aggressive jumps we have now. I think 9% over 252 blocks is too slow, that’s over 10hrs between adjustments, more than enough time for people to leave. Something every 100 blocks would be better as 100 is easy to remember when the next change is about to happen. Honestly, if it was up to me I would be going for +/-2% every 10 blocks just to be ultra smooth.I don’t really understand why diff changes can’t be small and fast, to the point where they are largely ubiquitous.
[/quote]We are in a pump and dump world. There would be no reason to buy more hardware if the diff jumped before you could even install it. Real time change is for when we actually use it. Going from one extreme to the other gets you the same results. Smooth is bad. Gaps are profit. We are uncomfortable because we’re not buying or selling.
-
Terracoin is a bad example to start with.
First of all, TRC is a SHA-256 coin without ACP or PoS. It has been very vulnerable to ASIC attacks in the past and still is to a lesser extent. We are in a different position.
When TRC was started, they imported the code from BTC in October of 2012, changed some variables and left many unchanged. They set up block target of 2 minutes and retarget frequency every 30 blocks. They were unwise enough to operate 1 hour (30 blocks) averaging window and difficulty limiter of 4. They also didn’t care to address the time warp exploit properly which was critical at their settings. So, they were asking for a trouble right from the start.
Avalons came and brought the trouble in March of 2013. Sunny suggested to increase the averaging window to 1 day (720 blocks). They did so initially ([url=https://github.com/terracoin/terracoin/commit/300d6ac14fd5aaa6a71e14090fa72b1b1d029488]patch 1[/url]), and screwed up very soon to keep teasing miners ([url=https://github.com/terracoin/terracoin/commit/bbb25e650b8306ec89282eb340e1fb16f59061d8]patch 2[/url] and [url=https://github.com/terracoin/terracoin/commit/6d18a667fa7f98eaaccab2d5f155b257cbf204e0]patch 3[/url]). Neither 90 blocks linear window with 30 blocks retarget nor 2016 blocks exponential window with 1 block retarget really helped them. They tried many tricks, even banned IP subnets of top BTC pools and attackers, but couldn’t make it well anyway. Their last hard fork brought in settings very much like BTC. Game over. No ACP, no PoS, and no glory.
We have nearly nothing in common with Terracoin. Their network is 0.05% of Bitcoin by hash power. That’s 2000 times difference. A mid-range ASIC miner can screw them without much effort. We can learn from their mistakes, but to decline frequent difficulty recalculation solely due to Terracoin failures doesn’t seem reasonable.
[quote name=“zerodrama” post=“26760” timestamp=“1377897696”]
We are in a pump and dump world. There would be no reason to buy more hardware if the diff jumped before you could even install it. Real time change is for when we actually use it. Going from one extreme to the other gets you the same results. Smooth is bad. Gaps are profit. We are uncomfortable because we’re not buying or selling.
[/quote]That’s what coin hoppers think. Loyal miners tend to disagree. If you lose them, say good bye.
By the way, smooth is also good for block target. Haven’t you forgotten that the primary purpose of all these difficulty matters is to make actual block targets as close to nominal block targets as possible? At any moment of time.
-
I was looking to Ghostlander idea and found it interesting using a frequent change over a larger sample. (the large sample remove most of the time warp and luck issue of small sample)
But after analyzing zetacoin (a small summary of finding here http://forum.feathercoin.com/index.php?topic=3403.msg26437#msg26437). I’m not sure this would work great as the larger sampling amplify past event and current trend is taken only when it compensate past trend so past swing are “echo” and produce swing in the future. yes zetacoin has a way way too big change so it goes wild. but it prove that larger sampling can add some amplification of past event in the present.
for fast retarget, the 2 biggest problem other coins have suffer are. too fast change change that are way over the 41.4% for 504 we have. the second one is time wrap. ACP will protect us against constant time warp as you need to orphan valid time block on retarget to abuse it fully. but a partial abuse will still be possible using large hash power. as the time manipulation of the future 2h can be used several time in a fractional to get 100% the retarget effect and one time to reset it.
What that means for example 12 blocks: You can make for example 4 retarget to lower diff when it should go upper using 0.5h in future then 1h then 1.5h and 2h in future for 4 blocks retarget(yes been unable to orphan block makes this really working mostly only if you have the majority of hash power) to get the full retarget in each. the addition of .5h would be enough to make the calculation the opposite of what it should have been. the fifth blocks would just make a single correct time or in the past to restart the same process within the limits. so you get 3 extra lower diff on each cycle. the reverse to make it go to high diff is also possible using past time.so time warp and diff should be address in pair the actual 2h future and 6 block back time median would make retarget below 100 blocks vulnerable to time warp over a long period of time manipulation even with ACP. [b]the continuous time warp in the past/future will still be possible with ACP[/b] so how it is solved can impact the acceptable retarget sampling
smaller change in diff, changing the rate to 18% over 504 can be good to 9% over 504 would be probably bad as it would no longer be fast enough to compensate in a timely way. as a drop in price of nearly 50% we see in the last week 0.0020 to 0.0010 would keep us in too high diff for way too long for the profitability. causing potentially greater problem then what is try to be solved.
so the Bushstar proposal of 18% over 504 or 9% over 252 seems border line to be fast enough. going bellow this ratio would add risk to take too long to react to some event.
[quote]We are in a pump and dump world. There would be no reason to buy more hardware if the diff jumped before you could even install it. Real time change is for when we actually use it. Going from one extreme to the other gets you the same results. Smooth is bad. Gaps are profit. We are uncomfortable because we’re not buying or selling.[/quote]
gaps are profit only if your a hoppers. gaps are lost for steady miner. gaps are also bad for business as you get variation in the confirm time of transaction. I usually buy more when i have a steady stream of revenue than when i have big variation in my revenue and unpredictable revenue in the future. BTC and LTC have way smoother curves and it works well. i don’t see why it would be bad for FTC to have a smooth curve especially as FTC want to be something different than just a pump and dump alt.
-
Although I agree the rises and falls are profits if we only plan of thinking of crypto as a commodity. But the reality of wanting mass adoption of public or the use of merchant services relies in the smooth and consistent. Realistically attracting more investors in the process. Its hard to explain to a potential merchant that this transaction should process in a few minutes, or ten, or one, or ten…
The large sway in diff makes miners jump on and off (fair enough)… but its adjust tends to compound the time per block. As diff goes up 41% the time per block can go up 300%, and time to adjust looked like 24hrs is now 3 days…its a snowball effect.
My thoughts are with future stable adoption
-
groll and zerodrama also have concerns about real time difficulty adjusts. This is not the right time to go with real time difficulty adjusts so let’s move on from that discussion please.
The concern is that 18/504 or 9/252 is too slow to move when there are large shifts in the market. In short no one likes my idea of moving to 400% over 5 days so we’ll stick with 400% over 2.5 days.
On the other difficulty threads the most popular “conventional” solution was 9/126.
I suggest that we go with this a week after ACP is in.
-
At the risk of stating the obvious - what’s so bad about my previous suggestions of 9/126?
I’t nimble enough to adjust to big swings in the market and hash rate and there’s enough time for profit miners to make a quick a buck and move on. And above all, ultimately we are at the same overall max adjusts as currently.
…Or should i get my coat?
-
[quote name=“Bushstar” post=“26787” timestamp=“1377934884”]
groll and zerodrama also have concerns about real time difficulty adjusts. This is not the right time to go with real time difficulty adjusts so let’s move on from that discussion please.The concern is that 18/504 or 9/252 is too slow to move when there are large shifts in the market. In short no one likes my idea of moving to 400% over 5 days so we’ll stick with 400% over 2.5 days.
On the other difficulty threads the most popular “conventional” solution was 9/126.
I suggest that we go with this a week after ACP is in.
[/quote]And some how i completely missed this post! Still - good to know we’re both singing from the same hymn sheet. :D
-
[quote name=“Nutnut” post=“26796” timestamp=“1377948328”]
[quote author=Bushstar link=topic=3447.msg26787#msg26787 date=1377934884]
groll and zerodrama also have concerns about real time difficulty adjusts. This is not the right time to go with real time difficulty adjusts so let’s move on from that discussion please.The concern is that 18/504 or 9/252 is too slow to move when there are large shifts in the market. In short no one likes my idea of moving to 400% over 5 days so we’ll stick with 400% over 2.5 days.
On the other difficulty threads the most popular “conventional” solution was 9/126.
I suggest that we go with this a week after ACP is in.
[/quote]And some how i completely missed this post! Still - good to know we’re both singing from the same hymn sheet. :D
[/quote]Same.
-
[quote name=“Bushstar” post=“26787” timestamp=“1377934884”]
groll and zerodrama also have concerns about real time difficulty adjusts. This is not the right time to go with real time difficulty adjusts so let’s move on from that discussion please.
[/quote]These concerns are resolved as they have been discussed already over a month ago and again. Risk of time warp attacks is minimised by reducing allowed future time from 2 hours to 30 minutes and increasing median sampling of the past blocks from 11 to 49 blocks (4 retargets 12 blocks each + 1 block).
http://forum.feathercoin.com/index.php?topic=2866.msg26089#msg26089
http://forum.feathercoin.com/index.php?topic=2847.msg22378#msg22378It makes me wonder why me, Groll, Wrapper and others try to develop solutions to improve Feathercoin if we get ignored? You could at least try our suggestions on the testnet or we can even set up some dummycoin for testing and even simulate a 51% attack with time warp on it.
I’m not saying that my model is perfect. If anyone wants to contribute and their suggestions prove to be superior, I accept them gladly. All I’m asking is to do extensive testing on various models before deciding on the hard fork. I wonder at your unwillingness to cooperate and pushing your settings which are clearly not optimal.
By the way, about 9% over 126 blocks settings. Phenixcoin switched to them yesterday. No miracle happened and they are raided by coin hoppers still. Most of the coins generated go straight to Cryptsy to be sold for BTC and the price is near bottom (0.00006 while it was reaching 0.00060 just 2 months back). Their network hash rate jumps between 30MH/s and 700MH/s. Actual block target also jumps wildly between several seconds and several minutes literally vs. 45 seconds nominal. How come do these settings work well for Feathercoin if they work bad for Phenixcoin?
And one more thing. Why do you keep mentioning 2.5 and 5 days for factor 4 difficulty increase? I’ve [url=http://forum.feathercoin.com/index.php?topic=3447.msg26589#msg26589]pointed out[/url] already that our factor 4 is 3.5 days and has always been (Sunny’s [url=https://github.com/FeatherCoin/FeatherCoin/commit/1f97245f17c92ad622955703a649c108757ed834#src/main.cpp]1st patch[/url]).
