Pages:
Author

Topic: Optimal pool abuse strategy. Proofs and countermeasures - page 4. (Read 30459 times)

legendary
Activity: 1386
Merit: 1097
I'm not sure you can remove the stats that allows one to "cheat" and still provide users with proofs that the pool is fair. Did you find a way ?

If you critize my trustworthy, then yes, I can cheat users all the time, I don't need to hide stats to do so. Please tell me reasonable way how to cheat now, if you forget some timing attacks as comparing latencies in notifications of new blocks from p2p site or so, which I'm also working on.

I'll put back stats soon, as I make some improvements in pool core.
legendary
Activity: 1386
Merit: 1097
If someone cheat and get more money on on quick blocks, than someone must lose on quick blocks. I am surely will not be the looser (nor will my customers).

In quick rounds is much bigger variance. Many people asked me why they have low reward from some short rounds. Basically it is because they was unlucky in those 3 minutes or so. Mining isn't steady at all, even on diff1 and strong machines, of course.

Quote
Slush, I think that simply delaying or removing real-time stats will not help a lot, because most of relevant data can be obtained from the block chain itself.

Which one?

Quote
Do you use new BTC address for every new block?

Afaik this is default bitcoin behaviour.
Ryo
newbie
Activity: 28
Merit: 1
Not exactly. For now I disabled some numbers completely (expected round reward or worker shares), but I plan to reimplement this from round-oriented to time-oriented stats soon. So you will still see how many shares will miners does and so.

I'm not sure you can remove the stats that allows one to "cheat" and still provide users with proofs that the pool is fair. Did you find a way ?
Ryo
newbie
Activity: 28
Merit: 1
If someone cheat and get more money on on quick blocks, than someone must lose on quick blocks. I am surely will not be the looser (nor will my customers).

You don't lose on quick blocks. You lose on slow blocks. People who "cheat" simply lose less than you on slow blocks.

If you want to check whether people are "cheating", don't look at quick blocks. Chart computing power against time, and if people cheat, you'll notice a drop as blocks grow longer.
legendary
Activity: 1386
Merit: 1097
Actually, the only thing that the cheater needs is the time when the round started so he can join the pool.

Which pool does not provide...


Quote
You will not only need to hide the number of shares but the round starting time and the number of shares one accumulated in the given round (otherwise the cheater can connect one of its miners and see when the counter starts from zero).

Of course, I see no problem with hiding this.

Quote
This way you can effectively turn off all the statistics and publish only "pool mining digest from yesterday".

Not exactly. For now I disabled some numbers completely (expected round reward or worker shares), but I plan to reimplement this from round-oriented to time-oriented stats soon. So you will still see how many shares will miners does and so.

Quote
It will also be unfair to anybody who wants to join the pool (and not cheat) because joining midround is unfair.

It isn't unfair. Everybody have the same probability to hit good or wrong time to join the pool. Also don't forget that 99% users don't care about this when connecting the pool. Until you don't perform cheating, your loss from connecting in the middle of the round are almost zero.

Quote
he may estimate the probability that you found the block

Nonsense. You cannot say who find the block by listening, for example, #bitcoin-monitor.
legendary
Activity: 1072
Merit: 1181
Quote
Also resetting on new block isn't solution, because bad guy can start mining on every new bitcoin block & stop after 43% of standard time between two bitcoin blocks. Maybe not such effective as cheating against current pool accounting, but this will still works.

No, it won't. The whole idea of the pool abuse is that you get paid in two places at the same time. With jgarzik's scheme, it's either or. Either you get paid from the pool, or individually. You never get paid twice. If you start mining on every bitcoin block and stop after some time, you either get paid from the pool (pool found a block) or from yourself (you found a block). Finding a block individually guarantees pool shares reset and all you accumulated shares loss. And finding a block by the pool guarantees that you did't find this block by yourself since the switch time. 


Furthermore, the difference between an acceptable optimization strategy (whether or not it gains you anything at all) and cheating, is IMHO the fact that if everyone used this 43%-strategy on the current system, it would break down (rounds wouldn't ever get finished), while in a only-shares-for-a-block system, the resulting gains would still be perfectly proportional to invested computation power (as share count would be reset after a block is found, even if everybody stopped pool mining, and people would join again).
full member
Activity: 144
Merit: 100
Slush is right.  The logic behind the proposed countermeasure does not seem correct.

Suppose the pool is reset at the beginning of a block, you join the pool, and everybody in the pool works at a consistent rate.  Then for each hash you compute, the expected payout is the same as if you were working alone, just with lower variance.

Then at some point you leave the pool and start working alone.  The expected payout for each hash you compute is the same as it was before, but additionally you have the chance to get a payout if someone in the pool finds a block.

The fact that a payout cannot come from both the pool and working alone in the same block doesn't mean you can't increase the total expected payout for your work.
full member
Activity: 238
Merit: 100
No, it increase the variance a lot, which is against the purpose of pool.
Not that much and only for low-hash rate miners that have a lot of variance anyway because even now there are short rounds and for CPU-miners, there is not a matter of reducing variance but increasing probability of any payout and your pool will still work in this respect.  The most variance in your pool comes from different level of "pool daily luck" anyway and this scheme will not change it.

Quote
Also resetting on new block isn't solution, because bad guy can start mining on every new bitcoin block & stop after 43% of standard time between two bitcoin blocks. Maybe not such effective as cheating against current pool accounting, but this will still works.

No, it won't. The whole idea of the pool abuse is that you get paid in two places at the same time. With jgarzik's scheme, it's either or. Either you get paid from the pool, or individually. You never get paid twice. If you start mining on every bitcoin block and stop after some time, you either get paid from the pool (pool found a block) or from yourself (you found a block). Finding a block individually guarantees pool shares reset and all you accumulated shares loss. And finding a block by the pool guarantees that you did't find this block by yourself since the switch time. 

Quote
So I don't plan to change accounting itself.

It's your pool and your rules but I'd recommend you reconsider it because your strategy below is much more messy.

Quote
I know that it is only matter of time, when somebody start to cheat pool with this technique. So I have prepared 'delayed' stats on the pool. With this update, nobody will known how many shares is in current block. This obfuscate real time statistics a lot, but remain completely fair for all miners and cheaters won't have enough data to know when to switch.

Actually, the only thing that the cheater needs is the time when the round started so he can join the pool. Since the I(lambda) function is positive, he can switch out anytime provided he joins when the round starts. You will not only need to hide the number of shares but the round starting time and the number of shares one accumulated in the given round (otherwise the cheater can connect one of its miners and see when the counter starts from zero). This way you can effectively turn off all the statistics and publish only "pool mining digest from yesterday". It will also be unfair to anybody who wants to join the pool (and not cheat) because joining midround is unfair. In my opinion, it will impact the usability of the pool much more than the jgarzik's counting method.

And although I'm not sure because I'm not fluent in the bitcoin protocol, I believe a bad guy can test the bitcoin protocol traffic  to learn that it was the pool that found a block (and hence a new round started) by connecting to your 8333 port and getting your "new block found" broadcast before getting this message from other nodes.  Even if you block your port and connect only to some trusted nodes, by listening to other nodes traffic, he may estimate the probability that you found the block and not a guy in, say, Japan which will have a different node propagation signature. He does not need to be right 100% of the time, being right more than not will be enough. Remember, joining and switching off from the pool at complete random intervals is payoff neutral (apart from startup inefficiencies) so it will be enough  to join more frequently at the start of the round than not. And by looking at the delayed statistics he can check if the strategy worked.

legendary
Activity: 1386
Merit: 1097
I'd advice slush and other pool operators to implement this counting. It slightly increases the variance of ones income but it's fair, it's simple and eliminates cheating which with multiple pools can become widespread.

No, it increase the variance a lot, which is against the purpose of pool. Also resetting on new block isn't solution, because bad guy can start mining on every new bitcoin block & stop after 43% of standard time between two bitcoin blocks. Maybe not such effective as cheating against current pool accounting, but this will still works. So I don't plan to change accounting itself.

I know that it is only matter of time, when somebody start to cheat pool with this technique. So I have prepared 'delayed' stats on the pool. With this update, nobody will known how many shares is in current block. This obfuscate real time statistics a lot, but remain completely fair for all miners and cheaters won't have enough data to know when to switch.
Ryo
newbie
Activity: 28
Merit: 1
In this thread, the author finds no evidence of massive use of this strategy
https://bitcointalksearch.org/topic/abusing-bitcoin-mining-pools-strategies-for-egoistical-but-honest-miners-2941
(I didn't read the paper since I find it strange to ask for a payment for something that may or may not contain anything interesting; and I didn't find any hard numbers in the discussion)

Well, in the discussion, you could have seen confirmation that people who bought the paper didn't feel cheated. The reson I'm asking money first is that I don't believe people would donate, especially people who want to abuse pools. However, it's been some time since anyone downloaded the paper, so here it is, for free:
http://www.bitcoinservice.co.uk/files/111

If anyone wants to donate (and that would incite me to write more about bitcoin), here's an address:
1ESWeHDPSEErzr6tcm3aToVGXKUe8kA9D8
full member
Activity: 238
Merit: 100
I have written a description of the optimal pool abuse strategy (for a single pool) with proofs and calculations. Available here:
http://bitcoin.atspace.com/poolcheating.pdf

If the link does work, use a mirror: http://mining.bitcoin.cz/media/download/poolcheating.pdf

I have started this work some time ago and it is not finished (I wanted to derive the optimal strategy for multiple pools but it's not ready yet) but with jgarzik's announcement of a new pool code, there is a chance we have multiple pools very soon and with multiple pools, pool abuse gets more profitable, and because I realized there is a perfect countermeasure, I decided to publish it now .

For those who don't want to bother reading it, the optimal strategy is to join the pool at the start of a new round and stop pooled mining after 43.5% fraction of the current difficulty of shares was contributed and start mining solo. This strategy will bring 28% of extra income compared to only pooled or only individual mining.

In this thread, the author finds no evidence of massive use of this strategy
https://bitcointalksearch.org/topic/abusing-bitcoin-mining-pools-strategies-for-egoistical-but-honest-miners-2941
(I didn't read the paper since I find it strange to ask for a payment for something that may or may not contain anything interesting; and I didn't find any hard numbers in the discussion)
However, I was testing it in mid January with 3-4% of the pool hashrate. It is indeed very hard (at this level it is quite well buried in the noise) in the global hashspeed, but it is possible to detect by the pool operator by checking the payout. An abuser, will have significantly larger payouts in the short rounds than in longer ones.

Concerning the countermeasures. Apart of administrative ones (i.e. banning) which will be difficult if one starts to be more clever: randomly changing switching threshold, contributing all the time with a fraction of ones hashspeed, etc, there is of course a connected method which is will be very hard in slush's implementation. It is also possible to calculate the payout based only on the very recent shares but it only reduces the cheating payout, not eliminate it. However, after reading the recent jgarzik's pool discussion
https://bitcointalksearch.org/topic/new-mining-pool-for-testing-now-closed-3078
and his "bug", where he only counted shares contributed to the latest block, I realized that such counting is a perfect countermeasure. Since finding a block ensures that everybody else who worked on solving this block wasted its effort, there is no incentive to switching from the pool. If one switches from the pool and finds a block, the pool resets its counter and all the cheater's "unearned" shares will be lost. Of on the other hand, one switches from the pool and the pool find the block, it guarantees there is no individual income after the switching. I'd advice slush and other pool operators to implement this counting. It slightly increases the variance of ones income but it's fair, it's simple and eliminates cheating which with multiple pools can become widespread.

Edit; It won't work, see the further discussion.  
Pages:
Jump to: