"Our immediate calls for assistance at their github were met with hostile and unhelpful comments - after a while, our request was even tagged as "off topic" and closed. We were shocked to receive an even more aggressive reply from them in our Support the next day."

Immediate?  13 days ago, Gulden v2 came out more than 2 month ago
Hostile comments? Maybe short and dry instead of super friendly explaining him basics of how blockchains work. It's github, not slack/forum chat. Some understand the difference, others obviously not.

Other side of the story:
https://dev.gulden.com/a-clarification-on-coinomi/

They (coinomi) demanded money to delist NLG because they could not handle the chain?

And for those who can read a block format:
https://github.com/Gulden/gulden-official/issues/138

LOL he sees a block getting orphaned after the chain tip increased (longer chain), doesn't understand it and demands changes to keep the orphaned one valid (means to invalidate the valid one with the rest of the valid blocks following).
Make a guess what would happen than?

The first block he saw (the orphaned one) was only propagated to a part of the network before it was replaced by the second version (and its followup block).
And to make it clear: There is not 1 blockchain out there that has no orphans and all handle them by themself (see chain reorg).
Orphans are unavoidable and and part of the blockchain design is to handle them.

It's block 682412, so 4/30 was a guess depending on block times.
We passed that block like 30 min ago, now the update is in progress and expected to take a couple of hours

Either
you are a genius coder and I look forward to see your stable code release within the next 2-3 weeks
or
this is your way to say that you need to start reading about the technical details of p2p blockchain technology.

BTC carries the burden of keeping old/long time outdated nodes on the network, limiting the savings alot for another couple versions (translates into years!).
They are on v0.15 and I still see v0.10 nodes on the network.  

During the activation phases (giving users time to update their wallets), Gulden 2.0 will leave old 1.6 nodes step by step behind and is than free of that burden.  
Pretty sure this is part of the magic.
Still doesn't take anything away from the great dev work.

0.00002% of 17m population?
0.0000002 * 17000000 = ? 

 

The number of merchants accepting Gulden directly is already more than 0.0003% of the population.
Gulden slack channel: Number members close to 0.0008% of NL population.
Direct Twitter followers of Gulden (most of them look dutch to me) equals to 0.005% of NL population (indirect followers not included).
Direct Twitter followers of Nocks (here too, most of them look dutch to me) equals to 0.02% of NL population (indirect followers not included).
That's only a few numbers put together quickly. 

Including family members and friends that got talked about it, it looks like a good amount of people to me.

https://bitcointalk.org/index.php?topic=1377744.new

They just opened 3 days ago 
Languages are english and japanese.
No company info on the site?
Located in ?
Domain Registered 2016-02-18
Registrar hidden

So be careful
For now I hear a couple alarm bells ringing

Anytime since April 4th, 2014. 

Welcome MiningPool(dot)tk/pool/NLG/   
and congratulation to your first block 303747

Little hint:
The links for block hash and transaction hash are
https://explorer.gulden.com/#/block/...
https://explorer.gulden.com/#/transaction/...

Found at http://syscoin.org/faq/ :

https://docs.google.com/spreadsheets/d/1mRAT5tPiRwjSa0edNml6Z89uXCafagOZQi2-4JrFxzM/edit#gid=349715230

Is there any reasons why not simply use dumpprivkey/importprivkey ?

Saw this discussion by chance and thought to give you some input from discussions on another coin.

Main point is, how much is the hashrate changing?

If the changes are rather decent, everything from DS, KWG, DGW to DGW3 should do.
DGW3 i.e. uses the last 24 blocks (can be easily modified) to recalculate the diff every block (like most modern algos do to react quicker).
It has a minor 'one-off' bug, but nothing serious and easy to fix. Even the btc algo had a bug like this at one point.

If you see big jumps in hashrate, none of the actual algos are helping you here.
There is a dev building a hashrate simulator to develop and test new diff algos for this problem.

If you need more info, you can PM me because I don't want to take over your thread and I think I saw some familiar names from the other thread here too.

You are right: While GeertJohan is concentrating on a new diff algo for NLG which is a big task and takes time, I was digging into the code we use now for a better understanding how it reacts and how it could be modified as a quick solution with low risk until the new algo is ready to go live.
Analysing the DGW3 code I found 2 smaller mistakes leading to a max factor of ~3.13 instead of 3.0 (not a big deal) but the set of 50 blocks thsminer posted earlier smelled like I needed more data. Ask and you will be given thsminer was sending me data of 2000! blocks a few days ago.
On the first view it looked like it was basically in line with what I was expecting based on the code.
Running some calculations on this big pile of records to compare the diff of the block against what I was expecting from the DGW3 code was the easiest part of the work. Reading through all those lines of numbers took a lot of time and coffee, but finally I found a row of blocks where the diff changes still seems far too late and far slower than they should be; right now I am trying to understand why and how this happened. Understanding those problems seems necessary to me to prevent them showing up again in the future.

We basically follow the same path. The more weight you give to the newer blocks, the quicker it reacts to the hash rate change.
Neither your nor mine idea are big deals to implement; only a few lines of code in the loop that calculates the actual time and average.
From how I understand it, you are putting it as 6 new blocks to 1 averaged over the 18 older ones.
My approach is to increase the weight in steps the closer you come to the newest block with the weight of 40% or 53% to the most relevant set of blocks.
Which one is better? We can speculate but best would be to see some numbers from test cases or network tests.

The danger of putting too much weight on the latest block:
Lets put it to an extreme and you use only the last 1 or 2 blocks. A pool can easy cherry pick those blocks, leave for 2 blocks, come back... and repeat. The diff would jump up and down like crazy.
So it is important to fine tune the settings and find a good path between instant reaction and smoothing the diff changes.

(I had a quick look at NiteGravityWell and without digging too deep into it, it looks like a slightly modded KGW.)

DGW3 was developed at a time and for a network that had far smaller spikes than we see today.
I still think what we need is a faster reaction to the hash rate spikes and drops we see.
The more time it takes to settle in to the desired diff for the actual hash rate the more time we give pools to take advantage of it and normal miners will suffer after a drop and the time it takes to bring the diff back down.

The idea I wrote about a few pages back and some others picked up too is to give the newer blocks in the interval a higher weight than the older ones.

Lets say we split the 24 blocks into 4 parts when calculating nActualTimespan.

older ---> newer
part1, part2, part3, part4 (each part 6 blocks)

a more conservative approach:
part1: block times * 1   (counted like 06)
part2: block times * 2   (counted like 12)
part3: block times * 3   (counted like 18)
part4: block times * 4   (counted like 24)

sum / 60 = weighted average
weighted average * 24 = nActualTimespanWeighted

a more agressive approach:
part1: block times * 2^0  (=block times * 1)   (counted like 06)
part2: block times * 2^1  (=block times * 2)   (counted like 12)
part3: block times * 2^2  (=block times * 4)   (counted like 24)
part4: block times * 2^3  (=block times *   (counted like 48)

sum / 90 = weighted average
weighted average * 24 = nActualTimespanWeighted

Splitting it into more parts would make it react even faster, both on the way up and on the way down.
Giving the newest i.e 1 or 2 blocks additional weight can even speed it up more; giving the very latest blocks too much weight could lead to an exploit for an attack.

It should be an easy mod to our DGW3 diff algo with lower risk than a completely new algo.

The target for the block time is 2.5 min
Reject blocks of lets say less than 30 sec or 1 min block time (could even be by same IP). That would take away a reasonable part of the advantage for very high hash power jumping in at low diff.


Dividing it by 4 to bring it back closer to the default block time sounds better.


Anyway, here is what I was thinking about to modify our DGW3 for faster adaption to hash rate changes:
Either take the actual hash rate reading into account (was reading weeks back that a coin did this but can't find it again) or try to predict it by giving the blocks in the interval different weight for the calculation.
The first (oldest) block in the interval gets the lowest weight and increase it to the last (newest) block with the highest weight. Maybe double or triple the weight from one block to the next, so the latest blocks are getting far more important for the next diff.
This way it would react much faster to heavy hash rate changes and would not have a big impact on smaller variations.
I still think the very short blocks should get rejected too; less than 40% of the default time is too short.

Wasn't POW supposed to end at block 5000?


Block 9323

Hash 00000000121d5b80127d52592b84fe2fba277b170e6438d3259a7e108e7d26c1
Previous Block 3e7550f94dfa15ccef2ebac672dc81b91a6501a7a362ce9f147443f31e5ab6bd
Next Block 00000000143859492ae97276517ba3c034990b9096339dab9eee26f98471cc3d
Height 9323
Version 6
Transaction Merkle Root 9fec23a9b26e74bc8b3dfb07070421b1ea26a4f97ebfc89d416a468a001db1b6
Time 1412755652 (2014-10-08 08:07:32)
Difficulty 8.344 (Bits: 1c1eadd1)
Cumulative Difficulty 3 594 801.926
Nonce 12996936
Transactions 1
Value out 4000
Transaction Fees 0
Average Coin Age 0.925654 days
Coin-days Destroyed 0
Cumulative Coin-days Destroyed 35.21%
Transaction   Fee   Size (kB)   From (amount)   To (amount)
9fec23a9b2...   0   0.13   Generation: 4000 + 0 total fees   GfH6xoSRDLkP8rHqmKcaANhrZQfMzaPgRr: 4000


There is more wrong with this code than only the missing check for the POW block reward.

So your chances to get a working coin again are:
a) fix that max POW block check too and hope there are no more surprises in the code
b) get a serious code review from a well known trusted coin dev so you know what else to fix
c) start again with a fresh copy from the clean(?), original source (not! the compromised code) and put your params and mods in

Vielleicht meinst du hier die Zeit für meine personliche Order Liste; dort habe ich sie nach etwas Suche auch zuerst gefunden. In der Order Liste des Coins erschien sie aber erst einige Minuten später als ich bereits dabei war mein Posting zu schreiben.

Zu erwartender Kontostand:
Wenn ich 0 Coins habe und eine Kauforder für 150 Coins setze, dann erstaunt mich ein Minus vor der Zahl.
Stellt dir vor ich habe bereits 150 und kaufe weitere 150. Steht dann dort 0 oder -300? Beides ist zumindest sehr verwirrend.
Und wieso stieg die vorhandene Sell Order von 150 auf 300 Coins sobald ich mein Buy auf genau das Angebot abgesendet habe und fiel wieder auf 150 sobald ich meine Buy Order gecancelt habe?
Obwohl meine Order als Buy unter Orders gelistet wurde, sieht es für mich eher danach aus als ob aus meinem Buy ein Sell gemacht wurde (passt zum geänderten Sell Eintrag und zu meiner negativen Anzahl Coins) und dabei zudem nicht geprüft wurde ob ich die Coins zum Verkauf überhaupt habe.

Ich handel nicht zum ersten Mal an einer Crypto Börse, habe einige durchprobiert mit gemischten Erfahrungen und bin momentan an drei von ihnen aktiv.

Dachte ich geb euch mal ein bischen Zeit bevor ich nochmal teste.
Nun also der 2. Versuch "Buy and Withdraw".

Pusher ist immer noch da.

"In order to protect your crypto coins and personal information, we strongly suggest that you use Two-factor Authentication"
"suggest" heißt "vorschlagen", withdraw geht aber noch immer nicht mit Email Verification.

SYS und VIA nicht mehr gelistet.

Versuch DOGE zu kaufen:
150 DOGE für 90 Sat gelistet.
Buy akzeptiert.
Market History und Your History zeigen nichts.
Nun plötzlich 300 Doge für 90 Sat in den Sell Orders.
Viel später steht meine Order endlich Your Open Orders, wurde also wieder nicht umgehend ausgeführt.
Zwischendurch waren für mich -150 DOGE gelistet, nach Order cancel (braucht refresh um zu sehen das sie weg ist) aber wieder auf 0.
Nun (nach der gecancelten Buy Order) sind es wieder 150 Doge für 90 Sat in den Sell Orders.

"Ansonsten werden wir nun auf Deinen Wunsch hin "Beta" auf der Homepage vermerken damit die User besser bescheid wissen das es noch Möglich ist das Fehler vorkommen können."

Nichts davon auf der Homepage zu sehen.
Nach meinen hier beschriebenen Erfahrungen I would strongly suggest.

Example:
nTargetSpacing = 2.5 min
minBlockTime = 1 min

A solved block comes in that took less than minBlockTime (using time diff between blocks like it is used for diff recalculation anyway).
Block gets rejected, diff recalculates to i.e. 1.5 times what it was before (so that the expected time for this block gets above the minBlockTime) and the network notified about the new diff.
This catch would only kick in if the times to solve a block are getting below the set minimum.
If the times are in the allowed range, the normal diff adjusting will do its work and level it out again.

How would a time warp attack work here? What am I missing?
Wouldn't the normal diff calculation (DGW3 here) be vulnerable to it too if you can use the number of blocks of an interval in a row for it?
Coins like UTIL or SLG are using an algo with far less blocks per interval and giving the actual block time double weight to calculate the diff modification factor. Wouldn't they be vulnerable even more?

I said it sounds bad
Your reference to pooled mining did help a lot so I am now able to hopefully describe better what I ment with my vague words of "resending blocks with a corrected diff sounds far better".
Acting like a pool saying 'try it again with this higher diff' if block times are too short.
A bit more complicated on the other side, when block times are getting to long. 'Try it gain with this lower diff" doesn't work here. But with an intelligent algo we should be able to keep the upper block times limited too.

DGW3 still adjusting? We are at 1760 new blocks now, 1760 calculations to adjust. I can't see any reason in the code why it could take that long.

On the bride site: Looks like the heavy dump of ~900k coins this morning cleared the way to a nice price improvement during the last hours. Monday still coming, so there is something to look forward to during the coming week.