Please add a cumulative graph comparing total earning over time for both methods, or at least a weighted average trend line for the PPLNS reward. Otherwise it is not readily apparent how the rewards from two methods compare over time...

I removed the first shifts (proofs of work are grouped in shifts, each of size difficulty/10). I started recording these before I switched to PPLNS, so the first ones naturally had no rewards.

This is just 46x difficulty worth of proofs of work. We are a small pool, and it wasn't always PPLNS, so we don't have that much data to go on yet.

You can see some bad luck in the beginning put us below average. Then a nice streak of good luck put us at about twice the expected earnings. From there up until now it's been pretty average. Right now we are having a really bad block, which is the reason for no earnings towards the end. Luckily we had some short blocks just before that.

Obviously the big lucky streak at the beginning takes a while to even out. Ending at 29 rather than 23 BTC is a big difference.Since switching to PPLNS we made 58 blocks rather than the expected 46. Too small sample size maybe? Any other pool ops have some data?

Can you explain that last graph? How can you have cumulative earnings higher than the expected average without corresponding dips below the average? Seems like that would imply the pool is losing money (and a great deal of it if that graph is accurate).

What parameters did you use to generate the graph? What is the timeframe of the second graph... if it's 1 million years, you're going to be stuck in the dip for your expected lifetime, losing money the whole time. If it's 2 days, then it would be silly to not mine there, since your actual revenue would then be guaranteed to be more forever? Without the time scale, it's kind of a meaningless graph.

Good looking graphs, though!

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

Can you explain that last graph? How can you have cumulative earnings higher than the expected average without corresponding dips below the average? Seems like that would imply the pool is losing money (and a great deal of it if that graph is accurate).

What parameters did you use to generate the graph?

The pool was simply lucky. It payout what it earns.

It actual earnings were more than its expected earnings (based on mathematical odds and hashing power of pool over time).

For example a solo miner w/ 1 GH would have an EXPECTED EARNINGS of 25.64 BTC per month however as solo miner it is impossible to earn that. In one month he will either earn 0 BTC, 50 BTC, 100BTC ... etc. Thus his actual recovery will always be more or less than expected recovery.

Obviously the big lucky streak at the beginning takes a while to even out. Ending at 29 rather than 23 BTC is a big difference.

What does the 29 and 23 BTC represent? Obviously the pool has earned a lot more than 29 or 23 BTC? Since nominal terms are meaningless (although some users might like to see them) it may be more useful to graph the difference between expected and actual recovery over time as a %. i.e. the ending point of 29 vs 23 would be +26%.

Please add a cumulative graph comparing total earning over time for both methods, or at least a weighted average trend line for the PPLNS reward. Otherwise it is not readily apparent how the rewards from two methods compare over time...

I removed the first shifts (proofs of work are grouped in shifts, each of size difficulty/10). I started recording these before I switched to PPLNS, so the first ones naturally had no rewards.

This is just 46x difficulty worth of proofs of work. We are a small pool, and it wasn't always PPLNS, so we don't have that much data to go on yet.

You can see some bad luck in the beginning put us below average. Then a nice streak of good luck put us at about twice the expected earnings. From there up until now it's been pretty average. Right now we are having a really bad block, which is the reason for no earnings towards the end. Luckily we had some short blocks just before that.

Obviously the big lucky streak at the beginning takes a while to even out. Ending at 29 rather than 23 BTC is a big difference.Since switching to PPLNS we made 58 blocks rather than the expected 46. Too small sample size maybe? Any other pool ops have some data?

Nice graph. The title is a bit misleading, though -- instead of saying "PPLNS vs. Expected Average" it should probably say "Pool earnings vs. expected average". The higher earning came from pool luck, not from the reward method.

Obviously the big lucky streak at the beginning takes a while to even out. Ending at 29 rather than 23 BTC is a big difference.

What does the 29 and 23 BTC represent? Obviously the pool has earned a lot more than 29 or 23 BTC? Since nominal terms are meaningless (although some users might like to see them) it may be more useful to graph the difference between expected and actual recovery over time as a %. i.e. the ending point of 29 vs 23 would be +26%.

The second graph is what someone with 1% of the pool's hash power would have earned since the time we switched to PPLNS. Maybe +26% makes more sense, instead of picking some arbitrary hash power.

Nice graph. The title is a bit misleading, though -- instead of saying "PPLNS vs. Expected Average" it should probably say "Pool earnings vs. expected average". The higher earning came from pool luck, not from the reward method.

I felt it was wrong to call the second graph "actual earnings" because noone hashed at 1% of the hash power the entire time. It's a bit hypothetical. Maybe it's ok to call it actual earnings if I put percentages on it like DAT suggested.

Also, the graph is PPLNS vs PPS (for this specific pool for the time we've been using PPLNS). The higher earnings came from pool luck, yes. But it was paid out to miners because of PPLNS. In this case we were lucky and payout was higher than PPS. But it could of course have been the opposite. It shows the variance from PPLNS. And as we see, 46x difficulty is not enough shares to even this out.

In this case, with PPLNS, the +26% earnings from good luck went to the miners. If it was PPS it would have gone to the pool op. Same thing of course if it had been -26%. With PPLNS the miners get the variance, with PPS the pool op does.

Can you explain that last graph? How can you have cumulative earnings higher than the expected average without corresponding dips below the average? Seems like that would imply the pool is losing money (and a great deal of it if that graph is accurate).

That's just the pool having better than average luck for a while near the beginning.

What parameters did you use to generate the graph? What is the timeframe of the second graph...

The timeframe for both graphs is 46x difficulty number of shares. Which is a while at a 70 Ghps pool, but I guess only about a day on deepbit? You can see that every area with zero pay in the first graph leads to a flat line in the second graph where earnings don't increase. Everything matches up between the graphs on the X-axis.

It would have made very much sense to mine here at the lucky period near the beginning, yes. But of course noone can predict that, and that's what makes PPLNS safe from pool hopping.

I felt it was wrong to call the second graph "actual earnings" because noone hashed at 1% of the hash power the entire time. It's a bit hypothetical. Maybe it's ok to call it actual earnings if I put percentages on it like DAT suggested.

Yeah that isn't intuitively obvious. I would simply show the full pool earnings (i.e. ~2900 BTC) or show it as a %.

Both might be best. The % (just a single line showing variance from the expected) is the most useful from a statistical standpoint because nominal values aren't important however I have learned often people believe "real numbers" more than %. Illogical but true.

Since no-one has had exactly 1% of hashing power (which changes continually) I would just show overall pools earnings.

"actual earnings vs expected earnings"

and then possibly a second graph showing the % deviation from actual.

BTW could you provide this data in txt (or csv or xls) form. I would be interested is generating some graphs from it. +26% is would seem (without doing an standard deviation calculations) to be REAL lucky. I am interested in quantifying our luck. Would also allow me to make some predictions on our likely variance based on hashing power. I guess I could screen scrape it from the blocks or shifts pages. I am wondering how you handled changing difficulty intra-block to draw the PPS/expected line.

BTW could you provide this data in txt (or csv or xls) form. I would be interested is generating some graphs from it. +26% is would seem (without doing an standard deviation calculations) to be REAL lucky. I am interested in quantifying our luck. Would also allow me to make some predictions on our likely variance based on hashing power. I guess I could screen scrape it from the blocks or shifts pages.

Maybe I can add this sort of thing to the JSON API later. But you can grab it pretty easily from the html source. If you "view source" in your browser you will find 2 huge javascript arrays. The first is actual share values, the second is the expected average values. For each line there is first an index number and then the numbers you see when you mouse over the lines in the graph. The second graph just uses the same data after adding up the values with some javascript. Hmm, come to think of it, the expected average values are easily calculated with javascript too - I should do that instead.

I am wondering how you handled changing difficulty intra-block to draw the PPS/expected line.

I didn't handle it, I just listed it as an error source at the top of the page. It uses the difficulty at the end of the shift, pretending it was the same throughout the shift. It looks like the difficulty only changed in 4 places, so it should not matter much. But for those 4 shifts I think I could calculate the average difficulty and use that. I'll look into that later.

Anyway, to me it's a little surprising that we are that far from the expected average. Do we have any probability experts here? What is "the long run" for bitcoin mining? 46x difficulty number of shares definitely looks like the short run.

So I have to admit, to PPS fans, that variance can be a bigger factor than one might expect. Just remember, though, luck isn't always bad luck, and taking a 50/50 risk doesn't always mean you lose.

But you can grab it pretty easily from the html source. If you "view source" in your browser you will find 2 huge javascript arrays. The first is actual share values, the second is the expected average values. For each line there is first an index number and then the numbers you see when you mouse over the lines in the graph.

Thanks.

Quote

I didn't handle it, I just listed it as an error source at the top of the page. It uses the difficulty at the end of the shift, pretending it was the same throughout the shift. It looks like the difficulty only changed in 4 places, so it should not matter much. But for those 4 shifts I think I could calculate the average difficulty and use that. I'll look into that later.

Makes sense. The simplest way would be to take average of starting and ending difficulty. It should cut the error down some from just using the ending.

Quote

Anyway, to me it's a little surprising that we are that far from the expected average. Do we have any probability experts here? What is "the long run" for bitcoin mining? 46x difficulty number of shares definitely looks like the short run.

It does for me too. More than I would have "guesstimated" which is why I always like to look at hard numbers. When I get home I will run some standard deviations but I would say we are well outside 2 standard deviations.

hy guy´s i just bought a spondoolius 1,5 TH´s miner.... i read several tuts and topic´s and i really don´t know which pool is the best for me.

I have a flat with great power connection means i have constant power connection. About internet i have only a 3g router which means sometimes it´s not the best.

now i have the best question ever: Which pool is the best for me? or better said which type is the best

looking forward to your answers.

3G means whatever you do, don't mine a pool with the GBT protocol and don't use a Stratum pool that sends you the transactions (not sure if any Stratum pools are silly enough to do this - but some may)

The GBT transactions dramatically increase the amount of data sent from the pool to you, whereas a good Stratum pool only sends you a small work item every 30s (some of the not-so-good stratum pools wait longer than 30s, but that is not as good for bitcoin either)

Some pools also send empty blocks to their miners - avoid them - it's due to bad quality pool software and poor programming language choices.

Though, of course, I will add that my pool does all those things right Stratum, with 30s work updates, no address blacklisting in an attempt to degrade the fungibility of bitcoin, no hidden transaction filtering, no hidden connections with companies to mine their transactions, we simply use the standard bitcoind rules with a larger block size limit and always send work with only and all transactions in it that the bitcoind template provides.https://www.kano.is/

hy guy´s i just bought a spondoolius 1,5 TH´s miner.... i read several tuts and topic´s and i really don´t know which pool is the best for me.

I have a flat with great power connection means i have constant power connection. About internet i have only a 3g router which means sometimes it´s not the best.

now i have the best question ever: Which pool is the best for me? or better said which type is the best

looking forward to your answers.

3G means whatever you do, don't mine a pool with the GBT protocol and don't use a Stratum pool that sends you the transactions (not sure if any Stratum pools are silly enough to do this - but some may)

The GBT transactions dramatically increase the amount of data sent from the pool to you, whereas a good Stratum pool only sends you a small work item every 30s (some of the not-so-good stratum pools wait longer than 30s, but that is not as good for bitcoin either)

Some pools also send empty blocks to their miners - avoid them - it's due to bad quality pool software and poor programming language choices.

Though, of course, I will add that my pool does all those things right Stratum, with 30s work updates, no address blacklisting in an attempt to degrade the fungibility of bitcoin, no hidden transaction filtering, no hidden connections with companies to mine their transactions, we simply use the standard bitcoind rules with a larger block size limit and always send work with only and all transactions in it that the bitcoind template provides.https://www.kano.is/

Unless there are problems or design flaws with antminer.com? then the pool profitability will average over time directly to the pool fee.In my case the pool fee is 0.9% so the payout is 99.1% PPS + 99.1% txn which averages out to be about 99.5% PPSI've no idea what antminer.com fees are.

Unless there are problems or design flaws with antminer.com? then the pool profitability will average over time directly to the pool fee.In my case the pool fee is 0.9% so the payout is 99.1% PPS + 99.1% txn which averages out to be about 99.5% PPSI've no idea what antminer.com fees are.

I have never mined on antminer.com and don't plan on it but if you can believe what they post on their thread this is what I found:

Features0% fees and PPLNS earnings. (The tx fee is not paid out to miners for maintaining cost and the bonus for our engineers.)