Quote from: schnauzr on June 13, 2014, 04:48:05 PM

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 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.

Quote from: bbeesley on June 14, 2014, 09:35:42 PM

Quote from: zenMiner_Eric on June 14, 2014, 04:02:30 AM

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.

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.

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 Roll Eyes

, 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.