Quote from: sam0109 on May 21, 2011, 07:59:42 AM

Hey, so I have a few questions about cooperative mining and mining in general,
1) Would it be a good idea to create a hash-lookup table from the already generated hashes and then when a new block is released, just see if it is already in the hash table?
2) in the cooperative mining project, couldn't somebody just check the hashes to see if they match he block before they send them to the group, and thus getting bitcoins if they don't find it and the whole 50 if they do? (I know this isn't fair, but people rarely are)
3) Finally, the last graph here: http://mining.bitcoin.cz/stats/graphs/ seems to indicate that 100% of the blocks that this group attempts are found by this group. This seems odd because from what I understand about bitcoin mining, which is not very much, this is very improbable. Am I reading the graph incorrectly, have the blocks that were solved by others been edited out of the data, or am I making some other silly mistake?

Thank you in advance for you replies

Let me address you first question. While a rainbow table it technically possible it appears to be practically unattainable as of now. The reason for this is the current block being hashed has multiple inputs. The first input is the hash of the previous block, which is why it is referred to as the block chain. The second is the input of the new transactions waiting for confirmation (simplified I know). The third is a random set of data. What this means is that in order for a rainbow table to be created you have to create a resultant set of data comprising all possible inputs and the table would have to be extremely large. It is the addition of the random data that makes the table so large. See http://en.wikipedia.org/wiki/Salt_(cryptography). While the generation of these tables isn't out of reach for a "No Such Agency" governmental organization. It is practically impossible for mining operators. Bottom line, you could potentially create a master rainbow table covering all of the possible hashes but it would be 1.06x10¹⁸³ bytes in size.

Question number 2. No because the next block's hash uses the current hash as an input. Therefore you haven't hashed it before.

On the last question. Please see the wikipedia link that slush provided in order to understand what the CDF data means.