[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[Xanthon]

Not sure if I need Slush's permission to call the API but I have limited the refresh to 10 seconds minimum for now.

As a pool operator, I would recommend making the auto refresh interval measured in minutes, with 1 being the minimum.  Most people will run this in the background and rarely look at it, so having constantly up to date information is just adding load to the web server+database without much benefit.  It's one of the reason most pools removed/never added live refreshes on their websites:  Most people will just leave a tab open and forget about it.

Would be nice if slush added a anti-refresh measures. And maybe some other api for "vip" clients, if they so want. If you want to constantly spam refresh - consider a little donation.

Or even funnier method - your current round reward diminishes with every refresh by 0.005%

Perks activation like the way Bitminter is doing it should suffice.

Here's what Bitminter is doing.

1.5% donation to activate instant payout.
0.5% donation to activate API.

[1714109183]

1714109183

[1714109183]

1714109183

[1714109183]

1714109183

[sunriselad]

Just realized I cocked up the size of the stats window on the last compile.
Just resize the form and it should snap to where it's meant to be. 

[dishwara]

Strange, both tycho & slush not posting for the past some days, but coming online daily.

[digital]

Strange, both tycho & slush not posting for the past some days, but coming online daily.

I wouldn't post if I were slush either.  From my point of view, all the issues are fairly insignificant, and if he were to try to respond to each one it would likely make the clutter grow.  As soon as he started responding then it would be open season for every little non-issue out there...

[KNK]

I wouldn't post if I were slush either.  From my point of view, all the issues are fairly insignificant, and if he were to try to respond to each one it would likely make the clutter grow.  As soon as he started responding then it would be open season for every little non-issue out there...

+1

[Camello_AR]

He зa тo вóлкa бьют, чтo cep, a зa тo, чтo oвцý cъeл.

This is english forum.

OK - I going away.  Bye.

Nobody bans or kick off you. Only suggestd use of english, to be understanded by all of us. I´m not a english speaker, but , in fact I write here in english. Imagine how mess could be if I post in spanish, others in french, german, etc

[Lucko]

I disagree, there hasn't been a block miscalculation since the one everybody went berserk about exactly one week ago.

block=start_time,duration,reward,hashes,luck,difficulty,confirmations
235160=2013-05-08 15:13:44,1:27:14,0.00000096,9167,1.34,10076292,100

Since then people have been reporting the slightest variations as problems - when it's perfectly normal to have some variation - based on your own luck and the pool's luck as a whole.

Where people are reporting zero payouts, they are showing that they have submitted no shares - meaning connectivity issue - not block calculation issues.

I think Slush is monitoring from afar (I don't blame him for not coming on here with all the bitching going on) and long may it continue. Connectivity issues should be kept separate from the block miscalculation issues (which seem to have disappeared as I say).

User was looking at screen as he reports(and he is not the only one). I had logs that prove that shares are missing(unfortunately log is deleted when you restart CGminer and I deleted the copy from my computer since there were no way to report it to Slush and the block got confirmed). CGminer reported accepted shares(meaning that cgminer sanded the share and pool confirmed it valid) and pool didn't record them. Nobody is saying it is a calculation issue. It is database issue when you see this.

And I don't think Slush is monitoring this. Unfortunately I starting to think that something happened to him about 10 days ago and he can't control the pool and it is having bigger and bigger problems.

I still use Slush as a backup pool and I did see in time of maintenance of my new pool one miner connecting on Slush(stratum) and the other with same configuration going over all stratum server and api to old backup. So tell me that this is normal for a normal working pool. After loosing on 13 blocks I have given up on Slush since it cost me about 0.05BTC

[not.you]

Well as dishwara already pointed out, Slush's forum account is showing that he (or someone) is logging in to it.  But I agree with Lucko in that I have seen way too many anomalous payouts and missing shares in the past week or more to just think all is normal.  I already moved more than 20 of my miners elsewhere and only have one miner left on Slush.  Organofcorti posted a link a few pages back to a post about spreading your hashing power over several pools so I went that route.  I get less per found block on each pool but I get some kind of payout for a lot more blocks each day.  Plus since I put miners on both bitparking and bitminter I am also getting some alt coins.  I've got a pile of devcoins already whatever those are, woot!

[TomKeddie]

Code:

18048 	2013-05-15 23:00:36 	0:00:22 	43608 	24 	        0.01353690 	none 	236367 	25.00000000 	96 confirmations left
18047 	2013-05-15 23:00:07 	0:01:27 	165492     	94 	        0.01394973 	none 	236366 	25.14505001 	95 confirmations left
18046 	2013-05-15 22:58:40 	4:06:17 	32543599 	25921 	0.01909319 	none 	236365 	25.28750600 	94 confirmations left 

Woot!   Quick blocks, quick bucks!

I re-engineered my FPGAs to flush stale jobs faster sometime back, makes a difference on this pool for sure.  Payout is below average but the BTC per hour is superb!

[goatmonkey]

http://fileshosting.co.uk/files/MineMinder2.jpg

Fantastic! Thanks!

Will tip when I get more BTC. Only been mining a couple weeks.

[TObject]

Woot!   Quick blocks, quick bucks!

Awesome blocks. Unfortunately with over 900 MH/s I still have not managed to sneak a single share in ether one, according to my stats. Luck is not on my side today. LOL

[gbx]

I disagree, there hasn't been a block miscalculation since the one everybody went berserk about exactly one week ago.

block=start_time,duration,reward,hashes,luck,difficulty,confirmations
235160=2013-05-08 15:13:44,1:27:14,0.00000096,9167,1.34,10076292,100

Since then people have been reporting the slightest variations as problems - when it's perfectly normal to have some variation - based on your own luck and the pool's luck as a whole.

Where people are reporting zero payouts, they are showing that they have submitted no shares - meaning connectivity issue - not block calculation issues.

I think Slush is monitoring from afar (I don't blame him for not coming on here with all the bitching going on) and long may it continue. Connectivity issues should be kept separate from the block miscalculation issues (which seem to have disappeared as I say).

User was looking at screen as he reports(and he is not the only one). I had logs that prove that shares are missing(unfortunately log is deleted when you restart CGminer and I deleted the copy from my computer since there were no way to report it to Slush and the block got confirmed). CGminer reported accepted shares(meaning that cgminer sanded the share and pool confirmed it valid) and pool didn't record them. Nobody is saying it is a calculation issue. It is database issue when you see this.

And I don't think Slush is monitoring this. Unfortunately I starting to think that something happened to him about 10 days ago and he can't control the pool and it is having bigger and bigger problems.

I still use Slush as a backup pool and I did see in time of maintenance of my new pool one miner connecting on Slush(stratum) and the other with same configuration going over all stratum server and api to old backup. So tell me that this is normal for a normal working pool. After loosing on 13 blocks I have given up on Slush since it cost me about 0.05BTC

Man, all the Fear/Uncertainty/Doubt you can dish up.

All the blocks I've seen with incorrect payouts were eventually corrected.  I see some people freak out just after "Processing..." is completed.  It's clear there are multiple calculations on different boxes to get the final number.  I suspect on some of the blocks with "short" payouts, one of the boxes is missing from that calc.  You can refresh and watch it grow in 3rds...

I think the pool is better than ever.  He moved to a more stable host (and faster IMHO)....  I think he's tired of having 5000 employees and having a handful of those who work the least complain the most.

He's recalculating "short" blocks... it seems correct...   but I tell you what.  Log your next block session, don't lose the logs, and come back and complain with some REAL evidence you're being shorted.  Coming on here and bitching about what you suspect doesn't do anyone any favors.'

There are logging options in cgminer.  Use them, do the math, and then come back with real evidence and make some real accusations.  The pool has never been stronger....  He reacted to a theft, and a DDoS attack, and it's still going strong.  All the while, maintaining a good attitude and helping people.  Give the guy a break...  and we'll see you back next block with some real evidence, right?

[vs3]

I disagree, there hasn't been a block miscalculation since the one everybody went berserk about exactly one week ago.

block=start_time,duration,reward,hashes,luck,difficulty,confirmations
235160=2013-05-08 15:13:44,1:27:14,0.00000096,9167,1.34,10076292,100

Since then people have been reporting the slightest variations as problems - when it's perfectly normal to have some variation - based on your own luck and the pool's luck as a whole.

Where people are reporting zero payouts, they are showing that they have submitted no shares - meaning connectivity issue - not block calculation issues.

I think Slush is monitoring from afar (I don't blame him for not coming on here with all the bitching going on) and long may it continue. Connectivity issues should be kept separate from the block miscalculation issues (which seem to have disappeared as I say).

User was looking at screen as he reports(and he is not the only one). I had logs that prove that shares are missing(unfortunately log is deleted when you restart CGminer and I deleted the copy from my computer since there were no way to report it to Slush and the block got confirmed). CGminer reported accepted shares(meaning that cgminer sanded the share and pool confirmed it valid) and pool didn't record them. Nobody is saying it is a calculation issue. It is database issue when you see this.

And I don't think Slush is monitoring this. Unfortunately I starting to think that something happened to him about 10 days ago and he can't control the pool and it is having bigger and bigger problems.

I still use Slush as a backup pool and I did see in time of maintenance of my new pool one miner connecting on Slush(stratum) and the other with same configuration going over all stratum server and api to old backup. So tell me that this is normal for a normal working pool. After loosing on 13 blocks I have given up on Slush since it cost me about 0.05BTC

Man, all the Fear/Uncertainty/Doubt you can dish up.

All the blocks I've seen with incorrect payouts were eventually corrected.  I see some people freak out just after "Processing..." is completed.  It's clear there are multiple calculations on different boxes to get the final number.  I suspect on some of the blocks with "short" payouts, one of the boxes is missing from that calc.  You can refresh and watch it grow in 3rds...

I think the pool is better than ever.  He moved to a more stable host (and faster IMHO)....  I think he's tired of having 5000 employees and having a handful of those who work the least complain the most.

He's recalculating "short" blocks... it seems correct...   but I tell you what.  Log your next block session, don't lose the logs, and come back and complain with some REAL evidence you're being shorted.  Coming on here and bitching about what you suspect doesn't do anyone any favors.'

There are logging options in cgminer.  Use them, do the math, and then come back with real evidence and make some real accusations.  The pool has never been stronger....  He reacted to a theft, and a DDoS attack, and it's still going strong.  All the while, maintaining a good attitude and helping people.  Give the guy a break...  and we'll see you back next block with some real evidence, right?

Thank you gbx! I concur that Slush's pool is among the best options available (and in my opinion The Best).

Yes, stuff happens - just see that one:

Code:

18029 	2013-05-14 10:22:39 	1:18:11 	10929435 	1271 	0.00194877 	none 	236148 	25.61227001 	confirmed
18028 	2013-05-14 09:04:28 	1:04:00 	8890231 	1261 	0.00358784 	none 	236145 	25.34600000 	confirmed

Almost exact same length, almost exact number of shares submitted, half the payout ... Why? Because one of my miners had crashed (unfortunately) 20-30min before the end. So at the round end I was doing just about that much work and thus got the correct payout.

And I've seen a lot of other strange things happening with the miners - sometimes laggy internet (while me watching a movie), a switch misbehaving, etc - you name it. So - before blaming the pool check your end first. Don't rush to see the straw in the eyes of others and not see the beam in yours.

[Gamah]

I'm curious as to your reasoning to why you think you deserved 54% payout in the 2nd round when you submitted 82% as many shares/minute as the round before... aka... did 82% as much work per X time.

Or if we look at total contribution per pool shares...
You got .00016% total pool shares for the lesser paid round, and .00014% total shares for the better paid round. You actually contributed 14% more of the total shares on the round where you received 46% less reward.

[autonomous42]

Yeah let's not fearmonger here. If I were to put money on it, I'd say he's doing something related to the hack at OVH. Perhaps seeing legal counsel. I'm also sure he's heard our complaints and will have or has ironed things out but hasn't the time to write in detail. In the last day, however, I've seen my reward go up due to fewer miners at the pool. An interesting side effect.

[vs3]

I'm curious as to your reasoning to why you think you deserved 54% payout in the 2nd round when you submitted 82% as many shares/minute as the round before... aka... did 82% as much work per X time.

The reason is - this is not a PPS (pay-per-share) pool, but more like a PPLNS (pay-per-last-N-shares). In Slush's case "last" is about an hour, but when you add exponentially lower score to the older shares - it's really about the last 15-20min.

Many people get confused in this exact way - the number of shares DOES NOT mean a proportional payout. It would be proportional in a PPS pool, which this one IS NOT.

It is the TIME of those shares that matters (and by time I'm referring to how old the shares are, or in other words - how closely before the end of the round did you submit them).

So, back to your question - I learned (although too late) that one of my miners stopped submitting shares, and unfortunately it stopped closer to the beginning than to the end of that round. Hence the payout. I know how Slush's scoring works and that's why I'm not surprised by the result.

[gbx]

Yeah let's not fearmonger here. If I were to put money on it, I'd say he's doing something related to the hack at OVH. Perhaps seeing legal counsel. I'm also sure he's heard our complaints and will have or has ironed things out but hasn't the time to write in detail. In the last day, however, I've seen my reward go up due to fewer miners at the pool. An interesting side effect.

Don't forget, Slush is a miner too..  So he's looking at it from our perspective also.

I'm sure that OVH hack was no laughing matter.  ~3000 BTC is significant!!!!  If you've ever been robbed, had your car broken into, or been taken advantage of, you know what psychological impact that can have on you.  He's probably lurking, and taking care of things.  He's just not active on the forum is all.  Let's all just relax a bit and assume the best.... and avoid inaccurate or incorrect assumptions based on "feelings".

[Gamah]

I'm curious as to your reasoning to why you think you deserved 54% payout in the 2nd round when you submitted 82% as many shares/minute as the round before... aka... did 82% as much work per X time.

The reason is - this is not a PPS (pay-per-share) pool, but more like a PPLNS (pay-per-last-N-shares). In Slush's case "last" is about an hour, but when you add exponentially lower score to the older shares - it's really about the last 15-20min.

Many people get confused in this exact way - the number of shares DOES NOT mean a proportional payout. It would be proportional in a PPS pool, which this one IS NOT.

It is the TIME of those shares that matters (and by time I'm referring to how old the shares are, or in other words - how closely before the end of the round did you submit them).

So, back to your question - I learned (although too late) that one of my miners stopped submitting shares, and unfortunately it stopped closer to the beginning than to the end of that round. Hence the payout. I know how Slush's scoring works and that's why I'm not surprised by the result.

I see... I'll have to look more into this, I thought the N in PPLNS was in relation to the round as a whole... In that N being a variable was fixed to the duration of the round.

If you miner stopped near the beginning of the round, how can you be expected to have pulled a higher total pool percentage?

[organofcorti]

I'm curious as to your reasoning to why you think you deserved 54% payout in the 2nd round when you submitted 82% as many shares/minute as the round before... aka... did 82% as much work per X time.

The reason is - this is not a PPS (pay-per-share) pool, but more like a PPLNS (pay-per-last-N-shares). In Slush's case "last" is about an hour, but when you add exponentially lower score to the older shares - it's really about the last 15-20min.

Many people get confused in this exact way - the number of shares DOES NOT mean a proportional payout. It would be proportional in a PPS pool, which this one IS NOT.

It is the TIME of those shares that matters (and by time I'm referring to how old the shares are, or in other words - how closely before the end of the round did you submit them).

So, back to your question - I learned (although too late) that one of my miners stopped submitting shares, and unfortunately it stopped closer to the beginning than to the end of that round. Hence the payout. I know how Slush's scoring works and that's why I'm not surprised by the result.

I see... I'll have to look more into this, I thought the N in PPLNS was in relation to the round as a whole... In that N being a variable was fixed to the duration of the round.

If you miner stopped near the beginning of the round, how can you be expected to have pulled a higher total pool percentage?

Slush's pool is scored proportional and so is not much like PPLNS either.

[vs3]

I'm curious as to your reasoning to why you think you deserved 54% payout in the 2nd round when you submitted 82% as many shares/minute as the round before... aka... did 82% as much work per X time.

The reason is - this is not a PPS (pay-per-share) pool, but more like a PPLNS (pay-per-last-N-shares). In Slush's case "last" is about an hour, but when you add exponentially lower score to the older shares - it's really about the last 15-20min.

Many people get confused in this exact way - the number of shares DOES NOT mean a proportional payout. It would be proportional in a PPS pool, which this one IS NOT.

It is the TIME of those shares that matters (and by time I'm referring to how old the shares are, or in other words - how closely before the end of the round did you submit them).

So, back to your question - I learned (although too late) that one of my miners stopped submitting shares, and unfortunately it stopped closer to the beginning than to the end of that round. Hence the payout. I know how Slush's scoring works and that's why I'm not surprised by the result.

I see... I'll have to look more into this, I thought the N in PPLNS was in relation to the round as a whole... In that N being a variable was fixed to the duration of the round.
If you miner stopped near the beginning of the round, how can you be expected to have pulled a higher total pool percentage?

I have more than one miner. The rest worked fine - the final payout reflects the amount that the rest did.

The newer the shares - the higher the score (and also the older the share - the lower the score which eventually becomes zero). The miner that died had some shares towards the beginning of the round, but by the round end they were already too old and as a result their score was almost zero.

One "feature" that I'd like to have (even if it is a paid one) would be a database dump with the timing of each of my shares and their score. Slush already has that and that's what he uses to calculate the final score. That way everyone can crosscheck and match each share against what his/her logs say. And this can also help with troubleshooting and isolating misbehaving miners (because if you have several miners you can never be sure which was the bad one).