Move FTC to factor four diff swing over 7 days
-
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]).
-
[quote name=“erk” post=“26804” timestamp=“1377957946”]
9% every 126 blocks is too slow, even for a 45sec coin, that’s like 95min. It would be worse on FTC. These hopping pools jump in less than 10min.Just look at the FTC block explorer. [b]When the FTC diff goes up, it typically takes less than 20 blocks before the block time is way too high, it only took 10blocks last time from 74088.[/b] I have punched the timestamps into a spreadsheet and looked at how quickly the changes are occurring. I use a 10 block moving average to smooth out the random fluctuations, and assume the target should be 150sec +/- 10%.
[/quote]That’s it. I’m getting sick of explaining why we really need frequent difficulty adjustments.
-
[quote name=“ghostlander” post=“26803” timestamp=“1377954681”]
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.
[/quote]I never got back to you on this and I should have. I got some peer review of your suggestion without positive result and did not pick it up from there. We should get public feedback of the proposal and trial put it on the testnet. I was very stretched at the time and parked you solution.
[quote author=ghostlander link=topic=3447.msg26803#msg26803 date=1377954681]
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.
[/quote]Technically anything other than real time is not optimal. We want a difficulty patch that does not exclude profit miners and will not affect the market adversely. I am not convinced that your solution can cover those two points in the current crypto climate. I believe that you have a very technical focus but there are broader issues.
The miners want a difficulty fix now and I do not have the time to test and implement your solution to the level I would like to in only a few weeks. Past this upcoming change we have the move to 0.8 which is going to be a huge task on which your help would be greatly appreciated.
[quote author=ghostlander link=topic=3447.msg26803#msg26803 date=1377954681]
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?
[/quote]I know, they have profit miners and next to no loyal miners at the moment. Their recent patch which saw them take a tumble has been a learning experience for them.
[quote author=ghostlander link=topic=3447.msg26803#msg26803 date=1377954681]
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]).
[/quote]Because I’m an idiot. At the top of my head I had Bitcoin at 10 days when everyone knows it is 14 days.
Is there any possible way that you could come to the Feathercoin meet in Oxford? It would be excellent to have you there. Let me know if you need help getting here.
-
[quote name=“Bushstar” post=“26869” timestamp=“1377985988”]
Technically anything other than real time is not optimal. We want a difficulty patch that does not exclude profit miners and will not affect the market adversely. I am not convinced that your solution can cover those two points in the current crypto climate. I believe that you have a very technical focus but there are broader issues.[/quote]Making bet on profit miners is not good. That’s Terracoin way. They will not help us willingly if anything bad happens. Loyal miners will do. All miners don’t mind profits though. However, long term profits come from merchants and institutional investors, and merchants they don’t want large difficulty jumps influencing actual block target to unpredictable levels. It hurts business simply.
If we please loyal miners, we also please real world business people. Some of the coin hoppers will also come. My observation shows that we’ve lost a fairly large share of loyal miners recently. We have less than 15% of them vs. over than 85% of coin hoppers. That’s still 10 times more of what we’ve had in May.
[quote author=Bushstar link=topic=3447.msg26869#msg26869 date=1377985988]
The miners want a difficulty fix now and I do not have the time to test and implement your solution to the level I would like to in only a few weeks.[/quote]Of course they want a difficulty fix. On the other hand, you see 9%/126 doesn’t work well for Phenixcoin with their block target of 45 seconds, and Erk has pointed out that it’s going to be only worse with our block target of 2.5 minutes. Let’s concentrate our efforts on something better. I’m sure we can prepare a couple of models for testnet in just a few days. There are people who can help. If everything goes as planned, we can make a release in 2 weeks.
[quote author=Bushstar link=topic=3447.msg26869#msg26869 date=1377985988]
Is there any possible way that you could come to the Feathercoin meet in Oxford? It would be excellent to have you there. Let me know if you need help getting here.[/quote]I’m doing business currently on the other end of the EU. If I have a chance to get back to the UK some day, I’m sure to pay a visit to Oxford :)
-
erk, agreed, it has to be very fine grained to get us to 2.5 minutes. 252 blocks is too slow and 18% is too big.
Ghostlander, I remember the main concern with the time warp fix was that it would hard fork. Well, we now have a hard fork coming up.
9/126 was a popular idea in the community and I can see no danger in it. I can see this solution being very suitable for some time to come.
erk and Ghostlander are very keen for very fine adjustments. Zerodrama, groll and I see the benefit in a more conventional solution. The majority want to see the 41.4% swing reduced. We can at least please the later to.
I will implement and test the 9/126 code change and Ghostlander’s changes to make time warp attacks more costly and less effective.
-
Peter, would you keep 504 blocks averaging window at least? 126 blocks averaging is too small. We shall be experiencing many 9% swings with it.
-
[quote name=“ghostlander” post=“26917” timestamp=“1378040548”]
Peter, would you keep 504 blocks averaging window at least? 126 blocks averaging is too small. We shall be experiencing many 9% swings with it.
[/quote]Okay, so please help with this conventional solution. 41.4% is too wild but 9% seems agreeable to miners, but with current diff change/block ratio that works out at 9/126.
One of the questions I was getting at in this thread was, do we need to be able to adjust difficulty by 400% over 3.5 block days?
I was hoping that question might lead to a slower adjust that could perhaps be more frequent like 9/252. We cannot have 9/504 or we will be Bitcoin slow.
The question now is that considering the solution at hand, what values would you suggest knowing that 41.4% is too great?
-
41% is too wild if done in one increment over 504 blocks. There is absolutely no problem if we do 41% over the same range in many smaller increments. In fact, we’re unlikely to reach those 41% under regular conditions as coin hoppers will go elsewhere half way if not sooner.
My idea of those increments as small as 12 blocks doesn’t seem to to be accepted warmly. Alright, I can live with it. Let it be 126 blocks. That’s 10x coarser granularity, but still better than 504 blocks at once. I’m not asking for 9% over 504 blocks at once. I’m asking for 9% over 504 blocks every time we retarget at 126 blocks. To be correct, 9% over a moving average of the past 504 blocks. We still maintain factor 4 over 3.5 days.
By the way, 9% is 1.0905077 difficulty limiter with the closest integer pair of 494 and 453. The rest of the patch is a breeze.
[quote name=“erk” post=“26919” timestamp=“1378042506”]
We have already been down this path months ago with the net stats on this site being wildly inaccurate from the averaging being over way too many block. Bush ended up reducing it to 60.
[/quote]Reducing to 30 works even better for the net stats. They’re supposed to show current network hash rate and nothing more. Doing difficulty calculations on such small window is not good.
-
[quote name=“d2” post=“26930” timestamp=“1378049246”]
[b]The smaller the difficulty adjustments, the faster they need to be performed.[/b]
[/quote]Indeed. The question is what averaging window to choose. Small allow for difficulty spikes, large are too slow. 504 blocks linear seems to be a very good choice. Maybe 2K blocks EMA (exponential moving average) window is also good, it needs to be researched further and we’re out of time.
Here is a graph of our network hash rate and difficulty for the last 2 weeks. We’ve had about 1.7GH/s of loyal miners and 9GH/s (12GH/s peak) of coin hoppers. 15% vs. 85%
[attachment deleted by admin]
