Tired of stale shares?

[lebuen]

Given that information, 100 shares in any reward scheme will net you more reward than 98 shares would.

Not in a proportional scheme. 100 shares out of 100,000 will give you the same reward as 98 shares out of 98,000.

you don't think this through to the end. less valid shares means you'll need more time (on average) to find a block. so of course it's important to reduce stale shares. reducing stale shares is the same as increasing your hashrate.

[JoelKatz]

you don't think this through to the end. less valid shares means you'll need more time (on average) to find a block. so of course it's important to reduce stale shares. reducing stale shares is the same as increasing your hashrate.

No, not at all. Consider two mining pools. One reports 2% stale shares. The other doesn't even check if shares are stall at all and so reports all shares are valid (no stale shares). Assuming a proportional payment scheme, your returns will be (on average) precisely the same with both pools. To conclude that a proportional pay pool with fewer stale shares will pay more than one with more stale shares requires that you closely scrutinize the algorithm used by both pools to determine whether a share is stale.

[lebuen]

No, not at all. Consider two mining pools. One reports 2% stale shares. The other doesn't even check if shares are stall at all and so reports all shares are valid (no stale shares). Assuming a proportional payment scheme, your returns will be (on average) precisely the same with both pools. To conclude that a proportional pay pool with fewer stale shares will pay more than one with more stale shares requires that you closely scrutinize the algorithm used by both pools to determine whether a share is stale.

Well, I'm sorry to say and I know you'll refuse to admit that you were wrong. But you are.

There is no "algorithm" to determine whether a share is stale or not. Either a share has the chance to find a block (it's valid), or it's duplicate/wrong and thus doesn't have a chance to find a block (it's stale). Every valid share has the same chance to find a block.

So in your scenario where a pool "doesn't even check if shares are stall at all and so reports all shares are valid (no stale shares)" this will happen: a miner submits 100 stales and 1000 valid shares, but he will be displayed 1100 valid shares. Let's say there are 10 more miners with the same numbers. The pool then has 11000 shares in total and every miner get's 1/10 of the total revenue. BUT: the pool only has 10000 valid shares so far and thus has a lower probability of finding a block than another pool, which in the same time had 11000 valid shares (and really NO stales). So the members of the pool with no stales also get 1/10 of the total revenue, but total revenue is more (on average).

My english is a little limited, so I don't know how to explain this any further. But it's simple math: your hashrate is limited. the more valid shares you get out of the total amount of shares you compute, the better is your chance of finding a block.

[gentakin]

If JoelKatz is talking about the "reward per block", he is right. Stales don't change it if the stales happen to everyone on the pool.

Who cares about reward per block though? It's all about the reward per day/hour/whatever. And less stale shares means more blocks found by the pool because less proof-of-works have to be discarded, thus  higher reward per day. lebuen is correct.

[JoelKatz]

There is no "algorithm" to determine whether a share is stale or not.

Yes, there is. And different pools use different algorithms.

For example, some pools consider a share stale if the share was reported to the pool after a new block was found. Some pools don't consider a block stale even if it doesn't extend the currently longest hash chain if it would have extended the previously-longest hash chain. Pools do this specifically so they can advertise a lower number of stale shares, even though it has no effect on returns.

Either a share has the chance to find a block (it's valid), or it's duplicate/wrong and thus doesn't have a chance to find a block (it's stale). Every valid share has the same chance to find a block.

You are assuming that every pool uses precisely the same algorithm to determine whether to consider a share stale or not. I know for a fact that this is not true.

[JoelKatz]

Who cares about reward per block though? It's all about the reward per day/hour/whatever. And less stale shares means more blocks found by the pool because less proof-of-works have to be discarded, thus  higher reward per day. lebuen is correct.

This is completely false. If you don't see why, consider this argument:

A pool uses proportional rewards. 1% of all shares are stale. The owner decides to change the algorithm and no longer consider any shares stale. 0% of all shares are stale. What happens to the rewards per day/hour/whatever?

Answer: They are exactly the same.

What you're missing is that different pools use different algorithms to determine when they consider a share stale. They do this specifically so they can advertise fewer stale shares just like is happening here. But it's a form of scam or at the very least misrepresentation because it has no effect on proportional payouts.

[gentakin]

What you're missing is that different pools use different algorithms to determine when they consider a share stale. They do this specifically so they can advertise fewer stale shares just like is happening here. But it's a form of scam or at the very least misrepresentation because it has no effect on proportional payouts.

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.

[lebuen]

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

A pool uses proportional rewards. 1% of all shares are stale. The owner decides to change the algorithm and no longer consider any shares stale. 0% of all shares are stale. What happens to the rewards per day/hour/whatever?

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

[JoelKatz]

Stales are mostly occurring 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.

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.

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

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.

[MrSam]

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.

That's my quote !

[JoelKatz]

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.

That's my quote !

I knew I had heard it somewhere.

[lebuen]

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"  

[JoelKatz]

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

[lebuen]

Pools generally don't track stale shares

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

[JoelKatz]

Pools generally don't track stale shares

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

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

[indio007]

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

[1bitc0inplz]

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

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.

[JoelKatz]

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

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.

The point of the matter is that stales reduce miner's income. Period.

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.

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.

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.

[1bitc0inplz]

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

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.

[JoelKatz]

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.

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.