Abusing Bitcoin mining pools: strategies for egoistical but honest miners

[theymos]

It seems easier for the server to cheat in connected mode. With contributed mode, if they have doubts, miners can log how many shares they contribute, check how much they gain, and decide whether it's fair. The server could "invent" imaginary shares to keep some bitcoins, but at least you have some hard numbers to check. With connected mode, how would you know if you got a fair share ? What if the server pretends you were not connected when the block was found ?

It's more difficult, in fact. The server continually tells you what it believes your hash/s is. You can compare this number with other servers to see if it is reasonable. When a block is found, you can calculate your share from the server-reported total hash/s. Over many blocks, you can check that the server's hash/s is accurate by seeing if the actual time to solve blocks matches the projected time at that hash/s.

People will get very angry if they appear to disconnect just before a block is solved...

Since the shares in puddinpop's server are divided within the generation transaction and you download the temporary block, you can also see exactly how the block reward would be distributed at any given time. Verify that you and some other people are listed at an appropriate amount.

[1713965956]

1713965956

[1713965956]

1713965956

[slush]

Short quote from document:

but if several pools were ran based on the same code, it may also be protable to submit your work to all of them.

It's not true, at least for existing pools (puddinpop's and mine), because each instance of pool has own merkle root. So submitting shares from another pool (even based on the same code) won't work. Please correct this in your paper.

About disconnecting from pool after some count of shares; There are much more factors than price of one share and power consumption. For example, rising network difficulty or some fixed costs (costs from owning mining rig, even in idle). If there is only one pool and you are big guy, disconnecting from pool saves your energy, but you have to wait much longer for new round, because pool is missing your hash power. So you are waiting, but new higher difficulty is coming and later it will be even harder to find new block... But I didn't spend time thinking about it, so this is just my intuition, not exact math.

Good point is the switching between pools. But unless there are not two pools with similar hashpower, it's probably not relevant. Any rule which affect main formula for calculating rewards from contributed shares probably change overall pool fairness in some way.

I think your paper is interesting and thank you for working on this. I'm just missing some graph in section 4.2, which shows time (X), hashpower(Y) and vertical lines where new block was found. All of this is public information and it would add more weight to sentence "there was no evidence that people gave up on old blocks".

[slush]

Ah, also one note regard to 'unfairness of short rounds'. No, it is completely fair, but in longer term, not in one (short) round. Yes, when you are lucky and find 10 shares in 80 shares round, you will receive significant amount of bitcoins from this round. But everyone has the same probability to hit this premium in every short round. More exact, everyone with the same hashpower has the same probability, of course.

[Ryo]

If so than to me this seems to be an exercise in futility. Past performance does not guarantee the future results.

This is not about past performance, on the contrary. At any point in time, no matter how long the round has been active, there is the same expected time before finding a block. But what you will gain is not constant, it depends on the number of shares. Because of this, you can optimize.

because each instance of pool has own merkle root. So submitting shares from another pool (even based on the same code) won't work.

Thanks, I will correct this.

Good point is the switching between pools. But unless there are not two pools with similar hashpower, it's probably not relevant.

Even with two identical pool, unless they start their rounds at the same time, you can switch between them and gain a lot.

I'm just missing some graph in section 4.2, which shows time (X), hashpower(Y) and vertical lines where new block was found. All of this is public information and it would add more weight to sentence "there was no evidence that people gave up on old blocks".

I have to admit I have been lazy. I intended to provide that graph, but there was a network outage during the time I gathered my data, so there was a gap of a few hours, and I didn't want to start again. If you keep a log of computing power over time, and rounds over time, maybe you could send me the data, so I don't waste your bandwidth again ?

[FreeMoney]

Ah, also one note regard to 'unfairness of short rounds'. No, it is completely fair, but in longer term, not in one (short) round. Yes, when you are lucky and find 10 shares in 80 shares round, you will receive significant amount of bitcoins from this round. But everyone has the same probability to hit this premium in every short round. More exact, everyone with the same hashpower has the same probability, of course.

What isn't 'fair' is comparing outcome per/round when the rounds can be vastly different lengths. No one rational cares about payout/round, they care about payout/time.

[FreeMoney]

Think about this. Brand new pool, I start mining, if I find a block I get it all because I'm the only one there. Later someone joins me with exactly my hashing power, we are contributing equally, but I will get more than him under contributed method. Why is he paying me for mining before he got there? I wasn't going to give anything to him if I found a block back then, he gets no benefit from the fact that I previously mined, but he pays for it anyway.

Contributed method is not a rational equilibrium. But neither are a lot of things that persist for a long time. 

[eMansipater]

I did an extensive analysis of this a couple weeks back, with the aim of potentially working it into a short story.  Basically when you look at expected value per cpu/gpu cycle the beginning cycles of every round have much higher expected value and decrease the longer the round progresses, asymptoting out to the current network rate.  If everyone stays connected all the time at a consistent rate, or disconnect/reconnect with no correlation to the number of shares in the round so far, it all balances out to the same as mining on your own, just with reduced variance.  Whether you actually find shares or not and when varies from round to round but not in the long run, where it averages out (with the one interesting implication that the larger a cooperative effort gets as a percentage of overall network power, the higher the variance becomes for a set amount of hash/sec).

The specifics of the successful attacks are as follows:  if your aim is to maximise your expected value per cpu/gpu cycle you should throw as much power as possible at finding the first share in each round, quitting once it is found.  Your value per cycle goes through the roof for a decent sized pool, but your overall income is negligible because even a person with access to an extraordinary amount of idle processing power will only earn a small income in any given period of time--you only compute during extremely brief periods and have to wait for the next round to do it again.  Your income, however, is disproportionately higher than spending that same amount of cycles mining by yourself, and the income comes from the other pool participants.  And this type of attack would be immediately noticeable to the pool operator no matter how you set up the clients.

Strategies that leave the pool later and later in the round progressively reduce your value per cycle in exchange for being allowed to use more of them, thus increasing your actual income and decreasing your advantage due to the exploitation.  Any strategy that has you leaving the pool after X shares are found without a block gives you a higher value per cycle than working on your own, but only by a negligible amount for high X.  Strategies that use your time out of the pool to hash solo thus give an above average income, but with a higher variance--you choose the tradeoff by setting X, and this assumes that your hash/dollar makes it profitable to mine bitcoin in the first place.  If it didn't you need to not mine on your own and set X at a low enough value to provide you with actual income.  There are edge cases where these types of strategies might make sense, but your maximum gains from them are pretty low, and any reasonably sized value of X will be easily noticed by the pool operator.

My analysis--it would take some pretty severe edge cases and a very oblivious pool operator to make any significant money this way.  And "cyber-genius makes off with $500 in untraceable cash" makes a lousy heist story  .  Chances are anyone capable of coding this attack would make more money simply going to work.  But it's good for pool operators to be aware of.  One of those extreme edge cases did turn out to provide interesting plot fodder though, so stay tuned on that one .

Sincerely,
eMansipater

[sidd]

All the pool has to do to prevent this type of abuse is weight the reward of the shares by exp( current shares / difficulty )

[eMansipater]

Tips can go to 1LyHQFP41e6PtgKaEHHXresnyszE3YrTF6 for anyone who found it useful.  One of the exciting things about bitcoin for me is that the emergence of a successful microcurrency allows us to develop a culture of tipping , akin to what has emerged in restaurants and similar service industries.  Enforced by no one, yet powerful enough to provide meaningful incomes on the internet scale.  If we can train people that when something is valuable to you, you tip that person in some fashion no matter how small the amount, we can start developing meaningful post-advertising models for web content.  We have a little bit of work to do to make it easy and user-friendly, but if we can get people in the habit of tipping at least something, no matter how small, when you want to support a certain type of content, things can really add up!  Giving someone 2 or 3 cents, times a million visitors, is pretty good incentive to keep producing content.

/rabbit trail

sincerely,
eMansipater

[FairUser]

Is this strategy is based on making a choice of whether to join or not to join, to keep working or to stop working, to/for some particular pool out of a given set of pools at any given time?

If so than to me this seems to be an exercise in futility. Past performance does not guarantee the future results. You have nearly perfect model of random walk here, at any given time chances of finding a solution for a given contribution (i.e. risk reward) is about the same. By jumping around a bunch of pools you win some than loose some. Over longer period of time it will be all the same. More likely though you lose some on overheads related to pool jumps.

It is nearly the same as day trading on stock market following some pundit recommendations or some TA strategy, i.e. you win some, you lose some but in the end you are inescapably screwed by broker fees and liberated from your money.

Agreed.  Jumping pools doesn't damage/cause any time of fraud or attack against that pool.  That's just someone who is *trying* to play their odds, but the odds of winning in some pools and loosing in others will balance out.  The point being, it's useless to jump pools.

Pick one and stick with it.  Why anyone put any credit into pool jumping I don't know, but if you think it's worth it, then give it a try.....you'll be back to mining in a single pool within a few days.

[Local]

 
Pick one and stick with it.  Why anyone put any credit into pool jumping I don't know, but if you think it's worth it, then give it a try.....you'll be back to mining in a single pool within a few days.

This is just wrong. If you know a pool has fewer share owed you get a bigger % faster for the same power.

[Delia]

Possible attack against a connected-mode pool: when you find a pool-grade hash, send it immediately to gain credit, but when you find a block-grade hash, hold it until the pool hashrate dips.

This introduces some risk that someone outside the pool will find a block in the meantime, so you can't hold too long, but the optimal wait time is almost certainly greater than zero.

[slush]

Possible attack against a connected-mode pool: when you find a pool-grade hash, send it immediately to gain credit, but when you find a block-grade hash, hold it until the pool hashrate dips.

This introduces some risk that someone outside the pool will find a block in the meantime, so you can't hold too long, but the optimal wait time is almost certainly greater than zero.

Probably not. I didn't do exact math around it, but though about this possibility, too. You cannot take the share too long, because with new bitcoin block, your share become invalid. And this time should be proportional potential gain of delayed submit... Of course I'll welcome exact calculation about this possibility.