Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 115. (Read 224961 times)

Right, that's a valid argument. I was thinking about the probability of this, I expected it to be pretty low, such an huge server outage like today is very unlikely statistically. I've to schedule user request ofc, it was a bad decision to prioritize other things.

Bad practice in programming think that something isn't happen. Try to predict all cases.

This is slightly one sided ofc.                                                                                               
Server outage like today is very unlikely to happen during the next week.                                                     
So there is some time (and it's a of high priority ofc) to think about a solution which works reliable for all users in all locations. People that have concerns about zm's current reliability (this is perfectly valid ofc) have the option to use a different mining software. I don't want to hack an unreliable solution as fast as possible just to make it look good.

Just wanted to say that I'm switching back to EWBF even if zm gives me a ~3% better hashrate. No fail-over for dev shares is not going to work for my farm. Not interested in having a similar outage again.

I was thinking of this possibility, it's easy to implement, however it has drawbacks since some pools require login information.

 Set up one or more backup pools - somewhere else.
 Doesn't help if YOUR ISP or the core ISP they connect to goes down, but can make a big difference is the POOL'S ISP goes down on one pool.

I have no intention. I'm just saying that zm should not shut down if you cannot connect to the server for your fees.
You have to act fast. Do something. Lower the hash rate or I dont know... but find a solution now.
We don't have to wait that you find the perfect anti piracy solution.

Let me remind you that you are taking 700 bucks everyday from us.
This is no donation! this is your fees. We are paying you. So, in case of problem like that we expect you to act fast.
No blabla, no bullshit.

We all lost today because of that (including you), and you act like it is nothing.
The problem is not the network failure, it is the way your miner react.

What if not hardcode flypool, but mine with user on same pool? If user run zm on nanopool, also mine on this pool, and same with other pools.
Sadly, that dev fee №1 in prioritate 

I'm not sure about your intention, I don't see any productive proposal in your statement.                                     
I've clearly stated the preference for reliability above the developer fee I've also stated some possible solutions I'm thinking of. This allows people to discuss them if there are any concerns about them.

Well, after reading this, it's clear that you fees are your number one concern.
You do not care about the down time as long as your fees are not stolen.

This kind of reasoning will get you hacked, this is just a matter of time.

Some more information about the downtime:

OVH hosting went down for a couple of hours today. They are one of the biggest hosting service in Europe - multiple pools went down because of this in Europe.

Concerning zm's developer fee implementation:                                                                                 
It's not easy to differentiate between a server outage and someone simply blocking network access to dev fee servers for a user space program. This is why zm behaves like this. Nevertheless expected downtime due to this is still very low.

There are multiple technical solutions to this.                                                                               
Failover servers is one possibility, however they have to be chosen carefully such that they are distributed among different hosting providers.

Another possibility is to differentiate between a server outage and someone trying to bypass dev fee. Such an implementation would allow to simply disable dev fee as long as the corresponding server is down. However this would require zm to communicate with it's own servers.

A third possibility is to extend zm such that it's able to solve blocks without the need of a pool. This one requires the most work - I'm currently not sure about the constraints of this solution, however it might also be useful for some users.

For users that have concerns about zm's current reliability because of this. Pls use a different mining software - it's your choice ofc.

Same here... here we go again. No flypool, no zm mining... can't connect to nanopool,
working perfectly with ewbf...

I see people are having a problem just showing mine the one working miner on there is using EWBF as I haven't found a OC setting that dstm likes yet.https://imgur.com/T0w7lT9

u can change some bytes.... 

Yeah, make us pay to beta test and ignore us... that's the best way to go!
If people change their miner for a 4% gain, they certainly care for 2% fee as well.

NP  just make it more clear what you mean this software seems awesome or better then EWBF's CUDA Zcash miner ...so until you get it working again please take your time fixing it and ignore some of the others an me for that fact ..... an fix it : ) ...the good thing i guess no one seems to care about the Fee they just want it working because it does work good, when it is working ... or better then EWBF's CUDA Zcash miner .

I do have one request add some color to the screen ... .....

Guys! is that so hard to understand that you can edit whatever you want, it won't work!
it is HARDCODED
zm try to connect to eu server anyway, for the DEV FEE

I'm as noob as you here, but at least read the last 2 pages before posting shit

totally agree, its a crap

We already know that.
The problem here is that the server for the dev fee is hardcoded (eu flypool).
So, if eu flypool is down, you can't mine anywhere with zm.

this morning there was an outage in EU affecting several pool providers that had the EU servers there: suprnova, flypool, ethermine, miningspeed, hence an almost 3 hour downtime.