Bitcoin Forum
December 03, 2016, 10:02:38 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Do we want oblivious mining pool shares?  (Read 7103 times)
goatpig
Legendary
*
Online Online

Activity: 1316

Armory Developer


View Profile
April 28, 2011, 08:13:44 PM
 #21

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

Quote
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?

btcarmory.com
1480802558
Hero Member
*
Offline Offline

Posts: 1480802558

View Profile Personal Message (Offline)

Ignore
1480802558
Reply with quote  #2

1480802558
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480802558
Hero Member
*
Offline Offline

Posts: 1480802558

View Profile Personal Message (Offline)

Ignore
1480802558
Reply with quote  #2

1480802558
Report to moderator
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
April 28, 2011, 08:40:05 PM
 #22

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
goatpig
Legendary
*
Online Online

Activity: 1316

Armory Developer


View Profile
April 28, 2011, 10:00:59 PM
 #23

Quote
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?

btcarmory.com
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
April 29, 2011, 12:23:06 AM
 #24

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

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
anisoptera
Member
**
Offline Offline

Activity: 98



View Profile
April 29, 2011, 01:36:55 AM
 #25

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.

online poker, bitcoin style - https://betco.in/
feeling tipsy? 1Q7ktWPwu4Q8MivKdmYxnmsGaBeauMTGwU
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
April 29, 2011, 01:57:12 AM
 #26

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.

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
anisoptera
Member
**
Offline Offline

Activity: 98



View Profile
April 29, 2011, 03:16:24 AM
 #27

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

online poker, bitcoin style - https://betco.in/
feeling tipsy? 1Q7ktWPwu4Q8MivKdmYxnmsGaBeauMTGwU
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
April 29, 2011, 05:25:03 AM
 #28

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

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
June 20, 2011, 06:53:14 PM
 #29

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
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 20, 2011, 07:22:44 PM
 #30

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!