Topic: Is Zenminer Scamming Us? (Read 2352 times)

can confirm, brand new

No. One unit left GAW Miners with a previous provision assigned to it. All other units are brand new Raspberry Pi's with GAW's standard SD image loaded.

So basically your shipping used units out / selling them as brand new?

This is a bit concerning

As promised, I am delivering on my promise of full transparency with this issue.

After a thorough investigation, we've determined how the improper pool credentials were being inserted into one customer's (DarkKnight) ZenController configuration. Each ZenController is tracked by its unique MAC address which is hard-coded into every device. The controller communicates with ZenMiner cloud servers and identifies itself via MAC and activation code. The device DarkKnight received was previously assigned to GAW Labs as one of their early test models. We've determined that the MAC was not properly removed/reallocated in the ZenMiner database, therefore the controller still thought that it belonged to GAW Labs. This is why the pool information inputted by the customer was constantly overwritten, the controller was doing what it was supposed to. Unfortunately, the device was not properly provisioned to the new owner.

Since this issue only affected an early test device that was assigned to GAW Miners at one in point in time, it makes sense why we didn't see this as a wide-spread issue and identify it sooner. All subsequent controllers sent out were "fresh" devices that had never previously been provisioned to anyone. That doesn't change the fact that one of our devices made it into the hands of a customer and caused unacceptable operation. We've since purged the database of any entries from legacy test devices and are working with GAW Miners to ensure any future devices that are shipped have no prior association in the database.

We sincerely apologize to DarkKnight and hope to regain his trust as well as the trust of the community we serve.


EDIT: I wanted to answer a very good question DarkKnight brought to me offline regarding how we'll be mitigating something like this in the future. We're currently redesigning our entire activation mechanism and implementing measures that would prevent one device from accidentally (or intentionally) being activated to another account without support intervention and the deletion of all prior account provisions to that device.

DarkKnight has agreed to test that this issue has been resolved and will post his findings when that time comes

Yes, of course I'm open to solving the problem. Contact me via email with how I can help. We will take it from there. 

DarkKnight,

Thanks for the response, more importantly, the time that you have taken to look in to this.

To agree with your post, there is no malicious intent here, so I am glad we got that out of the way.

As you read from my previous post, if the controller does not sync to the cloud it will use its last known config file. Since this controller was sold from GAW, and GAW tested them before they shipped, it would be their test settings.

In your case, since you have both configured/synced your device to the ZenOS and this problem still existed, it sounds like it may be a different issue that we need to look deeper in to. This is the first known case we have had of a config changing after it was synced. And while it may be the only one I have heard of, its important we address it immediately.

Are you open to assisting our dev team track down the bug? Since you have found it before anyone else has (customers included), we would be grateful for your help. It would also allow you to let the community know we have addressed it.

In either case, we will make sure its addressed.

Lastly, full responsibility means all the items you listed. If there was a pool mistake, we would gladly reimburse you for that (we should probably handle through PM for that). And/Or refund your controller if you wish.

Thanks again, this is a learning process for us too. And, sometimes, it takes many different kinds of use cases to discover issues like this.

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?


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?

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.

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.

Update 6/19/14: Although I have been unable to test out a current image, what was happening appears to be isolated to only to me, and having been corrected on the Zen back end should no longer effect me. Eric has worked with me in a capacity that was unexpected to say the least. Having spoken with him on the phone concerning this matter, I am genuinely confident that any impropriety while unfortunate was also completely unintentional.

I believe the road ahead for Zen is both bright and exciting and look forward to fully transitioning my farm to their platform. To any wary souls who might still be hesitant because of past events, I say that you have nothing at all to be worried about, and that you would be doing yourself a disservice by not giving Zen the opportunity to show you how great they can be. Any who so desire may reach out to me personally about this for reassurance.


I am leaving the post below intact for posterity, but know that it no longer reflects my attitude toward Zen and Gaw, and I believe that they more than deserve the benefit of the doubt from anyone still harboring reservations. Because this issue has been resolved, and because I do not wish to see undue harm come to the nascent company, I am locking the topic and letting forum slide do the rest. All further discussion regarding the Zen service should be directed to the dedicated topic or dedicated forum:

https://bitcointalksearch.org/topic/zenminer-unmoderated-service-discussion-thread-628615

https://hashtrader.com/