It's to make it numerically robust and avoid overflow. Both lS and ls eventually get so large that exp(lS) and exp(ls) cause overflow. But their difference lS-ls always manageable.

That's why we're using logarithmic scale in the first place, if you could handle exp(lS) directly you could simply work directly with S as in the original formulation.

Right.

The assumption is explicit = \xi is defined as n / (2^32 D), meaning that D = n / (2^32 \xi).

And yes, in this calculation n and D both go to infinity at a specified ratio \xi. The assumption that \xi is fixed was not explicitly written but it follows from context.

D doesn't have to "go to" infinity in real life for the calculation to show that if D is sufficiently large, then for any n the probability of not finding a block is roughly exp ( - n / (2^32 D)).

It's not an error, though tricky and somewhat unclear.

He is assuming that \xi is constant while n and D are variable. For \xi=2, for example, he is considering a case that the hashes calculated are twice the average needed; he then considers what happens when D, and correspondingly n, go to infinity (continuous case). In this case the chance of not finding a block is indeed exp(-2).

Were you a victim of this? Are you providing evidence that this was not brute-force, or simply explaining how to properly choose passwords?

Update - after speaking some more with my affected customer I am no longer convinced his password was indeed strong enough.

Maybe passwords were brute-forced after all? silvereagle - just how strong was your password?

Will be happy to hear about any progress in figuring this out.

Thank you, and you're welcome.

If you have some spare time, you don't have to speculate about the contents of my thesis - it's available at https://bitcoil.co.il/files/Thesis-Meni-f2.pdf.

Yes, I should have clarified that, sorry.

If you want to assume he keeps mining, there are two factors to consider - his current score and his future proportion of the pool's hashrate. Taking them both into account requires some calculations. It's easier to just show what his reward will be if a block is found right now.

Shares submitted after the orphan will be worth more than those submitted before, and this is proper.

The orphan did happen and this is information that needs to be taken into account. The orphan blocks are not in addition to the valid blocks - they are instead, some of the blocks which should have been valid end up orphans instead. The correct comparison is not orphan vs. no block, but rather orphan vs. valid block.

When a block is found, all past shares have a chance to get a payday if it ends up valid. The cost of this chance at payment is the score reduction - even if, contingently, it ends up an orphan. Later shares never had a chance to profit from the block, and thus don't get their scores reduced for it.

This is similar to the situation with shares in general in a pool - when you submit a share, you are rewarded even if the particular share was of no use, because in finding a share you had a chance to benefit the pool - and you get an expected reward equal to your expected contribution.

Right. In practice you could trim scores which are below a very low threshold.

It seems you are suggesting that rescaling on every share is easier than rescaling once in a while, I don't see why.
I do recommend logs, they're less intuitive but more robust and probably less resource intensive.

S/s is not the expected payout from the next block. S/s (or more accurately (1-f)*(1-c)*S/s, accounting for fees) is what you asked about just now - the expected total eventual payout for already submitted shares.

The expected payout for the next block is S/s * (1 - c/(1-o+co)) * (1-f).

I have a customer who is a victim of this particular theft.

Here are his answers to piuk's questions.


He insists that he is keeping a secure environment and that neither his computer nor strong password were compromised.

Any leads on what could have caused this? Or who the thief is?

Will reimbursing affected users be considered?

Leaving the score alone won't work.

You could add to the worker's score in a way that compensates for the lost payment, but that is more complicated. It is simpler to keep a record for each miner of the total deferred payment, and when it is high enough make the physical payment via a normal transaction. Deferred payments will be kept in a designated address in your control.

It's even simpler than that - you don't need to set S=S/o. The score will remain in its reduced state and only the actual payment will be cancelled, and if you pay in the coinbase this happens naturally when the block is orphaned.

I can see why it is intuitive to treat orphaned block as if they never happened - thus cancelling S=S*o - but the method invariant is based on the assumption that a share has a probability of d/D to be a block. If orphans exist this is no longer the case, shares actually have a lower chance of becoming a valid block. If orphans are ignored completely, the operator will pay out more than he should (the block rewards he actually receives are lower than the method assumes). I've done the math and if you simply cancel the payment specified for the orphan blocks, everything is just right. This assumes, however, that every block, once received by the pool, has the same chance to become an orphan.

A tricky part is how to combine this with the dust payments mentioned earlier. You can no longer rely on the network to cancel the orphan payments - you'll need to actually remember for each worker the reward per specific block, and if a block becomes an orphan remove that record yourself.

Yeah, it's discussed in AoBPMRS.

Yes.

It doesn't need to be but that generally gives a reasonable tradeoff between variance and maturity time. X in PPLNS is in some ways analogous to approximately c/(1-o).

It wasn't designed to work with variable c; I think we could make it happen if we change the way some things are parameterized, but it's easier to vary f (make it 0 for the high-difficulty-share miners, and slightly higher for the low-difficulty shares).

Correct. But it wasn't a misunderstanding on your part either - if f<0 the operator can indeed pay out of his own pocket.

You can choose f=0 to avoid having to pay out of pocket, but it limits your options for reducing variance and maturity for miners. You could use something like f=0, c=0.01, o=0.99, it turns out similar to PPLNS. in core parameters.

PPLNS is "supposed to be" a method where there is no operator risk, he just pays out the rewards for each block in some way. However, for the method (or any other method) to be hopping-proof even when the block reward changes, this is no longer the case.

Shares are still paid (Bd / DX) duntil the total of d/D reaches X. If, when a block is found, the reward is low in comparison to the reward at the time recent shares were submitted, the amount he has to pay according to the method is higher than the block reward, and he must pay the difference from his own pocket. And conversely, if the actual block reward is higher he keeps the difference.


If B is highly variable it can cause quite a lot of risk to the operator. It could be mitigated by basing the credit per share not only on the expected contribution but also the variance created.


In pay-once PPLNS you know the maximum amount you can be paid for a share, but you don't know whether you'll be paid it at all or not. It's not just that you don't know when you'll get it. Future B has no effect on whether you get paid and when.

True.

It's d/D, and yes, d is for the share that solved the block.

To be clear, when I said pay-once isn't it, I meant it's not simple, not that it's not hopping-proof.

I think if you follow the original method, and just cap the payment for each share to (sB/X), skipping already paid shares, it will work fine and be protected from hopping based on both pool past and future difficulty changes. You'll need to keep for each share not only whether it was paid, but how much, so if it was partially paid, it can be paid more in future blocks.

I added in a later comment that to be protected from hopping based on block reward (which will be critical when the reward is based on tx fees), B for each share needs to be chosen when the share is submitted, not when the block is found.

If you want a simple hopping-proof method, PPLNS is it (not the pay-once variant), assuming it's implemented correctly. Or shift-PPLNS which is more scaleable.

You're welcome.

It's variance, not maturity time. A miner submitting a share has a chance to get more than the PPS amount, but also a chance to get nothing at all, ever. If he does get paid, it will be with high probability in a short time.

Not really. If for example X=0.5 then still normally a block will be paid out 100% to recent miners - each share will be paid twice the PPS rate. But in lucky times when there aren't enough unpaid shares, past miners can be paid.

Payment always starts at the last share and continuously moves backward as much as possible, skipping any already paid shares.

That post has some fundamental errors regarding how double-spending works (explained in a comment there).