[ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool

[Prelude]

Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?

There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect  .




I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.

Hmm, looks like I'll have to dig. Thanks for the tip.

Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.

Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).

The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.

Thanks for the reply.

I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.

The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.

I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.

Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.

[1714953220]

1714953220

[1714953220]

1714953220

[1714953220]

1714953220

[NiceHashSupport]

Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?

There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect  .




I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.

Hmm, looks like I'll have to dig. Thanks for the tip.

Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.

Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).

The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.

Thanks for the reply.

I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.

The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.

I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.

Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.

As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.

[nicehash]

We have to apply a few updates, therefore connection to NiceHash web as well as stratum servers will be interrupted in the next hour. Thank you for understanding.

[nicehash]

Service back up&running.

For those interested in mining Quark algorithm coins (Quark coin, etc.) on NiceHash/WestHash: Quark algorithm has been added

You can download sgminer with Quark support here:

https://www.nicehash.com/index.jsp?p=software#sgminer

MULTIALGO note:
Quark is disabled on multilago by default (transition will probably take a while). But nevertheless if you want to use multialgo you can still use it by manually adding Quark factor to your pool's password setting, for example:

"pass" : "f0=0;f2=0;f3=8.5;f4=4.5;f5=500;f6=3.5;f7=14;f8=0.35;f9=1.25;f10=135;f11=6.5;f12=2",

(as always, remember to add this to ALL your NiceHash/WestHash pools entries, not only for the new Quark entry).

[Prelude]

Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?

There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect  .




I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.

Hmm, looks like I'll have to dig. Thanks for the tip.

Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.

Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).

The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.

Thanks for the reply.

I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.

The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.

I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.

Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.

As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.

Ahhhhh, I see. I misunderstood what you were saying.

In this example, from top to bottom: A2 90, A2 60, Titan, Achemist



The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit?

Thanks

[NiceHashSupport]

Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?

There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect  .




I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.

Hmm, looks like I'll have to dig. Thanks for the tip.

Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.

Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).

The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.

Thanks for the reply.

I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.

The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.

I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.

Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.

As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.

Ahhhhh, I see. I misunderstood what you were saying.

In this example, from top to bottom: A2 90, A2 60, Titan, Achemist



The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit?

Thanks

Proxifying will not help. If buyer has low diff pool or mines low diff coin, there is nothing you can do but to press your ASIC provider to give you better software/firmware (if anything can be improved with new software at all).

[Prelude]

Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?

There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect  .




I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.

Hmm, looks like I'll have to dig. Thanks for the tip.

Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.

Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).

The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.

Thanks for the reply.

I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.

The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.

I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.

Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.

As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.

Ahhhhh, I see. I misunderstood what you were saying.

In this example, from top to bottom: A2 90, A2 60, Titan, Achemist



The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit?

Thanks

Proxifying will not help. If buyer has low diff pool or mines low diff coin, there is nothing you can do but to press your ASIC provider to give you better software/firmware (if anything can be improved with new software at all).

I understand that, what I meant was if I were to run all the rigs through a proxy they should all get the same diff (low or high) since they'd be seen as one available rig to your servers, correct?

[Prelude]

And why do my slower rigs get hit with such high diff?



They are all asking for 8192 (except proxy which doesn't ever get the 32768 I'm asking for). The 60MH rig is especially prone to getting diff way too high as can be seen @ 131072.0000.

[NiceHashSupport]

With d= you can only set starting diff, then our proxy will adjust diff according to speed of your miner. If your miner sends too little shares, it will reduce diff (but never below buyers target pool diff) and if your miner sends too many shares, it will increase diff. Because number of shares depend on luck, even your slow miner can sometimes get high diff (winning streak), but as soon as this "luck" ends, it will get low diff. What is more important is that your miner shows approximate the correct speed (declared) over longer period of time.

[Prelude]

OK, thank you.

Out of curiosity, what is your SPM target set to?

[jelin1984]

How connect Titan at nicehash pool
Any details???

[pdx99]

How connect Titan at nicehash pool
Any details???

Here's a config with Westhash as primary and Nicehash as fail-over:

{
  "pools": [
    {
      "url": "stratum+tcp://stratum.westhash.com:3333/#xnsub#skipcbcheck",
      "user": "<ADDRESS HERE>",
      "pass": "<PASSWORD HERE>,d=16384"
    },
    {
      "url": "stratum+tcp://stratum.nicehash.com:3333/#xnsub#skipcbcheck",
      "user": "<ADDRESS HERE>",
      "pass": "<PASSWORD HERE>,d=16384"
    }
  ],
  "failover-only": true,
  "scrypt-n": 10
}

[bigbitmine]

Unfortunately my hashing has come to a screeching halt on Nicehash.  Deposited over 4 hours ago and 0 confirmations.  To make sure it keeps going I've already sent the next deposit.  Should be confirmed by tomorrow!   

[NiceHashSupport]

Unfortunately my hashing has come to a screeching halt on Nicehash.  Deposited over 4 hours ago and 0 confirmations.  To make sure it keeps going I've already sent the next deposit.  Should be confirmed by tomorrow!   

If you send transactions with 0 fee, they take few days to be confirmed - or they may not even be confirmed. Nothing we can do about it. That is bitcoin network. We do not make deposit cofirmations.

[bigbitmine]

Unfortunately my hashing has come to a screeching halt on Nicehash.  Deposited over 4 hours ago and 0 confirmations.  To make sure it keeps going I've already sent the next deposit.  Should be confirmed by tomorrow!   

If you send transactions with 0 fee, they take few days to be confirmed - or they may not even be confirmed. Nothing we can do about it. That is bitcoin network. We do not make deposit cofirmations.

That's probably the problem.  It's only been the last couple of days though.  I normally make at least 2 deposits per day and they have always confirmed in less than an hour.  I've added a minimal fee now and will see if that speeds things up.

[nicehash]

That's probably the problem.  It's only been the last couple of days though.  I normally make at least 2 deposits per day and they have always confirmed in less than an hour.  I've added a minimal fee now and will see if that speeds things up.

You should always add a minimal fee ... blockchain is gettting "slower" these days https://bitcoinwisdom.com/bitcoin/difficulty and most of the pools are being reconfigured to not accept zero-fee transactions (due to BTC/USD price pressure) ... so you really should always add a minimal fee (bitcoin-core client 0.10 makes this easy since it has dynamic fee calculation).

[bigbitmine]

That's probably the problem.  It's only been the last couple of days though.  I normally make at least 2 deposits per day and they have always confirmed in less than an hour.  I've added a minimal fee now and will see if that speeds things up.

You should always add a minimal fee ... blockchain is gettting "slower" these days https://bitcoinwisdom.com/bitcoin/difficulty and most of the pools are being reconfigured to not accept zero-transaction fees (due to BTC/USD price pressure) ... so you really should always add a minimal fee (bitcoin-core client 0.10 makes this easy since it has dynamic fee calculation).

Weird.  Both have now confirmed.  1st was over 4 hours.  Other was 10 minutes.

[Llord-of-the-Sword]

That's probably the problem.  It's only been the last couple of days though.  I normally make at least 2 deposits per day and they have always confirmed in less than an hour.  I've added a minimal fee now and will see if that speeds things up.

You should always add a minimal fee ... blockchain is gettting "slower" these days https://bitcoinwisdom.com/bitcoin/difficulty and most of the pools are being reconfigured to not accept zero-transaction fees (due to BTC/USD price pressure) ... so you really should always add a minimal fee (bitcoin-core client 0.10 makes this easy since it has dynamic fee calculation).

Weird.  Both have now confirmed.  1st was over 4 hours.  Other was 10 minutes.

How are you adding a fee to your transaction? Is it simply adding smaller bits to the amount (ie. 0.200001)

[Neosaan]

hi!
Im heve Sgminer 5.1   speed quark
280x = 2.5 mh\c
270x = 1.5 mh\c

In nicehahs table  scrypt speed  x 5 = quark speed
how to get the speed of the script * 5

[nicehash]

hi!
Im heve Sgminer 5.1   speed quark
280x = 2.5 mh\c
270x = 1.5 mh\c

In nicehahs table  scrypt speed  x 5 = quark speed
how to get the speed of the script * 5

"xintensity" : "64",
"gpu-engine" : "1000",
"gpu-memclock" : "1500",
"worksize" : "256",
"gpu-threads" : "1"