Do we want oblivious mining pool shares?

[goatpig]

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.

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?

[1715255886]

1715255886

[1715255886]

1715255886

[Meni Rosenfeld]

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.

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.

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?

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

[goatpig]

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 extra check if it satisfies the real difficulty.
For pools, the operators choose A 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.

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?

[grue]

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 extra check if it satisfies the real difficulty.
For pools, the operators choose A 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.

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?

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.

[anisoptera]

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?

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.

[grue]

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?

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.

IT'S NOT POSSIBLE!

thanks for the detailed reply. i got one question though, what is preventing a miner in a pool from not reporting a "winning" block to the server? this could easily be implemented, with a connection to bitcoind. if the block is above the target, it is submitted to the server, if it's below the target, submit it to the client, and claim the block for itself. could this attack be feasible?

That is not feasible because the block that you are solving for the pool includes the transaction that pays the 50BTC to the pool's account, not yours.

[anisoptera]

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

[Meni Rosenfeld]

Afaik, pool miners aren't directly part of the Bitcoin network, their connection and their work is with the pool only,

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.

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

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.

[iopq]

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

[Meni Rosenfeld]

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

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.