I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).

To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!

Cheers!

I know what you're talking about with the old dead code.  CED even mentioned it in PM.  I just left it as is, as almost every single DIGI code implementation I looked at still had it included.  I didn't want to stray from the norm, but I'm glad you were able to clean it up!  Kudos, mate.

Can you post the code block here for reference?  I'd love to see the cleaned up function.

-Fuse

LOL

Just uploaded a cleaned version but with many comments here:

https://github.com/cydg/NLG_difftest/tree/master/DigiShield_NLG

Ah cool. Yes it took some time but I believe I have a pretty neat piece of code now
Link below

I think the problem you are mentioning on your lines 59-56 (negative timespan) are solved by the limiter at your lines 74-78. Right?

I don't see a problem today to reject those blocks instead of accepting them into the chain. A submitting miner should be able to keep his clock within a few seconds of synced time nowadays, which should always lead to a positive nActualTimespan. If a miner mines a block faster than his clock is off, than bad luck for him (his own fault).

Digishield is not going to be a magic bullet against Clevermining. In fact, expect network difficulty to hit new record highs and be 'stuck' for long periods of time.

If Clevermining hits the NLG network with 10x or 20x hash-rate of the base nethash, the difficulty will hit 10x or 20x in a blink. Digishield deals very aggressively with hash-rate spikes, and when Clevermining exits, taking the hash-rate with them, the network is going to be 'stuck' at a very high difficulty.

This Digishield doing its job, reacting quick enough to make it unprofitable to attack the network with high hash-rate.

No one knows how Clevermining or its profitability algo will react to this change. Terk may continue to test the network looking for a way to get coins at a discount. Depends on the tenacity of the Clevermining team as to how many cycles the network has to go through till Clevermining discovers how to best handle the changed diff algo. Do not expect Clevermining to go quietly, NLG has been their cash cow for many months.

I am expecting new record highs of difficulty and some long, grinding sessions before the network achieves equilibrium. What I don't expect to see is false difficulty lows and Clevermining minting the majority of the blocks in a 24hr period by attacking. If Terk decides to park 20x hash-rate on the NLG network for a few days or weeks, Clevermining will own the NLG network by brute force, but not at a discount as they have been.

The NLG dev team and community need to have realistic expectations of the upcoming difficulty algo change and the above is what I expect to happen.

I even would reject every block that took less time than nTargetSpacing/3, which still allows 'lucky blocks' but denies blocks of only a few seconds (*hint*) and even helps DIGI to catch up faster to the needed diff for high spikes in hashrate. MPs like clever would need to adjust their hashrate down alot to not fall into the trap of their very fast blocks getting rejected. And the spikes in diff would not be that high, only leaving us stuck for far less time.

There is no code in place in the algo to reject blocks under a certain time.  This is something he is proposing as a new feature.  I like the idea, but this would require testing.  Not to prove it's validity, but rather it's vulnerabilities.  Timestamps can be altered, like I mentioned, and are the basis for TW attacks.  Delaying a set of blocks past the accepted time limit could be easily achieved by someone with enough know-how and patience.  I would suppose that 24Kilo could do it with his knowledge of TW attacks, but we would have to test this.

While it's a valid proposal, IMO it's not likely something that will be immediately needed with the DIGI implementation.  I would like to look into the possibility of implementing something like this in the future, although not as aggressive as suggested by c_e_d.  Maybe a community led testnet?

-Fuse

Wait a minute... the diff algo does not confirm or reject blocks, it adjusts the difficulty... nothing more or less.

Confirming or rejecting blocks based on time stamp requires fundamental changes to the codebase, not tinkering with the diff algo.

Using time stamps to calculate difficulty is one thing, but to use timestamps to confirm or reject blocks is a hacker's delight... you could open up a massive security hole that lets an attacker use both the codebase and the diff algo to do all sorts of nasty stuff with the network and blockchain.

The only thing I can say here when I look at all the tech talk, good job guys!! Like I said before, this will bring us to the next level!

The Tier 2 project now has 3 people dedicated to it and we will hopefully have this out in the 1st 1/4 of 2015. Looking forward to seeing the reaction to this one.