bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)

[hugolp]

What is with the big swings in the pool total hash rate today? In the lat hour or so I have seen it in the from 100Mh/s to 70Mh/s.

[tohwis]

Ok, I apologize. I thought you were referring to the hash rate estimation we display on our website.

Yes, you are correct, your miner will always display your "true" hash rate. And that shouldn't vary between pools unless your miner is idling a lot. I'm not sure about all the various mining software, but I know phoenix very noticeably says when it's idling.

If you are using the same flags, and you are not seeing any warnings about an empty queue or idle miner, let me know what mining app (and version if known) you are using. Also, your OS might be helpful too.

If all the settings do turn out to be the same on your end, I must say, this would be a first for me. But, I don't want to rule anything out either. 

Okay. Then the only reasonable explanation is that I have forgotten to add some flags, will check this later today. However, if I use the same settings as on other pools, I'll contact you with more details about the problem.

Thanks for the fast replies.

[lebuen]

What is with the big swings in the pool total hash rate today? In the lat hour or so I have seen it in the from 100Mh/s to 70Mh/s.

pool hopping? the point in time (about 0.4*difficulty) fits.

just want to clarify - abuse by pool hoppers (especially with prop/realtimestats) is not a question of faith. it's mathematically provable. for a good explanation, read this: http://forum.bitcoin.org/index.php?topic=24966.0

[1bitc0inplz]

Yes, the most recent drop in hash rate may have be due to pool hoppers leaving. We did pass the 600K share mark.

[luffy]

i guess 20% of the pool are the hoppers. do you think it is bad?
or good since we have the possibility to find a block during their "visit"?

[hugolp]

i guess 20% of the pool are the hoppers. do you think it is bad?
or good since we have the possibility to find a block during their "visit"?

Its bad because the non-pool-hoopers do the ungrateful work while it is being payed the same as the other work, while the pool-hoopers get the rewards from quicker finds of other mining pools. Pool-hooping is profitable unless the pool stablishes some time of anti-hooping mechanism, like rewarding more the late shares.

I know is tempting to not discourage pool hooping because you get more Hash/s rate for a while, but I think it also discourages the "legal" miners that feel they are being cheated.

[1bitc0inplz]

Indeed, that is why I'm very much inclined to like SMPPS....

But, I've yet to hear a direct yes or no from anyone regarding such a change.

[hugolp]

Indeed, that is why I'm very much inclined to like SMPPS....

But, I've yet to hear a direct yes or no from anyone regarding such a change.

How does SMPPS work exactly?

[lebuen]

Indeed, that is why I'm very much inclined to like SMPPS....

But, I've yet to hear a direct yes or no from anyone regarding such a change.

+1 from my side.

How does SMPPS work exactly?

http://eligius.st/wiki/index.php/Shared_Maximum_PPS

[1bitc0inplz]

How does SMPPS work exactly?

SMPPS is like PPS in that we'd offer a price per share. Unlike PPS, we'd have to wait until the round is complete (and the block has 120 confirmations) before payouts are made for shares.

One of the major downsides to PPS is that a really long round could eat into a pool operators reserve funds, and could possibly bankrupt a pool if either it was extremely unlikely or if someone attracted PPS via block withholding.

SMPPS avoids this downside due to it being "Shared Maximum", or in other words, if the total price of all pending shares exceeds the block income the pool operator pays out proportional to the funds that are available.

luke-jr wrote some pesudo code for how the payout scheme works here: http://eligius.st/wiki/index.php/Shared_Maximum_PPS

For readability, what luke-jr said was:

idealPayTotal = TotalMinerWork - TotalPaid
availableFunds = TotalPoolEarned - TotalPaid
if idealPayTotal < availableFunds:
    Pay according to Pay Per Share
else:
    Pay each miner PPSamount / idealPayTotal * availableFunds

During short rounds you will get paid less than proportional. In fact, during really short rounds the payout will be less than the block's 50 BTC. However, the excess is not something that the pool operator pockets. What the pool operator does, is move that into "available funds". Now, when a round goes long the pool operator will dip into the available funds to try and keep the per share price at the fixed and advertised price. If the available funds cannot suffice, total available funds are payout proportionally.

Now, since variance averages out over time, the available funds bucket will fluctuate up and down, but ultimately have a net of 0.

Remember our 8 million share round? In a proportional payout scheme, we all worked harder but got paid "less".

However, the two rounds before out 8 million share death round were very lucky. Had we been using SMPPS those two lucky rounds would have esthablished a reserve for us all, so that during out 8 million share round we can all get paid more proportionally to the time the block took to solve.

[1bitc0inplz]

Indeed, that is why I'm very much inclined to like SMPPS....

But, I've yet to hear a direct yes or no from anyone regarding such a change.

+1 from my side.

Thanks!

How does SMPPS work exactly?

http://eligius.st/wiki/index.php/Shared_Maximum_PPS

Lol, you beat me to it  

[Sangre]

EDIT: the stale thing is weird. I get amazing stale count, but suddenly I get like a burst of stales, for example this just happened:

It happens in random cards and only in this pool.

Except for this "bursts" of stales the stale count is amazing.

I confirm that, I have the same problem.

I just got done looking over our logs, and I do see a lot of stale shares coming from your works.

For example:

13 Jul 23:39:29 - info: getwork: stale share from XXXX
13 Jul 23:39:31 - info: getwork: stale share from XXXX
13 Jul 23:39:32 - info: getwork: stale share from XXXX

If you could tell me what miner you use, and what version you have that would be helpful. From our longpool logs it appears that you only have 2 open longpool connections, but four miners. Also, this rapid stales, like the above, indicates that either you don't have a longpool connection open or that we were not successful in getting you the LP getwork soon enough.

Also, on issues like this, for everyone I'd be curious to know what your ping response time to pool.bitp.it is. Network latence will play a small roll, and I figured it probably best to get as much info as possible  

Thanks all!

I use GUIMiner (2011-07-01 version) with poclbm kernel.
Two of my workers connects to the internet directly from the first computer, and two another connects via shared internet connection from another computer (I don't have a router, but have 2 LAN in my first computer). Perhaps, problem in it? Can you tell me the numbers (or labels) of my workers with no longpolling?

[1bitc0inplz]

I use GUIMiner (2011-07-01 version) with poclbm kernel.
Two of my workers connect to the internet directly from the first computer, and two another connects via shared internet connection from another computer (I don't have a router, but have 2 LAN in my first computer). Perhaps, problem in it? Can you tell me the numbers (or labels) of my workers with no longpolling?

That is awfully coincidental that you have your computers are split up two and two, and I'm only seeing two with an LP connection.

Right now, the way the logs are written out, all I see is how many LP connections per user, not per miner. I will need to jump into things to get that on a per miner basis, give me a little bit to get that info for you.

[hugolp]

How does SMPPS work exactly?

SMPPS is like PPS in that we'd offer a price per share. Unlike PPS, we'd have to wait until the round is complete (and the block has 120 confirmations) before payouts are made for shares.

One of the major downsides to PPS is that a really long round could eat into a pool operators reserve funds, and could possibly bankrupt a pool if either it was extremely unlikely or if someone attracted PPS via block withholding.

SMPPS avoids this downside due to it being "Shared Maximum", or in other words, if the total price of all pending shares exceeds the block income the pool operator pays out proportional to the funds that are available.

luke-jr wrote some pesudo code for how the payout scheme works here: http://eligius.st/wiki/index.php/Shared_Maximum_PPS

For readability, what luke-jr said was:

idealPayTotal = TotalMinerWork - TotalPaid
availableFunds = TotalPoolEarned - TotalPaid
if idealPayTotal < availableFunds:
    Pay according to Pay Per Share
else:
    Pay each miner PPSamount / idealPayTotal * availableFunds

During short rounds you will get paid less than proportional. In fact, during really short rounds the payout will be less than the block's 50 BTC. However, the excess is not something that the pool operator pockets. What the pool operator does, is move that into "available funds". Now, when a round goes long the pool operator will dip into the available funds to try and keep the per share price at the fixed and advertised price. If the available funds cannot suffice, total available funds are payout proportionally.

Now, since variance averages out over time, the available funds bucket will fluctuate up and down, but ultimately have a net of 0.

Remember our 8 million share round? In a proportional payout scheme, we all worked harder but got paid "less".

However, the two rounds before out 8 million share death round were very lucky. Had we been using SMPPS those two lucky rounds would have esthablished a reserve for us all, so that during out 8 million share round we can all get paid more proportionally to the time the block took to solve.

That is some clever idea.

The only problem I see with this is that if the first rounds after implementing this are very lucky the funds will be used to payout the future long rounds where miners that werent there before can profit. And there is no point on keeping it secret since it can be easily calculated from the pool stats. Anyway, given the options its not a bad solution.

[lebuen]

The only problem I see with this is that if the first rounds after implementing this are very lucky the funds will be used to payout the future long rounds where miners that werent there before can profit. And there is no point on keeping it secret since it can be easily calculated from the pool stats. Anyway, given the options its not a bad solution.

That's not true - it's still PPS, which means it eliminates "luck" entirely for the miners. You always get paid what you'd expect in the given time from your hashing rate and current difficulty.
So the only variable for you as a miner is time and hashrate. "Long rounds" don't change your rewards, an neither are "new miners" rewarded more at any time. It's always fair.

[hugolp]

The only problem I see with this is that if the first rounds after implementing this are very lucky the funds will be used to payout the future long rounds where miners that werent there before can profit. And there is no point on keeping it secret since it can be easily calculated from the pool stats. Anyway, given the options its not a bad solution.

That's not true - it's still PPS, which means it eliminates "luck" entirely for the miners. You always get paid what you'd expect in the given time from your hashing rate and current difficulty.
So the only variable for you as a miner is time and hashrate. "Long rounds" don't change your rewards, an neither are "new miners" rewarded more at any time. It's always fair.

So lets say the system gets implemented and the pool has horrible luck for two weeks. The miner will have some shares that are not payed since the reserve funds are 0. Now Bitp.it has two weeks of very good luck and creates some reserve funds. At this point some new mienrs come in. Now other two weeks of horrible luck, but this new miners get payed because the pool has available funds they did not contributed to obtain. Am I missing something?

[lebuen]

The difference between a miner's actual (SMaxPPS) earnings and PPS earnings is retained as credit, and considered in future blocks.

Unpaid shares remain as a credit and will be paid out before "new" shares are paid out. It's like a queue, no credit gets lost.

[TheSeven]

So does this mean that the pool will delay new share payout until all old shares are fully paid?
If there are withholders, this would mean that they will get full payouts one day, but payouts get delayed by possibly weeks, which is very unattractive to new users.

I can thing of two alternatives which might be better (I'm not sure yet):

• Keep track of the total number of bitcoins that a share should have been paid, and try to reach the same payout level for all shares. E.g. if all old shares have been paid 70% or something, the block's reward will first be used to bring the new shares to the same level, and if there are funds left, raise the payout level of all shares. (Of course if the block before had a lower payout level than average, these shares will be brought "up to speed" first.) This ultimately tries to achieve the same payout level for all shares.
• Do the same on a per-user basis. I.e. take into account that some users might have got 100% reward from some older blocks which by now are fully paid, and others only took part in "unlucky" (or just newer) rounds which aren't fully paid yet, and try to achieve the same average payout percentage for everyone. This sounds most fair to me in the long term, but may encourage users to register a new account after a couple of lucky rounds to escape redistribution. I'm not sure if that would be worth the effort though.

Any thoughts on these models?
Oh, and +1 for SMPPS in general

[luffy]

all systems have their "plus" and "minus" considering their fairness
what to choose?

[hugolp]

Unpaid shares remain as a credit and will be paid out before "new" shares are paid out. It's like a queue, no credit gets lost.

Ok, so there could be "negative" excess reserves, meaning that the pool will pay in the future those shares when they are found.

So does this mean that the pool will delay new share payout until all old shares are fully paid?
If there are withholders, this would mean that they will get full payouts one day, but payouts get delayed by possibly weeks, which is very unattractive to new users.

I can thing of two alternatives which might be better (I'm not sure yet):

• Keep track of the total number of bitcoins that a share should have been paid, and try to reach the same payout level for all shares. E.g. if all old shares have been paid 70% or something, the block's reward will first be used to bring the new shares to the same level, and if there are funds left, raise the payout level of all shares. (Of course if the block before had a lower payout level than average, these shares will be brought "up to speed" first.) This ultimately tries to achieve the same payout level for all shares.
• Do the same on a per-user basis. I.e. take into account that some users might have got 100% reward from some older blocks which by now are fully paid, and others only took part in "unlucky" (or just newer) rounds which aren't fully paid yet, and try to achieve the same average payout percentage for everyone. This sounds most fair to me in the long term, but may encourage users to register a new account after a couple of lucky rounds to escape redistribution. I'm not sure if that would be worth the effort though.

Any thoughts on these models?
Oh, and +1 for SMPPS in general

Yeah, this sounds like a good idea. But if the pool goes into a strike of bad luck, new users still know that they might be payed less, unless the pool goes into a strike of good luck, so its not as big but there is still a disincentive. Also, its complicated, people like simple things.