Do we want oblivious mining pool shares?

[Meni Rosenfeld]

Currently, when a participant in a mining pool finds a share, he knows whether this share is winning for the true difficulty. This knowledge can be used for at least two kinds of attack:

• Sabotage - Miner never submits winning shares. This doesn't increase the miner's own profits, but it decreases the total rewards of the pool and thus the payouts of participants. For Pay per Share, this can do heavy damage to the operator.
• Lie in wait - When miner finds a winning share, he doesn't submit it right away. Instead he pulls all his mining capacity (assuming he has extra capacity used elsewhere, perhaps specifically in preparation for this cheat) into this pool, using his "inside knowledge" that a winning share is imminent to increase his expected payout.

I suppose there are ways to mitigate these problems, but I think the only way to be truly immune to them is to change the Bitcoin protocol to make pooled miners oblivious to whether their shares are winning. I have an idea what this change would be and I may suggest it in a different thread (and argue for its cost/effectiveness), but first I would like to inquire - do we want shares to be oblivious? It could be argued that oblivious shares make it easier for the operator to cheat, but I'm not sure that's true.

[grue]

the second one won't work, because shares expire every 10 minutes (approximately)

[MoonShadow]

but I think the only way to be truly immune to them is to change the Bitcoin protocol to make pooled miners oblivious to whether their shares are winning.

Ah, no.

The Bitcoin protocol does not exist to make things easier on pool miners.  If this is really a concern, perhaps you shouldn't be pool mining.

[Meni Rosenfeld]

the second one won't work, because shares expire every 10 minutes (approximately)

So you hold out for 2 minutes. With a pool which is 25% of the total network that's all you need to be effective. It also depends on the scoring method used.

but I think the only way to be truly immune to them is to change the Bitcoin protocol to make pooled miners oblivious to whether their shares are winning.

Ah, no.
The Bitcoin protocol does not exist to make things easier on pool miners.  If this is really a concern, perhaps you shouldn't be pool mining.

I disagree, pooled mining is an important aspect of Bitcoin and the limitations of the protocol that hinder it should be fixed.

[FooDSt4mP]

the second one won't work, because shares expire every 10 minutes (approximately)

So you hold out for 2 minutes. With a pool which is 25% of the total network that's all you need to be effective. It also depends on the scoring method used.

but I think the only way to be truly immune to them is to change the Bitcoin protocol to make pooled miners oblivious to whether their shares are winning.

Ah, no.
The Bitcoin protocol does not exist to make things easier on pool miners.  If this is really a concern, perhaps you shouldn't be pool mining.

I disagree, pooled mining is an important aspect of Bitcoin and the limitations of the protocol that hinder it should be fixed.

Pooled mining is important... but I think it will mostly be smaller, private pools where trust is less of an issue.  Or one miner using pool software to track all his mining rigs.

[Meni Rosenfeld]

Pooled mining is important... but I think it will mostly be smaller, private pools where trust is less of an issue.  Or one miner using pool software to track all his mining rigs.

Small pools will be fairly useless. Variance for small miners will be huge, and you need a large pool to get a remotely steady payout.

[MoonShadow]

Small pools will be fairly useless. Variance for small miners will be huge,

What do you base this statement on?

[Meni Rosenfeld]

Small pools will be fairly useless. Variance for small miners will be huge,

What do you base this statement on?

Expected payout for mining = hashes * block reward / difficulty
Variance of payout = hashes * block reward^2 / difficulty
Standard deviation of payout = sqrt(hashes/difficulty) * block reward
Ratio between SD and expectation = sqrt(difficulty/hashes)

(In this notation I integrate the 2^32 factor into difficulty)

As Bitcoin grows, the total hashing capacity of the network will be much higher than that of an at-home miner (difficulty >> hashes), so his relative variance will be correspondingly high. Same goes for pools which are too small.

Or, more simply, when there are lots of miners, one with little capacity has a snowball's chance in hell to ever find a block.

[JorgePasada]

Small pools will be fairly useless. Variance for small miners will be huge,

What do you base this statement on?

The Maths.

[grue]

Lie in wait - When miner finds a winning share, he doesn't submit it right away. Instead he pulls all his mining capacity (assuming he has extra capacity used elsewhere, perhaps specifically in preparation for this cheat) into this pool, using his "inside knowledge" that a winning share is imminent to increase his expected payout.

what do you mean by that?
here's my interpretation:
1. you find winning share, you don't report it
2. you take all of your miners off of the pool, and onto another pool

am i getting this correctly?

[JorgePasada]

I dislike pooled mining because of the capacity for 'cheating' and the pool owner exploiting the miners in the pool. That is, however, why you have a choice to mine on your own, or as part of a pool, or to change pools if you think the operator of your pool is being less than honest about how the pool is being operated.

That being said, I think pooled mining will be essential to the future of the bitcoin network.

If 80% of the hashing power is accumulated by 3 or 4 people not only will it give opportunity for collusion, it could make those nodes (which will be in theory physically large and hard to conceal) easy targets for institutions which do not wish to have a banking system with competitive transaction costs, high portability, and high security.

What did the first politician pay the first prostitute with?    Q.E.D. Banking is the oldest profession.

If this catches on like I'm hoping and betting it will, there is going to be a lot of very influential powerful people who want their cut. Look at online poker a couple weeks back. I just hope things are as robust as possible by that time so we can weather that storm.

[Meni Rosenfeld]

Lie in wait - When miner finds a winning share, he doesn't submit it right away. Instead he pulls all his mining capacity (assuming he has extra capacity used elsewhere, perhaps specifically in preparation for this cheat) into this pool, using his "inside knowledge" that a winning share is imminent to increase his expected payout.

what do you mean by that?
here's my interpretation:
1. you find winning share, you don't report it
2. you take all of your miners off of the pool, and onto another pool

am i getting this correctly?

It's the other way around. You take all of your miners off other pools and into this pool. After you've generated a hefty amount of shares for this pool, you submit the winning share and get a nice reward for all these shares.

I disagree.

Pooled mining is not a concern for bitcoin protocol and as such it should not be changed for such petty reasons. It's up to the pool operators to figure out how to deal with this. I'd say that even if an alternative is the rampant cheating by pool users and eventual shut-down of all the pools, than it is still not a concern of bitcoin protocol but a concern of pool operators and users.

The only sustainable way Bitcoin can live up to its role of being decentralized is if >50% of mining capacity is in the hands of small miners, and pools are what allows this to happen. That's far from petty.

You could just as easily take any problem solved by some part of the protocol and say "That's just a problem for X, you shouldn't change the protocol because of this."

I see that people prefer to discuss here whether fixing this is worth a protocol change, despite me clarifying that's not what the thread is about. So to make it less abstract I'll just outline my planned change (which of course could be improved by people experienced with the protocol):

1. The block header will include 3 extra fields, which for now I'll call simply A, B and C.
2. B is a hash of A.
3. The block hash will be a hash of all the usual stuff and also B.
4. C is a hash of the concatenation of the block hash and A.
5. For the block to be valid: Instead of requiring that the block hash is less than (1 / (2^32 * difficulty)), it is required that the block
hash is less than (1 / 2^32) and C is less than (1 / difficulty).
So solo miners choose anything for A (maybe all zeros) and hash it once to find B. Then they calculate hashes normally but with B added. When they find a difficulty-1 hash they calculate C to check if it satisfies the real difficulty.
For pools, the operators choose A randomly and keep it secret, but hand out B as part of the getwork. The participants can calculate the block hash and if it satisfies difficulty-1 they submit it as a share, but they don't know if it satisfies real difficulty because they don't know A and thus can't calculate C. The operator can of course make the verification, and at round end A is published as part of the block and participants can verify that none of their winning shares were rejected.

I don't think this should in any way affect how Bitcoin is used, it just solves this very important problem behind the scenes.

I dislike pooled mining because of the capacity for 'cheating' and the pool owner exploiting the miners in the pool. That is, however, why you have a choice to mine on your own, or as part of a pool, or to change pools if you think the operator of your pool is being less than honest about how the pool is being operated.

In case you're unaware, the most commonly known form cheating in mining pools, pool-hopping, has a solution waiting to be implemented. It should be possible for pool operators to publish their records in a way that guarantees they themselves don't cheat. And lie in wait can either be solved with my proposed change or significantly alleviated by other methods.

[martok]

Wouldn't this create more work for the miner? That is, isn't he doing an extra hash per block or do I read this incorrectly?

I was thinking about this problem too recently. If the miner simply doesn't submit the share, it doesn't benefit anyone including himself. If he holds the solution temporarily and then brings capasity online to increase his score, I think that is something a pool operator should be able to detect.

That being said, if your solution has no loss, why look at it? Would the bitcoin protocol even need to be modified. Could just modify the RPC protocol between miner and pool but not between pool and bitcoind as bitcoin proper doesn't care about pools.

[Grinder]

The only sustainable way Bitcoin can be live up to its role of being decentralized is if >50% of mining capacity is in the hands of small miners, and pools are what allows this to happen. That's far from petty.

Except it's not really decentralised when 50% of the capacity goes away if two IPs are DDOSed.

[goatpig]

It's the other way around. You take all of your miners off other pools and into this pool. After you've generated a hefty amount of shares for this pool, you submit the winning share and get a nice reward for all these shares.

Would that really work? To hold 25% of the network hashrate means you're expected to solve one out of every 4 blocks faster than any other miner, but that doesn't mean you can sit on the solution eternally. Chances are a couple minutes later another pool/miner will have found the solution to that block and submitted it. The only thing I see this method accomplish is to gimp the targetted pool to the benefit of other pools, so I don't think the "Lie in Wait" part is feasible.

[Grinder]

Would that really work? To hold 25% of the network hashrate means you're expected to solve one out of every 4 blocks faster than any other miner, but that doesn't mean you can sit on the solution eternally.

The point is that on Slush's pool the newest shares have the highest value, so if you can hold it back for 1 minute you would increase the expected payout by several percent. If somebody else solves it first you don't really loose anything unless it's the pool you moved the other miners away from.

[goatpig]

Would that really work? To hold 25% of the network hashrate means you're expected to solve one out of every 4 blocks faster than any other miner, but that doesn't mean you can sit on the solution eternally.

The point is that on Slush's pool the newest shares have the highest value, so if you can hold it back for 1 minute you would increase the expected payout by several percent. If somebody else solves it first you don't really loose anything unless it's the pool you moved the other miners away from.

If I understand this thread properly, we are talking about pool users exploiting/damaging the pool reward, in this case I see 2 situations:

1) Small contribution: If you're only running, let's say, 1~2 Gh/s, the chances are ridiculously low for you to find that full difficulty solution. To be sitting at the computer all day waiting for it to happen once a week is beyond tedious. You could always modify your miner to hold the share, but at this point you're just trying to troll the pool, and it's not all that efficient.

2) Big contribution: You're like 10% of the pool. Now you have to assume you have consequent hashing power contributed to another pool or mining solo. This isn't impossible, but limited to a few individuals with stellar hashing power. Who's walking around with 30~40 Gh/s and pool mining hmm? Besides Gusti, I can't name anyone. At this point, holding out on every full difficulty solution you found long enough for you to move all your hashing power on slush's pool (there are no other who realistically suffers from this attack) is a huge risk. It'll take certainly more than a minute, there are several mining rigs that need to be reset for the purpose of the exploit.

What you are risking here, technically, is to try and increase your payout on a few blocks, at the risk of losing your original payout if a pool finds the solution you are withholding, all this considering you need to move all your hashing power to slush's pool and let it beef up your reward to a seizable profit under 10 minutes (If no one beats you to it under 10 minutes. Given the way the network is built, this is more than likely)

If you ask me, it is not only tedious, but has low chance of success, and a high risk of losing your "fair" reward.

Also any user with a big contribution can be easily monitored by the pool owner. If you see his reported hashing speed double up once a while a few minutes before a block is completed, it'll speak for itself.

[Meni Rosenfeld]

Wouldn't this create more work for the miner? That is, isn't he doing an extra hash per block or do I read this incorrectly?

He only needs to do an extra hash if the first hash solves difficulty 1, which happens once in 4 billion hashes. The extra work is negligible.

That being said, if your solution has no loss, why look at it? Would the bitcoin protocol even need to be modified. Could just modify the RPC protocol between miner and pool but not between pool and bitcoind as bitcoin proper doesn't care about pools.

Bitcoin cares about the hash found by the miner, which needs to satisfy difficulty requirement. Unless the hashing function used is broken, if the miner doesn't know if he has a winning share then he doesn't know if he has a share at all, so he won't know to submit it to the pool.

The only sustainable way Bitcoin can be live up to its role of being decentralized is if >50% of mining capacity is in the hands of small miners, and pools are what allows this to happen. That's far from petty.

Except it's not really decentralised when 50% of the capacity goes away if two IPs are DDOSed.

Of course there will be more than 2 pools. I expect there to be at least one pool in every country.

It's the other way around. You take all of your miners off other pools and into this pool. After you've generated a hefty amount of shares for this pool, you submit the winning share and get a nice reward for all these shares.

Would that really work? To hold 25% of the network hashrate means you're expected to solve one out of every 4 blocks faster than any other miner, but that doesn't mean you can sit on the solution eternally. Chances are a couple minutes later another pool/miner will have found the solution to that block and submitted it. The only thing I see this method accomplish is to gimp the targetted pool to the benefit of other pools, so I don't think the "Lie in Wait" part is feasible.

You don't do it eternally. If you're holding a winning share, every share you submit is much more valuable than normal shares. Every unit of time you hold out you submit X additional valuable shares, but risk that someone will find a block and make all your shares lose their extra value. You submit the winning shares when the constantly increasing risk outweighs the reward. The greater your hashing rate the more effective the attack.

1) Small contribution: If you're only running, let's say, 1~2 Gh/s, the chances are ridiculously low for you to find that full difficulty solution. To be sitting at the computer all day waiting for it to happen once a week is beyond tedious. You could always modify your miner to hold the share, but at this point you're just trying to troll the pool, and it's not all that efficient.

Of course you'll modify your miner rather than sitting at your computer. I don't understand what you mean by "troll the pool".

2) Big contribution: You're like 10% of the pool. Now you have to assume you have consequent hashing power contributed to another pool or mining solo. This isn't impossible, but limited to a few individuals with stellar hashing power. Who's walking around with 30~40 Gh/s and pool mining hmm? Besides Gusti, I can't name anyone. At this point, holding out on every full difficulty solution you found long enough for you to move all your hashing power on slush's pool (there are no other who realistically suffers from this attack) is a huge risk. It'll take certainly more than a minute, there are several mining rigs that need to be reset for the purpose of the exploit.

The attack can be used against proportional pools too, albeit less effectively. Why would a mining rig need to be reset? It just needs to switch to a different pool which I think takes about a second.

What you are risking here, technically, is to try and increase your payout on a few blocks, at the risk of losing your original payout if a pool finds the solution you are withholding, all this considering you need to move all your hashing power to slush's pool and let it beef up your reward to a seizable profit under 10 minutes (If no one beats you to it under 10 minutes. Given the way the network is built, this is more than likely)

If you ask me, it is not only tedious, but has low chance of success, and a high risk of losing your "fair" reward.

Compared to not doing this cheat, you only risk losing the reward for the single winning share, which is negligible. All the other shares you submit in the ambush are rewarded normally.

Also any user with a big contribution can be easily monitored by the pool owner. If you see his reported hashing speed double up once a while a few minutes before a block is completed, it'll speak for itself.

Who's "his"? The cheater can create several accounts and use an anonymization service to hide his IP.


Personally I don't understand why anyone would settle for "this attack will probably not be very effective and can be monitored" when they can easily have "this attack is impossible and you never have to worry about it again". However, since the answer to the title question is apparently "no", I won't pursue this further for now.

[goatpig]

I don't understand what you mean by "troll the pool".

Let me rephrase: You'll be a minor annoyance to the pool, attempting once in a long while to make the pool lose money.

Why would a mining rig need to be reset?

 I was trying to imply that the hashing power spent on solo mining with the switched portion of your mining speed would be essential "wasted". Many big miners prefer soloing to avoid pool fees. The exploit would be much more efficient if you keep your "ambush" mining power in a proportional pool while setting up, which represents another portion of steady earning (the pool fee the soloers avoid) that you would be risking.

It just needs to switch to a different pool which I think takes about a second.

On 20 or so computers? The attack is only worth it when you have a sizeable portion of the hashing power of a big pool. Consider most of those mining rigs don't even have a monitor plugged to them. To render this attack profitable would require a good amount of coding necessary to automatize the switching.

Who's "his"? The cheater can create several accounts and use an anonymization service to hide his IP.

It's quite easy for the pool operator to establish a ratio between between total shares submitted per block vs reward. Any worker used for that attack can be automatically identified and have its rewards denied.

[Meni Rosenfeld]

It just needs to switch to a different pool which I think takes about a second.

On 20 or so computers? The attack is only worth it when you have a sizeable portion of the hashing power of a big pool. Consider most of those mining rigs don't even have a monitor plugged to them. To render this attack profitable would require a good amount of coding necessary to automatize the switching.

Of course. If he's invested in 20+ computers, he can invest in coding the automation.

Who's "his"? The cheater can create several accounts and use an anonymization service to hide his IP.

It's quite easy for the pool operator to establish a ratio between between total shares submitted per block vs reward. Any worker used for that attack can be automatically identified and have its rewards denied.

Good point, though there will be false positives.
My main point is that if you make the protocol immune to such attacks, the operator doesn't need to deal with such nonsense and the participants don't risk being hurt by the countermeasures.