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

slush

legendary

Activity: 1386

Merit: 1097

Quote from: ribuck on February 05, 2011, 06:09:24 AM

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

ribuck

donator

Activity: 826

Merit: 1060

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

legendary

Activity: 1386

Merit: 1097

Quote from: geebus on February 04, 2011, 09:25:31 PM

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.

Quote

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

Quote

etc...

For example?

Quote

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.

geebus

sr. member

Activity: 258

Merit: 250

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.

geebus

sr. member

Activity: 258

Merit: 250

Quote from: slush on February 04, 2011, 03:28:10 PM

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.

DiabloD3

legendary

Activity: 1162

Merit: 1000

DiabloMiner author

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

slush

legendary

Activity: 1386

Merit: 1097

Quote from: ?? on ??

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

slush

legendary

Activity: 1386

Merit: 1097

Quote from: CFSworks on February 04, 2011, 01:40:22 PM

The true/false return value on getwork?

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

Quote

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

Quote

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

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

Quote

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

I was not serious, this is my special humor

.

CFSworks

member

Activity: 63

Merit: 10

Quote from: slush on February 04, 2011, 01: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, 01: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, 01: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, 01:27:10 PM

This explains a lot

.

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

BitLex

hero member

Activity: 532

Merit: 505

Quote

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: CFSworks on February 04, 2011, 01:13:02 PM

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: BitLex on February 04, 2011, 01:23:07 PM

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

Quote

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.

Ryo

newbie

Activity: 28

Merit: 1

Quote from: CFSworks on February 04, 2011, 01:13:02 PM

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

legendary

Activity: 1386

Merit: 1097

Quote from: CFSworks on February 04, 2011, 01:13:02 PM

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.

Quote

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.

Quote

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.

Quote

I don't understand pool cheating all that well

This explains a lot

.

Quote

you could put the estimated reward back in

Will be back soon, please be patient.

BitLex

hero member

Activity: 532

Merit: 505

Quote from: ?? on ??

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

legendary

Activity: 1386

Merit: 1097

Hi guys,

I temporary removed some stats which may be useful for pool cheaters following this thread: https://bitcointalksearch.org/topic/optimal-pool-abuse-strategy-proofs-and-countermeasures-3165. 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.

CFSworks

member

Activity: 63

Merit: 10

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

BitLex

hero member

Activity: 532

Merit: 505

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?

gusti

legendary

Activity: 1099

Merit: 1000

Quote from: BitLex on February 04, 2011, 12:41:52 PM

i really dislike your decision to remove all the useful stats and only keep those that don't really matter to me anyways.

it doesn't matter how many blocks my workers found, won't get me anything more or less if they found a lot or none,
but what i want to know is the number of shares that a given worker got, makes tweaking and debugging a lot easier.

right now i can't tell which worker (or miner-version) is performing good or bad.

Well, I believe that you may count them on your side, too.
But I also think that stats were useful, I think Slush needed to take them out due to pooling cheating.

BitLex

hero member

Activity: 532

Merit: 505

i really dislike your decision to remove all the useful stats and only keep those that don't really matter to me anyways.

it doesn't matter how many blocks my workers found, won't get me anything more or less if they found a lot or none,
but what i want to know is the number of shares that a given worker got, makes tweaking and debugging a lot easier.

right now i can't tell which worker (or miner-version) is performing good or bad.

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