Ok, I've got some results, though I haven't spent enough time on this to be sure they're correct. Doing this for slush's method is complicated, so I've done this for PPLNM (the temporal version of PPLNS). Wlog assume that the window is 1 time unit. We have a miner with hashrate H2 mining intermittently for a pool which, besides him, has a constant hashrate H1. Once in a while he starts mining for some time and then disconnects. We will denote H = H2/H1. His efficiency in the first time unit he joins is
 (H (2 + 3 H) - 2 (1 + H) Log[1 + H])/(2 H^2)
And his efficiency in the last time unit before he disconnects is
 1/2 + 1/H + Log[1/(1 + H)]/H^2
So his average efficiency in these two time units is
 (Log[1/(1 + H)] + (1 + H) (2 H - Log[1 + H]))/(2 H^2)
This is always less than 1 so he earns less than normal. It achieves a minimum of 94.8064% at H=3.47669. As H->Infinity the efficiency approaches 1. For H~0 the efficiency is (1-H/12). This is only for the 2 time units spent in the beginning and end of each connected session; the rest of the time the efficiency is 1.

slush's method is a little different but I'm no longer confident it could create a positive effect.

I'd like to remind everyone that this happens only in temporal pools. Hopping-proof methods like unit-PPLNS and DGM are immune to the effect. slush's method is temporal which is one of its two problems, but since it's so big you likely won't see the effect - if you're mining at 1GH/s you'll only have 0.008% (1 part in 12000) reduction in the worst case (with the reasonable assumption that the numbers for slush and PPLNM are similar).

Edit: Fixed a critical error.

My estimate is that the difficulty will decrease by about 20%.

Yes, Bob was given both X and Y. See my edit for some example scenarios.

For me what happened is that I used a separate address for each worker in my mining pool. I wanted to know how much each generated. But instead, the client's display merged all coins received from the pool, so I didn't know which is which (of course I can collect the info from blockexplorer, and it didn't matter that much to me, but again, I could have really cared about this and I could have wanted to do this conveniently without hunting addresses in BE. And again, there's no justification to merge).

In other words, it's not the same thing at all. Senders are identified by the output address, not the input address. If I tell Bob to pay me by sending to address X, I know that anything that I receive to X is from Bob. I don't care what the input address is, only the output address (and indeed, the client tells me the output address but not the input address). If the client represents a payment to address X as a payment to my other address Y that's misleading.

True, there aren't many scenarios where this would happen. But for these scenarios we do want to know the true addresses, and there's absolutely no justification to merge them.

For me the scenario was mining pool rewards. Another imaginable scenario: Bob purchases products A and B from me, in amounts not agreed in advance but rather determined from the actual payment sent. I tell him to pay address X for product A and address Y for product B. If both payments are in the same block (I think it doesn't even have to be the same transaction), I don't know how much he paid for each. Also donations (send to X to support my project A, to Y to support B) and voting (X to vote A, Y to vote B - assuming one wants to vote for multiple items).

Looks like the same phenomenon I reported here. It's a bug if you ask me, but I didn't get taken seriously back then.

I wouldn't be surprised if it's a real result caused by self-hashrate-hopping. As you recall, in temporal pools it is an advantage to mine when the hashrate is higher. When you disconnect from the pool its hashrate is reduced, so conversely, you mine when the hashrate is higher.

I haven't quantified this effect, and AFAIK it could just as easily have the opposite effect by expediting decay of share submitted before disconnecting. I'll try to look into it.

amazingrando's debt is now fully repaid.

Ok, I get it now.

To be honest I don't understand what the first two charts are saying.

I removed the second link. I'll leave now.

The dependence on other pools is done only via difficulty retargeting, which happens once every two weeks. In between difficulty adjustments, each pool really is its own completely independent Poisson process.

Pool-hopping works by maximizing your gain for every share. Your gain per share in a proportional pool depends only on the eventual number of shares in the round, which is completely independent of any temporal considerations (such as the pool's hashrate) - only on the fixed probability of every share to be a valid block and end the round. The less shares in a round, the more you gain per share, so you want to submit to pools with the least shares in the current round.

You mean it doesn't now? How... uninspired.

One way to test if a list of empirical values were generated from a specific distribution is by comparing moments. If you take each round length and divide it by the difficulty at the time, you'll get values supposed to be distributed exponentially with mean 1. So the average nth power of the values should be n!. But you need quite a lot of observations to be accurate, more so for the higher moments - with 100 samples, even the second moment will be a bit off.

They don't have to be similar in nature. As long as the miner makes sure to only mine in pools were he doesn't lose to pool-hopping, his reward will converge to the average.

This doesn't make the quoted sentence any less wrong. The intermittent issue either exists in both PPLNS and proportional or in neither (and if it's neither, remove PPLNS from "...score-based and PPLNS pools require special consideration on your part").

The score for previous shares decays exponentially whether the miner disconnects or not. Remaining connected doesn't stop the decay, it just replenishes the score with the score of the new shares.


I'm not completely sure if we're still discussing in good faith. If I'm not welcome I'll leave, no hurt feelings.

Then say that. Don't say they punish people. A little bit of wording can go a long way.

Also note my other points above.

No coherent thread, but here's a short version of my vision: There will be several low-fee PPS pools, acting as a proxy to a p2pool as a backend. There will be many getwork servers, and people will freely mix-and-match their pool and getwork server(s). Oblivious shares will be used to prevent block withholding. Larger miners will skip the PPS pool and participate directly in the p2pool.

Chapter 5 is complete. Took me less time than I expected. (Let's hope the quality isn't too much adversely affected.)

It's in AoBPMRS. Prop variance is roughly (pB)^2*ln(D), PPLNS variance is (pB)^2/X. So you need X > (1/ln(D)), or roughly N = 7.1% of the difficulty. The number is different if metric other than vanilla variance is used, but for any reasonable one X=1 (which IMO is a better parameter than 1/2) makes PPLNS better than prop.

Ok, this is getting ridiculous. Life is not a zero-sum game, if it was there would be no way for pools to work in the first place. Pools exist to reduce a miner's variance without significantly affecting his expected payout and maturity time, and some reward systems do this better than others. Some systems make different tradeoffs between the three which are suitable for different miners.

Being the one who developed most existing hopping-proof methods, I choose to take this personally. Thankfully, your opinion of my work means very little to me.

In a 0-fee PPLNS pool, all of the block reward goes to the miners. Nothing stays with the operator. To claim that this has anything to do with the operator's bottom line is silly.

Any type of pool - even more complicated ones like DGM - can be trivially audited to make sure the operator indeed conforms to the method and doesn't cheat. If you're concerned they don't publish enough stats to enable auditing, lobby for them to publish share tables including hash values and block headers. Make sure the tables are consistent with the payouts given. Log the shares you find and make sure they appear in the table. Verify that the shares in the table are valid.

It's your guide. I don't have to agree with your opinions, but I'm hoping at least the facts will be straight.

That's just wrong. They don't punish anyone. Saying they can be confusing (or unintuitive, or unpredictable) will be more reasonable.

And again, this is relevant to high-variance methods, but not so much for PPLNS. You can easily have PPLNS decay rate measured in days rather than minutes.

It is unfair to condemn all hopping-proof methods just because slush's pool has very fast decay. Part of the reason for this is that slush doesn't use a score-fee, so fast decay is necessary for hopping-resistance. The geometric method is hopping-proof regardless of the decay, so decay can be more gradual if the operator can absorb some variance. Also, the size of slush's pool makes the decay temporally faster.

That's wrong. You could mine in a different score-based fair pool every day, and your total rewards will still converge to the average.

There ain't no such thing as a free lunch. PPS needs to take a fee to maintain stability; and, conversely, PPS has a lot of advantages so it is reasonable to pay a fee for it. I think going forward we'll have stable 1%-2% fee PPS pools.

That's wrong. Even setting aside the hopping issue, proportional pools have higher variance than a PPLNS pool with the default parameters. So if PPLNS is bad for intermittent miners, so is proportional.

If you're able to do this with a simple and clean user experience, I think you'll have a large market at that price.

But if by "sneaky way" you mean that the user will use PayPal to buy A, use A to buy B, and use B to buy bitcoins, it will be closer to 0.

That's true to some extent wrt slush/geometric (though IMO it's a bit overstated). It's not very true for PPLNS/DGM, since with the right parameters their window can be such that the variance for intermittent miners is pretty much the same as for continuous miners.

Sorry, fixed.

Is what you want to calculate "average per round of the total earnings which go to honest miners"?

This has no effect whatsoever on what really interest miners, which is how much they get in relation to what they would average solo (which is 56.5%). And if you want to calculate this quantity, then it has very little to do with the calculation in the appendix. In a round of length X the amount awarded to continuous miners is B * max (1 - (0.435*D)/X, 0)). Calculate the average of this over an exponentially distributed X and you'll get your answer.