<p>A 6 sided die rolled 99 times gives <code>6^99 = 1.088864372500119e77</code> possible combinations. This is almost exactly the same key space of a 256 bit private key (roughly 2^256), in other words, without knowing how many digits you changed, it is impossible.</p>

<p>Let's see, if my math is correct, I believe if you changed 1 digit, then you have to try each number 6 times, or 99 x 6 = 594 tries. If you changed 2 digits, then you have to try 594^2 = 352836. If you changed 3, 594^3 = 209584584. That is much more doable and will have less to do with what language you use, and more to do with how you implement it. You can generate the private key, and then the public key and encode it to see if the address matches (assuming you still have the address).</p>

CC BY-SA 4.0
2019-08-15T14:12:30.817Z
Assuming I only changed 3 digits and using Python, checking 209584584 different keys will take 242 days running 24/7.  Any idea how much faster it would be to check in  pure C code (compiled language)?  Trying to understand if its worth it to learn enough C to get a tester written in C.
BitGaffe
CC BY-SA 4.0
2019-08-15T19:57:56.600Z
The page at https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html suggests anything from 0.52% of the time (1.27 days) to 54% (131 days). Perhaps more valuable is discovering early that it wasn't only 3 digits.
Alistair Mann
CC BY-SA 4.0
2019-08-15T02:11:04.437Z
2019-08-15T02:11:04.437Z
JBaczuk
<p>Your best bet would be to implement GPU to generate the private key.</p>

<p>There are tools like vanitygen on Gihub where you can generate keys using OpenCL libs and GPU or simply use btcrecover tool (might need modification in your case)</p>

<p>The Vanitygen github is here: <a href="https://github.com/samr7/vanitygen" rel="nofollow noreferrer">https://github.com/samr7/vanitygen</a>
BTC recover Github is here: <a href="https://github.com/gurnec/btcrecover" rel="nofollow noreferrer">https://github.com/gurnec/btcrecover</a>
Good luck!
/KX</p>

CC BY-SA 4.0
2019-08-15T22:56:57.430Z
2019-08-15T22:56:57.430Z
KeychainX
<p>So a few years ago I created a private key by rolling dice.  Following the instructions from bitaddress.org, I rolled a dice 99 times and entered the string into the bitaddress.org.  Rather than storing the private key in WIF or HEX, I wrote the 99 digit string of dices rolls.  However, I changed some of the dice rolls to obfuscate the true private key if someone else stumbled upon the 99 digit numbers.  Now I can't remember which digit(s) I changed.  </p>

<p>Using Python libraries, I've been trying different combinations/permutations of the 99 digit number.  Stuff like what if I swapped two positions or straight replacement of one or two digits.  No luck.  </p>

<p>Any ideas?  How fast can I create keys and check if my key matches my bitcoin address?  Python libraries that I have found let me check about 10 permutations a second.  How much faster can I do with C?</p>

<private-key><lost-bitcoins>
Recovering a Bitcoin Key Made From Rolling Dice
BitGaffe
# Recovering a Bitcoin Key Made From Rolling Dice

(Asked by: username_0 on 2019-08-14)

So a few years ago I created a private key by rolling dice. Following the instructions from bitaddress.org, I rolled a dice 99 times and entered the string into the bitaddress.org. Rather than storing the private key in WIF or HEX, I wrote the 99 digit string of dices rolls. However, I changed some of the dice rolls to obfuscate the true private key if someone else stumbled upon the 99 digit numbers. Now I can't remember which digit(s) I changed.

Using Python libraries, I've been trying different combinations/permutations of the 99 digit number. Stuff like what if I swapped two positions or straight replacement of one or two digits. No luck.

Any ideas? How fast can I create keys and check if my key matches my bitcoin address? Python libraries that I have found let me check about 10 permutations a second. How much faster can I do with C?

**Tags:** private-key, lost-bitcoins


---

## 2 answers

### Answer by username_1 on 2019-08-15. Score: 1

A 6 sided die rolled 99 times gives `6^99 = 1.088864372500119e77` possible combinations. This is almost exactly the same key space of a 256 bit private key (roughly 2^256), in other words, without knowing how many digits you changed, it is impossible.

Let's see, if my math is correct, I believe if you changed 1 digit, then you have to try each number 6 times, or 99 x 6 = 594 tries. If you changed 2 digits, then you have to try 594^2 = 352836. If you changed 3, 594^3 = 209584584. That is much more doable and will have less to do with what language you use, and more to do with how you implement it. You can generate the private key, and then the public key and encode it to see if the address matches (assuming you still have the address).

> **Comments:**
> **username_0**: Assuming I only changed 3 digits and using Python, checking 209584584 different keys will take 242 days running 24/7.  Any idea how much faster it would be to check in  pure C code (compiled language)?  Trying to understand if its worth it to learn enough C to get a tester written in C.  
> **username_2**: The page at https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html suggests anything from 0.52% of the time (1.27 days) to 54% (131 days). Perhaps more valuable is discovering early that it wasn't only 3 digits.  

---

### Answer by username_3 on 2019-08-15. Score: 0

Your best bet would be to implement GPU to generate the private key.

There are tools like vanitygen on Gihub where you can generate keys using OpenCL libs and GPU or simply use btcrecover tool (might need modification in your case)

The Vanitygen github is here: <https://github.com/samr7/vanitygen>
BTC recover Github is here: <https://github.com/gurnec/btcrecover>
Good luck!
/KX


---

