Topic: Abusing Bitcoin mining pools: strategies for egoistical but honest miners (Read 17153 times)

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.

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.

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

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.

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

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

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

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. 

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.

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.


Thanks, I will correct this.


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


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 ?

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.

Short quote from document:

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

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.

Is it clear that in the period from here to the next difficult change the EV of mining in a fresh contributed pool or a connected pool is identical to the EV of running alone?

How about over the period from the start of new difficult to the new difficulty after that?

If each period is equal then the sum of the EVs must be equal.

That said there is obvious benefit in reducing variance. The benefit is more than psychological; it allows more accurate planning on when you will be able to afford new equipment, etc.

I can envision a future where lottery tickets are 10 minutes with a powerful GPU rig. Or where even a big mining operation cannot be sure to get a block this month so they need to be in a pool to make sure they can pay the electric bill.

I do mean expected value, but by saying "gain" I make sure we're not talking about expected time before a share or some other value.

Again, I didn't make calculations, I'm just using intuition (which can be tricky), but I'm pretty sure that expected gain decreases if you mine all by yourself and you're not powerful enough to have a good chance of finding a block before the next increase in block difficulty. At current difficulty, my CPU would take about half a year to have a 50% of finding a block, but before that difficulty will have increased, so my chance of finding a block in half a year is actually lower.

If by expect gain you mean formal EV then it doesn't drop close to zero it stays close to zero. It's the variance that is reduced by the pool. I don't mean to imply that you don't know this; I'm only saying that the language is not precise.

I am no economist, even if might have things to say about game theory and optimization from times to times. I can write about computer science, though, and I already asked in the "bitcoin times" thread if you would be interested in publishing a series of articles about the science behind bitcoin or other crypto-stuff. Writing such articles is time-consuming, and I wouldn't want to do that unless some interest was voiced beforehands.

I agree, this was written from the point of view of a miner estimating his expected gain from one specific block (or more precisely, one round), but as long as blocks (or pools) are exchangable, there is no reason to do this. If he has a choice, a small miner should switch to a pool with a "younger" round. I don't belive he should start mining all by himself is there is no other pool, though; his expected gain would drop close to zero, because of the increasing difficulty.

If the goal is to not get left out when your pool makes a block then you want the second. But the two have the exact same EV and the first has lower variance.
 

Let's take two simple scenarios:

- A pool with three people. Two of them have clusters of 5970s, one of them has an old Pentium IV. For blocks that are found before 10000 shares or so, that third person won't even have submitted one share, and thus will get nothing, not even a small fraction of a bitcoin.

- A pool with three people. Each of them has an old Pentium IV. Blocks will take a long time to be found, but most likely a lot of the members will have submitted at least one share.