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

[slush]

Phoenix miners working, both GPUs.... must be GUIMiner. Gonna delete, then re-extract.

[edit] Fixed. had to create new openCL miners and re-extract. Seems some settings got jumbled up

Hm, really crazy. Great that you fixed it.

[CanaryInTheMine]

How come there are two entries for block 132473???

This looks fishy...

[CanaryInTheMine]

And for block 132468 also?

What's going on here?

[nomnomnom]

weird, I see this too.
But they point to different blockexplorer addresses, and one shows no such block.

Something else:
Is there still ddos attacks going on? because sometimes my miners stop for a moment
with workque empty. I am not sure if this is maybe my internet connection.

[scooter]

I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...

[scooter]

I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...

7 blocks with no reward now.. any idea what is going on?

[scooter]

I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...

7 blocks with no reward now.. any idea what is going on?

Ok finally getting rewards

[nosfera2]

Sometimes, when blocks are found in a few seconds, most pool miners end up not getting anything at all for that block and a few lucky ones get to keep all the loot (rewards as high as a full bitcoin or more). It's just a matter of pure luck who manages to send in a share or two in such a short time.

See entries 5896 and 5898 in this screenshot for an example.

Since the idea of pooling is to eliminate luck and distribute the rewards of mining as fairly as possible, I'm proposing that in these cases, when a block is found sooner than say 30 seconds (admins can better determine the best time to use from their logs) the reward is shared out according to the share proportions of the previous + current blocks, so that everybody gets something.

The only possible 'downside' to this is that if someone happens to leave the pool in the few seconds it takes to find the last block they still get a share. However that is surely fairer than not rewarding all those who have been mining for the previous blocks and denying them the lucky strike that balances out the longer mining times on other blocks.

What do you guys think?

[slush]

I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...

7 blocks with no reward now.. any idea what is going on?

It takes some time to calculate everything, reward of last found block can change few times.

[slush]

How come there are two entries for block 132473???

This looks fishy...

It's well known bug, but only cosmetic one. Link to blockexplorer is correct.

[slush]

About blocks #5898 and #5896; They were very short, but both are invalid.  Probability of finding two solutions by two pool backends at same time (and twice in the row) is extremely small, but as you see, it may happen.

Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.

[Roland68]

check hardware ....!!!!

pool brocken again

[cosurgi]

check hardware ....!!!!

if you get "check hardware" errors, it means that solutions found by your GPU do not pass a short & simple verification by CPU. This means that your GPU is doing mistakes in calculation. You need to:

1) check temperature of your GPU, if it's above 85 C, you need to downclock it
2) if you overclocked your card, you need to downclock it
3) if none of above, you need to RMA your card, because it's broken.

[Roland68]

check hardware ....!!!!

if you get "check hardware" errors, it means that solutions found by your GPU do not pass a short & simple verification by CPU. This means that your GPU is doing mistakes in calculation. You need to:

1) check temperature of your GPU, if it's above 85 C, you need to downclock it
2) if you overclocked your card, you need to downclock it
3) if none of above, you need to RMA your card, because it's broken.

Thanks for reply ...

temp is 75 deg. (5830)

gpu is 1000 and mem 600

this was ok until now ...(280 Mh)

will check again later ... thanks

[nosfera2]

About blocks #5898 and #5896; They were very short, but both are invalid.  Probability of finding two solutions by two pool backends at same time (and twice in the row) is extremely small, but as you see, it may happen.

Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.

Thanks for your reply. I see now that the blocks turned out to be invalid, but that if they were OK? The reward would be shared only by the lucky people who submitted shared to those blocks and in one of those cases, a maximum of 60 people would share 50 BTC that really belong to the whole pool. This is what I am trying to fix by suggesting that the rewards of extremely short block runs are shared according to the results of the previous block.

[finnthecelt]

About blocks #5898 and #5896; They were very short, but both are invalid.  Probability of finding two solutions by two pool backends at same time (and twice in the row) is extremely small, but as you see, it may happen.

Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.

Thanks for your reply. I see now that the blocks turned out to be invalid, but that if they were OK? The reward would be shared only by the lucky people who submitted shared to those blocks and in one of those cases, a maximum of 60 people would share 50 BTC that really belong to the whole pool. This is what I am trying to fix by suggesting that the rewards of extremely short block runs are shared according to the results of the previous block.

Yes, of course my reward was very high for those blocks. Now invalid. Bummer.

[slush]

I just released email confirmations for wallet changes on profile page.

[Kuber]

I just released email confirmations for wallet changes on profile page.

Thumps up

[kerogre256]

Hi how long its take to send coin ? or how to check it I  mine my 1 coin but it was not send to me ?

[finnthecelt]

Hi how long its take to send coin ? or how to check it I  mine my 1 coin but it was not send to me ?

Is your send threshold set to 1? Do you have your wallet opened and are all the blocks downloaded?