Ok, I can easily explain what's going on here. The ZenController was initially developed for GAW Miners to accompany their Generation A devices. GAW used these controllers in their labs and on their own devices for some time to test them and perform quality control before shipping them to customers.
It is not uncommon in this industry for a manufacturer to ship a controller with an "initial configuration" that reflects the pool the device was initially set up to use. GAW QC'd every one of these controllers using their own devices and pools prior to shipping them.
HERE is what went wrong, and the fault is ZenMiner, not GAW. The config that came shipped on the device was supposed to be wiped away upon initial activation using the 4 digit code. We had a major flaw in our activation that did not permit the devices to connect to the cloud and receive the customer's pool information. Therefore, the initial pool information did not get overwritten. This is the single issue that our developers have been working non-stop to remedy as it is the one that is diverting all of our resources, including me (help desk).
I can assure you, and the entire community that the ZenController has *zero* malicious intent to redivert your hashes. This was a launch bug that we are taking full responsibility for and doing everything we can to fix.
We will provide the community with 100% transparency from this point until total resolution.
I've been waiting to hear back from you for a week about Gridseed support, and you have been nowhere to be found, but 15 minutes after I post this you are able to investigate and reply.
Your story is so full of holes it really stretches credibility. My device *is* connected to your service and *did* receive it's pool information from it. I never inputted anything in regards to pools on the actual device. I changed the pool on the website, and when I rebooted, my new pool was there in the mining client. The very first time I accessed my device via SSH, before I installed gridseed support, I saw my pool listed in the conf file. There is no initial configuration which has your pool already in it that I can find. It's not until after the mining client has been running for a bit and opens the API that the Josh's pool populates in there. It also doesn't just populate in as an extra pool, it specifically disables and then deletes my pools after it has been added. That is vastly different than say Hashra's RPi binary shipping with default pools already configured.
Here is the real sticking point for me. You say that you've only just now done a scan to find affected customers and contacted them about this issue. Only, you've also been working on it as your overriding priority. Regardless of your '*zero* malicious intent' -- that still means that you've knowingly let your customers mine for someone else without their knowledge or consent this entire time (12 days?). However, you come out and promised to notify customers and be transparent only after you've been busted publicly.
What does '
Full Responsibility' mean to you? Refunds? Credit for lost mining time? Payments for misappropriated mining time?
To further deliver on my promise of transparency, we've run a query on every single device we have fielded and identified that less than 2% of ZenController users are affected by this issue. We've sent an email to all of these users.
Obviously, I'm one of those affected customers. My device is registered to my primary email address. Yet, I have nothing in my inbox and no messages on my zenminer page indicating anything about this. Are you
sure you've identified
everyone AND contacted them? It doesn't seem like it to me.
You should have been transparent
from the beginning. You should have given device access
from the beginning. You should have told us the launch problems meant we were mining for someone else at our expense
FROM THE BEGINNING. Get it now?
