Topic: ZenMiner (unmoderated) service discussion thread - page 8. (Read 27963 times)

Oh right. I think Zen ties in the MAC address so not sure that would work. I haven't tried it yet though. I did make a backup of the SD Card before I powered it up the first time.

Anyone can put the os on their raspberri pi.  It would defeat the purpose of buying the zencontroller from GAW or someone else if you didn't need an activation code to register with the website.

Yeah they put the label on top.

Thats good, they fixed it fast. Where did they put the label, on top?

What do you mean? What would defeat the purpose?

Lol... my label isn't covering my vents fortunately.

I haven't gotten home to hook it up yet, so it may activate without the code. 

But that would defeat the purpose of actually buying a zencontroller rather than just flashing your own raspberry pi with the os, wouldn't it?

You can email support and they can get you a code. It may activate without it.


Btw check if yours has a label on the bottom

http://www.mobilewill.us/2014/06/zenminer-rpi-temps.html

I just got a Zencontroller from GAW without an activation code too...

Did you ever get it activated?

Mine second one didn't have a code either but it was recognized by my IP address I guess because it's working fine.

Received another Zen controller last week. I'd like to put it to use, but it did not come with an activation code attached. The instructions still reference using this missing code. I've emailed Eric, but have received no response. Is anyone aware of an alternative activation process?

If your pool supports VarDiff you can adjust it to get fewer discards and better rate.
Your pool will have instructions on how to do it. On the BW I would start with 1024 and work your way around a few with a test of at least 6 hrs each one to see which works best for you.

I got a BW today and tried to hook it up to a PC where I already have a Fury running but it just would not install the drivers correctly. I plugged it into the new Zen I got for it and wow, it actually worked. About 50% discards on Clever straight up Vardiff... but it works.

Zenminer is horrible. Its impossible to even log into their website. Since i got the thing 2 weeks ago not once has it worked and the support button seems to be attached to a deep dark empty hole where 1-2 mins of time filling out the form go to die

I am aware of what a default config is. This was something different as my pool information was actively being disabled and replaced after mining had commenced, even if I reentered the details directly into the client. Their cloud backed was jacking my controller remotely and making it mine for it's original owner. Being sold a new used Zenminer, in addition to being connected to a service that isn't fully developed, missing promised support for devices I had -- all of this led to what happened.


There needs to be some reasonable protection against customers or other potential bad-actors trying to hook additional unauthorized RPi's into the zen cloud, I don't think a serial number is enough. Perhaps a MD5 hash of the MAC, activation code, and serial number could be enough. However, if the SD card or OS on it get's hosed, you don't want customers to be without their controller when they can just reflash. A custom serial would make that process difficult. The customer will need to understand that use of the service is tied to that specific RPi. It's no more complicated to switch an RPi out with another RPi than it is switch an SD card from one unit to another. I personally don't see it as a burden to require that particular RPi be used to use the service, and at the same time it provides some level of protection to Zen. I will say that I don't imagine their community of users will ever be so large that the resale market becomes too much a burden for support to address.

Once Eric explained that the activation was tied to the MAC and that I was sold a new used ZenController from GAW  , it made sense. Except that it should not have been able to put my pool details in if it wasn't registered to me. It was clear at that point that some mechanism was missing and Zen had allowed the device to be registered to two accounts. I can only hypothesize that because GAW had the device first, and their registration was older that it would write my pool, then override it with theirs as the cloud backend cycled through customers devices. That is why I suggested to Eric that Zen add in a safeguard to prevent MACs being re-registered in their system.

While I'm still very frustrated with my experience purchasing equipment with GAW, I will say that GAW and Zen did work together to quickly identify and resolve the bug in their back end. Eric was reasonably forthcoming with information about how their service works and how this happened. After our chat, I confident this a beta software issue rather than anything malicious.

I'm awaiting a new build of the Zen firmware that is supposed to resolve my specific issues. When I receive it and am able to test it I will report back.

Not at this time, but we are including that feature soon. We've already got the basic functionality, just tweaking and refining it.

Glad to hear the image flash fixed your controller!

I appreciate your advice luckily, our support team is prepared to assist any users experiencing those issues. We expect such things to happen as ownership transfers or users switch devices. We may revisit this in the future.

Hi Eric,
   Is there anyway to change the clk speed on our devices via your service?

I fixed that problem I emailed you about, put the new img on and no probs

I think this is good idea but I will caution you about some issues I have experienced working for a cable operator who "locked" cable modems in a similar fashion and has ended up with multiple issues where someone legitimately purchased a modem on ebay or other public sites only to have it refused to be provisioned because it was still mapped to another account.

as I understand your previous thread, you are mapping the mac address to the account.   This is going to bite you for in three ways in the future.

first, if your customer moves his SD card to another rPi, then the MAC address will change

same is true if they in the future use a wireless interface rather than the built in ETH interface

last, if someone decides to sell their rPi and it inadvertently gets picked up to run your software...well, you get the idea.

I would suggest you would be better off placing a user serial number in a config file so that it is mapped to the software and the user rather than using the hardware as your auth mechanism

it will save you, and your customers much grief in the future.

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.

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.


I will post this into DarkKnight's thread once he reopens it.

Just wondering, have you ever used any other Linux OS-based miner images (BAMT, PIMP, SMOS, etc?) - because if not, I can tell you, that each and every one of these images and many others, come pre-configured with the developer's pool info that's up and mining for them as soon as you power on.  It is up to you to ensure that you change it after the OS is launched, and you may be mining for the dev in the first few minutes until you make the change.  Now, I understand you did make your appropriate pool changes, and it would appear Zen is overwriting that info periodically, so that's REALLY ODD - no excuse for that.. but Eric's response seems genuine so I would say why don't you give him the benefit of the doubt?  If you completely don't trust them anymore then just use a different mining distro that's not cloud-based.  There are other Pi options for blades, you may want to check out Starminer to start, there is a 'gridseed-blade' profile.  If you are experienced with Linux just run cgminer on raspbian.

I believe Eric's explanation and it does make sense. I haven't used my Zen to mine since I first got it because it's not getting recognized by the website as being active. I have PCs mining so it's not a big deal. I also don't know if there is any benefit to the unit as far as better hashing/lower rejects or HW errors.