You have wrong extension in the filename. Use this one: "commercium.cfg"

I'm on CMM currently https://bitcointalk.org/index.php?topic=4355691
Building a long hold bag before the Equihash ASICs dominates the hashrate.
Finally not a copy-paste clone and the coin has lot of potential hence the long term plan.

These 3 addresses are the pools.
Here is the richlist which shows the coin distribution: http://explorer.commercium.in:3001/richlist

Devs were warned several times here and on Discord that this MN price vs reward ratio is not sustainable and as the time spent then increasing reward remained the last option to keep the coin running.
Now those coins which were mined at the beginning worth 1/20 compared to the new coins.
It would be fair from the devs to compensate the initial miners however I don't see any reasonable option as the premine is not enough to cover the gap.
As miners we take risk when we start mining new coins and this one was a fail.

I didn't find the blocktime so made the calculation based on this: "MASTERNODE START PAYMENT: ~10 DAYS / 2401 BLOCK"
This means ~6 mins blocktime which sounds a bit too much if you plan instant pay.
Could you please clarify?

Edit: corrected the math (from 15 mins to 6 mins). This is the same what was shared on discord.

I experienced the same and I also got new stake rewards as well after the update.
Then I realized that I'm not on the main chain. I did what zajiczech suggested above. Now I'm on the main blockchain and the extras have gone.
Check what is the latest processed block (move the mouse over the pipe at the bottom). If it is the same what you can see in the explorer: http://185.223.31.170:3001 then you're fine.

When one of my card went wrong then the EWBF miner still worked (with some reject rate) but the ccminer failed instantly.
Try to run 2 ccminer instances with 2 GPU groups. With the "-d" switch you can specify the GPUs.
So: 1st ccminer instance: "ccminer.exe -d 0,1,2 -o ..." 2nd ccminer instance: "ccminer.exe -d 3,4,5 -o ..."
If one of your instance fails but the other goes well then you might have a faulty card. If both fail then still a generic issue.

I got this error when I had too much OC. I have Asus Strix 1080Ti OC variants and these are my settings: PL: 55 (doesn't really matter as it sticks at ~52%), Core: +90, Mem: -500
If you have non-OC variant then most probably these exact values won't work for you. I also have 6x Asus Strix in my rig.
I suggest to give a try with Core: -100 (yeap minus) and Mem: -500.
Lyra2z drives the GPU to much higher. At Lyra2z with +90 Core the GPU goes at 2050 MHz. At Equihash with +125 Core the GPU goes at ~1850-1900 MHz.
This might sound strange but with -100 core you can exclude the OC issue factor.
As I mentioned earlier on my EVGA FTW2 1080 cards I had to underclock with -50 MHz and now those go at 1975-2000 MHz. On the stock settings those were freeze.

What OC settings do you use?
On my regular 1080 cards I had to UNDER-clock by 50 MHz to stabilize the rig.
My Ti cards accept ~100 MHz less OC for Lyra2z than what I have for Equihash algo.

The blocktime is about 80 sec currently instead of 60 as on your page. Please recheck it.

Sorry, I have no more ideas except for try out another miner. However I have doubts that the miner itself would cause the issue.
BTW, just because of the curiosity I checked and the username/workername are not case-sensitive and accepts underline "_" so you can exclude those as well.

In the command line it should be -u ACCOUNTNAME.WORKERNAME --> the two separated with a dot "."
For example my user is szasza576 and I have worker with name rig1 hence I have this: -u szasza576.rig1 -p workerspass
I assume your username is "mikebzh44", right? So now check where is the dot in your command line: mikebzh44wrk1.quadro_gtx1060
In the workername don't use dot. I hope this helps.

Does your worker name match with the one what you created in the account settings?
Did you use the worker's pass what you set here? https://xzc.suprnova.cc/index.php?page=account&action=workers
I know it is basic but once I used my account's password instead of the worker's and spent ~10 minutes to figure out what's wrong.  So just a hint...

After you unzipped the dowloaded source use these commands inside the extracted directory:
./autogen.sh
./configure.sh
make -j 4

Djm's source doesn't contain build.sh so instead of build.sh you can use "make -j 4". The "-j 4" means linux builds the miner with 4 parallel threads.
For me djm's fork worked only with up to 8 GPUs but broke down above 8. In addition I have better hashrate with Tpruvot's miner https://github.com/tpruvot/ccminer/releases (as I mine on Suprnova I have no issues with the reported hashrate).

Regarding the autogen issue I cannot help as it worked fine for me (see below). I use GCC 5.4.0 and CUDA 8.0.
./autogen.sh
configure.ac:4: installing './config.sub'
configure.ac:6: installing './missing'
Makefile.am: installing './depcomp'

Hello, this is my first post however I follow this forum from a while (and thanks for your shared experience ). So please be patient if I share too obvious things.

I investigated the P states a bit earlier so let me share my experience. When you start or stop your miner then the GPU jumps to P0 for a second otherwise it runs in P2 during mining.
The P2 state has lower frequency settings than P0. When you OC your card then you set offsets. When you start/stop then the GPU switches to P0 and the same offset is applied to the higher base frequency. This leads to crash as it is too much to the card.
I have Asus 1080Ti Strix OC cards and EVGA 1080 (not Ti) FTW2 cards. With these cards I saw that the base core frequency is the same for P0/P2 but the memory is reduced to 5 GHz on the Asus and 4.5 Ghz on the EVGA. When I overclock the 1080Ti with +500 mem then it reaches the operation frequency (5.5 Ghz -> effectively 11 Ghz due to dual rate). So the OC sets the factory maximum in P2.
You can check the absolute frequencies in Afterburner on Windows and with nvidia-smi on linux. The base frequencies mapped to the P states are burnt in so we cannot change them.
The crash happens during the short P0 period when the GPU raises the memory frequency to the factory max, 5.5 GHz and it gets the OC offset as well which results 6 GHz which is too much to the GPU.

Here you can read more: https://devtalk.nvidia.com/default/topic/1010856/linux/how-to-force-performance-level-3-driver-381-22-with-gtx-1080-ti-/3

Nevertheless let me ask you how can you fix to the P0 (or any other) state on Pascal GPUs? I have both Windows and Linux machines so I'm interested in both OS.