user4783: Running a miner node, one would have to verify transactions. This includes checking all the inputs of all the transactions.
Does this mean that a miner must hold all the block-chain in memory (currently about 8.7 GB)? If not, how can a miner find previous transaction (a transaction input does not have an indication to the block containing it)?

user2306: You can search through a file on disk, it's just slower. However, whether it's in memory or on disk isn't as important as whether it's indexed. There is a list of transaction id's (aka: txid) and their corresponding block numbers, called the unspent transaction output database. It's not in the blockchain because it doesn't need to be - every node can come up with it individually.
The reason why transaction inputs don't have the block that contained them is that there might be a block reorganization, putting transactions in different blocks, and you want other transactions that depend on those to still be valid.
The downside of indexes is that they take up space. This is one of those space-vs-time tradeoffs you have to make.

user208: No, miners do not need the entire block chain to be accessible. Technically, they don't even need it at all. The blocks themself are only needed for rescanning wallets, reorganisations, and serving blocks to other nodes. That is why pruning them away will likely become viable in the future.
What you need for validating blocks and transactions (a fundamental demand from miners), is the database of unspent transaction outputs. 0.8+ clients maintain this database explicitly in a compact form (around 200 MB now, as of May 2013).
In addition to that, a miner needs to maintain a memory pool: a set of transactions that are validated against the current best chain, to choose transactions for the next candidate block from.

4783: <p>Running a miner node, one would have to verify transactions. This includes checking all the inputs of all the transactions.</p>

<p>Does this mean that a miner must hold all the block-chain in memory (currently about 8.7 GB)? If not, how can a miner find previous transaction (a transaction input does not have an indication to the block containing it)?</p>
 2306: <p>You can search through a file on disk, it's just slower. However, whether it's in memory or on disk isn't as important as whether it's indexed. There is a list of transaction id's (aka: txid) and their corresponding block numbers, called the <em>unspent transaction output database</em>. It's not in the blockchain because it doesn't need to be - every node can come up with it individually.</p>

<p>The reason why transaction inputs don't have the block that contained them is that there might be a block reorganization, putting transactions in different blocks, and you want other transactions that depend on those to still be valid.</p>

<p>The downside of indexes is that they take up space. This is one of those space-vs-time tradeoffs you have to make.</p>
 208: <p>No, miners do not need the entire block chain to be accessible. Technically, they don't even need it at all. The blocks themself are only needed for rescanning wallets, reorganisations, and serving blocks to other nodes. That is why pruning them away will likely become viable in the future.</p>

<p>What you need for validating blocks and transactions (a fundamental demand from miners), is the database of unspent transaction outputs. 0.8+ clients maintain this database explicitly in a compact form (around 200 MB now, as of May 2013).</p>

<p>In addition to that, a miner needs to maintain a memory pool: a set of transactions that are validated against the current best chain, to choose transactions for the next candidate block from.</p>
