<p>It's at best irrelevant to the search, cranking up the re-key interval too high will end up reducing your performance rather than increasing it. There would really be no problem choosing a single seed for each thread and just incrementing for all eternity just due to the sheer number of possible private keys. No particular area of the key space will get you better results due to the output being passed through ECDSA and two chained hash functions.  </p>

<p>The main time you would worry about re-keying while doing a brute force search is if you were making multiple keys, as in that case revealing one (intentionally or accidentally) indirectly reveals the others. With one key in hand and the knowledge that you simply incremented from it a third party could just roll forwards until they hit other ones you would have made as well. </p>

CC BY-SA 3.0
2015-07-11T16:39:15.107Z
So does that mean lowering that value to the key search rate equals a new seed every second? If so, is that any good? Thanks so much
btw im looking for multiple keys
happyvirus
CC BY-SA 3.0
2015-07-11T17:45:29.280Z
I'm not that familiar with vanitygen, so I can't say for sure if modifying that would be safe or not in that context. Generally speaking the software hasn't had much further development partly due to it being seen as encouraging address reuse, which isn't great.
Claris
CC BY-SA 3.0
2015-07-11T16:24:44.027Z
2015-07-11T16:24:44.027Z
Claris
<p>The file 'vanitygen.c' has a constant "BN_ULONG rekey_max". I suppose it denotes the value until which vanitygen keeps using the same RNG seed?</p>

<p>If the value is lowered to about, say 100K, will it affect the quality of particular prefix searches? What is the best optimal value to tune it up?</p>

<bitcoind><vanitygen>
Vanitygen Rekey_max
happyvirus
# Vanitygen Rekey_max

(Asked by: username_0 on 2015-07-11)

The file 'vanitygen.c' has a constant "BN\_ULONG rekey\_max". I suppose it denotes the value until which vanitygen keeps using the same RNG seed?

If the value is lowered to about, say 100K, will it affect the quality of particular prefix searches? What is the best optimal value to tune it up?

**Tags:** bitcoind, vanitygen


---

## 1 answers

### Answer by username_1 on 2015-07-11. Score: 0 | Accepted answer

It's at best irrelevant to the search, cranking up the re-key interval too high will end up reducing your performance rather than increasing it. There would really be no problem choosing a single seed for each thread and just incrementing for all eternity just due to the sheer number of possible private keys. No particular area of the key space will get you better results due to the output being passed through ECDSA and two chained hash functions.

The main time you would worry about re-keying while doing a brute force search is if you were making multiple keys, as in that case revealing one (intentionally or accidentally) indirectly reveals the others. With one key in hand and the knowledge that you simply incremented from it a third party could just roll forwards until they hit other ones you would have made as well.

> **Comments:**
> **username_0**: So does that mean lowering that value to the key search rate equals a new seed every second? If so, is that any good? Thanks so much btw im looking for multiple keys  
> **username_1**: I'm not that familiar with vanitygen, so I can't say for sure if modifying that would be safe or not in that context. Generally speaking the software hasn't had much further development partly due to it being seen as encouraging address reuse, which isn't great.  

---

