Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 333. (Read 794443 times)

if you want to believe him or not is up to you,  but i can tell you he aint lying, i don't have the smarts to explain in detail but i came from that pool.

Show me sniffed log. NiceHash will drop connection when p is too high for current order, regardless of what kind of orders are there (maxed out or not). We have seen this faulty behaviour only happening after cgminer/sgminer is running for a while, and it always *fixes* it-self when you restart the miner. Completely logical conclusion is that there is bug in cgminer/sgminer, because NiceHash keeps no track of miners, all it gets is socket with IP and port - it doesn't know whether it is a reconnect after a while or a connect from restarted miner. If the bug was on NiceHash side, then restart of cgminer/sgminer would not help you.

Your secretive behaviour does not help you with your credibility. I am not fully sure whether we should even accept your feedback input at all. You talk about some mysterious pool for several pages now already, and we still haven't learned which pool this is.

Buyer or a provider?

As a buyer, you are in complete control of what is being mined.

As a provider, you get work and are paid in BTC. It is completely out of your hands what you are mining (you might even be creating private chains, attacking a blockchain, etc).

The buffering I am talking about is very key. Yes, it has been done before. And you are correct that a reconnect is neccesary to change extranonce1 and possibly extranonce2_size.  Having work buffered on the server ready for the miner before you force a reconnect and update the on-connect nonce params allows you to instantly provide work when the miner reconnects, essentially eliminating switch downtime.

As for the problem with idle miners - I have not observed failed auths in these cases. I see the pool accepting the auth request with p=, but not being able to provide work. This seems to occur when there are jobs at the desired profitability, but those jobs are already maxed on miner (no slots available). The pool keeps the connection open and allows the auth innappropriately.  If I set p high enough that no jobs are available (full or not),  this doesn't happen.

Don't know what you meant about slush's proxy. The pool I am talking about has a fully custom stratum implementation and can proxy traffic at will. The miner sees only the interupted message and mining barely hiccups.

My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?

I also still don't think the idle issue is a cgminer bug.  The addition of stratum commands to change the extranonce params that are limited to on-connect right now would be valuable, however.  Stratum is dying for a few extension like this, as well as for pool provided algorithm and nfactor.

Is there a the ability to select the coin you mine? How about somewhere else?

no phzi is right i know exactly which pool implemented it as i used to mine there(still do on occasion ), it is very possible.

NiceHash will send authorization error and drop connection. You can see that if you check logs of network traffic (sniff it, if you don't believe). Beyond that, there is nothing in our power to do about it, but to get sg/cgminer fixed. NiceHash cannot refuse connection until it gets authorization request, where p= is specified as password. Until this event, NiceHash will of course keep connection alive.

EDIT: Could you point me in direction of fix for sgminer? Thanks.


For each order, extranonce1 has to be changed. This cannot be done otherwise but to drop connection and force miner to reconnect. Once extranonce1 is changed, miner WILL have to change it's internal work that is being hashed, because extranonce1 is part of the work that is being hashed. There is no point in any kind of buffering you are referring to.

If any multipool actually implemented "real" proxifications to other pools like NiceHash is doing, it would hit same obstacle of extranonce bug in cgminer 3.7.2. And I really don't recall/haven't heard of any multipool not being compatible with cgminer 3.7.2. This makes me to believe, that no multipool is actually doing internal job delegation which you can observe with NiceHash service - or when slush's stratum proxy is used. They most likely use same extranonce1 numbers and can of course do "buffering" as you propose, because work for hashing does not change after doing reconnect.

NiceHash appends additional byte to extranonce1 which is taken from buyers pool. It cannot give own set of extranonces, because all work would be invalid on target pool in such case - it can only iterate from 0 to 255 (appended single byte), while the first part of extranonce1 (4 bytes) is equal to what was assigned by the buyers pool.

By buffering the next job's work before disconnecting the miner for a switch, you can get switch time down to a fraction of a second, and the risk of lost work is no worse then stales (and if you accept shares after a re-connect, then it's less).  In fact, a famous multi-pool has implemented just this so that when they proxy work to other pools, all you see is "Stratum connection to __ interrupted," and mining never skips a beat. Your post, therefore, seems an unacceptable reason for the poorly designed switching system that so far nicehash has implemented.  The current system isn't fair for providers or miners.  As a miner, I have to abuse the system to get the best rewards (constantly check if there is new work at higher pay, and reconnect whenever there is).  As a provider, there's no solid reasoning behind what bids will garner what hashrate.  I have had 1BTC unlimited rate orders and still watched someone with a 1BTC/GH lower bid continue to have a higher hashrate then my order for the following hour!  (That means over half the pool's buyers were earning less then they could have been, by a margin of over 10%). Not to mention, when bids are getting bumped around, the system will sometimes drop almost all the miners from my job, moving them up a job, and re-assign other miners to my job.  That's just flat out inefficient, and causes hashrate luls for both providers and buyers much worse then faster and appropriate switching would.

I am also not buying your guy's excuse that the idle miners are a problem with sgminer/cgminer.  Yes, you can fix it by patching sgminer...  but, your system is accepting stratum auth for miners that it should not - it accepts connections when there are jobs open but no work available.  That's a logic problem in nicehash, not in sgminer.

---

As for paying based on averages - your stats on the main page seem to show the current average BTC/GH/day rate... this is the rate that all miners should be paid, if you want a fair system.  Round robin is not working.  If you want to minimize switching, then average payment to miners is the only thing that makes sense (because then switching is irrelevant).  Just make sure you take into account reject rates per jobs vs per user when calculating proportional earnings if you want a fair system.

And don't count BTC - count shares, and then compute BTC periodically (say every 5 minutes for the previous 5 minute window) instead of on a PPS basis.  You don't have to worry about round hopping because found blocks aren't directly relevant here, so there is no reason not to use a proportional system based on short rounds.

Often miner restarts actually cause your miner to hash with lower hashing speed on longer run - that is why switches are not happening often. When switch happens there are three things to consider:
- possibility for some shares being lost
- miner procedure to issue reconnect, get new work, load work onto video card and start hashing again
- possibility for miner to switch to backup pool and mine there for few minutes before switching back again

Average payment is something we are consider to implement in future, but there might be some issues regarding tiny values. The BTC amount increase for each share submitted by all miners would be so tiny for slow miners, that we need to first run some calculations to see whether standard double float precision data type is enough or we need perform some tricks to get past this.

I am also confused why you are using a round robin method.  The buyers pay BTC/hash so why don't you average those among all the jobs that are currently being mined.

During some of the short periods where someone puts in a really high bid price, some of us may be locked into long-term lower priced jobs and miss the boat.

Also, if everyone wrote scripts as you suggest, wouldn't that really screw with your stratum?

So if I write a script that automatically restarts the miner if there is a new higher paying order, I will get paid more than everyone else? I already wrote a script that restarts it whenever there is a new "No limit" order, because your system just hates switching, even though it takes like 3 seconds, and I usually mine 1-2 BTC lower order because of that. I guess now I have to upgrade it to take that into account Maybe I should just restart miner every 3 minutes?

Can't you just pay the average, so we don't have to rely on luck or write some bizzare scripts to restart the miner every N minutes?

Where are you from? Asia?


Miners are gradually assigned to better paying orders. We decided to go with gradual assignation, because quick one would be causing too much disconnects and less work performed, because buyers usually do create new orders and cancel them a lot in short period of times. With slow gradual assignation, the factor of disconnects is minimal.

When re-assignation happens, miners from lowest paying orders are assigned to best paying orders. On long term run, this is fair distribution and makes all miners earn approximately same amount.

You can manually give your miner best paying order, if you restart your miner, because system always assigns new connecting miner to best paying order.

Do not forget about speed limitations. If order is 0.9-1.2 x of limited speed, it will be skipped and assigned to next best paying.

Website is down?

Edit: Or back up?

Question for the dev

At the moment, the top price is 11.60, and second it 8.90, with the lowest miner being paid 7.70.  It what order do miner get assigned work,  Who gets the highest rate.  This is currently at 50% gain from low to high.

Thanks

I am mine in your pool,but got so many reject at about 10%-15%
can someone help me to fix it?

More providers are needed! We're constantly at 10+ BTC/GH/Day with peaks reaching 20 BTC/GH/Day!

I still can't decide if nicehash timed it perfectly to start the site or they somehow rigged the whole thing with shitcoin pumping and whatnot 

Even still, what is worth that much?

who knows but that was short lived , back down to  13 now

edit: i guess its going back up, already to 14.50 ...

What the heck are people mining with Scrypt that makes paying 20BTC/Ghash/Day a good idea?