You are right that the Bitcoin hashing process is essentially finding an input (a block header) that makes the resulting hash have a certain output.
Rainbow tables in theory help for that, but under some conditions:
- They don't reduce computation time (you still have to calculate all hashes of all inputs), but allow the resulting table to be stored in a relatively compact form
- As a result, the input space has to be small
- The wanted output has to be fixed
- They are only useful for doing several hash lookups
However, in our case, the input is 80 bytes of block header data (=640 bits), which is humongous. Typically, rainbow tables are used on input sets no larger than 50-60 bits. Of course, significant parts of this block header are fixed, but many are not actually known in advance (merkle root, time stamp, previous block hash), so restricting those would mean the rainbow table can only be computed at the time the block is being constructed when the block is being constructed. At that point, there is no need for a rainbow table anymore, as we're only interested in finding one hash.
Secondly, the resulting hash isn't fixed - there is only a required generic property: it has to be low enough. Starting to search in a rainbow table with the set of all low-enough hashes would be completely infeasible.
So: no
