Topic: Optimal pool abuse strategy. Proofs and countermeasures (Read 30439 times)

The question was how I came to this topic. The answer is that I was looking for some kind of algorithm (or even implementation) to hop to a different coin, as opposed to a different pool, when the difficulty goes up.

Not sure what you mean but IIRC the formulation in AoBPMRS treats difficulty changes properly, it will work even if the difficulty changes frequently.

Terracoin retargets it's difficulty on each block (unless it changed its algorithm recently: the dev has already pulled a 24h mandatory update out of his hat forking the chain like that). Some people are mining Terracoin only when it's more profitable than other coins: this has similar effects than the ones happening when a pool is hoppable...

I'm not sure how your last comment relates to the strategy suggested by Raulo in his paper.

I was thinking about what is the most "fair" reward system. I was interested on what others have written about the topic. Meni's paper on the topic (which I have yet to finish reading) struck me as more deep and thorough.

I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm  that makes hash rates more even would actually benefit the entire community.

June 13, 2011, 12:18:25 PM  <<<


Posted on: May 01, 2013, 02:12:30 AM
 Posted by: drlukacs


So why did you resurrect a dead thread on cheating?? Most pools conteract this...

The assumption is explicit = \xi is defined as n / (2^32 D), meaning that D = n / (2^32 \xi).

And yes, in this calculation n and D both go to infinity at a specified ratio \xi. The assumption that \xi is fixed was not explicitly written but it follows from context.

D doesn't have to "go to" infinity in real life for the calculation to show that if D is sufficiently large, then for any n the probability of not finding a block is roughly exp ( - n / (2^32 D)).

So, is there an implicit assumption that n and D are linearly related?

You see, I have no problem with the observation that finding a block has a Poisson distribution. But the "proof" provided as it stands is simply wrong, unless D is a function of n,  and \xi is the limit of their ration when n tends to infinity.

It's not an error, though tricky and somewhat unclear.

He is assuming that \xi is constant while n and D are variable. For \xi=2, for example, he is considering a case that the hashes calculated are twice the average needed; he then considers what happens when D, and correspondingly n, go to infinity (continuous case). In this case the chance of not finding a block is indeed exp(-2).

Raulo, you have a mathematical error on page 1, in equation (4).

Your \xi depends on n. Consequently, you cannot pass to limit only in part of the expression.

The expression q:=1- (1/2^32* D)  is a real number < 1. Consequently, Q(n)=q^n -->0 as n --> \infty.

This makes perfect sense, because the probability that you will "almost surely" (in the sense of probability theory) find a block if you wait long enough (infinitely long).

Right. So you benefit by ditching the pool with a way longer round (so your investment in that pool is higher considering the time you put in, but still low considering what you could have gotten if you stayed) to a pool that found a new block. The only draw-downs to this method is when you have to switch between pools that still haven't finished a round and you go back and forth, and when you go into a fresh round, but because you stay too long in the fresh round pool, the other pool you ditched could end the round has a shorter round which is worth more than the long one, for which you don't get anything because you left).

You look at the number of shares as a fraction of the difficulty. But you don't do the whole calculation in block granularity.

Because all this information is irrelevant. Your expected payout from a proportional pool for a share you submit now depends only on the number of shares in its current round (as a fraction of the difficulty).

Specifically, if there currently are K shares in the round, the expected payout (in units of block reward) is $\sum_{i=K+1}^{\infty}p(1-p)^{i-K-1}/i$.

It has no effect on the payout from this pool. But once the payout from this pool, due to the length of its current round, is too low, you hop to a pool where it's higher.

It looks like the "paper" that describes the process assumes you need to use a median time for block generation, I am referring to that.

What I'm saying is I don't see how you can use a static number to refer to all possible scenarios, and assume that just because in a specific combination of circumstances you get an advantage, that advantage is possible to maintain in the other situations (such as those presented above). I feel that either the methods explained in the paper to abuse the pool are not taking all variables into account (very short blocks, very long blocks, other miners, other pools, random distribution of blocks, comparison with PPS in different scenarios) or they do and I couldn't locate this information in that paper.

Also, how come anything that happens outside the pool has no effect when in fact you need to "hop" to other pools in certain circumstances?

Whatever happens outside the pool has no effect (unless it affects the decisions of miners). It doesn't matter at all if in a given minute 0 blocks were found outside the pool or 8. It does of course matter whether in this minute the pool found a block or not.

It looks like you're thinking a block is found like clockwork every 10 minutes. That's false, finding blocks (for Bitcoin at large, for a pool, for a miner) follows a Poisson process, so the time to find the next block is distributed exponentially.

We're not hiding anything. We've specified exactly how to pool-hop (well, at least as long as the pool doesn't try to implement counter-hopping measures, there's some room for discussion there) and why it works. Some people have done it.

It should be emphasized that pools using a correct payout method (geometric, PPS, inter-round window) are completely immune to the effect.

I am pretty sure my payout is dependent on the fact that a block is found inside or outside the pool, at least this is my impression:
- block inside the pool? Round ends, I get 50 BTC * My shares / All shares during the round time.
- block outside the pool? Round continues, everyone has to add more shares to the extended round time.

Sure, in the end it evens out in sufficient rounds, but then again we are talking about pool abuse efficiency, and I still don't see the practicality in doing it. If anyone feels that posting in the public forum would damage the pools (even if information has already been posted) feel free to PM me.

Your payout from a pool is completely independent of the blocks found outside the pool, so I'm not sure what you're trying to say.

Ok, so let's suppose you know when the round started on pool A (longpoll on pool, blockexplorer shows your pool got a block, pool stats, etc). I assume that that pool A is now going to solve a block and I get in fast. Supposedly this rounds ends in one of the following scenarios:
- round is closed on the first block found in the chain, pool gets consecutive blocks
- round is closed after the second block found in the chain, some other pool gets the first block
- round is closed after the n-th block...

If I mine for 100% of the time, then I get:
- 50 * my_shares / pool_shares -- every 7 minutes
- 50 * my_shares / pool_shares -- every 14 minutes
- 50 * my_shares / pool_shares -- every n*7 minutes

If I mine for 43% of the time to get a new block only at the beginning of a round, I get:
- 0.43 * 50 * my_shares / pool_shares -- every 7 minutes
- (0.43 / 2) * 50 * my_shares / pool_shares -- every 14 minutes
- (0.43 / n) * 50 * my_shares / pool_shares -- every n*7 minutes

If I mine for 43% of the time to get a new round (when every new block pops up), I get:
- 0.43 * 50 * my_shares / pool_shares -- every 7 minutes
- 0.43 * 50 * my_shares / pool_shares -- every 14 minutes
- 0.43 * 50 * my_shares / pool_shares -- every n*7 minutes

Other pools have similar situations, no to mention solo mining. The only place left to go is PPS, which is starting to fade out and offers a ~7% penalty or more.

The following is a sample of block intervals at this time:
0:09:51
0:01:48
0:01:33
0:05:58
0:03:19
0:05:56
0:00:31
0:12:36
0:04:12
0:01:17
0:00:43
0:00:45
0:18:56
0:05:20
0:07:53
0:14:50
0:04:48
0:01:01
0:17:38

The current interval is 399 seconds, or 0:06:39. The 43% of that is 172 seconds or 0:02:52. What will happen with this method, in case of the above bolded intervals? You will be:
- effectively mining for the whole duration of the block
- effectively mining for the whole duration of the block in some cases, the whole duration of a second block in some cases, and in a small example above, statistically probable for the whole duration of a two blocks round
- in the case of n-blocks rounds, your contribution will be even less important, for example in a 40 minutes round you will be mining just 3 minutes, while everyone mines the full period, your payment will be less than 10% of that of honest miners, how much can you abuse out of that?

Yes. Cheating depends on the time spent on each round, not on the pool at large. By the way, there are solutions, but most people don't understand the problem well enough to want to use them.

But we have already explained practically how to do it. Mine for the proportional pool until the number of shares in the current round is 43.5% of the difficulty, after that mine solo (or score-based) until the next round. You can use the time since round start as a proxy. And if you don't know when the round started you can try to estimate it.

It you submit 100 shares, the payout you get depends on the length of the round. If it's 1000 you get 10% of the block, if 10000 you get 1%. The length of the round is a random variable not known in advance. However, its conditional expectation depends on how long it's been already. If the round is fresh the expected length is equal to the difficulty. If the round has already been going on for twice the difficulty, the expected length of the round is thrice the difficulty. Thus your expected payout per share submitted will be less if the current round is old. And as Raulo explains in his paper, 43.5% of the difficulty is the point at which the expected payout per share becomes less than solo/score-based.

Moral of the story, give the man an answer, I'm trying for 3 days to understand this, why can't anyone explain practically how it works. On that topic there's a guy that claims 30% increased performance by pool hopping. And then again he only claims 3.5% effective gains in reward in a later post. He even said he could abuse slush's pool (on which btw, I rarely get shares in the 2 minutes rounds, and if I disconnect it's usually during those 2 hours rounds, definitely pegged against me but not this guy for some reason). I suppose his advantage is he knows exactly which pool finds a block every time a block is found, thus he can get a piece of each round, even if it's crumbs.

What I still don't understand, how is it he can get a higher reward during a round than what effort he has put into the round? If nobody can explain, nobody really understands, right? Or I'm very very stupid that I can't understand the theory without a practical example, right?

I have not read in detail the previous 3 pages but I had a simple solution to the problem.


1) charge a refundable fee to join the pool
2) refund the fee such that when the potential cheater has been there long enough to overcome the cheater advantage, the fee is refunded.


Is that over simplifying?