Topic: Tired of stale shares? (Read 7118 times)

Unfortunately this thread has gotten way off topic.

I understand that some people may not be concerned about stale shares. My hat if off to you. However, for those of us who prefer for our mining efforts to be as meaningful as possible, I was simply trying to point out that there is an alternative pool for people to join that does not suffer from stales.

Joel makes a very good point here.  Im inclined to agree that stales arent really as big of an issue as many people make them out to be.  I think its more a psychological issue and a misunderstanding of how things are working that cause people to be so concerned about it.   a huge high percentage of stales could indicate something is wrong with your mining client but in general i dont think its anything to be overly concerned about.   

As far as I know, pools still allow people to use miners that don't support LP. I think it might not be a bad idea to at least notify people that they're wasting effort. This is especially important for pools that pay proportionately and count stale shares.

I agree. In practice, the only way you can actually do this is never pay for stale shares or require LP.

Exactly. I've been trying to reason out if people who mine faster or slower would have more stale shares --during the 9 minutes or so when no blocks are generated and no stales are possible, the faster miner builds up more shares. But the slower miner is less likely to generate a share during the window where stale shares are possible.

Higher network latency could mean more stale shares. But the effect should be pretty minimal. Even assuming an extra 800ms latency, that would be at most an extra .2% stales.

I don't think your math is correct. A stale share simply means that the network found a new block before the share was submitted. It doesn't mean the work generated to produce the stale share had no chance to produce  valid block. Losing the race doesn't mean you didn't have a chance to win the race.

You are assuming that because a work unit lost the race, it had no chance of winning the race.

Ok, that's a good point. And I think the answer cannot be simply yes or no. If he continued the same work after he should have known it served no purpose, then I think his work was a waste and he should not be paid. If he just arrived back with his results 1 second after the other guy, it would only be fair that he would also be rewarded for his efforts. Perhaps one could have a grace period of a second or two after block change. "You wasted some work, but it's not your fault, so you still get paid."

I don't think this would matter as these stales are the same for everyone and won't affect your share of the payout. But it might have a psychological up-side seeing 0% stales even if it isn't true, and even if you just get the same amount of bitcoins as before.


Right. The cause for some stales may be the miner, and for other stales it's just that it takes time for the mining pool to notify all miners, or that the miner delivers a proof-of-work at the same time it is notified that it is stale.

I think if some users have more stales due to the miner they are using, it doesn't make sense to pay them for those additional stales.

Other than that all users would probably average the same rate of stales over time. In this case it doesn't make a difference whether you get paid for stales or not, you would still get the same share of the 50 BTC. It might have a psychologically positive effect to get paid for stales though?

The other side to it is that the mining pool is competing with other mining pools, so keeping the rate of stales down means a little more money for all users. Consider 50% stales versus 0% stales and a user with 10% of the proofs of work. With 50% stales it takes twice as long between every 50 bitcoins minted by the pool. Assuming all users have 50% stales it won't matter for each individual payout whether users are paid for stales or not. But it does matter whether you get a payout of 5 bitcoins every day versus every two days.

If the pool and/or miners are wasting 50% of the work, then they lose 50% of the potential income.  For 1% waste the loss is 1%. That said, it is impossible to get to 0% stales, because absolute synchronization is impossible in a distributed network. But getting closer to 0% means more money for everyone in the pool.

Non-stale shares are wasted work too, after all, you didn't successfully find a block, you just found a share. A person who finds a share and has it reported stale could have, with the same work, found a block a split-second earlier and been successful. You cannot say that just because the share was reported as stale that the work was wasted.

Sure, but having a share reported as stale only proves that the last bit of the work you did occurred after someone else found a block. Producing shares doesn't create a new block either, it only has a chance of doing so. Producing a stale share also has a chance of finding a block.

A better example would be a company that wants to make sure a job gets done as quickly as possible and so assigns two workers to do it. Both workers complete the job, but one does it a bit sooner and so the company winds up not needing the second worker's work. Should they pay the second worker? Was the second worker a waste?

That's quite true *IF* the cause of the stale PoWs is someone not supporting LP. But this thread wasn't about LP. It was about stales caused in other ways.

This is exactly right. Stales equal wasted work. Stales are proofs-of-work in the way that you prove that you were working. But were you working on something useful? No.

Pools are not paying you to burn GPU cycles. They are paying you to work towards finding those magic bits that can create a new block. Working on stale data will not create a new block.

This is why I worked hard to reduce stales in my pool backend and miner. In my current session I have right now 19848 accepted proofs-of-work and only 14 stales. Reducing the stales has real value. It has basically the same result as making a miner faster.

Consider an analogy: You have one employee in an office working, and another reading the newspaper. Both are doing something, but only one is doing something useful. Which is more fair for the company to do? Pay them the same, or pay only for useful work? If the company has 50 bitcoins to pay out as salaries, should both employees get 25 BTC each?

If you pay for stale proofs-of-work then everyone else will be paying for the useless work from that guy who's running an old miner without long polling support.

That is the thing you are missing. There are in fact pools that differ in their definition of a stale share. Some pools, for example, consider shares merely as proof of work and believe that a share that arrives at the pool server after someone else finds a block proves the same amount of work done as a share that arrives earlier. It is a fact that pools differ in their definition of what constitutes a stale share and therefore you cannot usefully compare stale rates across pools that pay proportionately unless you know how they define a stale share (and believe them or test it yourself).

You can, of course, compare stale rates across pay-per-share pools. If you don't get paid for stale shares, then stale shares come right out of your revenue stream. In pay-per-share setups, you don't particularly care whether the pool is efficiently finding real blocks or wasting your time finding blocks that will never get into the chain. If you're paid, you're good.

You are correct, the pool is the one who verifies shares. However, I am not aware of any pool that differs in what it rejects. At least for us, we reject invalid shares (e.g., shares that are corrupt or don't even meet difficult 1 target, etc), stale shares (stales that are not for the current network block), duplicate shares (shares that have been submitted before).

So, when I am talking about stale shares in this post I am talking about stales reported in the mining software. This encompasses all types of stales. For the honest miner on good hardware, though, it should only really encompass truly stale shares.

However, if a miner's hardware is failing or if someone wanted to intentionally resubmit shares or submit junk shares, then the pool has no control over their reported stale rate as they're jacking with it themselves by submitting junk.

The point of the OP was that most pools don't do enough on their end to reduce truly stale shares. And, by not doing that they are sending out getwork responses that will never be fruitful.

It depends. Stale rate is like CPU clock speed. For the same CPU architecture, clock speed can be important. But knowing the clock speed without knowing the CPU architecture, it is a meaningless number that can easily be manipulated to mislead you.

And, as I explained, this is incorrect. One can modify a pool to report zero stales and the miner's income is precisely the same. Pools do in fact use different algorithms to determine what a stale share is.

And that would be relevant if we were talking only about pools that defined shares in a particular way. However, different pools define stale shares differently. The purpose of a share is to prove work. Stale shares in this sense also prove work, so it makes sense fo pools to accept them.

In addition, miners can, if they wish to, submit the same share over and over after a new block is received. This will result in the pool having a very high percentage of stale shares. But it will have *no* effect on anyone's income.

What a "stale share" as reported by the mining client means is up to the pool operator to decide.

For everything you've denied, you have failed to say what you believe. Do you actually think that stale rate is not important?

The point of the matter is that stales reduce miner's income. Period. If more of the miner's and pool's efforts are spent doing work for the last block, then no forward progress is being made. This results in more accepted hashes per GH/s, and means the pool as a whole can check just that many more possible hashes per time period.

Good job, i have zero stales so far out of 400. 5 workers i usually get 1.4% - 2.7% stales.

Even if that was so, it doesn't matter, because this post is about reported stales.

I'm still talking about "real" stales, not reported ones. You're still missing the point  50% "real" stales would mean 50% less revenue.

I'd say the pool has one or more miners maliciously reporting stale shares to them. Pools generally don't track stale shares, so you can report the same stale share to them over and over. Failing that, it's possible they have a small number of miners unintentionally reporting stale shares to them due to bugs of various kinds.

So what would you say about a pool where >50% of the shares are stale, but they are reported to you (the miner) as valid? Screw "proof of work"  

I knew I had heard it somewhere.

That's my quote !

Or you can argue that stales are occurring because the pool is being informed of new blocks more quickly. A pool could always convert a stale share into a valid share by delaying when it processes a new block for purposes of declaring shares stale.

Stale shares occur when a share is received in a certain window, between when the map is cleared and when the LP triggers new shares to be given out. That window can be narrowed by processing LP faster, which is good. But it can also be narrowed by clearing the map later, which is bad.

How would that be a scam? The purpose of a share is to prove work, and stale shares prove work just as much as non-stale shares do. If pools are going to compete based on the number of stale shares, it makes sense to take technical measures to reduce them. If you believe stale shares are all or mostly the pool's fault (as the OP must) then it doubly makes sense not to count them against the miner.

There's a difference between accepting (stale) shares and reducing (real) stales and thereby increasing the number of valid shares.

Stales are mostly occuring because a pool is giving work out to multiple workers or is too slow to respond (send out LP) after a new block is found. Of course you can optimize this by writing better, more intelligent software.

If a pool just silently accepts stales as valid, then of course you're right. But this would be a scam (if it's not described as a "feature" in the pool manifesto).

That's not my point. It's not about "considering" shares stale, but really reducing the number of stales.

You're right. I didn't know that some pools accept shares that do not append the most recent block. I thought all pools only accept shares for the currently longest (known) block chain, and the difference in the amount of stale shares comes simply from bugs (in the pool software, or in miners) and the efficiency of long polling (faster LP response => less stales).

I could see why a pool would accept shares for the previous block for a few seconds after all LP requests have been answered (there might be a valid block among them that is superior to the current last block). This could actually increase the expected income of the pool. If other pools do the same though, it also increases the chance of invalid blocks, so it's the same if everyone is doing it as if noone did it. I guess. Thanks for clearing that up for me.