Optimal pool abuse strategy. Proofs and countermeasures

[Raulo]

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
http://bitcointalk.org/index.php?topic=2941.0
(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
http://bitcointalk.org/index.php?topic=3078.0
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.  

[1715447638]

1715447638

[Ryo]

In this thread, the author finds no evidence of massive use of this strategy
http://bitcointalk.org/index.php?topic=2941.0
(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

[slush]

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.

[Raulo]

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.

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. 

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.

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.

[twobitcoins]

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.

[Pieter Wuille]

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

[slush]

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

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.

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.

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.

he may estimate the probability that you found the block

Nonsense. You cannot say who find the block by listening, for example, #bitcoin-monitor.

[Ryo]

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.

[Ryo]

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 ?

[slush]

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.

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?

Do you use new BTC address for every new block?

Afaik this is default bitcoin behaviour.

[slush]

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.

[Ryo]

If you critize my trustworthy

I have no opinion about you, good or bad. My interest is what can be done, not what is actually done.

then yes, I can cheat users all the time, I don't need to hide stats to do so.

As the pool was before, with full statistics, users could check whether their revenue was really ((50/total_shares) * nb_shares). They could also, by talking with each other, evaluate if the pool reported a plausible number of total shares. While there were ways for the pool to cheat, the statistics allowed users to check it didn't cheat too much.

My understanding of the way your pools works now is: miners find shares, they receive bitcoins, but they can't know how much the pools pays each share. As long as you release data on how much a share is worth, "cheating" becomes possible. I was wondering if you had found a way to preserve both openness and fairness.

I believe having the value of contributed shares decrease over time would also fix the cheating problem, ensuring that the expected gain of joining is the same at all times. And you'd still be able to display the statistics like before.

[slush]

As the pool was before, with full statistics, users could check whether their revenue was really ((50/total_shares) * nb_shares). They could also, by talking with each other, evaluate if the pool reported a plausible number of total shares. While there were ways for the pool to cheat, the statistics allowed users to check it didn't cheat too much.

Currently, you don't see realtime stats, but you can compare those numbers on found blocks older than 2 hours, so not such big difference. Also, as I said, this is only temporary solution. Once I'll change some internal things, I'll show realtime stats per actual hour, so everybody will see almost the same numbers as before this last update.

As long as you release data on how much a share is worth, "cheating" becomes possible.

But you can calculate it itself, too. There is no fancy stats now, but I don't hide any needed info. You know how many shares you submitted and how many reward did you get. You also know that one round is worth of 50BTC. There's nothing hidden! You only cannot calculate/use this numbers at realtime.

I was wondering if you had found a way to preserve both openness and fairness.

Yes, described above.

I believe having the value of contributed shares decrease over time would also fix the cheating problem, ensuring that the expected gain of joining is the same at all times.

Tell me how, I'll implement this! But this attitude open completely different way of cheating, I spent on this many hours by thinking. And once I'll need to take a financial risk of pool unlucky/cheating, pool mining won't be for free anymore :-).

[Fractality]

I must admit I didn't go through every line of the paper, so I just wanted to double check if I understood the problem correctly, in simple terms.

Is the problem this, as an example: assume there are 10 miners in a pool, and they each calculate 1000 hashes before the winning block is found. Then among those 1000 hashes, each of them has created the same expected amount of shares (let's say they have 2 shares on average). That would be the fair case.

The problem is that usually the shares won't be the last hashes to be found. So miner X might already have generated 2 shares among his first 500 hashes. If he stops exactly then, he'll have the same number of hashes as the other minors, for only half the work (on average). Of course had he continued to do 500 more hashes, he likely would have created more shares, too, so the calculation is not THAT simple.

Or in other words: if you stop right after receiving a share, you will have done less work for your shares than the fair miners, on average.

Not sure if all the maths in the paper adds up, as I said, I didn't check thoroughly. For example it might be incorrect to talk about n hashes, because if the winning block is found before n hashes, there wouldn't even be n attempts at hashing (I assume once a block is found, all calculations reset to the start :-) Correct me if I am wrong, but isn't the expected number of winning hashes after n attempts simply n*p? 1-(1-p)^n is not the probability to find one block after n hashes, it is the probability to find at least one block after n hashes (and, as I said, in a typical scenario there would not be n hashes, as hashing stops after the first block has been found). (I tend to get these probability calculations wrong all the time, though - my apologies in case I am just spouting nonsense).

[Raulo]

slush and twobitcoins,

You are right. The block-shares resetting still allows for cheating. I was blinded by this nullification stuff and didn't notice it will erase some cheating gains but not all.

Slush "blinding" approach is probably best strategy currently (except awarding 50 BTC to the person who found the block which solves the porblem once and for all ) but I still think by some bitcoin network analysis (due to different network distances between the nodes) one can find at least the continent, where the current block is found. And the strategy would be to join the pool if the last block was found in Europe and leave the pool if not.  This way you will be more likely connected to the pool for fresh rounds and less likely for stale.

Contributed method is very tricky because in fact, all that matters is the winning block and the non-winning shares are all wasted.  

By the way, for those who want to have some practical test of this cheating strategy, instead of special functions, here is the Monte Carlo run which finds the round length (with exp(-x) distribution) and performs swiching to individual mining after some fraction of shares. Here is the awk code.

Code:

#!/usr/bin/awk -f
BEGIN{srand();lambda=0.434
print "pool  independ.  total"
for (i=1;i<=10000000;i++)
{
# calculate current round length..
  r=rand()
  y=-log(r)

  if (y > lambda) # we switched from the pool after lambda
  {
    payolaind+=(y-lambda)  # independent payout based on fractions not connected to the pool
    payola+=lambda/y         # pool payout reduced since we stopped mining after lambda
  }
  else
    payola++             #normal pool payout


  if (i%100000==0) print payola/i,payolaind/i,(payola+payolaind)/i
}
}

[Raulo]

Correct me if I am wrong, but isn't the expected number of winning hashes after n attempts simply n*p? 1-(1-p)^n is not the probability to find one block after n hashes, it is the probability to find at least one block after n hashes (and, as I said, in a typical scenario there would not be n hashes, as hashing stops after the first block has been found). (I tend to get these probability calculations wrong all the time, though - my apologies in case I am just spouting nonsense).

Yes, the average is n*p but what we need is the probability of finding indeed at least one block and by reverse not finding any. This is what drives the strategy. If the block is found early, keep mining for the pool. If not, start individual mining and return after the pool finds a block.

[Raulo]

I believe having the value of contributed shares decrease over time would also fix the cheating problem, ensuring that the expected gain of joining is the same at all times. And you'd still be able to display the statistics like before.

This will not help since all old shares are in essence worth zero. Only the winning one is worth 50 BTC. I(λ) function is always positive. No matter how low is your payout after switching out of the pool, you still get "unearned" gains.

It may be possible to make cheating impractical but at the expense of making the pool more like individual mining. Because switching between pool and solo mining costs you some hashes (even if you do it as cleverly as possible), if the payout from cheating is low enough, it may be not worth cheating. I did Monte Carlo simulations  that show that counting only last 10% of difficulty of shares in the pool, reduces the extra cheating income to about 5% but the variance in the pool gets larger. But with multiple pools it get more interesting.

[Raulo]

Below is a script for calculating cheater's income in a pool that keeps only some number of most recent shares. It makes the switching from the pool much less profitable.

Code:

#!/usr/bin/awk -f
BEGIN{srand();lambda=0.07 # when to stop mining for the pool as a ratio of difficulty.
payratio=0.05 # how many last shares pool counts. Here 5% of difficulty
print "Fractions of income from"
print "Pool     solo     total"
for (i=1;i<=100000000;i++)
{

  r=rand()
  j=-log(r)


  if (j>lambda)
  {
    payolaind+=(j-lambda) # independent payoff
    payola+=(j<=payratio ? lambda :  (lambda-(j-payratio) > 0 ? (lambda-(j-payratio))/payratio : 0 )) # pool payoff counting only last payratio shares
  }
  else
    payola++  #full payoff. Cheater stayed in the pool for the whole round.

  if (i%1000000==0) print payola/i,payolaind/i,(payola+payolaind)/i
}
}

The above code calculates payoff for a pool that keeps 5% of the difficulty number of shares and the cheater exits from the pool after 7% of the difficulty (this value has to be much lower, lower than original 43%). The calculated value is about 2% which should be low enough to discourage this behavior as switching miners has some overhead (and the pool also has some latency overhead compared to solo mining). Keeping 10% difficulty, results in about 4% gain.  

[eMansipater]

I think you are all missing the point a little.  The concern is not cheating but undetectable cheating.  Every method of cheating the pool proposed thus far, and indeed virtually any statistically significant exploit(by definition), is easily detectable by the pool operator.  Simply detect, warn, and remove.  Case closed.  Although I applaud Slush's efforts to keep abreast of this issue!  I just think his/her valuable time could be better spent elsewhere.

[Raulo]

I think you are all missing the point a little.  The concern is not cheating but undetectable cheating.  Every method of cheating the pool proposed thus far, and indeed virtually any statistically significant exploit(by definition), is easily detectable by the pool operator. 

With a little effort by the bad guy, slush will have to have an investigative team to find the problem. Switching users, switching IPs, being honest for some time or cheating with only a part of ones hashrate, all it make harder for the pool operator to detect. There is a lot of normal variance and it masks quite a bit. And it will be even harder, if there are many pools. Sure, if you cheat with, say, 25% of the pool hashrate, you are exposing yourself but with up to 5%, not that much.

[slush]

I think you are all missing the point a little.  The concern is not cheating but undetectable cheating. 

Bad guy can mask his behaviour pretty easily, so with anonymous registrations it is still a problem. And I'm also trying to keep the system to be fully automatic, with clear rules. I don't like to disconnecting users because I 'think' the worker is 'maybe' cheating.

[Cryptoman]

Slush, I miss the number of shares counters.  It was a good way for me to tell how my machines were doing relative to one another.  Is it possible to at least show a percentage or bar graph comparing each of a user's miners for the current block and maybe overall mining history?  It does not need to be compared to the pool as a whole.

[comboy]

Hiding number of my shares seems weird. I can see them in my miner. Why hide information that came from me in the first place?

[slush]

Hiding number of my shares seems weird. I can see them in my miner. Why hide information that came from me in the first place?

You see your shares, but you don't know to which block it fits. But shares on profile page were cleared when block was found. That's the difference.

[comboy]

Hiding number of my shares seems weird. I can see them in my miner. Why hide information that came from me in the first place?

You see your shares, but you don't know to which block it fits. But shares on profile page were cleared when block was found. That's the difference.

edit: sorry for not reading thread carefully, but as davidonpda mentioned, any kind of stats would be nice. Your site is very handy for monitoring miners performance.

[slush]

For those that like to see, say estimated performance, what if you included: Number of shares in the last 2 hours?

If you read yesterday's posts here and in pool thread carefully, I mentioned this many times.

But things changed, looks like there will be all stats back soon.

[eMansipater]

I think you are all missing the point a little.  The concern is not cheating but undetectable cheating. 

Bad guy can mask his behaviour pretty easily

Really?  My guess is that any of these strategies would differ drastically from the typical miner.  Your statistics may show differently, but I'm guessing most people who bother to use a mining pool leave their clients running pretty steadily in at least large chunks (if not 24/7), rather than connecting and disconnecting all the time.  All of the cheating strategies require disconnecting early, a behaviour that can be distributed but not masked by using multiple anonymous accounts--at any meaningful degree of exploitation, a significant proportion of those clients have to be in at the beginning of each round, with that same client disconnecting consistently before the end.  The only portion of the attack that can be masked through multiple accounts is the obtaining of statistics on the beginning of each round, which is not behaviourally necessary to identify the cheating signature.  Detection code consists of the following:

1.  Record connected/disconnected periods using getwork requests, not submitted shares (presumably already done based on your leaderboard's online/offline capability)
2.  Implement minimum send threshold of .5 bitcoins, or similar amount of value as the bitcoin exchange rate and network hashrate both grow.
3.  On send/payout of any account, calculate the average in and out times across blocks worked on by each worker, compared to the overall average.
4.  If times are notably shifted towards the cheating strategy once, send the following email:

Dear user, the server has detected that your worker account "X" is frequently connecting and disconnecting at odd times.  Perhaps there is a problem with your client software or internet connection?  Since it exists to reduce the variance of the mining process for a large group of people, pooled mining works best when your client is connected for longer periods at a time, or consistently during regular periods of the day and week.  If you are unable to connect your client consistently, perhaps pooled mining is not for you.  Should the problem persist, the next payout from that worker may be held by the server until you have an opportunity to resolve it.  Thank you for your cooperation!

If it happens again, do what you said but be willing to give someone one more chance if they can come up with a reasonable explanation for their mining client's bizarre behaviour.

...and then, because the only way to get around this method of cheat detection is to use accounts once and then burn them at an incredible rate....
5.  Implement captcha on account and worker registration.

Problem solved!

Keep in mind that for any of these attacks to work the cheater has to *consistently* be in at the beginning of each round (and I mean the very beginning, because even a short delay or randomisation will significantly impact the profits through loss of short blocks) and avoid the really long ones at all costs (because going all the way to the end with any kind of consistency, again, wipes out that edge very fast).  And I fail to see how this behaviour can be masked across any combination of accounts, because no legitimate user is going to randomly be connected at the precise beginning of every single round and then never stay connected to the end of a long block.

For any given detection code in step 4 above you can calculate both the chance of accidentally catching someone who's not trying to cheat and the maximum margin of cheating possible--you'll see what I mean pretty quickly.  As an example, if you're up for it Raulo or Ryo, try calculating these for detection code that flags workers whose average time logging in a worker for the first time (as opposed to just continuing from the end of a previous block) is < 5 minutes after a round begins, and average time out for good on a round is < 25 minutes later in it.  You'll notice that the cheating edge is blown away by trying to beat the detection filter, yet the probability of a user randomly obtaining these stats by accident is redonkulous.  Am I drastically missing a strategy here?

Sincerely,
eMansipater

[ByteCoin]

Good catch to spot this pool exploit! I completely missed this in spite of thinking about pooled mining quite a lot.

If you have any doubts about the reality of this exploit then consider the following thought experiment:
Suppose there are ten miners hashing at equal rates. After they each submit one work-unit to the pool, if a block is then found they each get 1/10th of the total profit. If one of the miners leaves and is replaced by a new miner at that stage and each miner then submits another work-unit then, if a block is then found the new miner gets 1/20th of the profit having done the same amount of work as the miner whose place he took. It's only fair if the share of the profit is proportional to the work done.

One solution to the problem is to make the payout for the block proportional to the time since the last block. The mining pool would have to have a slush fund to cover the cases where the block generation rate falls below the long-term average.

ByteCoin

[knoop]

Sorry, I'm failing to understand the nature of the "unearned income", discussed in the paper. The critical section appears to be the first two paragraphs of section 2 "Pool cheating". In particular, the sentence:

"However, if you stop mining before the block is found, there is an extra “unearned” income."

I can't seem to find an explanation of what this "unearned income" is. The only possibility I can think of is that it becomes more difficult to find hashes which have not been found before, as work progresses on a block, thereby making the earlier shares easier to find. If this is not the case, then I cannot see where the share based system would introduce unfairness.

Also, the paragraph starts with the sentence:

"Therefore, switching between pools in connected mode and between such pools and individual mining does not change your payoff."

This statement seems to directly contradict the hypothesis that cheating is in fact possible...

I expect all the conclusions made in the paper and the adjustments made on its basis are sound, but the paper does seem to lack at least one critical point, so some elaboration would be appreciated.

[Raulo]

"However, if you stop mining before the block is found, there is an extra “unearned” income."

I can't seem to find an explanation of what this "unearned income" is. The only possibility I can think of is that it becomes more difficult to find hashes which have not been found before, as work progresses on a block, thereby making the earlier shares easier to find. If this is not the case, then I cannot see where the share based system would introduce unfairness.

When you submit a share, there is 1/difficulty chance it is a winning hash. But all the non-winning shares do not help finding the winning hash. So if you stop contributing, all your previous effort has zero value to the pool and pool should pay you zero for them. If it pays something, it is "unearned" income.

"Therefore, switching between pools in connected mode and between such pools and individual mining does not change your payoff."

This statement seems to directly contradict the hypothesis that cheating is in fact possible...

"Connected" mode is defined in previous paragraphs of the paper. A truly connected mode is not practical because it means miners are sending all the hashes (not just shares) to server. In connected mode, if you do not sending hashes this very moment, you get zero payment if the block is found because it couldn't have been you that found the block. A connected mode can be approximated by taking into account only shares contributed during, say, last minute or like in current slush's pool, by wighting recent shares much more than the older ones. In such mode cheating is mathematically possible, but the benefit is so small that it is note worth the effort and switching costs (it always costs some hashes to redirect ones mining effort).

Slush's old pool (before anti-cheating measures) was in "contributed" mode. All your past shares counted. It was prone to cheating described in this paper.

[Ricochet]

This was also an issue back when doublec ran his pool using puddinpop's server and client programs (before slush started his) which used a slightly different mining method but the end result was similar.  It was originally in "connected" mode and then changed to "contributed" due to user feedback, but there was much debate between the two.  Because it took days for the group to find a block, this was a large problem since it would actively dictate the behavior of potential users and whether they'd join the pool or not.  My first post on the forums in fact was my thoughts on the matter, in which I suggested something similar to what slush is currently doing with the time-weighting.  

[Meni Rosenfeld]

It looks like the paper is unavailable from http://bitcoin.atspace.com/poolcheating.pdf . Where can I get it now?

[Raulo]

It looks like the paper is unavailable from http://bitcoin.atspace.com/poolcheating.pdf . Where can I get it now?

The web hosting I use, started to become pretty unreliable recently. I need to find something different. But if you PM me your email, I can email the paper to you.

[slush]

http://mining.bitcoin.cz/media/download/poolcheating.pdf

[Meni Rosenfeld]

It looks like the paper is unavailable from http://bitcoin.atspace.com/poolcheating.pdf . Where can I get it now?

The web hosting I use, started to become pretty unreliable recently. I need to find something different. But if you PM me your email, I can email the paper to you.

Thanks! This was obviated by slush's gracious hosting.

http://mining.bitcoin.cz/media/download/poolcheating.pdf

Thanks! Saved to disk this time.

[luv2drnkbr]

I'm not math-savvy enough to get the whole thing, but I am a gambler and I understand expectation, and the basic premise is false:

If one stops mining for a pool that has not found a share, one still gets a payment [...] even though now you contribute nothing to the pool chance of success. This enables cheating.

It doesn't matter if you contributed to the pool and a hash wasn't found.  It still took your previous work as well as the work of everybody else to find the hash.  You DID contribute to finding that solution.  And you are getting paid for the amount of work that you did.  If you then go and continue working on your own, that doesn't matter.

If I am playing in a re-buy poker tournament on a team's bankroll (a team I'm a part of), and if my win would get chopped with the team, but then I bust out, and the team doesn't want to re-buy me back into it, I can still go into my pocket and buy myself in on my own money.

If somebody on the team wins the tournament, I still get part of it because I AM part of that team, and if I cash on my own money with my re-buy, I get all of it because the team didn't pay for that.

That's not unfair to anybody.  I was working for the team, and if the team wins money, I should get paid for my role in the team effort.  If I then go off and put the effort in by myself and win, then I should get all of it.  There's no conflict there.

The basic premise of your paper is false.  The EV is the same for the miner--it's merely a function of his total effort put in, pool or no pool.

What you are describing is simply a "gambling system" that doesn't change the house edge.  You've stumbled upon the Martingale system for blackjack and now think you have an edge.

You don't.  Nothing has changed.  The premise is false.

I will demonstrate what I'm saying must be true:  If everybody in the pool mines for a bit then goes solo, the pool has done some work but now will never find a solution.  However, one of the solo miners will (assuming no outside people in this example).  The chance of any individual miner finding a winner is exactly the same as it was when he was part of a pool, it's just that when he was in a pool, he would have had to give most of his winnings away, but in return he got part of the winnings if somebody else won.  By mining solo, he has merely given himself a bigger potential payout but at a cost of it being less likely.  But his average monetary gain over the course of his lifetime will be the same, whether or not it's paid in small increments or in random 50 btc spurts.  Thus, if the two are equal, it cannot be true that switching to one or the other at some magical point in time will somehow yield a higher profit.

100% of $5 is mathematically equivalent to 10% of $50.  The only difference is variance.

The premise is false!

[Meni Rosenfeld]

luv2drnkbr, I agree with you. Raulo's formulation of "not having contributed if you leave the pool" is incorrect. I have never raised my dissent because the analysis of pool hopping does not depend on it as a premise. It is still a way to benefit on the expense of others in proportional pools, which is unsustainable if done by everyone.

The correct way to view this is to ignore the past, look at the present and see how it affects the future. If I submit a share now, what is the expected benefit to the pool? What is my expected payout? Are they the same? In my scoring method, the contribution and reward are always equal (up to fees). In a proportional pool, the reward is higher than the contribution in young rounds, and lower in old rounds.

On a proportional pool, suppose the current round already has shares twice the difficulty. If you submit a share, what is your expected contribution? You have a probability p=1/difficulty to find a valid block with reward B, so it's pB. What is your expected payout for this share? No matter what happens, you will get less than (pB/2) reward, so the expectation is less than pB/2. So you're better off mining solo which has pB expectation per share.

What if the round is very fresh, say, no shares at all? Your contribution to the pool is still pB. But now you have a probability of p to get the whole reward B to yourself, this contingency alone adds pB to the expectation; probability p(1-p) of getting half the block - since 1-p is quite small, this already puts you at almost 1.5pB; and with probability p(1-p)^2 you get a third, and so on. So your expected payout is roughly log(1/p)pB, which at current difficulty is 13pB. So shares submitted early on will give you a very large expected payout, much more than your fair share for your contribution to the pool.

[luv2drnkbr]

luv2drnkbr, I agree with you. Raulo's formulation of "not having contributed if you leave the pool" is incorrect. I have never raised my dissent because the analysis of pool hopping does not depend on it as a premise. It is still a way to benefit on the expense of others in proportional pools, which is unsustainable if done by everyone.

The correct way to view this is to ignore the past, look at the present and see how it affects the future. If I submit a share now, what is the expected benefit to the pool? What is my expected payout? Are they the same? In my scoring method, the contribution and reward are always equal (up to fees). In a proportional pool, the reward is higher than the contribution in young rounds, and lower in old rounds.

On a proportional pool, suppose the current round already has shares twice the difficulty. If you submit a share, what is your expected contribution? You have a probability p=1/difficulty to find a valid block with reward B, so it's pB. What is your expected payout for this share? No matter what happens, you will get less than (pB/2) reward, so the expectation is less than pB/2. So you're better off mining solo which has pB expectation per share.

What if the round is very fresh, say, no shares at all? Your contribution to the pool is still pB. But now you have a probability of p to get the whole reward B to yourself, this contingency alone adds pB to the expectation; probability p(1-p) of getting half the block - since 1-p is quite small, this already puts you at almost 1.5pB; and with probability p(1-p)^2 you get a third, and so on. So your expected payout is roughly log(1/p)pB, which at current difficulty is 13pB. So shares submitted early on will give you a very large expected payout, much more than your fair share for your contribution to the pool.

I did not understand that proportional pools existed.  Thank you for that explanation Holy-Fire.

[PoulGrym]

This to me just sounds messy. Why not just keep it simple and stay with PPS?? Then no weird stuff..  is there anyway to cheat with the Pay Per Share System? Not that I can think of anything. Skipping a share? Then you get a big pool of stales.. no way to get around that one..

Just keep it simple.. Just wasting time and energy. IMHO

[Raulo]

This to me just sounds messy. Why not just keep it simple and stay with PPS?? Then no weird stuff..  is there anyway to cheat with the Pay Per Share System? Not that I can think of anything. Skipping a share? Then you get a big pool of stales.. no way to get around that one..

Pay per share (PPS) is very dangerous for pool operators, especially the small ones. In PPS, the pool operators have to pay for bad lack streaks with their own pockets. It can make them go bankrupt because 10-20% bad luck streaks are not uncommon. Moreover, there can be malicious users who do not submit winning shares. With difficulty over 400,000, the loss for the user is negligible, for pool operator it is huge.

[Sukrim]

PPS has the downside that you pay for stale shares of others - even if the pool operator keeps as little as possible, this still means your income will be lower than in a pool with a different model. A proportional pool with 0 hoppers might be ideal "fairness wise", a score based pool raises variance and shifts some risks but this canbe tuned.

PPS however will very likely be worse, since it is not ver predictable for smaller pools how much they would really earn during 2016 Blocks to calculate correct values. This means they either have to have higher fees on PPS (deepbit for example has (or had, as they are down atm)) 10%(!) extra fee on PPS payouts.

[BombaUcigasa]

HELP, I don't see the proof.

Given 2 blocks, and an ability to generate 100 shares per block, and two pools, a pool hopper will try to jump the pool after each share, right? He will effectively generate 200 shares, in the two pools, each block he will generate 100 shares. Just like he would use a single pool. He will spend the whole time between two shares, in one of the pools, at the reward of a share.

Number of times waiting for shares to come up and compute hashes = Number of shares received in pools

Why don't I see the problem?

[Meni Rosenfeld]

Given 2 blocks, and an ability to generate 100 shares per block, and two pools, a pool hopper will try to jump the pool after each share, right?

No, he will always mine for the pool with the least shares in the current round. If all proportional pools are >43.5% he will mine for a score-based pool.

[BombaUcigasa]

No, he will always mine for the pool with the least shares in the current round.

Ok. That's like having two miners and increasing load on the one with less submissions so they equal up... I don't see the bad thing in this. If he pushes to a single pool all his shares, or pushes 50% to a pool and another 50% to another pool, his reward should be the same in all cases.

If all proportional pools are >43.5% he will mine for a score-based pool.

Proportional pools are > 43.5% what? I don't understand what is the percentage of.

[Meni Rosenfeld]

No, he will always mine for the pool with the least shares in the current round.

Ok. That's like having two miners and increasing load on the one with less submissions so they equal up... I don't see the bad thing in this. If he pushes to a single pool all his shares, or pushes 50% to a pool and another 50% to another pool, his reward should be the same in all cases.

The less shares in the current round in a proportional pool, the greater the expected reward per share submitted. Consider also the examples I gave in this comment. The bad thing is that hoppers get too much reward for their contribution to the pool (and to the Bitcoin network at large), while honest miners get too little.

If all proportional pools are >43.5% he will mine for a score-based pool.

Proportional pools are > 43.5% what? I don't understand what is the percentage of.

This means that for every proportional pool, the number of shares in its current round is more than 43.5% of the current difficulty.

[Sukrim]

Just read the paper!

43.5% of expected time to complete a block with the current hash rate.

[Meni Rosenfeld]

43.5% of expected time to complete a block with the current hash rate.

Actually that's just an approximation, which doesn't take into account changes in hashrate etc.

[BombaUcigasa]

I just red the paper AGAIN!

I still don't see how in practice you could abuse a pool. If you are contributing 43% of an average round period, you get 43% of that round's shares and a 43% chance of finding the block.

How do you get a higher reward? If the block required 200 shares and there are 2 people in the pool then you get:
- cheater does 43 shares then leaves, the non-cheater has to do 157 shares, the block is found, each gets proportional payment, cheater has a chance of 21.5% of finding the block, the non-cheater has a chance of 78.5%. The cheater gets 21.5% of the reward, the non-cheater gets 78.5%.
- non-cheater A can do 43 difficulty 1 hashes in 10 minutes, non-cheater B can do 157. The block is found, each gets a proportional payment, just like above, the total contribution is shares/time, in both scenarios, and the payoff is the same

[grue]

I just red the paper AGAIN!

lol

How do you get a higher reward? If the block required 200 shares and there are 2 people in the pool then you get:
- cheater does 43 shares then leaves, the non-cheater has to do 157 shares, the block is found, each gets proportional payment, cheater has a chance of 21.5% of finding the block, the non-cheater has a chance of 78.5%. The cheater gets 21.5% of the reward, the non-cheater gets 78.5%.
- non-cheater A can do 43 difficulty 1 hashes in 10 minutes, non-cheater B can do 157. The block is found, each gets a proportional payment, just like above, the total contribution is shares/time, in both scenarios, and the payoff is the same

I REPEAT, READ THE PAPER AGAIN! especially the part with the funny equations. don't just go "wtf", and skip it.

[BombaUcigasa]

I REPEAT, READ THE PAPER AGAIN! especially the part with the funny equations. don't just go "wtf", and skip it.

Yeah, what about them. They translate the long text into a mathematical formula. Both are theoretical models that seem to lack a certain factor that happens in practice...

This is why I ask, how exactly can one cheat in practice.

[grue]

I REPEAT, READ THE PAPER AGAIN! especially the part with the funny equations. don't just go "wtf", and skip it.

Yeah, what about them. They translate the long text into a mathematical formula. Both are theoretical models that seem to lack a certain factor that happens in practice...

This is why I ask, how exactly can one cheat in practice.

same question i asked.
https://forum.bitcoin.org/index.php?topic=9928.0
moral of the story? lrn2 search

[jhansen858]

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?

[BombaUcigasa]

same question i asked.
https://forum.bitcoin.org/index.php?topic=9928.0
moral of the story? lrn2 search

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?

[Meni Rosenfeld]

Is that over simplifying?

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.

same question i asked.
https://forum.bitcoin.org/index.php?topic=9928.0
moral of the story? lrn2 search

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?

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.

[BombaUcigasa]

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.

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?

[Meni Rosenfeld]

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.

[BombaUcigasa]

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.

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.

[Meni Rosenfeld]

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.

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.

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.

[BombaUcigasa]

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.

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?

[Meni Rosenfeld]

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.

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.

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

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.

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

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?

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.

[BombaUcigasa]

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.

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

[drlukacs]

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

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

[Meni Rosenfeld]

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

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

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

[drlukacs]

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

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.

[Meni Rosenfeld]

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

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.

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

[camaro69327]

June 13, 2011, 12:18:25 PM  <<<<WTF last post in this thread.



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

[drlukacs]

June 13, 2011, 12:18:25 PM  <<<<WTF last post in this thread.



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

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.

[organofcorti]

June 13, 2011, 12:18:25 PM  <<<<WTF last post in this thread.



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

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.

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

[gyverlb]

June 13, 2011, 12:18:25 PM  <<<<WTF last post in this thread.



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

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.

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

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

[Meni Rosenfeld]

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.

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

[drlukacs]

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.

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

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.