Someone is dumping a lot of sexcoins right now, and I'm buying
Ok, we've patched the KGW TimeWarp Attack bug and it's been a week and a half or so..... and I still see the same thing happening as described above.
I'm assuming we are not being hit with some non-public KGW attack, and that we are looking at "normal" results of mining power being switched on and off (as the OP stated, "difficulty adjusts waaaaaaaaaaaay too fucking slowly").
I say "normal" because it seems to me that we are not really exceeding the blocks per day as designed ( 1440 blocks per day). Here is a one liner that shows 1440 blocks(target blocks per day) per sample (row) being pretty close to every 24 hours:
sxcer@dev:~$ DAYS=21 ; curl -s http://sxcexplorer.com/chain/Sexcoin/q/nethash/1440/-$((DAYS*1440)) | sed -e '1,/START DATA/d' | awk -F, '{ printf "%8d " , $1 ; system("date -d @"$2)}'
631906 Thu May 1 00:25:31 EDT 2014
633346 Fri May 2 01:10:28 EDT 2014
634786 Sat May 3 01:32:53 EDT 2014
636226 Sun May 4 01:23:27 EDT 2014
637666 Mon May 5 01:29:34 EDT 2014
639106 Tue May 6 02:05:33 EDT 2014
640546 Wed May 7 01:25:28 EDT 2014
641986 Thu May 8 01:49:18 EDT 2014
643426 Fri May 9 01:36:52 EDT 2014
644866 Sat May 10 02:08:16 EDT 2014
646306 Sun May 11 02:12:47 EDT 2014
647746 Mon May 12 02:19:38 EDT 2014
649186 Tue May 13 01:25:35 EDT 2014
650626 Tue May 13 23:18:49 EDT 2014
652066 Thu May 15 01:34:49 EDT 2014
653506 Fri May 16 02:03:18 EDT 2014
654946 Sat May 17 03:20:43 EDT 2014
656386 Sun May 18 01:32:07 EDT 2014
657826 Mon May 19 01:18:56 EDT 2014
659266 Tue May 20 01:22:10 EDT 2014
660706 Wed May 21 01:27:50 EDT 2014
sxcer@dev:~$
Here's a direct url to the raw data used above, showing 21 days of raw data represented above with all data fields and API notes etc:
http://sxcexplorer.com/chain/Sexcoin/q/nethash/1440/-30240You can analyze the data any which way but I think you will see that the blockchain is not producing more coins per day or even per 4 hours than designed.
What seems to be actually happening is the target block rate of 1 block per minute is greatly exceeded(say 10 blocks per minute) for a minute or two, then greatly reduced for a longer period. Eventually the cycle repeats, 10blocks/min for a minute or so, then 2-5 minutes per block for a while.
Looking at the KGW algo, there is a effectively a "lag" in the adjustment. The lag is a product of the averaging window for calculating block rate. As an example consider driving a 60 mile trip with a checkpoint at each mile marker and a goal of driving 60 miles per hour. I could pass a mile marker every 60 seconds... but:
You could travel 120 Miles per hour for 29 minutes, then sit at mile marker 58, until 58 minutes elapsed, then proceed at 60 miles per hour to finish exactly on time.... passing mile marker 60 at 60 minutes elapse.
How fast did you go?
You went and average of 60 miles per hour for 1 hour. You also went an average of 120 for 30 minutes and and average of 60 for 2 minutes. I think you see the point.
While Sexcoin difficulty now adjusts per-block using the KGW algo, the adjustment is not based on the previous block alone. In the KGW forumla the number of blocks the adjustment is based on can vary..... call it PastBlocksMin and PastBlocksMax.
The reported issue comes down to PastBlocksMin.
Sexcoin long ago copied KGW code direct from Megacoin. The only change was to the TargetSpacing... setting it to 60 seconds. There are other values that might work better for us if they were changed also.
I'm not sure that proportionally changing them will actually squash the current mining "issue". I haven't analyzed it enough to say... yet. I started down this path long ago with a KGW simulation i worked on at
http://insightmaker.com/insight/13295 but I never finished it.
Anyway, here's sexcoin's current values which are just duplicates of megacoin, except the targetspacing, which is actually what causes the minimum blocks value to more than double.
static const int64 BlocksTargetSpacing = 1 * 60; // Sexcoin 60 seconds
unsigned intTimeDaySeconds = 60 * 60 * 24; // 86400 Seconds
int64 PastSecondsMin = TimeDaySeconds * 0.25; // 21600
int64 PastSecondsMax = TimeDaySeconds * 7; // 604800
uint64 PastBlocksMin = PastSecondsMin / BlocksTargetSpacing; // 360 Sexcoin Blocks
uint64 PastBlocksMax = PastSecondsMax / BlocksTargetSpacing; // 10080 Sexcoin Blocks
You can calcluate the above values for a 2.5 Minute target spacing coin as
BlocksTargetSpacing = 150 Seconds # 2.5 Minutes for Megacoin
PastBlocksMin = 144 Blocks # from 21600/150
PastBlocksMax = 4032 Blocks # from 604800/150
As you can see, Megacoin has a minimum blockrate averaging window of 144 blocks, whereas sexcoin's is 360 blocks... this is due to only altering the targetspacing, while leaving PastSecondsMin the same as Megacoin.
Basically PastSecondsMin is the determining factor of the "minimum averaging window in time" .... while BlocksTargetSpacing dictates how many blocks are in that window.
What should Min and Max be?... I'm not sure. That was what I wanted to simulate with the insightmaker simulation but never finished. I was going to simulate various hashrate pools jumping on and off and see how things worked.
To start with I'd say.... 60/150 is the ratio of blockspacing times, so call that .4 and adjust the Min and Max window times by the same
PastSecondsMin= 86400 * .25 * .4 = 8640 = 144
PastSecondsMin= 86400 * 7 * .4 = 423360 = 4032 Blocks
Hey, that works out to the same block counts as Megacoin
Further, if you look at the Kimoto Formula:
EventHorizonDeviation = 1 + (0.7084 * pow((double(PastBlocksMass)/double(144)), -1.228));
You see that 144 figures prominently as the denominator..... I'm up way to late to graph that out now but I'm very interested in the effect that has on things when the other factors are 360 and 10080.
Essentially the KGW looping process of averaging over previous blocks one at a time will quit once the average exceeds the EventHorizonDeviation calculated each loop (for each additional block averaged over, PastBlocksMass).
So you can see the base of that pow() shoudl be 1 when the looping average has hit 144 blocks.... which is the minimum # of blocks to aveage over... but in our current case with fubar values the base will be 360/144.
that should produce a higher adjustment rate? but then again it's averaged over 360 blocks
So should PastBlocksMin stay at 360 or move to 144 ?
I'd say pastminblocks should be lower (144) since we are a fast blocktime coin we should not have the same 6 hour window of averaging that a 2.5 minute coin (megacoin) does.
Code links for the stuff discussed above:
Megacoins PastSeconds{Min,Max}
https://github.com/megacoin/megacoin/blob/master/src/main.cpp#L1340Sexcoins PastSeconds{Min,Max} copied verbatim from Megacoin source code
https://github.com/sxcer/sexcoin/blob/master/src/main.cpp#L1110Megacoins Kimoto Equation with 144 in denominator based on their TargetBlockSpacing and desired PastSecondsMin and/or PastBlocksMin
https://github.com/megacoin/megacoin/blob/master/src/main.cpp#L1309Sexcoins Kimoto Equation copied verbatim with 144 as denominator based on block time of Megacoin
https://github.com/sxcer/sexcoin/blob/master/src/main.cpp#L981
it is alive and being traded although in volumes that could be a lot better.
