short answer too, that will take the exact opposite stance as @nicolas-massart ;)
in the long run you'll be always better off mining solo, ever because you get uncles and pay no fees
pool mining reduces your variance, period.
this reddit post is quite interesting, it's basically @vitalik-buterin asking as to why people mine in pools.
It's not true for all pools but most of them don't pay you uncles : that substracts to your gains.
It's almost true for all pools, there is a fee that substracts to your gains too
To recap, your mining pool will respond to the eth_getWork call with the following information:
DATA, 32 Bytes - current block header pow-hash
DATA, 32 Bytes - the seed hash used for the DAG.
DATA, 32 Bytes - the boundary condition ("target"), 2^256 / difficulty.
This information will be used to generate the DAG.
From here on I've referenced the Yellow Paper, rather than the Ethash wiki page. From the Yellow Paper, we can confirm the basis for your query:
J.3. Dataset generation. In order the generate the dataset we need the
cache c, which is an array of bytes. It depends on the cache size
csize and the seed hash s ∈ B32.
And:
J.2. Size of dataset and cache. The size for Ethash’s cache c ∈ B and
dataset d ∈ B depend on the epoch, which in turn depends on the block
number.
From section J.2. of the Yellow Paper you'll see that the size of the cache is constant for all mining performed during a given epoch, where an epoch is defined as 30,000 blocks (~100 hours). You therefore don't need to know the block number to calculate the cache size, only the current epoch number. The same holds true for the size of the DAG itself, which is also dependent on the current epoch number.
So... How do we locally find the epoch number?
We're told the seed hash by eth_getWork, but we can't reverse the hash to get the block number from which it was created. So we use trial and error. Starting with a block we know to be in epoch 0 - because we know epoch 0 is from block 0 to block 30,000 - we locally create a seed hash and check whether it matches the seed hash we've been sent.
An example in the code is as follows.
- A call to
getWork is made in MinerAux.h, and the 3 variables, including the seed hash, is returned
EthashAux::full() is called, and the seed hash from getWork is passed in- The action jumps to
EthashAux.cpp, where the main functions are defined
- In
EthashAux::full() we call EthashAux::computeFull(), again passing through the seed hash
- Here we calculate the (approximate) block number using
blockNumber = EthashAux::number(_seedHash)
The pertinent part of EthashAux::number() is the following line:
for (h256 h; h != _seedHash && epoch < 2048; ++epoch, h = sha3(h), get()->m_epochs[h] = epoch) {}
... which loops through epoch numbers, hashes to create a seed hash, and checks it against the hash sent by getWork.
The function then returns an approximate block number: return epoch * ETHASH_EPOCH_LENGTH;.
We then later use this value to calculate the cache size, which in turn can be used in generating the cache.
Edit - Addendum:
Parity - the client written by Ethcore - does include the block number in its implementation of eth_getWork.
Best Answer
In general, miners tend to prioritize transactions that pay the highest fees first, with many having a minimum gas price that they will accept. Pools that include fewer transactions in their blocks probably have a higher minimum accepted fee.
Pools that mine empty blocks often do so to avoid the overhead of having to process transactions at all--they can simply stamp out the next block header and begin mining immediately.
Some pools will adopt a hybrid approach: immediately after solving a block, they will begin mining the next block without transactions while validating and deciding which transactions to include. This allows them to avoid underutilizing miners while computing the next block's headers with transactions included, on the off chance they immediately solve the next block within that window (rare, but possible).