|
kenshirothefist: do you think we're going to see a few local stratum endpoints soon? Would be great to have at least 1 endpoint in North America, so we can beat back these reject rates a bit.
|
|
|
|
For these Pools, are we able to add difficulty at the end of out Bitcoin address, like we were able to when on p2pools of Vertcoin?
Diff is fixed at 512. You used to be able to specify 1024 manually in the password, but I don't think this has worked since PW's implemented his custom stratum layer. |
|
|
|
i wont say it WILL happen but it CAN happen, but thats all part of this game; is by the time most of these coins confirm its not gonna be worth what they're , but a ALOT less, its on CRYPTSY now, that means the death of this coin is inevitable, do not for instance tell me this is THE coin that will stand the test of time, hopefull thinker is hopefuly thinker. BUT they dont call it speculation for nothing. DONT get all your hopes up people, a little hope is ok. And hidden coin, really, the size of waffle alone makes it easy to spot where it's at, its like the elephant in the room.
A fair chunk has already been traded. Looking okay so far, and market depth is holding up. And maturation time is fairly reasonable. You are of course right, however - counting your coins before they are exchanged could be the new "counting your chickens". |
|
|
|
The system paid out 25 minutes ago, but I got nothing and it says transaction not found.
Date UTC TXID Amount BTC Fee BTC
2014-04-19 00:07:22 9edb382d0cd9b3fbbf2394cb7093608ebff87b055e038a631bba98c62de7eda6 0.00613913 0.00012529
My node sees this TXID without any issue. blockchain just hasn't picked it up yet, and it hasn't been included in a block. Just be patient. |
|
|
|
|
Oh coinwarz... CGA gets listed, and is ranked the most profitable coin to mine for a bit. Difficulty spikes, and now it's the least profitable coin to mine (can't even pay power costs). heh
|
|
|
|
This is why NiceHash can be attractive to you as a provider/seller: NiceHash will actually become a true multi-algorithm multi-pool where provider will be able to switch algorithm just by restarting his miner with different settings. This way you'll be able to see your earning all at one place, at NiceHash  In the future we'll provide an API for the sellers as well as for the buyers to be able to automate miners switching and orders switching. As a miner you'll be able to query our API and decide on which algorithm to point your miners in dependence of current orders profitability (if you can do a bit of scripting you can fully automate your miners to switch algos). You can already do this to some extent with the latest sgminer compiled from git. No need to restart the miner or script anything. sgminer now supports kernel hotswapping between different algorithms, and the hotswap takes less then a second. So, you can setup your pool config like below to automatically switch between scrypt and nscrypt, and within a small margin or error mine the more profitable algorithm: {
"name" : "NiceHash SCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "",
"pass" : "p=10.0;d=512"
},
{
"name" : "NiceHash NSCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3335",
"user" : "",
"pass" : "p=19.0;d=512",
"algorithm" : "nscrypt",
"nfactor" : "11"
},
{
"name" : "NiceHash SCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "",
"pass" : "p=8.0;d=512"
},
{
"name" : "NiceHash NSCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3335",
"user" : "",
"pass" : "p=15.0;d=512",
"algorithm" : "nscrypt",
"nfactor" : "11"
},
{
"name" : "NiceHash SCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "",
"pass" : "p=7.0;d=512"
},
{
"name" : "NiceHash NSCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3335",
"user" : "",
"pass" : "p=13.0;d=512",
"algorithm" : "nscrypt",
"nfactor" : "11"
},
{
"name" : "NiceHash SCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "",
"pass" : "p=6.0;d=512"
},
{
"name" : "NiceHash NSCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3335",
"user" : "",
"pass" : "p=11.0;d=512",
"algorithm" : "nscrypt",
"nfactor" : "11"
},
{
"name" : "NiceHash SCRYPT",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "",
"pass" : "p=5.5;d=512"
}
I interpret the p = 6.1 (or anything else) as a fixed number meaning not lower, not higher.
Are you saying it is a minimum of some sorts?
Of course it is a minimum... |
|
|
|
|
A better way to look at ROI is to decide at what difficulty they don't pay for theit power consumption anymore. Then, gage when you think that might happen. Gridseeds might be marginally profitable for a long while to come, so ROI might be a ways off, but if power costs aren't too high, you may well reach it.
|
|
|
|
I have the same problem and so does everyone else who has a minimum price set in the password. This is due to the new Limited GH/s option they added. Basically the speed is filled by other miners and it connects you and you just sit and wait for work that will never come.
They need to either add some code to fix this (not add new miners if the speed is filled) or remove Limited GH/s. This will really hurt the site if they leave it as it is since people will leave.
Working perfectly fine for me. The problem I see in the screenshot posted above is the 60second wait to see if wafflepool is stable. My dips on nicehash match with my peaks on wafflepool, so everything is looking fine. |
|
|
|
Is there a way to select a specific order# to hash for?
Nope. It's a round robbin assignment. |
|
|
|
This needs A LOT more hashing to cover more orders. If not it would just a private service for rich investors and would probably fail later. Hopefully we can see more miners joining and covering more orders so the price doesn't go to the moon and no one will want to use the service.
That makes almost no sense... If the price climbs high, then that means there are orders that high already, so we don't need more people to buy hashrate... Growth is good, but crazy growth would just clear the order books (which would be very bad). Awesome to see BTC/GH/Day rates climbing right now! >7 is pure awesome. |
|
|
|
I am pretty sure it is not [an average], since my graph says 5.90 at the moment, while countless others have 5.50
Hm, maybe it's just because I have multiple rigs mining here, and they are on different jobs. -- I think the Speed GH/s measurement is laggy or over a fairly long window. |
|
|
|
I certainly hope it's an averaging scheme, where all workers are getting paid for their portion of work completed irrelevant of what task it was on... although that might complicate matters regarding minimum profitability settings. I'm pretty sure it's not. 15 minutes ago I was mining @ 5.5BTC/GH, now I've been switched to 5.9BTC/GH, even though there is two 6.5BTC/GH orders. I am actually pretty sure it is an average. The chart shows my profitability has been fractional amounts like 5.54, 5.88, 6.12, etc since the change, and fluctuating much more rapidly. Previously it was 5.4 for a while, and then 5.6, back to 5.4, etc. Last 5 minutes have been at a profitability of 5.75BTC/GH/day. A very rough average based on GH limit rather then real GH rate would be (6.5*.1)+(5.9*.3)+(5.8*.2)+(5.6*.4)+(5.4*.01) = 5.874. Which is close enough to make me think the payout rate is definitely an average. |
|
|
|
The reject rate on this is horrible. Getting almost a 20% reject using cudaminer 750 ti.
I have been averaging around 5% rejects from western Canada, which is perfectly acceptable for a pool located in the EU (no geo-located stratum endpoints here yet, but apparently coming soon). please help me understand if i have these calculations right.
if i were to buy hashpower of 0.1 (that's 100mh/s correct?) and spend 5btc at a price of 5btc/day
i would get 100mh/s for 24 hours, is that correct?
.1GH would be 100MH, correct. If you ordered 5BTC of hashing at .1GH, at a rate of 5BTC/GH/Day, you would get 10 days of 100MH. also, i would essentially be bidding against other people that are purchasing hash power right? so the higher the price i list, the most likely my offer will get picked up? it looks like there is a wide range of bids, would a bid of say 2.5 btc/day get picked up? it's hard to tell it looks like every bid is being picked up right now.
Yes, you are in a bidding competition for hashing power. The higher you bid, the higher priority your job has. Keep in mind, however, that miners can set minimum payout rates. For example, I have p=5 set, so if there is no work paying >5BTC/GH/day, my miners failover to another pool and won't work on lower paying jobs. Furthermore, there have been rare few cases where the active jobs have been < 5BTC/GH/day since the pool started, so the chances of a 2.5BTC/GH/Day job getting completely quickly are very slim. kenshirothefist, can you explain how the hashing power is distributed from the seller's perspective, especially now that there are limits on the GH per job?
I certainly hope it's an averaging scheme, where all workers are getting paid for their portion of work completed irrelevant of what task it was on... although that might complicate matters regarding minimum profitability settings. If this isn't how it works, then I am going to setup a string of NiceHash failover pools with gradually decreasing minimum profitability, so that I'm always mining the highest paying job =p. --- Can you please add date/time added (or maybe "Time Waiting") to the current orders table? |
|
|
|
Any one else seeing similar or is it a problem at my end? I understand the two big up spikes - PW explained this on the previous page but the odd sawtooth display on the left is odd  That looks like you were failing over to WafflePool from another pool, or vice-versa. Or it's just missing data. |
|
|
|
Yeah, we're aware of it. This is also what phzi was talking about a couple of posts back. The issue is with the stratum protocol, which currently doesn't support changing the extranonce1. Therefore currently the only option is to disconnect a rig in reconnect it to new order. We'll see if we'll find a technical solution for this. It's possible to fix =). Multi-pools have had this issue in the past. However, another, organizational solution is already being implemented - will make sure orders don't switch too fast. There will be a minimum order time frame (not too long though, allowing for the buyers still to be flexible) and the possibility for order hash limit. This will allow more concurrent orders, less order switching and will make hash power providers to stay on single order for longer time. Will not be perfect, there will still be some disconnects form time to time. But at the end of the day we have to make some trade-offs between optimizations for sellers&buyers (we want to make a ~100% fair game for sellers&buyers). Stay tuned! Sounds like a good plan. --- I was just replying to your comment that everybody should switch from cgminer to sgminer - that's valid for GPUs only.
bfgminer has scaleability issues on Windows. Can't run more than a couple of instances, can't run more than ~20 miners. But that's another story, it's not a problem with nicehash.
I said everyone should stop using outdated mining software, and gave an example in sgminer. Yes, sgminer is opencl only. bfgminer would be an appropriate solution for miners with other hardware. I have no doubt that there are scalability issues on Windows... I also have no idea why anyone would run windows on a dedicated mining rig. And if you're using gridseeds, then a Pi is probably a better host platform solution. --- Looks like the stratum is completely offline right now? - my miners all just fell back to a failover pool. Nicehash.com not loading now either. |
|
|
|
sgminer doesn't support Gridseed
You can use bfgminer on gridseeds. At least bfgminer is actively maintained with scrypt support. |
|
|
|
can anyone (kenshirothefist: *poke*) summarize the problem with cgminer 3.7.2 and NiceHash's scrypt pool, point out the breaking commit (between cgminer 3.1.1 and 3.7.2) or the fix (in sgminer) relating to it? btw, great job on this service so far! it's great to see some innovative new pool ideas this year  cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer. There's really no good reason to be using an old version of cgminer anymore - switch to sgminer. --- Everytime the pool switches jobs, it seems to disconnect all my miners briefly. Lost mining time appears to be 1-5 seconds everytime, but any work that was performed immediately prior is lost as well. And sometimes when there are a bunch of small jobs, or several new jobs are posted in short succession, this is a pretty significant loss of hashrate. It's super obvious for me, because the R9 290 fans spin up slightly when the GPU isn't under load (noise change is very noticeable). With NiceHash, I hear the rig in my living room drop for a a few seconds several times in a minute sometimes. I see this regularly on my consoles: [21:50:14] Stratum connection to NiceHash interrupted
[21:50:15] NiceHash difficulty changed to 512
[21:50:14] Stratum connection to NiceHash interrupted
[21:50:14] NiceHash stratum share submission failure
[21:50:15] NiceHash difficulty changed to 512
[21:50:19] Network diff set to 84.7M
[21:50:19] New block detected on network before pool notification
[21:50:19] NiceHash communication resumed, submitting work
[21:50:20] Rejected 01529678 Diff 49.5K/512 GPU 1 NiceHash (Job not found.)
[22:08:30] Stratum connection to NiceHash interrupted
[22:08:31] NiceHash stratum share submission failure
[22:08:31] NiceHash difficulty changed to 32
[22:08:32] NiceHash difficulty changed to 64
[22:08:32] Network diff set to 10.4M
[22:08:32] Stratum from NiceHash detected new block
[22:08:32] Stratum from NiceHash requested work restart
[22:08:36] NiceHash communication resumed, submitting work
[22:08:36] Rejected cf84d7c0 Diff 316/32 GPU 4 NiceHash (Job not found.)
[22:08:30] Stratum connection to NiceHash interrupted
[22:08:30] Lost 2 shares due to stratum disconnect on NiceHash
[22:08:31] NiceHash stratum share submission failure
[22:08:31] NiceHash difficulty changed to 32
[22:08:32] NiceHash difficulty changed to 64
[22:08:32] Network diff set to 10.4M
[22:08:32] Stratum from NiceHash detected new block
[22:08:32] Stratum from NiceHash requested work restart
[22:08:36] NiceHash communication resumed, submitting work
[22:08:36] Rejected 04c785be Diff 54/32 GPU 3 NiceHash (Job not found.)
[22:08:36] Rejected 06e87f69 Diff 37/32 GPU 0 NiceHash (Job not found.)
[22:08:30] Stratum connection to NiceHash interrupted
[22:08:30] Lost 1 shares due to stratum disconnect on NiceHash
[22:08:30] NiceHash stratum share submission failure
[22:08:31] NiceHash difficulty changed to 32
[22:08:32] NiceHash difficulty changed to 64
[22:08:32] Network diff set to 10.4M
[22:08:32] Stratum from NiceHash detected new block
[22:08:32] Stratum from NiceHash requested work restart
[22:08:35] NiceHash communication resumed, submitting work
[22:08:36] Rejected 02350f7d Diff 116/32 GPU 2 NiceHash (Job not found.)
[22:08:36] Rejected 07b180d4 Diff 33/32 GPU 4 NiceHash (Job not found.)
There's no reason for the stratum server to be disconnecting miners like this when switching jobs. Please fix. Also, the server has been dropping me to down to low-diff on reconnects sometimes, even thought I have p=5.0;d=512 set as my password. --- Edit: just observed 3 connection drops within 20 seconds. |
|
|
|
phzi, are you reading my mind? That's exactly what we've been working on recently. We've implemented the first version of reject scheme and now you should see a lot less rejects. We've updated our stale shares detection about 15 minutes ago. Please check the reject rate in the past 10 minutes and let me know if it is any better (also check your graphs stats on NiceHash). Heh, awesome. Reject rates seem to have dropped into much more acceptable territory! Nice work. I will monitor for the next 24hr and try to remember to post again. Yeah, this issue was due to "partly-bad" end-point pools ... It's easy to detect when pool is really bad or really good, the tricky part is to detect when pool is "swapping". We also improved this - let me know if you still see "not responding" messages.
Thanks for your feedback!
Thanks for listening. Looking forward to seeing this pool grow. |
|
|
|
You can lower your share diff with "d=128" or whatever you want as password, so you submit shares more often you know.
I fail to understand how this is relevant to anything? Share difficulty affects ONLY variance. It has NOTHING to do with reject rates (a miner at 2048 diff vs 64 diff will be discover an identical number of valid shares, statistically speaking). Appreciate the link. I did read everything on the site, and this entire thread before I directed any hashing power here, however. We'll make sure it's a 100% fair game for sellers and buyers. Currently we've already resolved all the issues regarding general validation of the shares and this is already implemented. Provider is paid for all valid work it produces (even if some of this valid work is rejected by the buyers pool, because pool is not operating correctly).
Be nice if it was true... So far it certainly doesn't seem that way. You want fair? Then you need to implement a straight forward reject scheme such as, "shares submitted >1200ms after validity will be rejected". If you base rejects on the last block found, then you will never have a fair system, because that fairness will be completely destroyed when low-diff coins are mined. Otherwise, the highest BTC/MH job won't actually yield the highest BTC/MH, rendering this pool's entire work prioritization scheme broken. If the pool it putting enough hashrate on a job to orphan it's own blocks (I saw at least a dozen shares from my rigs that were valid blocks get rejected in under 2 minutes at one point!), then the pool is not operating optimally or IMO even within acceptable operating tolerances. What we're currently working on is better validation of stale shares. When a buy order is set to a pool that produces excessive stale shares on the provider side, provider is actually not being paid for those stale shares. However, even without intelligent stale shares detection we're not talking about 50% rejects but more like 5-10% worst-case scenarios.
Try 10% minimum. With properly tuned rigs that average <1% on most constant coin pools, and <3% on multi-pools, over the last 24hr I am getting >10% rejects here. And for several periods where there were high-diff coins getting mined... it was > 40% rejects for several minutes!!! But this is the exact same reject rate that a provider would have to "swallow" if you would be mining on any other pool or multipool which is hitting high-profitability fast-switching low-diff coins. But since our service is about renting (valid) hash power, buyer should pay for all the valid work that he gets, even if these are stale shares (buyer is the one that chooses a pool that produces stale shares) - therefore we'll improve this.
It is the amount that the person mining has to "swallow" when mining at a multi-pool, definitely! The person MINING at the pool must swallow, being key. The buyer is the person mining at a pool in this case, and they should be swallowing the cost of rejects due to their pool choice. NOT the miner. Otherwise, you need to allow miners to exclude jobs, or only select the jobs they want. Anyway - stale shares validation is currently being tested - will let you know when it's fully implemented.
Glad to hear this is still being worked on. I will definitely keep an eye and a few MH here for monitoring purposes. --- Overall tho, I have to warn the majority of miners to be careful of this pool for now. Due to the "we penalize only the miner for rejects" scheme, even with a properly tuned rig at low intensity you will see > 10% rejects at NiceHash.com. I provided a large portion of his pool's hashing power (around 10%) for over 24 hours, and my with response tuned miners (low intensity, tuned down even), reject rate has been >11% on average. This is completely unacceptable and needs to be fixed. I would have made more mining at WafflePool for the same period, once you account for the reject rate. NiceHash badly needs to adjust their reject scheme to at least partially penalize the buyer for choosing a high-reject pool or coin before this can possibly be a viable system. Penalizing the hash provider based on the buyer's decision to mine a low-diff shit coin is absolutely ridiculous. It would make significantly more sense to charge based on average reject rate, vs 0% reject rate. --- I think your definition of "valid" hashpower needs to change if this model is to remain viable. And I say this not because I wish to attack this site, but rather because I would like to see it succeed. --- One more question: The pool regularly stops accepting hashes for up to 10 seconds at a time: [17:22:13] stratum.nicehash.com not responding!
<...>
[17:22:22] Work available from pools, resuming.
I presume this happens on job switches due to an inefficiency in the stratum implementation? Regularly losing 10 seconds of work sucks quite badly, and is costing rigs here an extra percent or so of potential profit. |
|
|
|
Been trying NiceHash out recently, and overall it's great. However, non-payment for stale shares makes this site extremely hokey. Why? Because if someone pays to direct hashrate to an extremely low diff coin, you activity like this: [19:48:54] Stratum from NiceHash requested work restart
[19:48:54] Stratum from NiceHash detected new block
[19:48:56] Stratum from NiceHash requested work restart
[19:48:56] Stratum from NiceHash detected new block
[19:48:57] Stratum from NiceHash requested work restart
[19:48:57] Stratum from NiceHash detected new block
[19:48:57] Stratum from NiceHash requested work restart
[19:48:59] Stratum from NiceHash requested work restart
[19:48:59] Stratum from NiceHash detected new block
[19:48:59] Rejected 5aecc399 Diff 721/512 GPU 2 (Job not found.)
[19:49:01] Stratum from NiceHash requested work restart
[19:49:01] Stratum from NiceHash detected new block
[19:49:03] Stratum from NiceHash requested work restart
[19:49:03] Stratum from NiceHash detected new block
[19:49:03] Rejected 1908fd32 Diff 2.62K/512 GPU 4 (Job not found.)
[19:49:03] Stratum from NiceHash requested work restart
[19:49:04] Stratum from NiceHash requested work restart
[19:49:04] Stratum from NiceHash detected new block
[19:49:06] Stratum from NiceHash requested work restart
[19:49:06] Stratum from NiceHash detected new block
[19:49:08] Stratum from NiceHash requested work restart
[19:49:08] Stratum from NiceHash detected new block
[19:49:08] Stratum from NiceHash requested work restart
[19:49:09] Stratum from NiceHash requested work restart
When this site pushes so much hashrate to a low-diff coin like this, reject rates go thru the roof, and the actual payout is abimismal. Meanwhile, the person paying for hashes gets up to 50% "bonus" hashrate because most shares are rejected. I am going to move my rigs away from here until this is fixed, but I am definitely going to start buying lots of hashing time for low-diff coins that seem valuable... I think a change is needed here if you don't want this site to get gamed badly and fail. Either average reject rate needs to be considered, and the person paying for mining power should pay based on that average reject rate (individual miners with higher reject rates should get less of course). Or, NiceHash should avoid piling all of the pool's hashing power on a job when the difficult is so low that we compete with ourselves for orphans. |
|
|
|
|
Show Posts
