Bitcoin Forum
December 08, 2016, 08:24:37 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
Author Topic: bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)  (Read 76256 times)
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 06:53:37 AM
 #361

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481228677
Hero Member
*
Offline Offline

Posts: 1481228677

View Profile Personal Message (Offline)

Ignore
1481228677
Reply with quote  #2

1481228677
Report to moderator
tohwis
Newbie
*
Offline Offline

Activity: 10


View Profile
July 14, 2011, 06:55:07 AM
 #362

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

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
Member
**
Offline Offline

Activity: 106


View Profile
July 14, 2011, 07:25:06 AM
 #363

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
Member
**
Offline Offline

Activity: 112


View Profile
July 14, 2011, 07:28:01 AM
 #364

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


Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
luffy
Hero Member
*****
Offline Offline

Activity: 606



View Profile
July 14, 2011, 08:01:49 AM
 #365

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 08:05:30 AM
 #366

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
Member
**
Offline Offline

Activity: 112


View Profile
July 14, 2011, 08:07:35 AM
 #367

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 08:14:40 AM
 #368

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
Member
**
Offline Offline

Activity: 106


View Profile
July 14, 2011, 08:27:49 AM
 #369

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
Member
**
Offline Offline

Activity: 112


View Profile
July 14, 2011, 08:30:00 AM
 #370


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:

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

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 14, 2011, 08:31:10 AM
 #371

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!


Lol, you beat me to it  Smiley

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
Sangre
Newbie
*
Offline Offline

Activity: 22


View Profile
July 14, 2011, 08:39:09 AM
 #372

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:


Quote
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  Smiley

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
Member
**
Offline Offline

Activity: 112


View Profile
July 14, 2011, 08:43:55 AM
 #373

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 09:09:13 AM
 #374


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:

Quote
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
Member
**
Offline Offline

Activity: 106


View Profile
July 14, 2011, 09:24:02 AM
 #375

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 09:37:56 AM
 #376

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
Member
**
Offline Offline

Activity: 106


View Profile
July 14, 2011, 09:47:25 AM
 #377

Quote
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
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 14, 2011, 10:49:19 AM
 #378

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 Smiley

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
luffy
Hero Member
*****
Offline Offline

Activity: 606



View Profile
July 14, 2011, 10:50:08 AM
 #379

all systems have their "plus" and "minus" considering their fairness Smiley
what to choose?
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 11:15:46 AM
 #380

Quote
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 Smiley

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!