Вы правы, что процесс хеширования Биткойна, по существу, находя вход (а заголовок блока), что делает полученный хэш имеет определенный выход.

Радужные таблицы в теории помощи для этого, но при определенных условиях:

• Они не уменьшают время вычисления (вам все равно придется рассчитать все хэши всех входов), но позволяют результирующая таблица будет храниться в относительно компактной форме
• В результате, входное пространство должно быть небольшим
• Разыскиваемый выход должен быть зафиксирован
• Они полезны только для выполнения нескольких хэш-запросов

Тем не менее, в нашем случае, вход 80 байт данных заголовка блока (= 640 бит), который огромен. Как правило, радуги таблицы, используемые на входе не устанавливает не больше, чем 50-60 бит. Конечно, значительная часть этого заголовка блока фиксируется, но многие из них на самом деле не известны заранее (Merkle корня, штамп времени, предыдущий блок хэш), поэтому ограничения тех будут означать таблицу радуги можно вычислить только в момент блок строится, когда блок строится. В этот момент, нет никакой необходимости в таблице радуги больше, так как мы заинтересованы только в поиске один хэш.

Во-вторых, полученный хэш не фиксирована - есть только требуется общее свойство: она должна быть достаточно низкой. Начиная искать в таблице радуги с набором всех низко достаточно хэш будет полностью неосуществимым.

Итак: нет