First and foremost, everything I bring up is with the utmost respect.  When I lose faith in the team, the community will know it because I will flat out say it.  I am primarily posting this because I feel lost in trying to help this coin, and I want guidance.

That being said, the problem with your math is that clever will never throw 320GH at NLG.  If they were going to increase their mining it would be because NLG mining is profitable.  If NLG mining is profitable, we'll have more miners, and we'll have a higher difficulty.  Mining is all about proportions.  Clever will never increase their proportion if it's not profitable.  If they did, our proportion would probably increase as well.  But you forget something, too.  Clever won't stick around if they are cut off the chain with an algo change.  If you limit the number of blocks clever can mine before it pushes profitability out of reach, which DGW3 doesn't do, you shut clever down.  1000GH won't mean anything if you only get 3 blocks before it shuts down your profitability.  Also, throwing 320GH at NLG is basically saying that every other coin, including LTC are inferior to NLG at that point, and I'm pretty sure we'll have a lot more on our plate than clever at that point.  Think terahashes.  But at that point, you could implement a standard LTC algo and call it a day.

Anyone with enough hashpower can disrupt a blockchain.  That's a fundamental flaw with mining.  24Kilo and I almost burnt each others houses down in a heated argument over this.  Hashrate is king.  No algo change is going to change that.  The only way you could change that is implementing code that said that only X amount of blocks can be mined from a certain address in a certain amount of time, which is back to the centralized mining debate.  The other approach is POS, and that's a crap-shoot at best.  I've never seen a POS coin that didn't have forking issues, or even worse.  So yes, 320GH is a big scary monster that can trample our town like Godzilla on a Sunday stroll through the park.  However, that 320GH is governed by profit, and an algo change like DIGI would minimize that profit in a single git pull.

There is at least a year of data that can be mined from various coins that made algo changes.  There's testnet data that can be put together.  There's enough information out there that could be used to make an educated decision.  My question is what is it that the dev team wants?

If you want a 320GH testnet, then tell the community you want it, and we'll work on it.  If that's what it's going to take to convince the team of a proposed change, we need to know that.  We're flying blind here, mate.  We need input as to what direction to go to better support you and your team.

-Fuse

No... I think your first impression was probably right.  The simulator and the algorithm change aren't mutually exclusive.  So even if /GJ can't finish the simulator before next year, we could still push forward with an algorithm change.  Like I mentioned previously, my team has tested DIGI on a testnet and it performs very well.  We made a slight change to accommodate the longer block times, but it performs much better than the current DGW3 implementation.  I could put up a git pull request right now and we could move forward.  But that's not up to me.

We need the dev team to back a change.  The simulator will only take us so far, and from what /GJ said, it seems like it's hard programmed to only do traditional and DGW3 algos in the first release.  IMO, we already know what that looks like.  Other algorithms should be the focus... not what we already know doesn't work.  This is why my team went ahead and decided to do independent testing.  We need a solution to the problem at hand.  If the dev team wants to make a change to DIGI, I'm sure all of this clever nonsense would be behind us and we could move on with bigger and better things.  If they don't want DIGI, we need a clear indication of what expectations are, and my team will continue to test solutions.

We can lead a horse to water...

-Fuse

For sure, the current site is developed by a good experienced designer, but it just leaks the X factor and after a menu selection the subpages doesn't support a button to go back to the home page for example.

I think you are right. The main guldencoin.com website is not so appealing for new potential users and businesses.
Would be great when a experienced website developer will take some time to improve the site as it belongs in to be in the year 2015 

GJ, What do you consider a small/large hashrate wave? What percentage of hashrate against the network hashrate? Just curious.

I would get behind this.  You're 100% correct in that this would be an easy implementation.  The only thing I would worry about is forked side chains from people not updating their clients.  The breakdown looks good now, but before the 130 update, there were a lot of people on old wallets.  Of course, you would just ban versions older than the newest as well.

Not a bad idea, thsminer.

-Fuse

Great stuff! Can you tell us if they really work in a shopping car? If that is the case I think about ordering some too 

Nice to watch! Any idea how long it takes to complete it? Feel no pressure by asking this

Hell's yeah!

Nice GJ. Sent a PM: Big numbers this way 

I also sent him some extra Guldencoin, I do this quite often tbh haha.

There are solutions for preventing that, just by allowing only 1 IP from blocks of IP address ranges. The current giveaway of 100 NLG is probably more easy to manipulate.

How about starting a free distribution model among open wallets with IP's coming from The Netherlands? (like the new MCL coin is doing rather sucesfully at this time with over 7000 wallets in less than 2 weeks; every hour 5000 coins are divided by the number of opened wallets) If we would start such a campaign through social media informing the people to download and keep the the Guldencoin wallet open from i.e. 1 nov to 1 dec. to receive a percentage of coins [x coins every hour/divided by the number of open wallets] that could become a big hype and boost for Guldencoin.

Man, what a clusterf*ck... at least I'm not the only one with issues.

I'm with CED and Fuse in this, I would say three / four blocks minimum because otherwise the diff will be all over the place. I'm also missing some structure in this discussion. I did put down a list yesterday with strange diff values imho thats problem uno, if we don't solve that problem every solution will probably show the same weird behaviour as KGW and DGW are showing.

Second, if you want to modify the algo you need to identify the problem properly and with the problem description you can work out a solution. Without a proper problem description there is a huge risc of drifting away from the goal. Why take 6 blocks or 10 or 24? Because thats the number of doors in your office? Or is it the blocks that are being mined fast? So in my opinion the path could look like this:

phase1
- identify the cause of the swings more than 3 and 1/3
It is limited to 3 and 1/3 diff change. But the new diff is calculated from the average diff over the previous 24 blocks. So you can't compare the diff to the previous block as displayed in the list. Please see https://github.com/nlgcoin/guldencoin/blob/master/src/main.cpp#L1286 and line 1299 and lines 1303-1306.
- work out a solution for point 1 first
We could change it so the diff is calculated only from the diff of the previous block.. Then the diff change between individual blocks could never exceed 3x or 0.33x. But that also means the diff can go x3^3 (x27 !!!) when there are 3 lucky/fast blocks. I don't think that is a smart thing to do.
- if the fix for point 1 is outside DGW code see if DGW is acting as expected in the first place
I don't think point 1 needs to be fixed. I'm not aware of any code influencing the difficulty outside DGW. DGW is acting as it should (as it is doing in other coins), but simply can't handle these hash/sec spikes.
phase 2
- identify the problem and descibe it properly (yeah I know it's jumppool, but whats really the undelying thing that causes the trouble)
You're right. It is good to have a verbose explanation with some examples. As long as we keep in mind that diff readjustment should work for more problems than only this one.
- work out a modification of the algo by testing it on past hashrate swings and see if it smoothens out those.
Testing is very important. We shouldn't release a new algo too fast. Placing a new algo on the existing chain doesn't give a proper indication though, as it does not influence block times and doesn't change multipool behaviour. It would be better so simulate several cases of hashrate joins/leaves. I have done this before with DGW3, but never the amounts that we currently see. This time we must simulate extreme hashrates, even multiple times more than we currently see with clevermining. I plan to release the software I used for simulations, just needs some polishing and persistency of scenario's (currently the user must enter the block times manually, each time). That way everyone can apply and test changes locally.
- test the modification thorough for vulnerabilities and flaws
Very important! I think 24Kilo can be of great help here
- implement it
This time deployment will be very smooth. We can release a new algo one week in advance with a hardcoded block on which all nodes switch algo.

 

I think you're shooting too high with a 3X increase.  We'll have the same results we have now where it jumps too high for normal miners, and we get stuck.  The drop back down is fine, but the jump up in difficulty should be smaller IMO.

As 24Kilo always tells me, we don't need to reinvent the wheel.  We just need to make sure our current wheel is round.

-Fuse