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

I completely disagree.  The graph seems to show that slush's anti-cheating efforts result in a potential 3.5% gain for those who choose to abuse the system, but no more than that.  3.5% is small enough that the majority of people will not bother to try to cheat the system, which is exactly what we want.  3.5% is much smaller than the potential gain that could be had if slush did not implement the anti-cheating measures.

Has any one that has found at least 1 block for the pool earned more payout than the average?

ie: (blocks found * 50) - %tip < bitcoins payed out from pool?

What that graph shows is that the best a cheater can hope for if he manages to predict a random anomaly in pool round length is 3.5% better than staying in the pool constantly.

Now consider the case of pool that splits by % of shares in the round. For simplicity assume we have 2 pools each of which solves a block on average once an hour. The cheater average payout for staying though an entire round is X. So if after an hour of mining in pool 'A' without a success pool 'B' finds a block and starts a new round. The cheater jumps from pool 'A' to 'B'. Since the chance of finding a block does not change no matter how long you have been trying, the odds of either pool finding a block in the next hour are the same. Within about one hour both pools have found a block. The cheater gets .5*X from pool 'A' and X from pool 'B' for a total of 1.5 times what he would have gotten from staying put.

Dividing payouts by % of shares in the round makes early shares more valuable on average than later shares. The score system makes shares near the end of the round more valuable. You can predict the beginning of the round you can't predict the end.

A system of a fixed bitcoin value per share also eliminates cheating but forces the pool operator to take more risks and so you get higher fees.

 

Thank you for this great graph.  It helps prove that this type of "weighted" system is completely unnecessary and flawed.  Not accepting any block older than _currentBlock_ was more than sufficient to stop cheaters, and slush knows that.  This new "weighed" system seems to screw those who worker longer and harder for the pool, which in itself is incentive for long term miner's to find a new place to mine.  And if those of you who were under the believe that this "weighted share" system was going to stop those "cheaters" from "pool jumping", I guess you get to think again.  If anything, this graphs shows that the weighted share system helps those who jump in and out of different pools while punishing those who continuously stay in slush's pool.

Don't worry folks, a new pool is just around the corner, and every share will be treated fairly and equally.
Testing is underway as we speak....

I'm new to this program. As registrations on http://mining.bitcoin.cz/ have been closed lately, is there any way for me to join cooperative mining, or when could the registration be opened again?

Eager to join it~

So after the change for score based system, I thought it's maybe profitable to join only after N seconds since round start (kind of opposite to the previous cheating solution). Long story short it does not really seem to be the case (but I wasn't also so far off). I did some math (or rather coding), and here is how your earnings look depending on which second after round start you join. Y axis is normalized in the way that value 1 is what you get when you are mining with pool all the time:



This is based on real data from the rounds for prev difficulty (36k). As you can see, it turns out if you would be only joining about 2250 seconds after round start, then while mining with pool, you would be earning 3.5% more than those mining all the time. And since this plot is based on actual distribution of time to find blocks, it may vary in future, and it's hard to know ahead of time what moment is perfect.

Thanks for the answer. That's what i did on my cards, yay!

you need to make a new worker for each gpu. so since 5970's have 2 physical gpus you need to setup 2 workers. if you have for example 2 5870 then you would also need to setup 2 workers.

I have a question i coudnt answer searching the forum. How many workes should I set up? 1 for each gpu core? The only thing i was able to find was a guy with a 5970 that was suggested to use separate workes.

Thanks.

This is absolutely unnecessary. Getworks are really unique, no need to generating random nonces at all...

Yes you are right, this is the "known" bug, it sometime jumps up for a couple of minutes and then goes back to normal, but slush didn't have time to fix it yet, because he had more urgent programming to do.

is there a bug in how cluster performance is calculated? Just saw it spike to 240Ghash/s, and now its free falling back down to 70

You are right that all who receive a particular piece of work, will search for the same hashes. However, the getwork call to bitcoind never returns the same piece of work twice. To be more precise: there is a second nonce inside the generation transaction of the block too, and this one is set by the client instead of by the miner.

Hello. I'm new and I haven't read the entire thread. I apologize if this has been answered already. I don't know how to search for anything that has been said previously about this. I probably haven't understood how pooled mining works exactly.

I've downloaded jgarzik's cpu-miner program, and I see this code in the simple scanhash_c:


So, `n' starts from 0 and the `nonce' is set to the value of `n'. I think the rest of the algorithms are like this too. Does that mean that all clients who receive this particular "work" struct will attempt to compute hashes with `nonce' values starting from 0? If so, then this sounds like unnecessary duplication of effort.

Unless I am missing something... Maybe the `nonce' in the `data' that is the result of the `getwork' RPC call is pre-filled with some value and the client is supposed to attempt a fixed number of nonces from that value on (and cpu-miner doesn't support this?).

First version of poclbm with long living connection is from 15. Feb. So yes, version from yesterday is OK

@slush: By updated, you mean some specific version? I've downloaded poclbm from Github on yesterday morning, does it count as updated?

bobR seems very childish, I'm sure he's put off anyone that reads the drivel he writes.

You did. Now go away and learn how to be human.

Gee quite a mouthful for the head TROLL here
geck you have yet to post anything useful as far as I've seen
You just like to jump in & spout off


and who rattled your cage