Move FTC to factor four diff swing over 7 days
-
i put here the chart of each algo for the one that don’t have look or understand the spreadsheet. so it show the actual 504 as diverging a lot, 126/504 as diverging mostly as much but as peak with in between points.
126 diverge also just over a smaller range as do (126/504 + 126 ) /2
126, (126/504 + 126 ) /2 and 126/504 with squared weighting. all with a damping factor of .25 converge mostly nicely, i try many formula and all 3 seems to do a pretty good job. 126 damping .25 is the best, but it is more vulnerable to time manipulation. the 2 others are ok.
the source is in this googledoc version of the excel on sheet2
[url=https://docs.google.com/spreadsheet/ccc?key=0ApYFJvIJozEwdDBkZjZibm5LQ0JXYnJ0RmdseGtGUVE&usp=sharing]https://docs.google.com/spreadsheet/ccc?key=0ApYFJvIJozEwdDBkZjZibm5LQ0JXYnJ0RmdseGtGUVE&usp=sharing[/url]edit: i added another one that start nearly at stable and show that without damping the diff naturally diverge when the hashrate change faster then the difficulty
[attachment deleted by admin]
-
Groll, try to set up a 51% attack on your models. No time warps, a simple one for a day. 3GH/s before the attack (columns B to E or keep current), 12GH/s at the attack (columns F to I), 3GH/s after the attack (column J). We get a difficulty trap with 126 blocks averaging whether damped or not. No trap with 126/504 or (126/504 +126)/2, non-damped or damped.
Actually, (126/504 +126)/2 works well with no damping (+/- 27% block target variance). 0.25 damping makes it even better.
-
Taking a look at your scenario I can see that sampling over 504 blocks with adjusts every 126 blocks stops our difficulty getting to high if we come under a hash rate attack. I am very sure we have seen these before to get us into a state ready for further attacks. The attackers would need to spend more time getting our difficulty up.
We need to find the right balance between protection and responsiveness.
Personally I like the idea of the average between a 504 and a 126 block sample.
Considering all the data we now have available can you please make a recommendation Ghostlander?
-
[quote name=“Bushstar” post=“28039” timestamp=“1379073383”]
We need to find the right balance between protection and responsiveness.Personally I like the idea of the average between a 504 and a 126 block sample.
Considering all the data we now have available can you please make a recommendation Ghostlander?
[/quote]Yes, average between 504 and 126 block windows with 0.25 damping seems a very good trade-off and gets my vote.
-
timing of attack is important 504 was going from the b-c-d-e down so next was in range. putting diff 200 and 6Gh/s makes a very different graph(i don’t put 3G but 1G in J and any place where we are below 1Gh/s as we are likely to have mostly only hardcore miner from the high diff) what is interesting is that none is worst then the current 504. but all 126, 126/504, (126/504 + 126/2) got to the same high diff mostly and comes back. I don’t have time to simulate other scenario, feel free to try.
but I agree with Ghostlander using 126-504 sampling mix (as I identify as (126/504 + 126)/2). with damping 0.25 seems to be the best trade off.
Making the damping greater seems to help also as change(including warp) have less impact so more resilient to attack. see the 1/16 at the bottom of the sheet but not in graph. the draw back is the 144% range the adjustment can be too slow(put 1000 as hashrate to get a real time warp for this one)
note: timewarp can’t be solved completly as the timestamp of the block comes from the client. so we need to live with it and NTP don’t solve it as client can change it to what ever they want. to change that the structure of the chain and the protocol need to be reinvented to testify the block time from an external source to the miner.
[attachment deleted by admin]
-
Well this looks to work out well then. As I said I like the 126 and 504 average and we need that .25 damping so this is something that we agree upon.
Let’s get this implemented and running on a testnet. I am going to review the code with Ghostlander.
-
Interesting discussion, I’ve not been keeping up with developments. Can I also say that it was very heartening to see the progress in difficulty adjustment discussion. I have been closing my eyes and crossing my fingers for the past week and hoping for the best.
We are living in a quantum world of the Crypto Currency Big Bang where just discussing possible changes effects the system. I believe the quality of discussion makes that effect positive. I have already shown that the changes only have to be correct to an order of magnitude to work (in and unknown and varying / human / robot controlled / future environment).
I can’t predict the future, but from my analysis Feathercoin is over the bump and starting to accelerate downhill, its gonna take a lot to knock us of course now. Well done.
-
Many altcoins get screwed up when their developers try to come up with “the best, the fastest, the most advanced” settings. Most of these folks don’t even know the story behind Geist Geld.
Meanwhile, [url=https://github.com/ghostlander/FeatherCoin/commit/1f7a9e74895eaa723daea351b6e1a2294b864330]a small patch[/url] to fix broken getnetworkhashps.
-
Thanks for the patch Ghostlander. Can you make the changes on the Feathercoin/Feathercoin repo? You can edit it on the webpage. This will commit it to a temp branch with a pull request for me to accept. Currently I have to commit everything on your fork to pull your last commit.
-
Done. Our master branches are out-of-synch a bit since I’ve committed some of your recent changes myself.
-
this GME code only change the calculation of the hashrate approximation, this is [b]not[/b] involve in retarget calculation. This represent the hashrate average number for 30 blocks in the stats page of FTC, this is used to determine what you will get in the client when requesting the network hashrate in its console.
FTC was 120 and Ghostlander just make a patch to set it to 30 like the stat page (see the change link 5 post ago)
-
[quote] Well Gamecoin (GME) is a lesson in how not to do diff adjustments. [/quote]
There is no other coin in our position. We now have significant Hash rate to make attacks expensive.
We have been a consistent value, for a significant time, on the exchange, so even scammers have built up an investment in FTC.
The software changes have been successful, and have worked to stabilise the coin. Future changes look technically feasible and few side effects; look good to further increase network security. + Its still a community driven, open source coin…
Can I say thanks for that. Well Done.
-
I have pulled the commit from Ghostlander for better default values in the getnetworkhashps function.
https://github.com/FeatherCoin/FeatherCoin/pull/20
I spoke to Ghostlander last week about his branch for 0.6.4.4, there was an issue that he was ironing out. One question which he brought up was how to implement the .25 damping. I have not spent any time on this yet but have been very busy all the same on behalf of our project. If anyone has code they would like to put forward for this then please do and we can incorporate it.
-
when you get the nActualTimespan calculated (in an if for this patch like line 930) you just add 3 full target and then divide it back by 4 so if you get (in hour) 4.25 it is (4.25 +(3*5.25))/4 = 5
[quote]nActualTimespan += 3 * nTargetTimespanCurrent;
nActualTimespan = nActualTimespan/4;[/quote]you can have a nSample in it also depending on how you calculate nActualTimespan (as I have done in the spread sheet as 8 126 sample to construct the 504/126: so (nActualTimespan = (8 sample +(24* nTargetTimespanCurrent ))/32 )
-
[url=https://github.com/ghostlander/FeatherCoin/commit/69ec264e6c2405d4a2048267c2c3221990c25368]Update for 0.6.4.4 beta 2[/url]
Implements a new retarget strategy at block #87948 supporting combined average windows of 126 and 504 blocks with .25 damping. Tested on the livenet to report statistics in 504/2016 mode, seems fine. Ready for testnet.
-
edited: deleted, my mistake the code is ok the new naming just tricked me
-
I’d rather the testing phase irons out any kinks and nicks as to prevent another hard fork a few months from now when we realize the current rushed update wasn’t properly tested.
-
[quote name=“erk” post=“28576” timestamp=“1379643357”]
[quote author=mnstrcck link=topic=3447.msg28574#msg28574 date=1379641688]
I’d rather the testing phase irons out any kinks and nicks as to prevent another hard fork a few months from now when we realize the current rushed update wasn’t properly tested.
[/quote] Nice theory, now the reality, what testing phase?
[/quote]Ghostlander and groll both have been running calculations and simulations on getting the math right. The data is in this thread. Not sure what you’re getting at, maybe you can take the tongue out of your cheek and clarify?
-
[quote name=“erk” post=“28579” timestamp=“1379645562”]
When you test a coin modification you use the coins testnet. To my knowledge that has not been done, and I would imagine there would have been a call for participants.
[/quote]It’s up next re: Ghostlander’s last reply.
-
Speak of the testnet and it shall appear.
