Quote from: slush on February 04, 2011, 06:27:10 PM

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.

Quote from: slush on February 04, 2011, 06:27:10 PM

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.

Quote from: slush on February 04, 2011, 06:27:10 PM

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.

Quote from: slush on February 04, 2011, 06:27:10 PM

This explains a lot

.

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