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

[error]

Congratulations bobR, you've just managed to alienate me, and I have no plans to ever do business with you until you learn some basic social skills.

and who rattled your cage

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

[1713910182]

1713910182

[1713910182]

1713910182

[1713910182]

1713910182

[russ]

Congratulations bobR, you've just managed to alienate me, and I have no plans to ever do business with you until you learn some basic social skills.

and who rattled your cage

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

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

[M4v3R]

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

[slush]

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

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

[prcarter]

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:

        uint32_t *hash32 = (uint32_t *) hash;
        uint32_t *nonce = (uint32_t *)(data + 12);
        uint32_t n = 0;
        unsigned long stat_ctr = 0;
               
        while (1) {
                n++;
                *nonce = n;
        ... etc ...

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?).

[Pieter Wuille]

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.

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.

[epicenter]

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

[(void, *)]

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

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.

[slush]

Unless I'm mistaken, every work request to the server
returns a different piece of work (i.e. the base nonce is
different everytime). If that wasn't the case, this would
represent a huge waste of computing resources.

That being said, if you don't trust that it is the case,
nothing prevents you from changing the cpu-miner
code to try random 32bit integers instead of trying
them in a sequence. All you need is a fast, lo-quality
RNG, seeded from /dev/urandom.

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

[qed]

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.

[yunk3r]

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.

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.

[qed]

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.

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.

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

[comboy]

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.

[williamthec]

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~

[FairUser]

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.

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

[Dude65535]

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.

 

[epicenter]

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?

[Ricochet]

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.

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.

[Dude65535]

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?

My total payout so far is 68.35 and I have found one block for the pool. I had received about 20 BTC before I found a block.

[adv]

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?

According to the Slush's statistics, I found for the pool 8 blocks. And received 194 btc. Given the 2% charged by now, my "sponsorship weak miners" was "(1-194 / (8 * 50)) * 100 +2 = 53.5%". Or, in other words, I got 46.5% of the generated.
So that the last time I left in a pool only useless CPU-miners.