[ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows)

[Seb83]

Is there a consensus regarding this miner? Is it really much better than ewbf? Do we have an organized comparison between the two in various conditions for various cards?

The comparison is that this miner is clearly an unstable beta version, an I lost 3 hours of mining today... again.
And we are paying 2% fee on top of that, to participate to a beta test...

t1NEpmfunewy9z5TogCvAhCuS3J8VWXoJNv 

yea... like I said, dev fee is working perfectly.
just use Cheat Engine 

[1714837630]

1714837630

[1714837630]

1714837630

[at10ti0n]

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.

[Seb83]

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.

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.

[chancefx]

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.

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.

totally agree, its a crap

[Seb83]

With my 1070s, I have 460 sols instead of 440. So that's ~4.5% for me.
Today, with a 3 hours hole and the 2% fees, that makes 14.5% less...

I don't understand why the mining would need to stop if it can't connect to flypool. I mean, the fee shares are lost anyway.
So, what communication with pool owners? Just cut the crap

Looks like the dev fees are priority number one here, that sure works perfectly!

Was it so hard for you to visit pool website and realize, that EU nodes are down? Then was it so hard for you to edit your miner with US pool address and continue mining? No one shouldn't do this instead of you, for whatever fee...

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

[toptek]

To avoid misinterpretations of my previous statement:

ZM's reliability is of high priority.
There is no doubt - this needs improvement.
I'm thinking about a better solution to this ofc.
This requires some communication with pool owners and some testing.
I'll provide an update as soon as possible.
Sry for the downtime.

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

[Seb83]

To avoid misinterpretations of my previous statement:

ZM's reliability is of high priority.
There is no doubt - this needs improvement.
I'm thinking about a better solution to this ofc.
This requires some communication with pool owners and some testing.
I'll provide an update as soon as possible.
Sry for the downtime.

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

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.

[ap0stol]

Looks like the dev fees are priority number one here, that sure works perfectly!

u can change some bytes.... 

[that1lurk3r]

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

[Seb83]

hmm what is problem?
https://image.prntscr.com/image/x19jzSprTOGUvL9UluY1tA.png
i try port 3333 too..

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

[dstm]

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.

[Seb83]

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.

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.

[dstm]

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.

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.

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.

[uskovartem]

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 

[Seb83]

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.

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.

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.

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.

[QuintLeo]

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.

 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.

[dstm]

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 was thinking of this possibility, it's easy to implement, however it has drawbacks since some pools require login information.

[prettycode]

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.

[dstm]

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.

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.

[uskovartem]

                                                                       
Server outage like today is very unlikely to happen during the next week.                                                     

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