Topic: Do we want oblivious mining pool shares? (Read 7806 times)

This thread is about oblivious shares, and discussion of lie-in-wait is only on topic insofar as it refines the understanding of oblivious shares. Discussion of best ways to perform it belong elsewhere.

this is perfect for multipool, since you can tell all the miners in multipool to switch to slush while holding the winning share for 9 minutes thus making every miner score high

Right, but what the miners are calculating are real hashes that will later be recognized by the network. If a pool decided to implement their own scheme the resulting blocks will not be accepted by the network. If, with the current protocol, there is some way for pool miners to work on something other than the final hash while still knowing if their hash is a share, it means the hashing function is broken.

Focus your energies on implementing exploits that are possible .

That was tongue-in-cheek, but I do think it's beneficial for Bitcoin (and pooled mining in particular) if people develop proof-of-concept exploits of suspected vulnerabilities, of course while being open about their intentions.

Oh. Neat. Well then. Glad I didn't try!

IT'S NOT POSSIBLE!

I've thought of this exploit myself, but never really had the desire to try and implement it. This is definitely an exploit with the current system.

I believe that currently, pools defend against this by sometimes sending a piece of work to their clients that they already know contains a winning hash. If they don't get it back, they will ban the client.

the work that you receive from pools only works for pool. If you try to claim it, the reward will go to the pool owner, not you, because which address to pay to is embedded in the getwork from the pool.

Ok, I've reread this part.

I like the idea but it doesn't seem to me there is a need to modify the protocol for the operator to produce B and send it over. Afaik, pool miners aren't directly part of the Bitcoin network, their connection and their work is with the pool only, so only that part could be modified. Also, what is to stop a miner with the actual system from finding a full difficulty solution and modifying his miner to submit this result as a soloer. Wouldn't that kind of exploit be much more devastating and feasible?

Fair enough. Figuring out if there are downsides to oblivious shares was the purpose of this thread, but I don't really believe they are any.

"Oblivious shares" means that a participant can't know if his shares are winning. I think what you're really asking is if my suggested protocol change achieves oblivious shares. And I say yes, because in the notation of my outline, the attacker doesn't know A which is required to find C which needs to be valid. He only knows B which is a public commitment to a specific value A. Only the operator knows A and can use it to assemble a valid block, when given the right share.

I understand your concern. Mine is that I'd rather any attack that is not directly related to the Bitcoin protocol to be first realistically evaluated by those targeted, and a proper attempt at countering it delivered. Only if the counter fails should there be a discussion about integrating solutions directly to the project code. I think also this threads lacks discussion about the downside of implementing oblivious shares, to which I have sadly nothing to contribute.

Lastly, I wonder if oblivious shares would be the hard counter to your exploit. I don't understand how it would prevent the attacker from verifying his own produced shares against the target block on his own. Or would that cost him too much hashing speed?

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

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.

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


 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.


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.


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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.