Regarding Auroracoin TW exploit (Fix included)

[Cryddit]

 Almost every single one block difficulty adjustment algorithm contains a flaw with regard to timestamps, and if miners are not mining to secure the network, the coin will be forked.

Absolutely, it seems as if finally somebody understands this.

Anything where someone has 51% or more of the hashing power will go down to a 51% attack, of course.

But with timewarp, specifically, doesn't the attacker depend on being able to fool the code that estimates the hashing power in a chain?

If that code were producing an accurate estimate, then it shouldn't matter where you can get the difficulty via timewarp or anything else.

[1714047449]

1714047449

[1714047449]

1714047449

[1714047449]

1714047449

[Nite69]

One problem with difficulty readjustment is that is is designed to adjust the difficulty based on real block calculation times. It's symmetry causes difficulty to rise exponentially if time difference between blocks approach to zero.

Maybe this kind of symmetry gives better protection against time manipulation? Or is it even worse? (this area is full of mines..).

Code:

unsigned int static QuickRetarget(const CBlockIndex* pindexLast, const CBlock *pblock, uint64 TargetBlocksSpacingSeconds) {
	const CBlockIndex  *BlockLastSolved				= pindexLast;
	const CBlockIndex  *BlockReading				= pindexLast->pprev;
	if (BlockLastSolved == NULL || (BlockLastSolved->nHeight == 0)) { return bnProofOfWorkLimit.GetCompact(); }

	int64 LatestBlockTime = BlockReading->GetBlockTime();
	int64 targetTime = LatestBlockTime + TargetBlocksSpacingSeconds;
	int64 timeDiff = BlockLastSolved->GetBlockTime() - targetTime;
	if (timeDiff == 0) { // no need to change difficulty
		return  pindexLast->nBits;
	}
	CBigNum bnNew;
	bnNew.SetCompact(pindexLast->nBits);
	if (timeDiff > 0) { // slower, speed up by reducing difficulty -> increase nBits
		int64 adjustment = timediff / 4;
		// limit max adjustment to half the difficulty 
		if (adjustment > TargetBlocksSpacingSeconds) adjustment = TargetBlocksSpacingSeconds;
		bnNew *= (TargetBlocksSpacingSeconds + adjustment);
		bnNew /= (TargetBlocksSpacingSeconds);
	} else /* timeDiff < 0 */ { // faster, increase difficulty -> reduce nBits
		int64 adjustment = -timediff / 4;
		// No need to limit this one
		bnNew *= (TargetBlocksSpacingSeconds);
		bnNew /= (TargetBlocksSpacingSeconds + adjustment);
	}
	return bnNew.GetCompact();
}

[Nite69]

Honestly you guys should quit trying to fix this and switch algo.


~BCX~

:-D Frankly, do you see this as a new desperate attempt to fix something which is not fixable or do you see this as a new algorihtm maybe avoiding some of the flaws previous ones have?

This is basicly dogecoin's digishield with 2 main differences;
1) in dogecoin the reference point is difference between 2 latest block's time. In this algorithm the reference point is difference from the targeted time.
2) this does not limit the maximum adjustment (I think doge limits too much) that much.

Let's assume 10 minute target time and a block generated 1 min after previous, Fundamentally, Digishield (and all other retargets) considers it has been calculated with 10x hashing power and it should basicly increase the difference to 10 times higher (10/1). This algorithm considers it is 9 minutes too early and adjusts the difficulty just the same amount compared to a block which is 9 minutes too late. The adjustment would only be 1+(9/10) = 1.9. 

I must admit that for adjusting the hashing power, digishield is actually more accurate. But is it substantially better? Is this better against random time variance and intentional time manipulation? Does this open some new attack vectors? Maybe?

Downwards the adjustemtn would be the same, 10 times longer calculation times means 1/10 of the difficulty.

[Cryddit]

You can adjust difficulty every block, but you should take more than one block of history into account when you do.  Here's a simple algorithm for rapid emergency adjustment; you could use this in addition to a periodic fine-tuning adjustment, if you want. 

For a rapid emergency adjustment, look at the five, nine, and seventeen block average times.  If they are *all* too short (say, 3/4 of your desired interval or less) then adjust difficulty 20% upward.  If they are *all* too long (say, 4/3 of your desired interval or more) then adjust difficulty 20% downward.   You can make an adjustment every block, and the miners can lie about block completion times as much as they do now, but it won't be possible for them to drive the difficulty down while getting blocks faster than the interval time. 

Five, Nine, and Seventeen - because none of them divides any other, guaranteeing that no short repeating pattern of timestamp lies exposes a harmonic that will repeatedly allow them all to be mistaken in the same direction at the same time. You could use a different set, or more than three intervals, but whatever.  I'd advise against using something smaller than 5 as your smallest interval, if you're keeping the median-of-last-11-blocks rule.  Also, because although the shortest interval is your reaction time in *stopping* adjustments once the right difficulty level is reached, shortening it also increases the frequency with which natural time variation will stop a needed adjustment from being applied and how often someone lying about blocktimes can deliberately *prevent* a needed adjustment from being applied. 

20% adjustments up  or down because the 6:5 or 4:5 ratios of speed are closer to 1 than the 4:3 or 3:4 ratios that trigger the adjustment - so adjustment is guaranteed to 'damp' automatically rather than entering hysteresis (alternately overshooting in both directions).

When burst miners jump on with massive hashing power, there's a slight delay before the reaction starts as enough too-short intervals build up to 'tip the scales' of the averages.   But then block adjustments start happening *OFTEN,* and there is no pattern of timestamp lies that can do more than slow it down a little bit.  When difficulty reaches the "right" level, the adjustments quickly stop when the shortest interval saturates with appropriate-length blocks, and there is no pattern of timestamp lies that can keep it on average more than one adjustment off of where it's supposed to be.

Likewise when they jump back off again, there's a delay as enough too-long intervals build up to tip the scales of the running averages, but then difficulty adjustments start happening *OFTEN*, and once again there's no pattern of timestamp lies that can do more than slow it down slightly.  Again, when difficulty reaches the "right" level, the adjustments quickly stop because the shortest interval quickly saturates, and there's no pattern of timestamp lies that can hold it more than one adjustment off of where it's supposed to be.

If with any set of timestamp lies you can generate more blocks than the rest of the network with this adjustment algorithm in less time, you're within a few percent of being able to mount a "real" 51% attack anyway. 

[astor]

You should start with some control theory when adjusting difficulty.

I suggest looking at a Kalman filter first.  It is provably the optimum when the noise is random.  It is just a few multiplications and is easy to implement in a few lines of C.

But at a high level, don't try to write this in a small C function.  You have trillions of clock cycles between blocks, fork out some $$$ and write a decent high level implementation.

Why not add something like liboctave or R to the source code?  Then you could use ready-made implementations of these things.

In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct.

In addition to this error, you have a noise generator which represents your inability to control correctly.  The kalman filter will over time adjust and learn the standard deviation for the noise and thus apply the optimum error correction (adjustment to difficulty).

What you generally need to estimate is the correlation matrix between the variables in your model.

You want your underlying model to be as simple as possible, but also as correct as possible.  Some variables in a model could for example be:  the % increase in issued coins by a block, the difficulty, the difficulty error (difference from ideal inter-block time), the estimated hashing power of the network (which requires a separate model to estimate), the relative exchange value wrt bitcoin, etc.

You also need to estimate the correlation matrix between these variables, but this is mostly to make the filter more efficient.  You can set the correlations to 0 if you want.


A last point I want to make is that hard forks are not bad.  It has been shown again and again that bitcoin does not solve distributed consensus.  Both because the amount of computing power is unknown, and more politically because hashing power is already too concentrated.  Changing the algorithm on a deployed coin is something the users/developers of the coins control, not the miners, unlike what people tend to believe.  It doesn't matter how much hashing power an attacker has if he refuses to run the same algorithm as the users of a coin requires.

[x_static]

I invite you all to smack around Dobbscoin a.k.a. BOB, some.  It also uses KGW, has the fix in the OP applied, but it's running some settings we like to call BOB's Wormh0le, with a much smaller event horizon window.  Not intended to be the be all end all answer...  It's still KGW.  But putting something a little different out there, that we might be able to learn from.  Yeah, there is practically no hash on the coin, so it won't take much to hammer it, so try not to hit it too hard and just shatter it.  Though, at the end of the day, we're not trippin.  Checkpoint, increment versions, rebuild, release...  It'd be nicer if you didn't try to completely ruin the fun for everyone.  I'm thinking we're most susceptible to a difficulty walkup.  Haven't really tested it.  Figure some of you all might be better equipped to accomplish the task of exposing flaws with excellence.  BTCBob will probably get mad at me for posting this.  But hey...  Anyone down to hammer the h0le?  Heh heh...  Them other Bobbies will probably freak out if they see some huge diff spikes... LOL

Dobbscoin Homepage

Latest Dobbscoin Release

Dobbscoin Source

Dobbscoin Block Explorer (might be interesting to compare to Auroracoin block explorer)

Dobbscoin Home Pool

Dobbscoin SMF

#dobbscoin on FreeNode

P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.

[ghostlander]

Been looking for a decent replacement to the PPC every block retarget algorithm. KGW, DGW, DigiShield, whatever else does no good. Have got the job done myself finally.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Re-targets every block with separate fixed targets for PoW and PoS. Two averaging windows (short of 5 blocks and long of 20 blocks), both are limited against time warping. Interwindow averaging and 0.25 damping with the final +1% / -2% difficulty limiting. Runs fine so far.

P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.

OMFG, this Bobcoin spam is now here at Bitcointalk. This annoying Coingen nonsense will get killed some day. The sooner is the better.

[x_static]

Been looking for a decent replacement to the PPC every block retarget algorithm. KGW, DGW, DigiShield, whatever else does no good. Have got the job done myself finally.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Re-targets every block with separate fixed targets for PoW and PoS. Two averaging windows (short of 5 blocks and long of 20 blocks), both are limited against time warping. Interwindow averaging and 0.25 damping with the final +1% / -2% difficulty limiting. Runs fine so far.

P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.

OMFG, this Bobcoin spam is now here at Bitcointalk. This annoying Coingen nonsense will get killed some day. The sooner is the better.

LOL, this from the guy who can't even compile a release quality wallet.  DLL's included in the Zip for your pleasure, right?  LOL

Over at Dobbscoin, we release a full compliment of Wallets with each update.  Built to Bitcoin standards.  Not this frankenstein build system built, windows wallet only garbage that you and Shakezula seem to have pioneered.  You and your cult of crapcoin are the ones who will be dying off soon.

After a quick look at your Orbitcoin block explorer, it would appear your coin generation is all over the place.  Nowhere in the realm of where they should be for what you claim the targets are.  For PoS or PoW.

P.S. To BCX and other "testers"...  Orbitcoin is most definitely worthy of annihilation...  Feel free to hit Dobbscoin just as hard...

[ghostlander]

LOL, this from the guy who can't even compile a release quality wallet.  DLL's included in the Zip for your pleasure, right?  LOL

libstdc++ and libgcc_s_dw2 are regular 32-bit MinGW runtimes, no real need to compile them in. In fact, this executable has even these two compiled in after a project file update. All other non-system dependencies are also built in. A cheap insult, piss off.

Over at Dobbscoin, we release a full compliment of Wallets with each update.  Built to Bitcoin standards.  Not this frankenstein build system built, windows wallet only garbage that you and Shakezula seem to have pioneered.  You and your cult of crapcoin are the ones who will be dying off soon.

Blah-blah-blah. If no one in the community needs Mac or Linux or Plan 9 or whatever binaries, why am I supposed to deliver these? Come back to the real world where over 90% are Windows users and most Linux users can build Qt clients & daemons themselves. Feel proud of being a Mac user? Most of the others don't give a shit.

After a quick look at your Orbitcoin block explorer, it would appear your coin generation is all over the place.  Nowhere in the realm of where they should be for what you claim the targets are.  For PoS or PoW.

Really? Feel free to tell me more about coin generation, make my day.

[x_static]

libstdc++ and libgcc_s_dw2 are regular 32-bit MinGW runtimes, no real need to compile them in. In fact, this executable has even these two compiled in after a project file update. All other non-system dependencies are also built in. A cheap insult, piss off.

Actually, those are the MinGW Versions of standard GNU C & C++ runtime libraries.  32-bit, 64 bit, I don't know...  Your wallet ran on a neither my Windows XP or 64-bit Windows 7 VM's.  Fail!  Rather than adapting the project file to conform to your non-compliant build system(breaking the build for others in the process), you should be editing your command lines used to invoke qmake & make, to accomplish the task of statically compiling binaries.  Valid criticism is not a cheap insult.  It would seem you started the insults, so maybe you should piss off.

Blah-blah-blah. If no one in the community needs Mac or Linux or Plan 9 or whatever binaries, why am I supposed to deliver these? Come back to the real world where over 90% are Windows users and most Linux users can build Qt clients & daemons themselves. Feel proud of being a Mac user? Most of the others don't give a shit.

You need to come back to the real world, where people like options.  Stop making excuses for why you can't build to Bitcoin standards.

Really? Feel free to tell me more about coin generation, make my day.

Failed comeback.  Vague response.  You sound like a little child.  Game over.  This was actually a quite informative, leading edge thread on the subject of difficulty retargeting algorithms until you popped in and sullied it with your stench.  If you want to continue taking it on the head, we hash this out over on CCT.  No more cluttering this thread with your BS.   

[YarkoL]

This was actually a quite informative, leading edge thread on the subject of difficulty retargeting algorithms until you popped in and sullied it with your stench. 

Yes, and ghostlander has a number of quality contribution to the thread.

How about you doing the same?

[x_static]

This was actually a quite informative, leading edge thread on the subject of difficulty retargeting algorithms until you popped in and sullied it with your stench.

Yes, and ghostlander has a number of quality contribution to the thread.

How about you doing the same?

My first post doesn't count?  Default KGW is a coin fountain.  You don't even need to exploit it.  Just throw hash at the coin, and it starts spitting blocks out.  Grab about 40 - 50 blocks in a couple minutes, then take your hash elsewhere.  Simple as that.  BOB's Wormhole addresses that issue.  Does it create more problems than it addresses?  That's why I posted here for review.  Did I choose KGW for Dobbscoin?  No.  Another member of the Dobbscoin crew approached Shakezula on the subject of difficulty retarget algorithms, and he put together this commit, which with settings like "PastSecondsMin = TimeDaySeconds * 2.5;" was sure to turn Dobbscoin into a coin fountain.  Not to mention that he failed to address the fact that Dobbscoin has a working testnet.  BOB's Wormhole is KGW tuned to a 10 minute block target, with a much smaller event horizon window.  Settings like no one else is running.  Put forth in this thread to be scrutinized.  I personally think KGW sucks.  The Wormhole IMO being the best implementation out.  I'll take clamping over coin fountain, any day.  Especially with a 10 minute block target, on a coin that isn't meant for speculators.  Maybe look at my commit history for Dobbscoin, and learn how to make a Coingen coin better than most of whats out right now.

I invite you all to smack around Dobbscoin a.k.a. BOB, some.  It also uses KGW, has the fix in the OP applied, but it's running some settings we like to call BOB's Wormh0le, with a much smaller event horizon window.  Not intended to be the be all end all answer...  It's still KGW.  But putting something a little different out there, that we might be able to learn from.  Yeah, there is practically no hash on the coin, so it won't take much to hammer it, so try not to hit it too hard and just it.  Though, at the end of the day, we're not trippin.  Checkpoint, increment versions, rebuild, release...  It'd be nicer if you didn't try to completely ruin the fun for everyone.  I'm thinking we're most susceptible to a difficulty walkup.  Haven't really tested it.  Figure some of you all might be better equipped to accomplish the task of exposing flaws with excellence.  BTCBob will probably get mad at me for posting this.  But hey...  Anyone down to hammer the h0le?  Heh heh...  Them other Bobbies will probably freak out if they see some huge diff spikes... LOL

Dobbscoin Homepage

Latest Dobbscoin Release

Dobbscoin Source

Dobbscoin Block Explorer (might be interesting to compare to Auroracoin block explorer)

Dobbscoin Home Pool

Dobbscoin SMF

#dobbscoin on FreeNode

P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.

[x_static]

So, lets have a gander at Auroracoin Block Explorer to prove a point I made in my post right above this, about how default KGW sucks and is a coin fountain.

Lets look at the two most recent groups, of 100 blocks.  With a 5 minute block target, we should average 12 blocks per hour, taking about 8 hours & 20 minutes to generate 100 blocks.

14532   2014-04-29 08:34:53   10   diff 122.244
to
14631   2014-04-29 19:26:02   4   diff 109.553

Just shy of 11 hours to generate the above 100 blocks.  Over a 100 block period, I'd really hope that I'd be reasonably close to being on target time wise.  2.5 hours off is significant.  But lets look at the last 100.

14632   2014-04-29 19:36:12   7   diff 109.722
to
14731   2014-04-29 23:38:07   7   diff 134.433

100 blocks in 4 hours.  That is a huge swing, and what I like to call "clumping".  Which what default KGW is prone to, because its looking at a huge window, and not reacting fast enough to whats going on "right now". But look at the block 14731, right before the diff hit 134.433.

14730   2014-04-29 23:29:39   2   diff 118.773

So, 99 blocks to go from a difficulty of 109 to 118, then bam.  Finally it decides enough is enough.  But wait...  I just notice this...

14590   2014-04-29 15:34:26   22   diff 117.466
14591   2014-04-29 15:40:09   5   diff 114.095
14592   2014-04-29 18:18:58   33   diff 114.132
14593   2014-04-29 18:19:41   1   diff 71.654

With difficulty dropping, 14592 was a 2 hour and 40 minute block.  14593, difficulty dropped to 71!  Here is where the coin fountain kicked in. In a matter of 5 hours and 20 minutes, 139 blocks were generated.  Remarkably close to the 144 block minimum window standard KGW looks at. 

14592   2014-04-29 18:18:58   33   diff 114.132
14617   2014-04-29 18:23:37   1   diff 107.076

The first 25 block of this fast period were stripped off in 5 minutes!!!  25 blocks in the period that only 1 was supposed to be generated.  Crazy stuff...  KGW sucks...  Was this an attack, or just bad luck that prompted this crazy swing?  I think you can just chock it up to KGW sucking badly in stock form with that 144 block minimum window.  Yes, if you add up all the blocks over time since KGW has kicked in, you might be near your block generation target.  But no matter how bad of luck you run into, 25 blocks in 5 minutes is unacceptable.   Bad luck is bad luck, no one should be rewarded like that for it.  Those blocks should just be lost is it was that bad.  This scares me more than time warp, because it will happen under just normal operating conditions.

Those running KGW might want to take a look and my commit for BOB's Wormhole, and possibly adapt it to their own coin, if they still plan to keep it KGW.  That is if no one finds its flaws are worse than stock.
BOB's Wormh0le - Kimoto Gravity Well Customization

[YarkoL]

So, lets have a gander at Auroracoin Block Explorer to prove a point I made in my post right above this, about how default KGW sucks and is a coin fountain.

That was refreshingly hands-on approach, thank you.
Indeed, making charts like these serves as a great introduction to this sometimes abtruse subject.

[ghostlander]

Those running KGW might want to take a look and my commit for BOB's Wormhole, and possibly adapt it to their own coin, if they still plan to keep it KGW.  That is if no one finds its flaws are worse than stock.
BOB's Wormh0le - Kimoto Gravity Well Customization

This glorious patch has changed 2 lines of the actual code to make it fit your very slow coin and 1 more line to narrow event horizons. Now, it's surely the greatest thing since tinned beer. Or not? It's still KGW and it's still broken, time warping not fixed, but you don't get it anyway because you haven't cared to read this thread from the start before posting your advertising spam. 

[x_static]

Those running KGW might want to take a look and my commit for BOB's Wormhole, and possibly adapt it to their own coin, if they still plan to keep it KGW.  That is if no one finds its flaws are worse than stock.
BOB's Wormh0le - Kimoto Gravity Well Customization

This glorious patch has changed 2 lines of the actual code to make it fit your very slow coin and 1 more line to narrow event horizons. Now, it's surely the greatest thing since tinned beer. Or not? It's still KGW and it's still broken, time warping not fixed, but you don't get it anyway because you haven't cared to read this thread from the start before posting your advertising spam. 

Nice, you confirm some of my previous statements, but you obviously are guilty of what you assume I've done.  Which is not read this thread.  It's time to stop talking and backup your claims.  TimeWarp BOB.  I DARE YEW!!!   

[thaReal]

hey so I just stumbled on this thread - I've been researching an alternative form of a "KGW" type of difficulty readjustment (for simplicity). So I'm glad to start finally seeing comments like those from Cryddit and astor - I think we really need to do more research and work on developing a much better designed difficulty adjustment algo rather than simply trying to 'tune' an already flawed one. I'm not too sure about "bob's wormhole", but I'll definitely look into it as this is the first I've heard of it. That being said though, I think that in general there seems to be a huge fundamental misunderstanding on what this algorithm does and how it functions so before trying to create something new, I think a little better analysis needs to be done.

I think this excerpt from astor's post is probably the most accurate thing I've seen written on moving forward to date:

"In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct."

Also, I wanted to post on this thread because of the quality of these comments, but I do agree that this shouldn't really have anything to do with auroracoin specifically - so are there any legitimate threads that attempt to delve into this from a mathematical perspective elsewhere on this forum or should one be created?

[btcdrak]

hey so I just stumbled on this thread - I've been researching an alternative form of a "KGW" type of difficulty readjustment (for simplicity). So I'm glad to start finally seeing comments like those from Cryddit and astor - I think we really need to do more research and work on developing a much better designed difficulty adjustment algo rather than simply trying to 'tune' an already flawed one. I'm not too sure about "bob's wormhole", but I'll definitely look into it as this is the first I've heard of it. That being said though, I think that in general there seems to be a huge fundamental misunderstanding on what this algorithm does and how it functions so before trying to create something new, I think a little better analysis needs to be done.

I think this excerpt from astor's post is probably the most accurate thing I've seen written on moving forward to date:

"In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct."

Also, I wanted to post on this thread because of the quality of these comments, but I do agree that this shouldn't really have anything to do with auroracoin specifically - so are there any legitimate threads that attempt to delve into this from a mathematical perspective elsewhere on this forum or should one be created?

Look at Dark Gravity Wave which came as a result of KGW's timewarp exploit and post what you think about it. You can find it in the DarkCoin source.

[Nite69]

Also, I wanted to post on this thread because of the quality of these comments, but I do agree that this shouldn't really have anything to do with auroracoin specifically - so are there any legitimate threads that attempt to delve into this from a mathematical perspective elsewhere on this forum or should one be created?

https://bitcointalk.org/index.php?topic=505243.0


Edit: Actually I think that digishield is better for diff retarget than my suggestion here.. but I think one should bring ideas to common knowledge, even if they are not as good as the pervious ones.

[Cryddit]

Here.  

No timewarp.  Rapid adjustments when a burst miner jumps on or off.  And an experimental feature, adjusts the block interval to keep the blockchain height consistent (in the long run, and approximately...) with the wall clock.

Adjusts difficulty potentially every block, based on average block intervals observed within the last 17 blocks.  

Have fun with it.

Code:

// Bitcoin used 10-minute blocks; this uses six minute blocks.
static const int64_t nTargetSpacing = 6 * 60;  // seconds per block, nominal. 
static const int64_t nFastInterval = nTargetSpacing * 0.95; // seconds per block desired when behind schedule
static const int64_t nSlowInterval = nTargetSpacing * 1.05; // seconds per block desired when ahead of schedule
static const int64_t nTimeZero = 1400000000; // nominal date at which this blockchain starts, since unix epoch


void avgRecentTimestamps(const CBlockIndex* pindexLast, int64_t *avgOf5, int64_t *avgOf7, int64_t *avgOf9, int64_t *avgOf17)
{
  int blockoffset = 0;
  int64_t oldblocktime;
  int64_t blocktime;

  *avgOf5 = *avgOf7 = *avgOf9 = *avgOf17 = 0;
  if (pindexLast)
    blocktime = pindexLast->GetBlockTime();
  else blocktime = 0;

  for (blockoffset = 0; blockoffset < 18; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
    if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);    
  }
  // now we have the sums of the block intervals. Division gets us the averages. 
  *avgOf5 /= 5;
  *avgOf7 /= 7;
  *avgOf9 /= 9;
  *avgOf17 /= 17;
}



// This is a novel getnextwork algorithm.  It responds quickly to huge changes in hashing power, is immune to time warp
// attacks, and regulates the block rate to keep the block height close to the block height expected given the nominal
// block interval and the elapsed time.  How close the correspondence between block height and wall clock time is
// depends on how stable the hashing power has been.

unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock)
{
    int64_t avgOf5;
    int64_t avgOf9;
    int64_t avgOf7;
    int64_t avgOf17;
    int64_t toofast;
    int64_t tooslow;
    int64_t difficultyfactor = 10000;
    int64_t now;
    int64_t BlockHeightTime;
    int64_t nIntervalDesired;

    unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit().GetCompact();

    if (pindexLast == NULL)
        // Genesis Block
        return nProofOfWorkLimit;

    
    if (TestNet())
    {
        // Special difficulty rule for testnet: If the new block's timestamp is more than 2* 10 minutes then allow
        // mining of a min-difficulty block.
        if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
           return nProofOfWorkLimit;
        else
        {
            // Return the last non-special-min-difficulty-rules-block
           const CBlockIndex* pindex = pindexLast;
           while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
               pindex = pindex->pprev;
           return pindex->nBits;
        }
    }

    // Regulate block times so as to remain synchronized in the long run with the actual time.  The first step is to
    // calculate what interval we want to use as our regulatory goal.  It depends on how far ahead of (or behind)
    // schedule we are.  If we're more than a day ahead or behind, we use the maximum (nSlowInterval) or minimum
    // (nFastInterval) values; otherwise we calculate a weighted average somewhere in between them.  The closer we are
    // to being exactly on schedule the closer our selected interval will be to our nominal interval (nTargetSpacing).

    now = pindexLast->GetBlockTime();
    BlockHeightTime = nTimeZero + pindexLast->nHeight * nTargetSpacing;
    
    if (now < BlockHeightTime + 86400 && now > BlockHeightTime )  // ahead of schedule by less than a day. 
      nIntervalDesired = ((86400 - (now - BlockHeightTime)) * nTargetSpacing +  
			 (now - BlockHeightTime) * nFastInterval) / 86400;
    else if (now + 86400 > BlockHeightTime && now < BlockHeightTime)  // behind schedule by less than a day. 
      nIntervalDesired = ((86400 - (BlockHeightTime - now)) * nTargetSpacing + 
			 (BlockHeightTime - now) * nSlowInterval) / 86400;
    else if (now < BlockHeightTime) nIntervalDesired = nSlowInterval; // ahead by more than a day.
    else  nIntervalDesired = nFastInterval; // behind by more than a day. 
    
    // find out what average intervals over last 5, 7, 9, and 17 blocks have been. 
    avgRecentTimestamps(pindexLast, &avgOf5, &avgOf7, &avgOf9, &avgOf17);    



    // check for emergency adjustments. These are to bring the diff up or down FAST when a burst miner or multipool
    // jumps on or off.  Once they kick in they can adjust difficulty by a factor of nine or ten every ten blocks, and
    // they can kick in very rapidly after massive hash power jumps on or off.  The emergency speed-up adjustment uses
    // shorter intervals for quicker reaction times measured in blocks - which when it's needed will be longer in
    // minutes.

    toofast = (nIntervalDesired * 3) / 4;
    tooslow = (nIntervalDesired * 4) / 3;    

    if (avgOf7 < toofast && avgOf9 < toofast && avgOf17 < toofast)
    {  //emergency adjustment, slow down
      difficultyfactor *= 5;
      difficultyfactor /= 4;
    }
    else if (avgOf5 > tooslow && avgOf7 > tooslow && avgOf9 > tooslow)
    {  //emergency adjustment, speed up
      difficultyfactor *= 4;
      difficultyfactor /= 5;
    }

    // If no emergency adjustment, check for normal adjustment. 
    else if ((avgOf7 > nIntervalDesired && avgOf9 > nIntervalDesired && avgOf17 > nIntervalDesired) ||
	     (avgOf7 < nIntervalDesired && avgOf9 < nIntervalDesired && avgOf17 < nIntervalDesired))
    { // 3 averages too high or 3 too low.  Doesn't matter which. This will be executed occasionally on the basis of
      // random variation, even if the settings are perfect. It regulates one-fifth of the way to the calculated point.
      difficultyfactor *= (5 * nIntervalDesired);
      difficultyfactor /= (avgOf17 + (4 * nIntervalDesired));
    }

    // limit to doubling or halving.... though I'm pretty sure there are no realistic conditions where this will make a
    // difference.
    if (difficultyfactor > 20000) difficultyfactor = 20000;
    if (difficultyfactor < 5000) difficultyfactor = 5000;

    uint256 bnNew;
    uint256 bnOld;

    bnOld.SetCompact(pindexLast->nBits);

    if (difficultyfactor == 10000) // no adjustment
      return(bnOld.GetCompact());

    bnNew = bnOld * 10000; 
    bnNew /= difficultyfactor;

    if (bnNew > Params().ProofOfWorkLimit())
      bnNew = Params().ProofOfWorkLimit();

    LogPrintf("GetNextWorkRequired RETARGET\n");
    LogPrintf("Actual time %d, Scheduled time for this block height = %d\n", now, BlockHeightTime );
    LogPrintf("Nominal block interval = %d, regulating on interval %d to get back to schedule.\n", 
	      nTargetSpacing, nIntervalDesired );
    LogPrintf("Avg intervals of last 5/9/17 blocks = %d / %d / %d.\n", nTargetSpacing, avgOf5, avgOf9, avgOf17);
    LogPrintf("Difficulty Before Adjustment: %08x  %s\n", pindexLast->nBits, bnOld.ToString());
    LogPrintf("Difficulty After Adjustment:  %08x  %s\n", bnNew.GetCompact(), bnNew.ToString());

    return bnNew.GetCompact();
}

This tends to overshoot a little when making emergency adjustments, but it self-corrects within a dozen blocks or so when it does.