Pool sharking?

[teknohog]

I propose an idea for cheating in a mining pool. Please comment on the viability and suggest countermeasures if needed.

The current pool by slush uses standard getwork miners with an artificially low difficulty. Such succesful hashes are used to gauge the level of contribution from a given miner. Now suppose that whenever a miner finds a block that satisfies the actual Bitcoin difficulty, they return it to their own local bitcoind instead of the pool. The pool continues to get measures of contribution, but the actual contribution in terms of 50 BTC blocks goes to the miner. In addition, they get their "share" of the pool based on their "contribution".

Of course, both the ethical and practical problem is that the pool will not generate anything if everyone does this. But suppose that some are already doing it. In the long run, statistics may show who is cheating, but it is not obvious in the short term.

[1714832825]

1714832825

[1714832825]

1714832825

[1714832825]

1714832825

[Raulo]

It was discussed in the original pool thread (see, e.g., reply #20). The hash is useless for anybody other that the owner of the pool server. If you find a low hash, you can either send it to the pool (and collect your share) or discard (and collect none).

[teknohog]

The hash is useless for anybody other that the owner of the pool server.

OK, I stand corrected

[FreeMoney]

It doesn't matter if the miner takes the hash and turns it in because it only validates the block that contains the pool operators payout, if you change that then the hash won't be valid. You could simply refuse to report, but that hurts you too since you are entitled to some of the profits.

edit: looks like you already get it

[wumpus]

What about a collusion attack? In an attempt to get an unfair total share, multiple miners join the pool and pretend they are computing hashes, but only one of them (the master) is actually hashing. All the other miners report the same hashes as the 'master'.

Would that work?

[FreeMoney]

What about a collusion attack? In an attempt to get an unfair total share, multiple miners join the pool and pretend they are computing hashes, but only one of them (the master) is actually hashing. All the other miners report the same hashes as the 'master'.

Would that work?

I guess it would work until/unless the operator started checking that hashes weren't identical. He'd only have to keep to check against for as long as the exact same block was being hashed.

[slush]

What about a collusion attack? In an attempt to get an unfair total share, multiple miners join the pool and pretend they are computing hashes, but only one of them (the master) is actually hashing. All the other miners report the same hashes as the 'master'.

Would that work?

No, not on my pool. I'm checking if PoW corresponds with job sent to worker before.

[slush]

Also many people ask me why separate logins for each worker. This is just because those security checks. I'm locking job registry for each worker during checks of PoW to avoid double spending of the same PoW in parallel. So using the same login for more workers may also affects worker's performance because they have to wait for releasing worker lock.

[bober182]

What if the pool operator steals every 10th hash for himself?

[Delia]

If the operator uses a different address for personal unpooled mining than the pool's address, then there's no way to do so surreptitiously: the pool mints a block, and doesn't pay out.

[wumpus]

Nice to see that you even though about those kinds of attacks

What if the pool operator steals every 10th hash for himself?

Yeah, that's always a potential issue with 'trust', though it'd only be a problem if he did so secretly.  As long as he's clear about it, IMO it's not a problem if the pool operator decides to keep a small share to pay for server bandwidth and such.