|
Title: Perhaps pool's vulnerability? Post by: mikefdm on May 19, 2013, 08:14:13 AM Let our miner working with difficulty X.
Let's create another dummy miner with difficulty 2 * X. Let the first miner sends shares as usual, except for those that are appropriate for the second miner. In this case, we will send shares from the second miner. If we calculate total confirmed mining speed, it will be 1.5 times higher. In general, if the number of miners is equal to N, then the expectation of the speed will be (N + 1) / 2 times higher. I know that this can be fixed simply, just by checking "nonce belongs to work". The question is whether the pools are not doing such checking? Title: Re: Perhaps pool's vulnerability? Post by: -ck on May 19, 2013, 08:16:41 AM They are
Title: Re: Perhaps pool's vulnerability? Post by: techwtf on May 19, 2013, 08:28:09 AM most pools shouldn't have this issue. if different connection have different extranonce1 and only one (connection, worker, diff) => extranonce1 combination is allowed.
Title: Re: Perhaps pool's vulnerability? Post by: eleuthria on May 19, 2013, 03:28:17 PM Stratum should be immune to this unless the pool is attempting to let two workers run at different difficulties over a single connection. By default, Stratum defines difficulty per-connection, along with a unique extranonce per connection. This would make it impossible to shift shares between different difficulty workers unless the pool is doing something very stupid.
Getwork is the only method I believe *could* have this flaw by default, however I think there are only a handful of pools which offer multiple difficulties over getwork. Similar to the Stratum situation, all the pool would have to do is add a number to the coinbase to represent the difficulty the work is supposed to meet. |