<p>Rainbow tables are a lookup table, not an inherent speedup. In order to construct a rainbow table, someone has to - at one point - actually go through all possible keys to construct the table. Once the table is constructed, lookups are relatively fast, but it is all conditioned on that table being built in the first place.</p>
<p>Going over all possible keys (in order to build a rainbow table, or whatever other reason) is <em>completely</em> infeasible. The size of the keys is many orders of magnitude larger than typical password dictionaries.</p>
<p>Rainbow tables are just not a feasible approach for attacking Bitcoin keys.</p>

CC BY-SA 4.0
2023-04-22T13:10:01.767Z
Is this applicable to bitcoin seeds as well? They are both 128 or 256 bits strings so I assume so.
Martel
CC BY-SA 4.0
2023-04-22T12:42:47.100Z
2023-04-22T12:42:47.100Z
Pieter Wuille
<p>How are bitcoin seeds protected from rainbow tables attacks in the long term? Can't them started to be generated now and have some valid ones in 10 or 20 years?</p>
<p>If so, does the (what I think is) slowness of the wallet recovery process act as a security barrier? Let me explain:</p>
<p>If I have understood <a href="https://bitcoin.stackexchange.com/questions/85292/how-does-a-wallet-rebuild-itself-from-its-seed">this explanation about how a wallet recovery works</a>, the process involves to:</p>
<ol>
<li>Download the whole blockchain.</li>
<li>Generate a public key from the seed.</li>
<li>Hash it since it's possibly a p2pkh.</li>
<li>Iterate over the whole blockchain gathering all transactions whose recipient is the key in (3)</li>
<li>Repeat from (2) until 'n' (in a row) of these public key hashes (addresses) don't exist in blockchain, being 'n' the gap.</li>
</ol>
<p>That seems a long process, at least from the point of view of a rainbow tables attacker. Is this correct?</p>

<wallet><wallet-recovery><mnemonic-seed>
Does the time that it takes to recover a wallet by its seed protect the blockchain from rainbow tables attack on its seeds?
Martel
# Does the time that it takes to recover a wallet by its seed protect the blockchain from rainbow tables attack on its seeds?

(Asked by: username_0 on 2023-04-22)

How are bitcoin seeds protected from rainbow tables attacks in the long term? Can't them started to be generated now and have some valid ones in 10 or 20 years?

If so, does the (what I think is) slowness of the wallet recovery process act as a security barrier? Let me explain:

If I have understood [this explanation about how a wallet recovery works](https://bitcoin.stackexchange.com/questions/85292/how-does-a-wallet-rebuild-itself-from-its-seed), the process involves to:

1. Download the whole blockchain.
2. Generate a public key from the seed.
3. Hash it since it's possibly a p2pkh.
4. Iterate over the whole blockchain gathering all transactions whose recipient is the key in (3)
5. Repeat from (2) until 'n' (in a row) of these public key hashes (addresses) don't exist in blockchain, being 'n' the gap.

That seems a long process, at least from the point of view of a rainbow tables attacker. Is this correct?

**Tags:** wallet, wallet-recovery, mnemonic-seed


---

## 1 answers

### Answer by username_1 on 2023-04-22. Score: 2 | Accepted answer

Rainbow tables are a lookup table, not an inherent speedup. In order to construct a rainbow table, someone has to - at one point - actually go through all possible keys to construct the table. Once the table is constructed, lookups are relatively fast, but it is all conditioned on that table being built in the first place.

Going over all possible keys (in order to build a rainbow table, or whatever other reason) is *completely* infeasible. The size of the keys is many orders of magnitude larger than typical password dictionaries.

Rainbow tables are just not a feasible approach for attacking Bitcoin keys.

> **Comments:**
> **username_0**: Is this applicable to bitcoin seeds as well? They are both 128 or 256 bits strings so I assume so.  

---

