are there speed-differences between Pools?

[deepceleron]

problem with pps pools is it costs nothing for the blockfinder to withhold his block(besides having to wait longer to get paid).  I haven't heard of that happening but it's possible.

I think you're talking about SMPPS which is completely different from PPS. And no, that's not the main problem with either.

A share withholding attack is used against a PPS pool. If I modify my miner to send difficulty 1 shares to the pool, but not to send full difficulty block solutions, I still get paid the same amount per submitted share. Assume now that I and my fellow attackers are 50% of the pool's hashrate: the pool is earning 50% less in block generations than expected for the number of submitted shares, but still paying the same calculated rate per share, which will put them into financial losses quickly. The attack motive is purely lulz, or to bankrupt a competitor. This is hard to defend against; you can't just go banning miners that have never found a block, many have made over 400BTC pool mining but never found a block themselves. With PPLNS however, miners will be denying themselves earnings by not submitting the winning share they found, so it is not a realistic attack vector.

To address the original post, the factors that are the pool equivalent of "speed" in that they affecting earnings:
1. Efficiency/stale share rate
2. Uptime/responsiveness
3. Fees
4. Payment system (must not be proportional or "hoppable" system where earnings are reduced for other miners by bad actors)

[DeathAndTaxes]

A share withholding attack is used against a PPS pool. If modify my miner to send difficulty 1 shares to the pool, but not send full difficulty block solutions, I still get paid the same amount per submitted share. Assume now that I and my fellow attackers are 50% of the pool's hashrate: the pool is earning 50% less in block generations than expected for the number of submitted shares, but still paying the same calculated rate per share, which will put them into financial losses quickly. The attack motive is purely lulz, or to bankrupt a competitor. This is hard to defend against; you can't just go banning miners that have never found a block, many have made over 400BTC pool mining but never found a block themselves. With PPLNS however, miners will be denying themselves earnings by not submitting the winning share they found, so it is not a realistic attack vector.

A block finder's fee is best way to solve issue of share withholding (give 1% to 10% of block value to the miner who finds it).  It can be combined with a validation check.  When a block is found, randomly send that data is a subset of the pool (don't do entire pool otherwise that is detectable).  It payments are delayed 120 blocks this means that an attacker would need to detected and properly respond to multiple validation attempts.

To improve moral any cheaters funds are seized and distributed to the rest of the pool members.  If pool takes no cut in this compensation honest miners may even see it as a benefit.

[Meni Rosenfeld]

A block finder's fee is best way to solve issue of share withholding (give 1% to 10% of block value to the miner who finds it).

This is a terrible way. It greatly increases the reward variance for miners thus defeating the purpose of the pool. An attacker who is bent on destroying a pool will not be fazed by a 1% reduction.

The best way to solve block withholding is oblivious shares.

It can be combined with a validation check.  When a block is found, randomly send that data is a subset of the pool (don't do entire pool otherwise that is detectable).

This can work but it's sort of a band-aid solution, there are many potential problems.

It payments are delayed 120 blocks this means that an attacker would need to detected and properly respond to multiple validation attempts.

The payments are delayed, but broadcasting the block to the network is not.

[DeathAndTaxes]

This is a terrible way. It greatly increases the reward variance for miners thus defeating the purpose of the pool. An attacker who is bent on destroying a pool will not be fazed by a 1% reduction.

It wouldn't greatly increase the reward variance.  Even w/ 10% finder's fee only 10% of the reward is subject to variance.  What is your definition of "greatly"?

The best way to solve block withholding is oblivious shares.

Care to explain how that can be accomplished?

It payments are delayed 120 blocks this means that an attacker would need to detected and properly respond to multiple validation attempts.

The payments are delayed, but broadcasting the block to the network is not.

Of course a pool could delay broadcasting their own block by a fraction of a second.  Long enough to send out the validation check for blocks they solve.  This is the simplest but only allows a pool to check their own blocks.  If pools were concerned enough they could even privately share block solutions prior to public broadcasting.  

1) Pool X solves a block (x)
2) It broadcasts this to pools it shares data with (either for a fee or for as a "common defense" approach)
3) Pool A, B, C send data for block x to some % of their pool members (who at this point are unaware that block x is a known solution)
4) Pool X broadcasts block x to the public network a second later.
5) Miners which fail to solve block x are flagged.  Enough flags results in confiscation.

Not saying it is necessary.  Obviously there is an opportunity cost.  If the cost due to block withholding fraud is low (say 0.5% of gross revenue) then it wouldn't make sense paying 2% of gross revenue to defeat it.   Just as the proof of work doesn't prevent a 51% attack it simply makes it uneconomical a combination of a finder fee and block verification can make any such attack uneconomical.  The point of mentioning the 120 block window is to indicate a pool has multiple chances to catch an attacker and thus multiple chances to seize all funds (resulting in a 100% economic loss for the attacker).

[Meni Rosenfeld]

This is a terrible way. It greatly increases the reward variance for miners thus defeating the purpose of the pool. An attacker who is bent on destroying a pool will not be fazed by a 1% reduction.

It wouldn't greatly increase the reward variance.  Even w/ 10% finder's fee only 10% of the reward is subject to variance.  What is your definition of "greatly"?

If 10% of the reward is subject to full solo variance, it means the total variance is about (10%)^2 = 1% of solo variance, which is a lot. Let's say you have 500 MH/s, then it will be like mining for a normal pool with 50 GH/s. If you've mined in such a pool lately you know that its variance leaves a lot to be desired, especially for someone who went with PPS because he wants no variance.

The best way to solve block withholding is oblivious shares.

Care to explain how that can be accomplished?

With the protocol modification I proposed here. This is also discussed in subsection "6.2.3 Proposed solution - Oblivious shares" of AoBPMRS.

[DeathAndTaxes]

With the protocol modification I proposed here. This is also discussed in subsection "6.2.3 Proposed solution - Oblivious shares" of AoBPMRS.

Interesting.  Also I don't envy you.  I got frustrated wading through those pages of false claims, long since debunked myths and poor logic (rigs don't have monitors so changing pools would be difficult?  I guess they never heard of pool hopping ).

I had always know about the witholding attack.  Never considered the "lie in wait".  One thing I am confused about if I read right you said it would be best to attempt this on a large pool?  Wouldn't it be best to attempt it on a small pool.  Point a fraction of hashing power at a pool.  When you get the share point all the rest of your hashing power at the pool (should be a sizeable multiple).  Given you have a small window the smaller the pool relative to your hashing power the more shares (and a % of pool) you can pump in.  Right?

[Graet]

if you "lie in wait" until after a longpoll you have a stale share - useless

small pools larger variance...long round , more longpolls between block finds

big pools quicker rounds less longpolls between blockfinds

[DeathAndTaxes]

if you "lie in wait" until after a longpoll you have a stale share - useless

small pools larger variance...long round , more longpolls between block finds

big pools quicker rounds less longpolls between blockfinds

Huh?  You are only withholding YOUR found block which occurs at the same rate regardless of the pool's relative size.  Yes if you hold a share too long it will go stale but the same event which causes it to go stale in a small pool will cause it to go stale in all pools.

The goal if I am understanding this correctly would be to
1) mine at a pool using a fraction of total hashing power
2) find a share (thus this pool will payout and any share you add that increases your % of payout is a net +)
3) direct all hashing power to that pool.
4) withhold the share for some period of time.*
5) increase the number of shares as a % of the pool share count to get a bigger cut of the reward then submit share.

* Yes in step #4 there is a risk of losing everything.  The risk of your share going stale is ~1.6% every 10 seconds.  Thus to be profitable you would need to increase your reward by >1.6% (relative to fair mining) in 10 seconds.  

So the question becomes is it easier to do that in a small pool, a large pool, or the size of the pool doesn't matter.

While a large pool has a shorter round (in time) it has the same length round (in shares).  

[Meni Rosenfeld]

So the question becomes is it easier to do that in a small pool, a large pool, or the size of the pool doesn't matter.

This is kind of moot because optimally you do it with as many pools as possible. You distribute your hashing power among all available pools, and whenever you find a block in one you direct all hashrate to it. In AoBPMRS I only analyzed the case that all pools have the same hashrate, but I have reasons to believe that you need to distribute your hashrate in proportion to each pool's size.