Pooled mining

Pooled mining is an approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. Pooled mining effectively reduces the granularity of the block generation reward, spreading it out more smoothly over time.

Introduction

With increasing generation difficulty, mining with lower-performance devices can take a very long time before block generation, on average. For example, with a mining speed of 1000 Khps, at a difficulty of 14484 (which was in effect at the end of December, 2010), the average time to generate a block is almost 2 years.

To provide a more smooth incentive to lower-performance miners, several pooled miners, using different approaches, have been created. With a mining pool, a lot of different people contribute to generating a block, and the reward is then split among them according to their processing contribution. This way, instead of waiting for years to generate 50btc in a block, a smaller miner may get a fraction of a bitcoin on a more regular basis.

Pooled mining approaches

The problem with pooled mining is that steps must be taken to prevent cheating by the clients and the server. Currently there are two different approaches used.

The slush approach

slush's pooled miner sets an artificially low mining difficulty, and collects generated blocks at the lower difficulty from the miners as "shares" in a block generation. eventually, one of the generated blocks also happens to match the actual network difficulty, and then the 50 btc reward is distributed among the pooled clients, based on how many shares have been contributed by each. Client cheating is prevented, since in order to generate a lower-difficulty block, actual hashing must occur. It is not possible for a client to merely 'claim' that he has mined. Further, a client cannot benefit by withholding any block that actually generates the reward, since the private key necessary to redeem the reward is stored on the server, and is not accessible by the client.

Server cheating, by way of the pool operator fraudulently granting himself extra 'shares', is not addressed. Thus the clients have to trust the pool operator to fairly distribute the proceeds.

The puddinpop approach

Another approach is the 'metahash' technique, used by puddinpop's miner. Clients generate hashes, and also submit 'metahashes', which are hashes of a large chunk of generated hashes. The server checks that the metahashes are correct (in a round-robin fashion, picking up a metahash from a client that hasn't been checked on the longest), thus preventing clients from simply claiming that they have done work without actually doing the work. The withholding of good blocks by the clients is prevented via the server being in possession of the private key, just as in the previous approach. Rewards are distributed based on the number of metahashes submitted by the clients.

Cheating by the server, by way of the pool operator fraudulently granting himself extra shares, is also not addressed, requiring the clients to trust the operator.

Comparison

The slush approach uses a lot fewer resources on the pool server, since rather than continuously checking metahashes, all that has to be checked is the validity of submitted shares. The number of shares sent can be adjusted by adjusting the artificial difficulty level.

Further, the slush approach allows the clients to use existing miners without any modification, while the puddinpop approach requires the custom pool miner.