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

[BitLex]

well, it's a bit hard to count them, if you can't be sure they've been 'accepted' (i have to run at least 1 outdated miner-version that doesnt tell me).

and why do you think slush needed to?
if i want to cheat, i can still take the time since last block and current approx.cluster performance and calculate shares-this-round that way, can't i?

[1713940164]

1713940164

[1713940164]

1713940164

[CFSworks]

I agree with BitLex here. Cheaters can find their share count easily anyway, since the pool still tells the worker whether or not the share was accepted. Even if that were taken out, a cheater could monitor the work that their miner was sending and check if the sent work was of a low enough hash and not stale, and count that way, so a person's share count isn't secret information. Taking it out just frustrates honest people tweaking/monitoring their legitimate miners.

I don't really care about what information is on the statistics page, though, since I don't check that very often, but taking out the current round duration is another piece of easily-obtained information: (Current Timestamp)-(Timestamp of last round ending)

I don't understand pool cheating all that well, but to make an educated guess, the only really secretive information is the total number of shares in the current round. I have no objection to removing that. (And, you could put the estimated reward back in, just lower the decimal precision so it's harder for cheaters to calculate the share total exactly.)

[slush]

Hi guys,

I temporary removed some stats which may be useful for pool cheaters following this thread: http://bitcointalk.org/index.php?topic=3165.0. I believe it is the best way how to prevent pool abuse. I had prepared this for days ago, but now it was the right time to hide stats.

I'm sorry for discomfort for you, honest pool users, but I'm doing my best for pool safety and fairness.

I'm working on stats, which will be time-oriented instead of round-oriented. So you will see accepted shares (X shares / last hour) profile page and expected reward soon back.

[BitLex]

Unfortunately, slush had to do what he did. Good call.

i still don't get the point,
a "cheater" would just change it's behaviour from switch-after-X-shares to switch-after-Y-hours, what's the big difference?
yet for me the difference is quite big, i don't get ANY useful stats at all anymore.

[slush]

since the pool still tells the worker whether or not the share was accepted.

Which is related to new _bitcoin_ block, not _pool_ block. No useful info here.

person's share count isn't secret information. Taking it out just frustrates honest people tweaking/monitoring their legitimate miners.

It is. Nobody than miner and pool know how shares he submitted. And once miner don't know when the round ended, he cannot tell on which round he's working. Also as I said, some kind of share counter will be back soon, to allow miner checking by user.

I don't really care about what information is on the statistics page, though, since I don't check that very often, but taking out the current round duration is another piece of easily-obtained information: (Current Timestamp)-(Timestamp of last round ending)

Timestamp is simply current time, nothing about round duration.

I don't understand pool cheating all that well

This explains a lot .

you could put the estimated reward back in

Will be back soon, please be patient.

[Ryo]

I don't understand pool cheating all that well, but to make an educated guess, the only really secretive information is the total number of shares in the current round.

That's correct (regarding the specific type of cheating I described; there may be other ways to cheat).

[slush]

a "cheater" would just change it's behaviour from switch-after-X-shares to switch-after-Y-hours, what's the big difference?

There is no difference. But there is also not any 'time on current round'.

i don't get ANY useful stats at all anymore.

I'm sorry for removing share counts per worker, it was really usefull, but it need major changes in core to allow displaying it back. So hiding it was quick patch.

What other are you missing so much? I will replace 'shares in current round' by 'shares in current hour', so you will be able to check your performance and expected reward from those numbers (by comparing 'shares in current hour' with your worker's numbers). And total pool performance is very exact right now.

[slush]

the only really secretive information is the total number of shares in the current round.

And time, which is bounded to shares in round with given hashrate. That's correct. That's the reason why I hide all numbers calculated from those numbers. For example, with current formula, expected reward drop to zero when new round is started, so it should be hidden, too. I'll change it to not leak info about new round.

[BitLex]

But there is also not any 'time on current round'.

but you tell us when the last block was found, not hard to guess the current round duration.

[CFSworks]

Which is related to new _bitcoin_ block, not _pool_ block. No useful info here.

The true/false return value on getwork? I thought it told the miner whether or not the sent data was accepted by the pool and whether or not a new share had been awarded to that worker. Why can't cheaters count that? Or am I gravely misunderstanding something? (Also like I said, a cheater can always have a miner hash the getwork submission himself and determine for himself if it's valid/stale/invalid.)
Edit: Wait, I just saw what the problem is. A cheater can tell when a new round starts by watching the share counts reset to 0. Yeah, a "shares in last hour" system would be pretty agreeable then.

It is. Nobody than miner and pool know how shares he submitted. And once miner don't know when the round ended, he cannot tell on which round he's working. Also as I said, some kind of share counter will be back soon, to allow miner checking by user.

...did you mean to take out the "block history" on the stats page? Because that leaks information on which round is current (we're working on #737 at this writing) - again, I could be misunderstanding its purpose.
Edit: Just noticed it's delayed. I guess that's acceptable, too. Sorry about that.

Timestamp is simply current time, nothing about round duration.

The difference of two timestamps is a duration. If I take the time the last round ended (which can be obtained from the "block history" table -- and is equal to the time the current round started, right?) and subtract it from the current time, I can determine how long the current round has been running.

This explains a lot .

What does it explain? Are you saying I'm naive?

[slush]

The true/false return value on getwork?

It said if share was accepted by pool, but no info about new round or so. Useless.

...did you mean to take out the "block history" on the stats page? Because that leaks information on which round is current (we're working on #737 at this writing) - again, I could be misunderstanding its purpose.

No, we're working on #742 right now. Read carefully, those stats are delayed by two hours!

If I take the time the last round ended...

...which you don't know...

What does it explain? Are you saying I'm naive?

I was not serious, this is my special humor .

[slush]

If the stats are delayed two hours and we are currently working on a block, would they be able to tell after two hours if we are on the same block to abandon the current block?

The delay is calculated from block found time. So even if you don't see new block after three hours from now, you don't know if block was mined in 1:01 and pool crunched many short round in meantime or we are still on this one. Of course, with rising delay between last visible block and (now-delay) timestamp, users may be more suspicious that pool hit extremely long round. But you don't know what to start/stop mining, because you don't see what happen inside the last two hours...

[DiabloD3]

I've updated my miner to reduce share loss in pool situations. Update to newest.

[geebus]

The delay is calculated from block found time. So even if you don't see new block after three hours from now, you don't know if block was mined in 1:01 and pool crunched many short round in meantime or we are still on this one. Of course, with rising delay between last visible block and (now-delay) timestamp, users may be more suspicious that pool hit extremely long round. But you don't know what to start/stop mining, because you don't see what happen inside the last two hours...

Couldn't you just check against a local bitcoind for the current block number and have it updated in realtime? or near-to-realtime? I don't see how implementing a delay in stats reporting really stops them from knowing the block has changed.

[geebus]

All you would be concerned about is current round, but realistically, if you're (the pool) only collecting shares for the current block, it doesn't matter whether or not you're on current round, or what the round is for that matter.

By only accepting shares for the current block, you're forcing the focus of anyone attempting to exploit to be just the current block, and even pulling or delaying server statistics, there are plenty of ways to determine what block we're on. I.E. getwork hash, local bitcoind, invalid or stales submitted for previous getworks, etc...

I don't see how delaying, or simply not showing stats is a feasible way to prevent any sort of exploitation.

[slush]

there are plenty of ways to determine what block we're on. I.E. getwork hash

Which is different for every getwork(). Merkle si also changing with every new bitcoin block and every minute, when TX is received. Nothing useful for determining, if pool found a block.

local bitcoind

Where you see only new bitcoin blocks, not pool blocks. Some kind of traffic analysis may be useful here, but it also may be obfuscated by pool and I doubt it will be exact enough.

[/quote]
 invalid or stales submitted for previous getworks
[/quote]

Which is for every bitcoin bloc, not only for pool blocks...

etc...

For example?

I don't see how delaying, or simply not showing stats is a feasible way to prevent any sort of exploitation.

You still didn't find any solution how to find, that pool found a block, which makes "43% cheating" impossible.

[ribuck]

When the pool finds a block, it could pay out only for shares that were found in the last time "t", where "t" is 43% of 10 minutes (I think).

Because this is a sliding window, there is never an incentive for a miner to leave the pool at any particular time.

[slush]

When the pool finds a block, it could pay out only for shares that were found in the last time "t", where "t" is 43% of 10 minutes (I think).

All of these techniques can help, but add a lot variance for slow miners, which goes against the pool idea. Don't forget there are users which have less than one share per hour...

[geekmug]

You still didn't find any solution how to find, that pool found a block, which makes "43% cheating" impossible.

I think all you really need to is to estimate the compute power of the pool to work out expected time for 43.5% (as of writing that is about 23 minutes). If you switched to working solo after an average-43.5% duration and worked solo until the average block-find time (as of writing that is about 40 minutes), then your miner's average performance should still exceed the performance of full-time pool mining. Although, I haven't done the math to work out the expected pay-off of that strategy, so maybe I am wrong.

[FairUser]

Damn, I leave for 1 week, come back and the server stats are totally different and gone.
All this crap to try and prevent "fraud".  Delaying/removing stats doesn't stop that BTW.
The server already only accepts shares for current blocks, but what you've done is overkill, plain and simple.

Time for a new pool server to be born, cause this just blows now.