A 25% modified Digishield diff algo is my recommendation.
How is the algo modified? I'd be very interested to see how it works!
You change the max difficulty adjustment. Other than that it's standard DIGI.
Okay.. And it is increased 25% then? No other changes are made?
While I completely trust GJ, a simulator is a just that... a simulation.
A simulation is not "just a simulation".. it's a piece of code that executes the exact same maths as being done in the satoshi client, but does not require actual hashing power.. Thereby making it easier to see how an algo reacts.. This makes it a much more powerful tool to test algo changes.
Can it simulate a fork caused by an isntant, massive hashrate increase? You also talk about luck with a 100MH miner... well the 600GH miner is going to have luck too. Computer simulations, while very accurate(when proven so) are only as good as the code. There's a reason why robot AI isn't to a point of consciousness yet.
Forks aren't caused by the diff readjustment algorithm and so they're currently out of scope for the simulator, and are not part of the difficulty re-adjustment problem at all.
The chances of a 1MH miner having three lucky blocks are a lot larger then the chances for a 600GH miner having three lucky blocks.
1. Look at network difficulty adjustment in increments instead of minutes or seconds -
The common fault is to look at a network as blocks per minute or blocks per 24 hours, such as presented by 'nlgblogger', instead a network needs to be looked at as the number of diff adjustments per 24 hours. With a 60sec block time, there is 1440 increments per 24 hours, with 150sec(NLG), there are only 576. So any diff algo designed for a 60sec block time needs to be looked at over 1440 blocks, not a 24 hour period, to see if it is working as desired if that diff algo is applied to any other block time. NLG has only about 1/3 of the diff increments in 24 hours when compared to a 60sec block time network. Both DigiShield and DGW3 were desired expressly for a 60 second block time, Digicoin in the former and DarkCoin in the latter. This is why neither Digi nor DGW3 are effective without tuning.
I don't really agree. The main variable that drives the DGW3 calculation is the average block time for the past n blocks. Hashing power can be added/removed instantaneous. It's not like hashing machines need to "warm up" and slowly increase their hashing speed over a few minutes or hours, so it doesn't make sense for any diff algo to take into account how many re-adjustments per hour are happening.
I think you're missing the point here. The reason Kilo brings this up is VERY valid. If you have more iterations of retargeting in a specific period, the more change can happen. Lets say the NLG codebase was only allowed to be altered every 6 months. You would have to make a lot of major changes to account for everything that happened in that defined time period. Maybe something happened 5 months ago, but now you're waiting to catch up. If you say you can change the codebase every 3 months, now you're only 2 months behind instead of 5. Mind you, I know the blocks carry the changes with each block, but when they are targeted for a longer time, they reaction is more severe. I'll get back to this.
I totally agree that having more adjustments (smaller block times) will give the diff re-adjustment more opportunities to re-adjust, and so in theory it will work better.. But this is not something the algorithm itself should be aware of. Also, let's not forget that smaller blocktimes introduces a new problem: more chance of chain splits. (network must converge within the blocktime, if it doesn't, a split might occur.. if the split isn't handled well by the network, it becomes permanent and we're stuck with a fork..)
Digishield is a much simpler and more elegant diff algo that scales easily and effectively, while DGW3 is very complex and does not scale well.
I wouldn't say DGW3 is very complex.. It's not even complex relative to Digishield, because the two look a lot alike. Please tell me how you think Digi is more elegant and what you mean with "scaling".. Where in the maths does Digi scale better than DGW3?
Averaging difficulties to calculate the newer difficulty is more complex in ways. It's allows more room for error and skewed calculations. It's pretty obvious DGW3 doesn't scale well. You can't argue that because the chain shows it. I think it has for a long time now.
I'll take a stab at what Kilo meant by elegant. DIGI is simple. It's a 1 to 2 line addition to the base LTC difficulty algorithm. That's it. It's elegant in that it's simple and it works. Additionally, Kilo and I have witnessed DIGI implementations over the last year that scaled very well. When a chain's hashrate grows 5X it's size in a day and stays healthy, I would say it scales pretty darn good.
I know DGW3 doesn't handle the current spikes very well.. But what is this "scaling" factor? And why would Digi handle it well? Is there an example of a coin with Digi that has x30 hashrate increases (e.g.: clevermining) at the same level as Guldencoin currently is?
Also, Digishield is not really a 1 to 2 line addition to the base LTC algorithm. Please read
https://github.com/digibyte/digibyte/blob/master/src/main.cpp#L1268-L1555And we don't have 5x hashrate in a day.. we have 30x hashrate in 3 seconds..
I would fork NLG to a 75sec block target time with a 500NLG reward that retargets every block using a custom Digishield implemtation.
Blockreward is nowhere near related to the difficulty algorithm.. It wouldn't have anything to do with Digishield...
Completely related if you reduce the block time to accommodate for an algo that is meant for shorter block times. A 150 second block time works for LTC because LTC uses the standard algo with a shit ton of hashing power, think petahash, behind it consistently. NLG doesn't have that. Most other altcoins that have healthy chains use a block time closer to 60 seconds but not less. 90 seconds would be optimal, but Kilo's 75 seconds is probably a very safe number for NLG. Less than 60 seconds and you run the risk of timewarp attacks. Kilo has successfully done this to a few coins just to prove the maths. But that aside, shortening the block time is a solid idea. It reduces the magnification of the retarget changes and allows for faster reactions. If you shorten the block time, you have to reduce the reward, unless you want to mine out faster. Normally, I would be against reducing block rewards, but halving the block time and the block reward gives you the same coins mined daily, but with 100% more difficulty changes in that time.
With the current network stability (which isn't very high) I wouldn't recommend lower blocktimes.. Furthermore, it simply doesn't work because although lower blocktimes means more blocks and thus more re-adjustments.. it's the same calculations being done... say we would half the block time to 75 seconds, that means the difficulty would also be halved so we would get twice the number of blocks within the same amount of time. The income/costs for dedicated miners wouldn't change, they would just get twice the blocks with each half the reward per block. This also applies for clever, they would have to spend the same amount of hashingpower to get twice the number of blocks at half the reward per block.. so in the end it's just the same thing.. The only thing that changes is that if the dgw3 or digi impact isn't halved too: it will cause twice the size in blocktime spikes (both up and down).. So you'd have to half the dgw3/digi impact.. which means that in the end, you're left with 0 effect (apart from a network that's more vulnerable to time warp attacks and chain splits). The faster reaction you're talking about would work if the hashrate changes over a number of blocks' time. But with a jump pool, it's instantanious. If I'm missing something, please explain.
(....) This would reduce any 'stuck network' time by 50%, increase the number of diff increments per 24hrs by 100%, reduce the number of blocks that Clever can mint per 24hrs by 80%, and make NLG a much better network for micro-transactions.
How did you figure out these numbers ?
I would say the 50% stuck time is conservative with DIGI. I would guess you would reduce the amount of stuck time(blocks that take forever to mine) closer to 90-95%. The chain would function smoother, and not make wild swings into the stratosphere like it does now with DGW3. The 100% increase in difficulty adjustments is correct if you halve the block time. The reduction in the amount of blocks that clever could mint is about right. It's not hard to see in the charts I posted that if you threw 10X the network hashrate at the chain, based on profitability, you're profitability would be gone before you could grab 15 blocks in under a minute. There's no averaging, so DIGI doesn't need to take in to account the false lows that DGW3 produces. The reaction is instant instead of delayed because of a moving average.
The numbers, while not statistically absolute, are sound. No need to dismiss them.
The fact that digi doesn't take into account the false lows /does/ sound good.. As that is actually the largest part of the problem we're seeing.
Please don't take these remarks personally.. I'm merely pointing out that with the hashrate/sec spikes we're experiencing; both DGW3 and Digishield won't handle it. I know I haven't been active the last week or so, I'm sorry for that. But please keep in mind that we want a permanent and solid solution. We actually need a more complex algo...
I don't take the remarks personally, at all. I think you are 100% incorrect about DIGI not handling the hashrate spikes though. We've proved it on a testnet. It's funny... we presented actual data, but there's still people that deny it, like it was all made up lol. DIGI works, the graphs back that up, and
the solution will work until the entire altcoin environment makes it's next paradigm shift. You can't predict the future of mining, so you can't create an algo for it. You can however use what is effective in this era of mining. DIGI is the answer.You spent that entire post trying to debunk my team's findings, and shoot down the possibility of using DIGI. However, you didn't mention a single plan of action other than to state that a more complex algo needs to be created.
A plan that has been needed for months now. Give us direction. You're the rudder. Don't let us steer ourselves into the rocks.
So, I don't really believe in the halved blocktimes, but investigating more into digi seems to be worth the time..
Before christmas I had the idea to write 'GDR': "Guldencoin Difficulty Readjustment". Maybe it's a good approach to take what we've learned so far, including DGW3 and Digi approaches, and work out an algorithm that is better. After all that is how DGW3 and Digi were born too: by applying lessons learned and incremental development.
I would be extremely happy to do this, but not alone. If anyone can provide me with a Digi ported to the simulator that would be great, it's pretty simple, but will take some time.
If the community doesn't want a new algorithm and places it's bet on Digi, then I WILL help with that. I'd be happy to work together with youguys to apply and deploy the software patch. Just as before I will provide compiled binaries for all major platforms and update the seeds and send a network alert. I believe last time that went pretty well, and this time we don't have to do a chain fork.
Please though, understand that we should not do this without being absolutely sure. There are always risks.
Cheers!
The main question. When will the algo be solved 
The sooner the better.
We should start 2015 with a solid and healthy gulden with no room for Clever mining anymore. 
. And without a tool to test and fine tune the idea it's all theory. So the next steps of the simulator with mid and big waves are needed here too.
