Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 914. (Read 4382653 times)

Lately your pool has been rejecting all of my CPU work and it is timing out constantly in my GPU miner. What gives?

? I'm just voting for p2sh, it does not mean that pool will split blockchain when there won't be a consensus. Please don't start any FUD...

and here comes chaos..... great Satoshi give us a sign

It is combination of some natural variance coming from score method as described and simulated here: https://bitcointalksearch.org/topic/m.50002 and the effect of added hashpower on the beginning of the round from pool hoppers. I recommend you to check daily rewards more than round rewards, because round rewards are influenced by many factors, not only your own hashrate.

Just a question: I am mining on this pool from a couple of weeks hashing at 1 Ghs 24/7 with 4 cards.
In my statistics I notice huge differences in my BTC reward between the blocks: I got between 0.01 and 0.04 BTC per block in the latest 10 rounds and I wonder why, since I doubt that hoppers can explain a so big variance, and the pool speed do not seem to change so much.
Any idea?

Few days ago I found http://btcrelay.com/, service which allow splitting incoming coins to many different bitcoin addresses. I see many useful use cases for such service. You can, for example, split pool payout, one part forward directly to the exchange and let it automatically trade for USD and second part forward to savings wallet. It is pretty nice way how to automate something what I did manually once per week before launch of btcrelay service.

FYI, pool is supporting p2sh now (see /P2SH/ in coinbase):
http://blockchain.info/tx-index/14771803/e88e3339e636ae1764c78043c295105141d56e01c4086cca92b6593660c6786d

BinoX, you're right that this is change which should not affect miners at all. I'm just writing it for people who are interested in recent fights about bitcoin protocol improvements.

To be honest, as long as my payments come in at about the same rate it doesn't really bother me too much what happens

You've been a trustworthy pool operator, so I feel I can trust that whatever decision you make in this matter

I've gotten my hands on a 5970, so hopefully I'll be throwing another 600+MHash into the mix as well

I found that a lot of people started p2sh war on this forum and for some unknown reason they're "fighting" about my pool because of this.

I want to tell that I'm *supporting* p2sh and Gavin's initiative, as I stated here and here.

The only reason that I'm not in the blockchain.info/p2sh stats is that patching of pool's bitcoind takes some time, but I'm working on it with Gavin and other supporters intensively.

So all you with signatures and forum threads "boycott slush", please stop spreading FUD.

Eclipse uses c=0.01, o=0.99, f = -0.0101...

Did you take the time to understand how DGM works and then judged it based on its merits, or did you just arbitrarily decide that it penalizes intermittent miners? It does no such thing. Mining with multiple pools will not reduce your rewards (and could be a good way to reduce your variance), and if you're disconnected you will only lose the worth of the work you could have done during that time. For every share you submit you get on average (Block Reward / Difficulty), that's all there is to it.

For a long time slush's method has been falsely accused of penalizing intermittent miners, so in a way it's kind of refreshing to hear you acquit it of this crime. But it looks like you've just found a new scapegoat in DGM.

slush's method is high variance, less hoppable than proportional, but still significantly hoppable.
Geometric method is similar to slush's method, also high variance, but completely hopping-proof.
DGM is also hopping-proof, but much lower variance.

In fact with DGM you can have the variance as low as you want, much lower than in proportional for example - it's all in the parameters. The easy way to reduce the variance is by increasing maturity time, which I think slush can pull off because it's a big pool, so even the increased maturity time will be pretty short.

PPLNS, when properly implemented, is also hopping-proof and almost as low-variance as DGM. It can be used if DGM is too complicated. In particular, I think shift-PPLNS could work better with slush's parallel architecture than DGM.

PPS is definitely a possibility, and I think PPS proxy pools are the way of the future. But until the substrate for it is developed, slush would have to take great risks, which he may not want to do without significantly raising the fees, reducing the long-term gains of miners.

-1

You realise that there is no significant loss of earnings for intermittent miners on PPLNS or DGM? They are provably fair, and in this context fair doesn't mean just hopper proof, it means that each share's expected reward is the same. You're confusing variance with mean reward, and DGM can be adjusted to reduce variance.

Going with pure PPS is fine, except that in order to eliminate variance you get a significant decrease in payout because of a fee, which needs to be at least 7% for the pool to remain viable through bad luck periods.

So your choice is: learn to live with variance on DGM, or earn less on pure PPS with no variance. If you've mined on slush at a low hashrate, you've already experienced more variance than you'll get under DGM.

I hope this helps clear up this "score systems penalise part time miners". I ran some simulations on intermittent mining at slush, and didn't see any significant difference in payout from intermittent mining at a proportional pool.

Thank you very much. Slush already contacted me. Let me tell you anyway that most of my cards are not overclocked, and now they are all approaching 7% rejected shares.

Binox, thanks for the response to majamalu, I sent him PM and forgot to mention it here.

You sure your cards aren't clocked a bit too high and occasionally give invalid results? When I took my 5830s up to 980MHz my invalid share rate went up, so I clocked them down to 950MHz and get basically the same amount of accepted shares and rarely any invalids.

It's also possible that it's just one card that's not working properly (6 same spec cards = 16.66666% of your hashing power per card)

Don't worry, this short block is invalid :-). Actually those two blocks were found in less than one second and blockchains on backends wasn't in sync yet.

0shares on that one but
http://blockchain.info/block/00000000000003eae180415821018e35b5d00d501ed1b6ec6dc65f566d05ecbc?site=slush
no sign of our block 163552

Wow, a one second block with only 25 shares.  Those shares are worth 2btc (roughly) a piece!  

Too bad i didn't get one...  

Hi Slush! I am having a problem with rejected shares. With some of my cards rejected shares reach 15%. I tried all possible changes in the settings, without success. Then I tried disabling LP. I waited for an hour before restarting the rigs but didn't notice a significant improvement.

I'm using:
2 rigs with 3 6970 each one
Phoenix 1.7
aoclbf 1.75

¿Am I doing something wrong?

Thanks in advance for your help.

Thanks Slush!